Is your management style killing AI speed?
Bad leadership blocks AI adoption.
This is “Effective Delivery” — a newsletter from The Software House about improving software delivery through smarter IT team organization.
It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.
TL;DR
Some managers block AI-driven teams with rigid rules & instructions,
Managers who complement AI help them see what’s worth building,
They give the team a lot of autonomy, stepping in only when needed,
Such a mindset is necessary to maintain a high AI development speed.
Contents
1. When management enables engineers
Hey!
Andrzej here.
IT managers always try to figure out how to get their developers to be more efficient with AI tools.
This is also a major topic here at Effective Delivery.
But today, I want you to think about yourself.
What if you, as a manager, are the reason why productivity didn’t improve so much with AI?
When management enables engineers
AI has made coding dramatically faster, with our AI framework, copilot-collections, allowing engineers to build some end-to-end features in 30 minutes.
But it’s not just about coding. AI also speeds up work across multiple other aspects of a developer’s day. With it, developers can:
generate their own tasks from a brief,
quickly summarize information,
learn about new topics, communicate, get updates, and more.
This can result in an autonomous developer who uses AI assistance to gather a wealth of context and generate new tasks fast, completing them even faster.
They can do it all on their own, without any oversight.
That kind of autonomy can absolutely work, but only if you, as a manager, allow it.
Anti-AI management style
Some managers still haven’t adjusted their managerial style to AI, resulting in all that potential being wasted by one of the 3 traps.
The bottleneck trap
Some managers simply can’t let a decision leave their hands.
They approve the tiniest tasks, library or plugin choices, sign off on every scope change, and hold every option open until they say so.
Teams that could run at AI pace sit idle instead.
They wait for a decision they could have made themselves.
On a recent project, developers finished their tasks in 3 days.
Then they waited another 3 days for each approval step.
Half of the AI speed advantage disappeared in that waiting room.
The ownership trap
When managers don’t let anyone make decisions, the consequences go beyond just wasting time.
They shape a team composed of people who are too scared to make any decisions on their own and too detached from the product to care about it.
“I’m just doing my job” is what goes through their head.
Will such developers make the effort to understand the user they are creating for?
And when the decision-making is limited by the creativity of a single person, could it ever be optimal?
The activity trap
Some managers love tracking metrics like velocity or tasks shipped because they make it easy to show that they are doing a lot.
It’s even more true in the age of AI, where a skilled engineer can produce so much code with the help of agents.
But when a manager is stuck on velocity, smart developers who lack a sense of ownership will close their whole sprint in 3 days and pretend to work for the rest of it.
If velocity is what gets rewarded, velocity is what’s delivered.
Staying useful
Because of AI, the cost of writing code has dropped through the floor.
But the cost of building the wrong feature or shipping a bad product is as high as ever.
If you want to be useful as a manager today, don’t focus on details and volume of work.
1. Communicate the purpose
A manager must answer 3 questions about the project without hesitation.
Who is the user?
What problem are we solving for them?
How do we know the problem exists?
If a manager can create a high-level definition of done for a feature or an app, they can let AI and developers determine how to get there.
The developer will be responsible for defining the done for operational tasks that bring your vision to life.
2. Help decide what NOT to do
Instead of giving your teams rigid instructions, help them narrow down their choice.
A manager needs to say “we are not building this,” even against the client’s wishes.
The willingness to break a roadmap when it no longer serves the goal is essential now that writing new code is this fast.
3. Measure outcomes, not activities
As my friend Adam wrote, there are only 4 metrics that affect quality and timely delivery:
Lead time
Cycle time
Deployment frequency
Product bugs
4. Give your team more space
I design the team so the work can run for a week without me.
It starts with naming what the team decides without me and keeping my hands off inside those lines.
Think of how an insurance agent gets his pricing range.
He can close a deal anywhere between 500 and 1000, but to go below that, he has to pick up the phone.
The range is the team’s autonomy, and the phone call is where I come in.
5. Focus on unblocking
Rather than blocking your team’s creativity, do the opposite.
Every month, I review the team’s processes and cut anything that no longer earns its keep.
A simpler system lets the team react to project shifts and frees AI to carry more of the load.
But I also encourage managers to step in decisively when they actually see a problem.
On one project, one of our solution architects saw a long custom build estimate.
He found a ready library that covered most of the scope.
The team dropped the custom code path and delivered on time.
Next time
Aleksander Patschek will tell you why the latest technology isn’t always the right choice.
He will help you choose between the tried-and-tested and the new and innovative, depending on what your project really needs.
Happy weekend!
🟣 The latest AI-efficiency tactic
