This is brilliant. Anyone who expects a heavy paper because of the “pdf” header should take it from me: it’s 2 pages, and a really easy (and great) read.
I know that this is an old theme from me, but we’re really bad as a tribe at managing our own social status. We’re reasonably well-paid but still treated as low-status workers, with open-plan offices and the infantilizing culture of “story points” and two-week “sprints”.
You never would have guessed from all the glum retrospectives that the very software people who were being treated as village idiots were in the process of enabling the global economy, connecting people and companiesacross the world and far above it, and remaking the nature of virtually every business on Earth.
That’s an artifact of our navel-gazing culture. We’re far too ready to let other people take the credit for our accomplishments, because we overvalue respect within our group (look at this 6502-interpreter I wrote in point-free style) and ignore the bigger battle of getting respect within society at large. We’re the smartest and hardest-working of all the important tribes in the private sector (obviously, there are dumb/lazy programmers and smart/industrious business people; I’m talking about aggregates) but we’ve let ourselves be treated as untrustworthy (two-week iterations) and childlike.
We probably need to stop with our culture of self- and in-deprecation. I’ll regularly hear programmers say things like “I’m terrible at my job” when the context would make it clear that what they’re really saying is, “humans are innately bad at building rules-based systems, because it’s not at all natural to us”… but when business people take that out of context, bad things happen to us as a tribe. It’s not that “business people” are dumb. It’s that they’re surrounded by people who are inflating themselves and they learn to down-regulate what they hear from others, so when we deflate ourselves, they assume that we must be a group of total idiots.
Nobody had the guts to kick off the project until the competition proved it doable and desirable; by then, the project was in catch-up mode and had to be finished lickety-split.
Business tends to be reactive, not proactive. It’s not the fault of “business people”. The problem with us is that we’re much more honest than most people in the private sector. Most people in the business world have learned that they can get their way if they present their nice-to-haves as existential threats, and so there’s this game of exaggeration and risk-inflation that we’re terrible at playing. We present our nice-to-haves (let’s rewrite this ugly legacy code) as nice-to-haves. Nice-to-haves will always been tertiary in priority (meaning they’ll probably never get done).
Asking for permission is a huge drain and, yes, I certainly buy the argument that software failures are often caused by the inefficiency injected by asking for permission and playing politics.
If a project offered a value of 10 times its estimated cost, no one would care if the actual cost to get it done were double
the estimate. On the other hand, if expected value were only 10 percent greater than expected cost, lateness would be a disaster. Yes it would be a disaster, but instead of obsessing over “What’s the matter with those software
folks who didn’t deliver on the schedule we gave them?” we need to ask instead “Why did we ever kick off a project
with such marginal expected value?”
So fucking true it is painful. This is also why I avoid working on Scrum teams. If a project really needs to be micromanaged down to two-week increments, it’s probably one of those marginal projects that it’s probably better just not to do. See, this is the problem with business-driven engineering. If you do every 1.1x and 1.2x feature that comes your way (because politics) then, sure, you probably have to treat your engineers in a way that we don’t like to be treated. On the other hand, if you’re smart about seeking out the 5-100x projects, then you shouldn’t have to concern yourself with two-week iterations and story points.
[W]e’re continually beating ourselves up for something that’s somebody else’s fault.
Agree and disagree. If we continue to call it “their fault”, then we’ll never been seen as capable of our own leadership. It’s also ours. We failed to get for ourselves the status that would allow us to choose our own projects instead of the low-margin slogs assigned to us by non-technical middle managers and “product owners”. There’s a lot of fault to be divvied up, related to our perceived low performance (despite taking over the world) and our low status and our tendency to wind up on low-margin, ill-thought-out projects. To say that it’s just their fault (and not also ours) says, to me, that we’re not ready to step up and manage our own affairs. Of course, I think that the OP would actually agree with me; certainly, it’s not only or even mostly our fault. We do share some of the blame, though. If I’m selling someone something that will save his life, and he doesn’t buy it because I sold it poorly, is he singularly at fault? No, we both are.
Agree and disagree. If we continue to call it “their fault”, then we’ll never been seen as capable of our own leadership
This is the biggest issue I see in the agile companies I’ve worked in: the structure tries to remove any path for an IC to show leadership. I’m sure it’s different at different companies, however this is what I’ve experienced. I’ve worked at one company which is considered by the internet to be the closest thing to the gold standard in agile and between POs and agile coaches, there was little room for someone to lead unless you have a really strong personality.
Interestingly, many of the devs I interacted with liked it this way. They felt they had freedom without responsibility, when, IMO, the reality was little freedom and little responsibility. I also felt this favors lowest-common-denominator teams. When underperforming, the answer is more structure, never that a team member might be underperforming.
But like I said, it depends on ones experiences. I’m a very devoted IC and my best experiences are working on a team with similar people and very little structure around us.
This is the biggest issue I see in the agile companies I’ve worked in: the structure tries to remove any path for an IC to show leadership.
Yes. That’s one of the things that I dislike about “Agile”: the culture of terminal juniority. It assumes that anyone worth his salt will want to become a Product Owner or Scrum Master.
The Scrum Master isn’t supposed to be the people manager, but often he is, because no one wants to be an SM without authority. It’s a dangerous position, with responsibility but no power or even the ability to protect yourself. Managers have guns, Scrum Masters have suggestions.
When underperforming, the answer is more structure, never that a team member might be underperforming.
Yeah, and that’s a false security. No matter how “Agile” the process may be, management still thinks it knows who the underperformers are. Sometimes it’s right and sometimes it’s wrong, and that’s just an artifact of human organizations work; it’s not Agile’s fault. Still, Agile doesn’t provide real protection for actual or perceived low performers.
In fact, if one wanted to get very cynical, one could argue that the softer, more neutral “Agile” language of “spotting impediments” is actually there to encourage people to rat their perceived low performers out, with claims of, “Don’t worry, this is OK because we’re all working together here”.
This is brilliant. Anyone who expects a heavy paper because of the “pdf” header should take it from me: it’s 2 pages, and a really easy (and great) read.
I know that this is an old theme from me, but we’re really bad as a tribe at managing our own social status. We’re reasonably well-paid but still treated as low-status workers, with open-plan offices and the infantilizing culture of “story points” and two-week “sprints”.
That’s an artifact of our navel-gazing culture. We’re far too ready to let other people take the credit for our accomplishments, because we overvalue respect within our group (look at this 6502-interpreter I wrote in point-free style) and ignore the bigger battle of getting respect within society at large. We’re the smartest and hardest-working of all the important tribes in the private sector (obviously, there are dumb/lazy programmers and smart/industrious business people; I’m talking about aggregates) but we’ve let ourselves be treated as untrustworthy (two-week iterations) and childlike.
We probably need to stop with our culture of self- and in-deprecation. I’ll regularly hear programmers say things like “I’m terrible at my job” when the context would make it clear that what they’re really saying is, “humans are innately bad at building rules-based systems, because it’s not at all natural to us”… but when business people take that out of context, bad things happen to us as a tribe. It’s not that “business people” are dumb. It’s that they’re surrounded by people who are inflating themselves and they learn to down-regulate what they hear from others, so when we deflate ourselves, they assume that we must be a group of total idiots.
Business tends to be reactive, not proactive. It’s not the fault of “business people”. The problem with us is that we’re much more honest than most people in the private sector. Most people in the business world have learned that they can get their way if they present their nice-to-haves as existential threats, and so there’s this game of exaggeration and risk-inflation that we’re terrible at playing. We present our nice-to-haves (let’s rewrite this ugly legacy code) as nice-to-haves. Nice-to-haves will always been tertiary in priority (meaning they’ll probably never get done).
Asking for permission is a huge drain and, yes, I certainly buy the argument that software failures are often caused by the inefficiency injected by asking for permission and playing politics.
So fucking true it is painful. This is also why I avoid working on Scrum teams. If a project really needs to be micromanaged down to two-week increments, it’s probably one of those marginal projects that it’s probably better just not to do. See, this is the problem with business-driven engineering. If you do every 1.1x and 1.2x feature that comes your way (because politics) then, sure, you probably have to treat your engineers in a way that we don’t like to be treated. On the other hand, if you’re smart about seeking out the 5-100x projects, then you shouldn’t have to concern yourself with two-week iterations and story points.
Agree and disagree. If we continue to call it “their fault”, then we’ll never been seen as capable of our own leadership. It’s also ours. We failed to get for ourselves the status that would allow us to choose our own projects instead of the low-margin slogs assigned to us by non-technical middle managers and “product owners”. There’s a lot of fault to be divvied up, related to our perceived low performance (despite taking over the world) and our low status and our tendency to wind up on low-margin, ill-thought-out projects. To say that it’s just their fault (and not also ours) says, to me, that we’re not ready to step up and manage our own affairs. Of course, I think that the OP would actually agree with me; certainly, it’s not only or even mostly our fault. We do share some of the blame, though. If I’m selling someone something that will save his life, and he doesn’t buy it because I sold it poorly, is he singularly at fault? No, we both are.
This is the biggest issue I see in the agile companies I’ve worked in: the structure tries to remove any path for an IC to show leadership. I’m sure it’s different at different companies, however this is what I’ve experienced. I’ve worked at one company which is considered by the internet to be the closest thing to the gold standard in agile and between POs and agile coaches, there was little room for someone to lead unless you have a really strong personality.
Interestingly, many of the devs I interacted with liked it this way. They felt they had freedom without responsibility, when, IMO, the reality was little freedom and little responsibility. I also felt this favors lowest-common-denominator teams. When underperforming, the answer is more structure, never that a team member might be underperforming.
But like I said, it depends on ones experiences. I’m a very devoted IC and my best experiences are working on a team with similar people and very little structure around us.
Yes. That’s one of the things that I dislike about “Agile”: the culture of terminal juniority. It assumes that anyone worth his salt will want to become a Product Owner or Scrum Master.
The Scrum Master isn’t supposed to be the people manager, but often he is, because no one wants to be an SM without authority. It’s a dangerous position, with responsibility but no power or even the ability to protect yourself. Managers have guns, Scrum Masters have suggestions.
Yeah, and that’s a false security. No matter how “Agile” the process may be, management still thinks it knows who the underperformers are. Sometimes it’s right and sometimes it’s wrong, and that’s just an artifact of human organizations work; it’s not Agile’s fault. Still, Agile doesn’t provide real protection for actual or perceived low performers.
In fact, if one wanted to get very cynical, one could argue that the softer, more neutral “Agile” language of “spotting impediments” is actually there to encourage people to rat their perceived low performers out, with claims of, “Don’t worry, this is OK because we’re all working together here”.