Here are the kinds of questions I see development teams using AI tools run into in a single morning:
- The AI's second attempt at a feature is still wrong. Do we try again, or stop and rewrite the description?
- Three pieces of work are waiting for review. Does a developer stop writing new code to help review?
- This change touches the payment code. Who needs to look at it before it ships?
- The tester is swamped. Do we hold the next item, or pull someone off another task?
None of these is a big decision. Each one takes a minute to answer if the right person is in the room.
What changed is how often they come up. Every piece of work stops at the same few points: is it described well enough to hand to the AI, is the result right, who reviews it, is it ready to ship. When a piece of work took three days, a team hit those points a few times a week. Now that the AI can produce a piece of work in a few hours, the team hits them many times a day.
The decision queue
In most organizations, questions like these still go to non-developers who are "in charge." A manager or sometimes a Scrum Master who has turned into a project manager or, even worse, a "team lead." That person is usually busy, so the question waits.
When questions came up a few times a sprint, the wait didn't matter much. When they come up many times a day, it matters more than anything else. The AI wrote the code in ten minutes. The code then waited half a day for someone to decide what to do next.
The Product Owner who became the manager
There's one more person who often ends up at the front of this queue, and it's the one who should be furthest from it: the Product Owner.
In many organizations the Product Owner has quietly become the team's manager. They hand out tasks, decide who works on what, approve each small change and run the daily scrum as a status meeting. Teams go along with it, because the Product Owner is the person closest to them with any authority.
These Product Owners do twice the damage. First, every small question about the work now waits for the Product Owner, so they become the queue. Second, the Product Owner stops doing the job only they can do: deciding what to build and why, putting the work in sequence, and describing it clearly enough to build from. When that job slips, the descriptions get thinner, the AI builds the wrong thing more often, and the team has even more questions to bring them.
A Product Owner's authority is over the what: what goes into the product, in what order, and whether it does what was needed. The team's authority is over the how: who picks up the work, who reviews it, and when it's ready. When a Product Owner takes over the how, the team gets slower and the product gets worse.
Why a faster manager doesn't fix it
The obvious response is to make the decision-maker faster: more dashboards, more alerts, a standing slot to clear the backlog of questions. That helps for a week.
The problem is the number of decisions, not the speed of the person making them. One person can't answer fifty small questions a day and still do anything else. And the person furthest from the work is the one who knows least about the answer.
The people doing the work already know most of the answers. They know which change is risky, who understands that part of the code and whether the description was clear. What they often don't have is permission to act on what they know.
What leading looks like now
How the team works, its process, still changes deliberately, at the retrospective. What has to change is who answers the questions about the work.
This is where leadership comes in, and it isn't the same thing as management. You don't need a title to do it, and having a title doesn't mean you're doing it.
Leading a team that works at this speed means doing three things:
- Create authority boundaries. Say clearly what the team can decide on its own, and what it can't. Most teams are never told, so they ask about everything to be safe.
- Make the sprint goal clear enough that the developers decide for themselves. If they know what matters most this month, they can decide whether to hold an item or pull someone onto review. For a Product Owner, this is the job: a clear goal and clear descriptions do more for the team than answering their questions one at a time.
- Step back when they decide differently than you would. If you overrule the team's small decisions, they'll will stop making them and go back to asking.
None of this means the leader stops deciding. You still set the direction, decide what the team works on and the sequence, and handle the questions that really need you. You just stop being the place where every small question waits.
Three questions to ask yourself this week
- Count the questions your team brought to you last week. How many of them could they have answered without you?
- Ask your team: "What are you allowed to decide without checking with me?" If the answers differ from person to person, or from what you'd say, that's where the waiting starts.
- Think of the last time the team made a call you disagreed with. What did you do next?
If those questions were hard to answer, the Leadership Self-Check takes three minutes and shows which part of leading is holding the rest back. It's free, and you'll see your result right away.
I'm also rebuilding The Leadership Ascent as a small group working with me directly, for anyone who leads, with the title or without it. You can join the waitlist on the same page.