Inside what we can call the Principal Software Delivery Chapter.
Ghost Town by The Specials playing in the background.
How many of your senior engineers could bootstrap a production-grade project from zero — infrastructure, tooling, SDLC, “AI” agent workflows — with under 30% human involvement, in under 60% of estimated time?
Use this as an assessment
It is about what a specific kind of person can now do, and what that means for how you structure the organisation around them.
Whatsup?
The further into “AI” adoption an organisation gets, the more clearly a pattern appears.
A layer of senior professionals — not many, not evenly distributed — reaches a level of proficiency with new tools that separates them from the rest of the senior population. This is not “uses AI tools well.”, this is about us needing to build new tooling, tailor it for the teams and use it.
These are the people who can not just use the tools, but design and run and tailor tools and build multi-agent delivery systems. They build tooling custom-tailored for the team.
They onboard people to projects and projects to people.
The environment is ready before anyone arrives. The team jumps in with context, with scaffolding, with a working “AI”-assisted workflow already in place.
They build the SDLC and the practices as they go, because no playbook exists yet.
What we see is that they keep human involvement under certain percentage, concentrated at the moments that actually require judgment — the design, the ambiguous requirements call, the architectural decision point, the moment something doesn’t add up. Human involvement as an operating model.
When an organisation has enough of these people, it has to find a place for them.
Let’s give the chapter a name: the Principal Software Delivery Chapter.
For mature organisations, the obvious answer is wrong
The Principal Software Delivery Chapter as a permanent, separate institutional layer is the wrong answer (especially for mature organisations).
The capability is real. The instinct to institutionalise it — new structure, new management cycle, new career framework — is where most organisations will make an expensive mistake.
The productivity gain from this operating model is bounded. You have to understand what it is doing for you specifically, in your context, with your teams. And for a mature organisation, the answer is almost always: wire it into how you already work. Find where this capability boosts the flows you have. Adjust at the edges.
The stepping stone case
For organisations earlier in the “AI” delivery journey, or for teams just starting to build this fluency, treating the Principal Software Delivery Chapter as a distinct transitional layer is useful. The word there is transitional.
Use it to move fast. Generate signal. Learn what the capability actually is and isn’t in your context — because what worked at one company, at one scale, under one leadership, will need to be adapted, probably significantly, to work where you are. There are no best practices, there is not enough data to say what is the best. There are successful practices - the good enough practices.
The person who bootstraps everything and hands it back to the team should probably be making that team better instead — not leaving and/or becoming a permanent dependency. The stepping stone only works if you know you’re standing on one.
The diagnostic
The question is not whether you have people who fit this pattern. You probably do.
The question is which side you are on. Mature organisation, integrating a capability that boosts what already works? Or earlier in the journey, where a transitional structure accelerates the learning? There are also the consultancy firms but you guys will figure your model out.
This is the way to choose what you build next. Most organisations haven’t asked it clearly enough to know which applies to them.
The most expensive mistake
There are three ways to get this wrong, and they scale by cost.
-
Running these people through cycles designed for different work — standard sprint metrics, standard performance frameworks — loses you the people. Expensive, but recoverable.
-
Over-investing in making the transitional permanent — building institutional structure around a capability that should have been absorbed into how teams work — leaves you with a layer that has no clear exit.
-
But the most damaging move is the one that looks like ambition: deciding that AI proficiency level we are describing is where every senior should be heading A universal aspiration. A target for the whole engineering population.
This is precisely wrong. The value of the Principal Software Delivery Chapter comes from strategic placement, not broad distribution.
The key is that we should not push everyone to this role - we should choose people with broad enough skillset, that want to be involved beyond their key expertise and have abilities to contribute in the whole software delivery space, end to end in every direction. If some of them can also be good coaches, you are winning.
A small number of these people, embedded in the teams that already exist (ideally same team they are in already), enabling the people around them and the organization. Tech leads focused on technical direction. Architects focused on architecture. People managers focused on people. The functional layering.
The Incredibles(tm) got there first. When everyone’s super, no one will be. “AI” tooling amplifies what is already there. Trying to distribute high AI proficiency as a standard dilutes what makes it matter while it also makes it harder to control on every level (hello LLM harness/API bill).
The organisations that get this right will have the right number of these people in the right places. What is the number? Is there a way to know? At this moment - have a few and try, see what happens.