An anti-pattern I see often in software development is an organisation taking an A team – highly skilled, highly motivated – and somehow managing to squeeze a D performance out of them.
The problem is almost always that they won’t let the A team bring their A game. The team are micromanaged, often with dysfunctional processes and practices and other constraints imposed on them by management.
As a trainer and mentor of dev teams, I sadly often hear complaints like “We want to write more unit tests, but our manager won’t let us” or “We’re not allowed to push directly to the trunk” or “They don’t let us talk to the end users”.
Now, I would say “Why did you ask for permission?”, because I’m that kind of a developer. I will assume I was hired because they thought I’d do a good job (although I have been hired specifically not to do a good job, but that’s office politics for you). So I’m going to try to do the best job I can, the best way I know how.
And that means I’m going to continuously test the code. I’m going to continuously integrate my changes. I’m going to talk to end users. A lot.
One common characteristic of high-performing development teams is they have a considerable amount of autonomy to do what needs to be done to get good results for their customers. And here’s where it gets a little tricky.
Most people in positions of authority don’t willingly give away decision-making power. They find autonomy threatening. For all the talk of “servant-leaders”, they’re rare in reality.
Most often, when dev teams have high autonomy, it’s not because it was given, it’s because it was TAKEN.
But there are two sides to this bargain. If we get to work the way we think we should work, we have to deliver the goods. Teams who don’t deliver – perhaps because they’re being micromanaged – tend to get micromanaged even more closely. It’s a paradox. We have to earn the trust to be given the trust to do what needs to be done to earn that trust.
Our confidence – now there’s a word! – that we can deliver, and our ability to assert ourselves within the process, is a key enabler of achieving necessary levels of autonomy. It’s a quality A teams need to play an A game. Sorry folks. That’s the reality.
The mirror universe version of all this is those developers who insist on doing things badly. The thing about D developers is they can often genuinely believe they’re playing an A game (when I was new to the industry, I was inexperienced enough to believe this, too – I just didn’t know what an A game looked like).
Skills and education are pivotal here, as is a more democratic approach to setting the direction within the team. As much as I’d love to believe that my strong leadership was what delivered, I have to remind myself that – in reality – it’s the TEAM who deliver, and they do it the best way they can agree on.
If you’re serious about building your team’s capability to rapidly, reliably and sustainably evolve software to meet rapidly changing business needs, my Code Craft and Test-Driven Development live remote training workshops are HALF PRICE until March 31st 2025.
Codemanship's Blog 
