41–50 of 130 posts
I was thinking to myself as I read this: "this man has never worked somewhere long enough to be the guy who has to fix things when it breaks", and lo-and-behold, he's had 7 jobs in 8 years.
I was thinking to myself as I read this: "this man has never worked somewhere long enough to be the guy who has to fix things when it breaks", and lo-and-behold, he's had 7 jobs in 8 years.
I was thinking to myself as I read this: "this man has never worked somewhere long enough to be the guy who has to fix things when it breaks", and lo-and-behold, he's had 7 jobs in 8 years.
Please note the important caveat in the article: If the following are true: Your team is following software engineering practices that have been shown time and time again to be indicative of highly performing technology teams (think CI/CD and DevOps). This is all too often the root cause of developers being "too busy". I've had some variation of the following conversation nearly verbatim with six different teams in t…
It blew my mind that anyone at Microsoft, of all places would have this mindset.
I was thinking to myself as I read this: "this man has never worked somewhere long enough to be the guy who has to fix things when it breaks", and lo-and-behold, he's had 7 jobs in 8 years.
Please note the important caveat in the article: If the following are true: Your team is following software engineering practices that have been shown time and time again to be indicative of highly performing technology teams (think CI/CD and DevOps). This is all too often the root cause of developers being "too busy". I've had some variation of the following conversation nearly verbatim with six different teams in t…
Yes, creating automated processes would make things easier, but the time it would take to automate the process would take too much time before you have to deliver.
So everyone knows what needs to be done, everyone recognizes that it would help things, but no one can put down what they're juggling to handle it.
Sometimes it takes bringing on a person just to take on that project as its own thing to relieve the pressure on the existing team.
> as long as you are doing your work well and continuously working on the next most important thing prioritised by the business, any pressure to deliver beyond what your team is capable of is objectively unreasonable.
I feel like this is missing an acknowledgement that "what a team is capable of" actually depends on the manager! Managing people and priorities takes skills that require practice and learning. A manager that, for example, assigns people to work on things they enjoy working on and avoids excess pressure is going to have a team capable of a lot more than a team where the manager doesn't bother.
So, when I see the list of "reasonable ways for the business to exert influence over the work" I feel like a huge missing one is "help the manager manage their workload and the team better". The manager has a manager and this is ostensibly their responsibility to see and correct
One time I put together a strategy where the recommendation: "watch and wait". The idea was - there wasn't any work to do, what we had was "good enough" and flexible to be a good option no matter if the market shifts, and our job was to watch the market over the next quarter, observe, and collect insights. We were anticipating market changes, so any work done now might be worthless in 3 months.
People weren't comfortable with that at all. Clearly we should kick off some new product feature, or engage new start-ups on something innovative. We had to do something.
It reminds me of that scene from the movie Ronin when they are waiting for more information on the target:
Gregor: It would be nice to do something.
Sam: We are doing something. We're sitting here, waiting.
Please note the important caveat in the article: If the following are true: Your team is following software engineering practices that have been shown time and time again to be indicative of highly performing technology teams (think CI/CD and DevOps). This is all too often the root cause of developers being "too busy". I've had some variation of the following conversation nearly verbatim with six different teams in t…
When I started at Microsoft, this exact scenario happened. I was told I couldn’t automate things because there was no time. I did it anyway, and a 3 person job suddenly became an extremely part time job for one person. It blew my mind that anyone at Microsoft, of all places would have this mindset.
While I love this quote: > as long as you are doing your work well and continuously working on the next most important thing prioritised by the business, any pressure to deliver beyond what your team is capable of is objectively unreasonable. I feel like this is missing an acknowledgement that "what a team is capable of" actually depends on the manager! Managing people and priorities takes skills that require practic…
My experience tends to be that managers will rarely get help to manage the teams WIP and it's often left to that same manager to provide that mechanism of back-pressure. But if they then don't, for whatever reason, then it can be bad news for the team.
I'm weeks away from going on a significant period of leave and I sincerely hope that the precedents I have set carry forward during my absence.