The Team Principal, Bottleneck or Not
To be the bottleneck, or not.
For a long time the hard part of software delivery was building the thing. Specifications could be loose because turning them into working software was slow and expensive, and that step absorbed most of the risk. So that is where teams put their best people and their tightest process.
AI collapsed the cost of execution. When an agent writes the code, deployment frequency and lead time reach elite levels almost by construction, and the old delivery metrics stop being the interesting number. The constraint moves upstream, to the work that decides what to build and states it well enough to be built: forming a vision, gathering the primary requirements that carry it, and running the feedback loop that turns a rough intention into something a team can actually deliver.
That work has an owner: the Team Principal, the person who holds the vision and signs off on what is delivered. And here is the uncomfortable part. Once execution is cheap, the Team Principal is the bottleneck. Not through any failing, but by position: everything now waits on how fast one person can turn intent into buildable, accepted requirements. The system moves only as fast as they do.
So the AI era puts the role a familiar question. To be the bottleneck, or not.
The default answer is “to be”
In most delivery models the Team Principal has no way out of it. They own the vision and the requirements, and they do that work the way it has always been done: alone, in documents, in a calendar full of stakeholder calls, handing a written spec across to a team that builds it and only then discovers whether it was right. Validation comes after the build, which is the most expensive moment to learn you were wrong. Nothing in that setup lets one person keep pace with a delivery team that no longer waits on anything. So the role stays the bottleneck by default.
RACE is how the role stops being one
RACE Programming makes the Team Principal a first-class role and then does the thing most models skip: it gives the role an instrument. The Pit Wall is a forward-deployed engineering capability that works alongside the Team Principal on the requirements themselves, not downstream on the build.
That is what changes the answer from “to be” to “not.” With a Pit Wall, and the modern approaches and technologies it brings, the requirement can be made executable and testable before anyone commits to building it. The Team Principal works at the new speed instead of falling behind it. The catch is in how the instrument is used: having a Pit Wall is not the point, using it correctly is, and that looks different in the two situations the role actually faces.
Two shapes of the work
Requirements work comes in two shapes. The Pit Wall changes both.
New ideas: customer development made of prototypes
When the thing does not exist yet, when the Team Principal is chasing a genuinely new idea rather than improving an existing process, the right discipline is classic customer development. Find the users, test the value, learn what is actually wanted before building it out.
What changes with a Pit Wall is the medium of that conversation. It is no longer conducted in slideware and prose. It is conducted in prototypes and, more importantly, in options between prototypes. Rather than describe a feature to a user and ask whether they would want it, the Team Principal brings two or three working versions and watches which one the user reaches for. The prototype is not a mock-up meant to illustrate a document. It is the requirement itself, in a form you can put in front of a real user and test before you commit to it. For a Team Principal, prototypes are the primary instrument of customer development, and the Pit Wall is what makes producing them fast enough to use that way.
Existing work: two ways to reengineer, only one of them new
When the work already exists and the goal is to reengineer it, there are two genuinely different approaches, and the difference is the whole point.
The first is classic business-process reengineering. Map the value stream, write down every KPI and standard operating procedure, model the roles, then automate the segments that drive throughput or cost. This is legitimate and well understood, and expert consultants have done it for decades. It is also slow, and its output is documents. The value is validated late, after a long collection-and-analysis phase and after something has been built against the resulting spec.
There is a tempting shortcut here that does not work: pointing an agent at the whole department and having it interview everyone about their process. It looks efficient and it is the opposite. The person on the other side of that interview is the same one who was too busy to document their process before, and now they will have an agent answer on their behalf, from the job description. You collect a tidy restatement of what people are supposed to do, not the reality of what they actually do.
The second approach inverts the starting point. Instead of collecting the standard process and optimizing it in the abstract, start from one real expert who does the work, ideally someone senior enough to have both command of the job and the authority to delegate it. Pair that expert with engineers who know how to put AI tools to work and integrate them. Working together, they automate that person’s actual workplace. In the process they do not just speed up the existing steps. They create capabilities that did not exist before, because the tools to do them did not exist, and the result is a new version of how the job is done. Once that new version is stable and repeatable, it moves out of one person’s workstation into the shared environment, so the whole team can do the job the new way, using the same reusable unit of captured instructions and the code the system wrote for itself along the way.
To be, or not
The Team Principal is the new bottleneck. That is not an accusation, it is arithmetic: once building is cheap, the system waits on the person who decides what to build. Whether the role stays the bottleneck is the only open question, and it has an answer. With a Pit Wall, and the discipline to use it correctly, the requirement is settled before the build, the work runs at the new speed, and the constraint moves off the one person it had landed on.
To be the bottleneck, or not. RACE Programming is how a Team Principal chooses not.
Written by Pavel Khodalev, author of RACE Programming and CTO of First Line Software. Follow new essays via RSS.