16 minute read
- The operating model, not team practice, explains why transformation efforts and AI produce local gains that regress instead of durable organisational change. see why — jump to the section that argues this
- The real theory of the business is structurally embedded in governance, funding, measurement, decision rights, and accountability rather than in strategy documents. see why — jump to the section that argues this
- Predictive and adaptive theories of the business are mutually exclusive; budget behaviour reveals which one truly governs an organisation. see why — jump to the section that argues this
- Start by running the four diagnostics on your own span of control this week: move, wait, learn, and decay; no permission needed.
- Take the five operating-model questions into your next leadership meeting and leave with one accountable name and one date per question, or treat the meeting as failed.
- Stop treating culture as a lever; read culture as diagnostics about your structure and change the structure instead of trying to change the shadow.
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.
Two things make this worse than it sounds. First, a theory of the business does not become obsolete because it failed. It becomes obsolete because it worked, and success is what stops it being questioned. Second, and sharper: for many organisations the theory never matched the realities of their environment at all. But when every company in your competitive arc makes the same mistake, it is not noticeable. Nothing in the market punishes an error everyone shares. The mistake becomes institutional.
There is one exception worth naming. A personality, or a group, can through sheer force of will make an organisation override the implications of its theory of the business. But it is almost always departmentally local, and it rarely outlives the person. Heroics are not a structure, and this piece is about what persists.
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.
Drucker’s requirement was never just that the theory exists. It was that the theory be tested constantly, because it is a hypothesis, not scripture. That dashed return arrow is the piece almost nobody builds, and it cannot build itself: a theory made structural has no sensor. Nothing inside the structure can detect that its founding assumptions have lapsed, because the structure exists precisely so those assumptions no longer get argued. Detection is a job, and in most organisations it is an unowned job.
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.
The two theories are mutually exclusive. They make contradictory claims about the same environment, so at most one is true of yours. That does not make organisations pure: an adaptive theory of the business freely uses predictive practices wherever the work is knowable, in payroll, in regulated execution, in any known-good procedure. The practices serve; the theory governs. If you believe your organisation holds both theories, look at what your budget process does when the two collide. That is your theory.
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. Genuine means absent: nobody in the system has the skill yet, and the work would fail even with every gate removed. That is fixed by hiring, training, and time. But if skilled people keep leaving, or mastery never gets funded time, that is not a capability gap. That is the funding surface wearing a skills costume, and you are back in this article. My claim is narrower than it sounds. When the practices are present and the people are capable, the operating model is the explanation you have least examined, and it is the only one this piece gives you a way to test.
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. The property being destroyed here is what I call decision testability: the ability to validate a decision against reality before the commitment becomes irreversible. Every gate lowers it.
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.
There is a third rung. Fund an outcome, and the money is attached to the result rather than the plan, so learning redirects the work instead of being defended against. A project buys a plan. A product buys a capability. An outcome buys a direction. The chain should run downward from the vision: the vision defines the outcomes, outcomes drive the products, each product hosts a capability, and projects, if you use them at all, are batches of work inside a product, never the unit of funding.
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. The book calls this surface economic ownership.
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, the degree to which the signals reaching leadership reflect operational reality, 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, the time between recognising a need for change and having the authority to act, 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 inside the constraint. The operating model is not a layer above the work. It wraps it. They can make a team better at working within the system. They cannot change the system, because the levers that define it (budget, structure, policy, decision rights) are outside everything they touch. 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.
This is also why culture change programmes fail. Culture is the shadow the structure casts on the wall, cast by the structure, which was formed from the theory of the business. You cannot change a shadow. You can only move the thing that casts it. Culture is a read-out, not a lever: read it, because it is excellent diagnostics about your structure, and stop pulling on it.
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.
The four questions above tell you what your system does with work. These five tell you where that behaviour is written, one per surface. The order matters: run the four yourself, this week, on the span you control. No permission needed. Take the five to your next leadership meeting once you have the numbers, and leave that meeting with one name and one date per question, or the meeting produced nothing.
- 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 standing mechanism for stopping it? Drucker asked the first half of that question in 1954, and his version was not a question but a calendar entry. 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?
Not one of these questions is about your teams. That is the point.
Subscribe to Martin's articles
Writing since 2006
Articles, usually weekly on Mondays. One click to leave.
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.
Engineering as a leadership system means two things, and I mean both. Engineering, the function, is a leadership system: its performance is produced by structures leaders own. And the leadership system is what needs engineering: your operating model is an engineered artefact, designed once, by someone, under assumptions that were true at the time. It deserves what any engineered system deserves. Instrumentation. Testing against reality. Maintenance. Refactoring when its assumptions expire.
The engineering problem in your organisation was never the code. It is the company. Go engineer it.
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. You can watch the session recording.
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.
Enjoyed this? One click, no account.
Questions this answers
Why do Scrum, agile frameworks, coaching, and AI often fail to improve software delivery speed and predictability?
Because the organisation’s underlying operating model—its structural assumptions embedded in governance, funding, measurement, decision rights, and accountability—conflicts with adaptive team practices, the operating model reasserts its constraints and dominates, so frameworks, coaching, training, and AI only optimize work inside a system they cannot change. When practices and skills are already in place but results are still disappointing, the operating model is usually the unexamined constraint.
How can I diagnose whether my organisation’s operating model is constraining engineering and delivery performance?
You diagnose it by examining five structural “surfaces”—governance, funding, measurement, decision rights, and accountability—along with how work moves, waits, leads to learning, or decays. Concretely, you look at where approvals and permissions sit, what and how you fund, what your metrics trigger when they reveal structural problems, how far information must travel to reach decision-makers, and where people are accountable for outcomes without controlling the conditions, then run the four move/wait/learn/decay questions and the five leadership questions to locate the constraints.
When is a predictive operating model actually appropriate, and when is it my real constraint?
A predictive operating model is the right design when demand is stable, work is knowable in advance, product lifecycles are long, and efficiency and consistency drive advantage; changing it in that context would remove a strength, not a weakness. It becomes your constraint when the environment changes faster than your planning cadence and, despite capable teams and adopted practices, you still see slow, expensive, and unpredictable delivery, indicating your theory of the business no longer matches your environment and no one is accountable for noticing.
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.