11 minute read
Most of the engineering leaders I work with have already done the work. Scrum is in place. Teams are cross functional and mostly stable. There is a platform team, a pipeline that builds and deploys, a dashboard with four metrics on it, and now an AI assistant on every desk. The practices are not missing. The people are not weak.
And yet delivery is still slower than anyone expects, less predictable than anyone will admit in a board meeting, and more expensive to change than it was three years ago.
That gap is what this is about. My argument is easy to state and uncomfortable to act on. The frameworks and practices your teams adopt cannot overcome the operating model your organisation runs them inside. Engineering is not a set of team practices. It is a leadership system.
Your operating model is a theory of the business
Every organisation runs on what Peter Drucker called a theory of the business: a set of assumptions about the environment, about who the customer is, about what that customer values, and about what the organisation has to be good at in order to win. Most of those assumptions were never written down, and almost none of them are revisited. They were correct once. That is usually why nobody questions them.
An operating model is that theory made structural. It is the assumptions converted into governance, funding, measurement, decision rights, and accountability, so that they no longer have to be argued. They become the way things are done here.
This is why operating models are simultaneously so powerful and so hard to see. A framework is something you adopt, and you can point at it. A theory of the business is something you inherit, and it points at you. Scrum can be installed in a quarter. The assumption that work can be specified up front, approved centrally, and then executed to plan is installed in your budget cycle, your capitalisation rules, your job architecture, and your promotion criteria. One of those two things is going to win, and it is not the framework.
The distinction between a predictive operating model and an adaptive one is not a moral one, and it is not modern against traditional. Predictive structures work extremely well when their assumptions hold: stable demand, knowable work, long product lifecycles, advantage from efficiency and consistency. They fail when the environment changes faster than the planning cadence that governs it. Most organisations I see are not badly run. They are running a theory of the business that stopped matching their environment some years ago, and nobody was accountable for noticing. I have written about that distinction at length elsewhere.
When this is not your problem
I should say this plainly, because the argument reads as universal and it is not.
If your demand really is stable, your work really is knowable in advance, and your product lifecycle is measured in years, a predictive operating model is not your constraint. It is the correct design, and changing it would cost you the advantage you have.
If your teams genuinely cannot do the work, structure will not save you. Capability gaps are real and they are fixed by hiring, training, and time. My claim is narrower than it sounds. When capable people using good practices keep producing disappointing outcomes, capability has already been ruled out by the evidence in front of you, and the operating model is what remains.
And if you can answer the five questions at the end of this piece with evidence rather than opinion, you are not the reader I wrote this for.
Where the theory is actually written down
If you want to find an organisation’s real theory of the business, do not read the strategy deck. Read five things instead. These are the surfaces where the theory stops being an idea and starts governing behaviour.
Governance: what requires permission
Governance answers one question: what may a person do without asking. Every approval gate is a recorded statement that the organisation does not trust the information held at the point of work, and would rather pay delay than accept variance. That is sometimes a sound trade. It is rarely a conscious one, because approval gates are added one incident at a time and removed almost never.
The cost is not the meeting. The cost is that a decision cannot be tested until it has been approved, and by then it has usually also been committed.
Funding: what you buy, and for how long
Funding decides what an organisation is structurally able to change its mind about. Fund a project and you have bought a scope, a date, and a team that disbands at the end, which means learning that arrives late has nowhere to go and no one to carry it. Fund a product, or a long-lived team that owns an outcome, and you have bought a capability that can absorb what it learns.
Annual funding cycles in a market that moves monthly do not just slow the organisation down. They make it structurally rational for everyone in it to defend a plan they know is wrong, because the plan is the thing the money was attached to.
Measurement: what you count
Measurement determines what leaders are able to see, and therefore what they are able to decide. When the measures are outputs, and the people being measured cannot change the system that produces those outputs, the measures stop describing reality and start describing what people need reported. Signal integrity degrades quietly, and it degrades first in exactly the places where you most need the truth.
The diagnostic is not whether your metrics are good. It is what happens when a metric reveals a structural problem rather than an execution one. Organisations that change the metric have told you where their accountability actually sits.
Decision rights: who may decide without asking
Context does not survive travel. Every layer it crosses on the way to a decision maker strips detail and adds interpretation. When authority sits several layers above where the information is generated, the organisation has designed decision latency into itself, and the delay is not a behaviour anyone can be coached out of.
The compounding cost is not slowness. It is that by the time a decision reaches the person entitled to make it, the option to reverse it cheaply has usually already expired.
Accountability: who carries the consequence
The most common structural defect I find is accountability without authority. A team is held to an outcome it does not control the conditions for. Engineers are asked for quality by an organisation whose funding, deadlines, and measurement all penalise the behaviour that produces it. Nobody in that arrangement is behaving badly. They are behaving rationally, given the system they have been handed.
Where accountability and authority sit apart, no amount of intent closes the gap. It is a structural property, and it is fixed structurally or not at all.
Why frameworks, coaching, training and AI change so little
Once you see those five surfaces, the disappointing return on transformation investment stops being mysterious.
Frameworks, coaching, training, and tooling all operate below the level at which the constraint lives. They can make a team better at working inside the system. They cannot change the system, because the levers that define it (budget, structure, policy, decision rights) are not in the room. This is why improvement arrives, holds for a while, and then regresses. The operating model reasserts its constraints, and everyone concludes the framework did not work.
AI is the sharpest current example, and it is worth being precise about why. AI does not create a new operating-model requirement. It accelerates execution, and in doing so it removes the technical effort that used to disguise where the real constraint was. When writing the code was the slow part, governance delay and context decay were hidden inside the estimate. When writing the code is fast, they are all that is left. The queue does not disappear. It just becomes visible.
There is a second effect that is easier to miss. AI output arrives quickly and looks precise, which means an invalid assumption can survive longer under AI than it did under manual work, because nothing about the output signals that it was built on the wrong premise. Where context quality is poor, AI does not compensate. It multiplies. This is why I treat AI as a diagnostic rather than an intervention: it will tell you, faster and more expensively than anything else you could buy, exactly what your operating model was already doing.
The tell: stated intent against the operating model
Almost every organisation I work with has a stated intent that is genuinely held and an operating model that contradicts it. The contradiction is not hypocrisy. It is usually that the intent was updated and the structure was not.
The tells are consistent, and you can look for them this week:
- You have asked for empowered teams, and every decision above a fixed value goes to a forum that meets fortnightly.
- You have asked for faster feedback, and you fund in annual cycles against fixed scope.
- You have asked for quality, and the only measure with consequences attached is date adherence.
- You have asked people to surface problems early, and the last person who did is still explaining it.
- You have asked for experiments, and there is no mechanism to stop one, so every experiment quietly becomes a commitment.
Where stated intent and structure conflict, structure wins, because structure is the thing with consequences attached. It wins without a meeting. People are reading the system, not the memo, and they are reading it correctly.
Move, wait, learn, decay
The most useful diagnostic I know is not a maturity model. It is four questions about what your system does with work, and you can answer all four this week from things you already have.
Does work move? Take ten items you shipped last quarter. For each, write down the date work started and the date a customer could use it, then subtract the days anyone actually touched it. What is left is waiting. In the organisations I look at, the waiting is usually the larger number.
Does work wait? Walk your board and find everything that is done but not released, or decided but not authorised. Count them, and note what each one is waiting for. If most are waiting for a person rather than for work, you have found where authority sits relative to information.
Does your organisation learn? Look at the last five problems that reached your desk and ask what changed afterwards. A new rule, a new report, a new dashboard, or a new approval is a reaction. A removed approval, a moved decision, or a changed budget line is learning. Count the two. Most people are surprised by the ratio.
Does the system decay? Find one approval, one report, and one recurring meeting that exist because of an incident nobody in the room can now date. Then ask who is accountable for removing them. If the answer is nobody, this is not entropy and it is not the market. It is an unowned job.
Five questions worth answering honestly
If you take one thing into your next leadership meeting, take these. They are diagnostic, not rhetorical, and the answers are usually already known by someone who has not been asked.
- Governance. What decisions currently require permission, and what evidence would tell us that permission is buying us more than the delay costs?
- Funding. What are we funding that we would not start today, and what is our mechanism for stopping it? Drucker asked the first half of that question in 1954. Most organisations still cannot answer the second half.
- Measurement. When a measure last revealed a structural problem, did we change the structure or the measure?
- Decision rights. Where is the largest gap between where information first appears and where the decision about it is made, and what is that gap costing us in reversibility?
- Accountability. Who is currently accountable for an outcome whose determining conditions they do not control?
None of these questions is about your teams. That is the point.
This work does not finish
The uncomfortable part of treating engineering as a leadership system is that it removes the possibility of completion. There is no target state. Operating models degrade through accumulation and through decay, continuously, and the work of removing obsolete commitments, realigning decision rights, and refreshing the assumptions the model rests on is permanent executive work. It cannot be delegated to a transformation office, because the levers are not there.
What changes when leaders take this on is not that delivery becomes fast. It is that problems arrive while they are still cheap, decisions get tested before they become irreversible, and leadership attention stops being consumed by crisis response and retrospective justification. That capacity is the real return, and it is structural rather than heroic.
If your organisation has adopted the practices and is still disappointed by the results, the constraint is very unlikely to be your engineers. Start with the five surfaces. The theory of your business is written there, and so is the reason your work moves, waits, learns, or decays.
Everything above is diagnosis. It will let you recognise your own organisation and tell you where to look, but it deliberately stops short of two things. It does not give you the mechanism by which each of these structures produces its outcome, and it does not tell you what evidence would prove the argument wrong. Both matter, because a diagnosis you cannot falsify is only a strongly held opinion. That is the work the book does.
I wrote this alongside my session for The Future of Work in Scotland, on engineering as a leadership system and what lies past framework adoption.
Read Engineering as a Leadership System on Leanpub , where the ebook comes with free updates for life and you set the price. Paperback and Kindle are on Amazon .
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.