Articles on Martin Hinshelwood on Engineering Leadership

Engineering as a Leadership System: Moving Beyond Frameworks

Martin Hinshelwood — Wed, 19 Aug 2026 00:00:00 +0000

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.

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.

Why Most Companies Operating Models Fail in Dynamic Markets

Martin Hinshelwood — Thu, 04 Dec 2025 00:00:00 +0000

Most organisations today operate under a Predictive Operating Model while competing in dynamic markets. This fundamental mismatch creates enormous waste, missed opportunities, and frustrated teams. Understanding why this model fails, and how an Adaptive Operating Model can replace it, is essential for any organisation seeking to deliver value effectively in the 21st century and beyond.

Defining the Two Operating Models

Before we explore why organisations struggle, we must clearly define the two operating models at the heart of this discussion, and more importantly, understand the theory of the business that underlies each one.

Every organization operates on a theory of the business ¹: a set of assumptions about the environment, the organization’s mission, and what it must do to succeed. Understanding the theory of our business begins with two foundational questions: Who is the customer, and what does the customer value? But it doesn’t end there. We must also understand the constraints we operate within, technological, regulatory, resource, competitive, and environmental factors that shape what’s possible. Without explicit answers to these questions, “value delivery” becomes an empty phrase.

Each operating model embodies a fundamentally different theory of the business and makes fundamentally different assumptions about the customer, what they value, and the constraints within which value must be delivered.

The Predictive Operating Model

Core assumption: The environment is predictable enough that organisations succeed through efficiency, standardisation, and control.

Underlying beliefs:

Demand changes slowly.
Work can be understood and specified upfront.
Variability signals defects and should be minimised.
Planning provides more certainty than adaptation.
Performance improves through specialisation and hierarchical coordination.
Management’s role is to optimise throughput and control deviation.

Customer and value assumptions: Customers primarily want consistency, reliability, and quantity. Value comes from standardised output delivered at lower cost and with minimal variation. This model fits environments with long product cycles, slow-changing needs, and stable demand.

How the model operates: The Predictive Operating Model is built on Taylorism and Scientific Management ². It separates planning from execution, functions from one another, and thinking from doing. Decision-making flows vertically. Work is governed through predictive plans, fixed scope and resources, detailed procedures, stage gates, and individual accountability. Output is the dominant measure of performance.

Where it works: This theory of the business is not wrong. It performs exceptionally well when its assumptions hold, predictable environments, repetitive work, limited uncertainty, and markets where efficiency and consistency create advantage.

The Adaptive Operating Model

Core assumption: The environment is dynamic enough that organisations can only succeed through continuous learning, rapid adaptation, and proximity to customers.

Underlying beliefs:

Demand shifts frequently and unpredictably.
Work cannot be fully known upfront; it emerges through discovery.
Variability provides information rather than noise.
Fast feedback is more reliable than detailed prediction.
Performance comes from empowered, cross-functional teams.
Clear, adaptive goals at every level provide direction without constraining discovery.
Success requires continuous alignment to customers, stakeholders, and the environment.
Management’s role is to design systems that enable learning, innovation, and quick adjustment.

Customer and value assumptions: Customer needs are diverse, evolving, and context-dependent. Value is created by solving specific customer problems, not by producing generic output. Organisations win by learning faster than competitors, adapting continuously, and delivering outcomes that matter in the customer’s current context. Where the Predictive Operating Model optimises for volume and repeatability, the Adaptive Operating Model optimises for relevance, impact, and adaptability.

How organisations discover value: Customer value is discovered through direct observation, rapid experimentation, real usage data, and continuous engagement with real users. In dynamic markets, discovery is an ongoing activity rather than an occasional research exercise.

How the model operates: The Agile Product Operating Model aligns with empiricism and continuous value delivery. It organises persistent cross-functional teams around products or value streams, decentralises decision-making to those closest to the work, and measures success through outcomes and customer impact. The model depends on transparency, inspection, and adaptation, supported by short feedback loops, modern engineering practices, and a commitment to technical excellence.

Where it works: This theory of the business succeeds when uncertainty is high, customer needs evolve rapidly, and competitive advantage comes from learning speed, responsiveness, and continuous alignment between what the organization delivers and what the market needs.

Why This Distinction Matters

These are not simply different management styles, nor is this a story of “modern vs traditional” or “agile vs waterfall.” The contrast is contextual, not moral. The Predictive Operating Model fails only when its assumptions stop matching reality, when the environment becomes too uncertain, too complex, and too fast-moving for prediction and control to work effectively.

Understanding the theory behind each model clarifies why transition is so difficult: you’re not just changing processes, you’re challenging fundamental assumptions about how success happens.

The Predictive Operating Model Was Fit for Stable Markets

The Predictive Operating Model was not a mistake. It was brilliantly designed for its context, an environment where its theory of the business held true.

During the Industrial Age, markets were stable and predictable. Demand grew steadily over long periods. Competition was limited. Products had decades-long lifecycles. In textiles, steel production, and large-scale manufacturing, success came from optimizing efficiency and driving down costs through standardization and economies of scale. The assumptions underlying the Predictive Operating Model, predictability, stability, knowable work, matched reality.

Frederick Winslow Taylor developed scientific management for exactly this environment, and Henry Gantt popularised it. When work is repetitive and predictable, breaking it into specialized tasks and optimizing each step makes sense. When markets change slowly, detailed upfront planning works. When products remain unchanged for years, separation of planning from execution causes minimal waste. Variability could be treated as a problem to eliminate because the “right way” was relatively stable.

The Predictive Operating Model delivered extraordinary results in stable markets. It built railways, scaled factories, and powered economic growth throughout the 20th century. The model succeeded because its theory of the business matched the actual environment: success truly did come through efficiency, standardization, and control in predictable work within predictable markets.

Why the Predictive Operating Model Fails in Dynamic Markets

Markets began shifting toward greater complexity and volatility in the early 20th century, and this exposed the limits of the Predictive Operating Model. By the mid-20th century, Toyota demonstrated a different way of working that reintroduced people into the centre of the production system, giving teams direct responsibility for quality, problem-solving, and continuous improvement. The pace of change accelerated again in the 1970s with the microprocessor revolution, and by the 1990s the internet had fundamentally changed how quickly ideas spread and how rapidly markets evolve. Today, AI amplifies this acceleration further, providing tools that enable teams to process information, align with stakeholders, and deliver value at unprecedented speed and scale.

Today, most markets are dynamic, customer needs change rapidly, technology enables new competitors to emerge quickly, and product lifecycles measure in months, not decades. Uncertainty is the norm, not the exception.

But it’s not just market volatility that challenges the Predictive Operating Model. The broader environment in which organizations operate has become fundamentally unstable. Regulatory changes like tariffs reshape entire supply chains overnight. Social movements like the remote work revolution force companies to reconsider workplace models, productivity assumptions, and organizational structures. Political shifts, elections, policy reversals, create cascading effects across industries. Economic shocks, pandemics, financial crises, disrupt assumptions that seemed solid months earlier. These environmental forces don’t just affect markets; they affect an organization’s ability to respond to markets. The confluence of market dynamics and environmental volatility creates both the challenge and the opportunity: organizations that can sense and respond rapidly gain advantage, while those locked into rigid structures fall behind.

The environment has shifted, but the Predictive Operating Model’s theory of the business has not. Organizations continue operating on assumptions of predictability in environments characterized by uncertainty, where both what customers need and how organizations can respond change continuously. This mismatch between theory and reality generates massive waste.

Planning waste emerges when organisations invest months creating detailed plans that become obsolete within weeks. Requirements gathered at the start of a project no longer reflect market reality by the time delivery begins. Change control boards slow response to learning, turning agility into a bureaucratic exercise.
Decision-making waste occurs when hierarchical approval chains delay action. By the time a decision escalates through management layers, the information is stale and the opportunity has passed. Teams closest to customers lack authority to respond to what they learn.
Innovation waste happens when rigid processes and risk-averse cultures kill experimentation. Ideas must fit into predetermined roadmaps. Small experiments that could provide fast feedback are blocked by governance processes designed for large capital investments. Teams cannot explore what customers actually need.
Human potential waste is perhaps the most painful. Talented people are treated as interchangeable resources, assigned to projects based on availability rather than capability or interest. Individual utilization metrics drive behaviors that undermine team collaboration. Separation of planning from execution means those doing the work cannot apply their insight to improve it.
Market disconnect waste grows as organisations become insulated from customer reality. Layers of management separate decision-makers from actual users. Success is measured by delivery of planned outputs, regardless of whether those outputs create value. Teams ship what was specified months ago, not what customers need today.

The Predictive Operating Model operates at fundamentally the wrong speed for dynamic markets. While the market iterates daily, the organisation plans annually or bi-annually. While customer needs evolve continuously, the organisation delivers in large batches after months of work. This speed mismatch is not a minor friction, it is a structural incompatibility rooted in an obsolete theory of the business that no longer reflects how markets actually behave.

The Adaptive Operating Model Enables Success in Dynamic Markets

The Adaptive Operating Model structures organisations for speed, learning, and adaptation. Its theory of the business, that success comes through continuous learning and rapid adaptation in complex, changing environments, matches the reality most organizations face today.

At its foundation lies empiricism: the practice of making decisions based on observation and experiment rather than prediction and assumption. Scrum, as a social technology, makes work transparent, creates regular inspection points, and enables rapid adaptation based on what is learned ³. Kanban, as an observability pattern, makes workflow visible and measures actual delivery performance, enabling teams to see and improve their systems.

Decentralization is essential, not optional. Mary Parker Follett recognized nearly a century ago that effective organisations distribute authority to where knowledge resides ⁴. In dynamic markets, that knowledge lives with teams close to customers and technology, not with executives insulated from both. Decentralization enables fast decisions based on current information. It eliminates escalation delays and management bottlenecks that plague hierarchical structures. However, decentralization only works when goals are clear and adaptive at every organizational level, from company strategy through product goals to sprint objectives. This clarity of purpose proves challenging for most companies, particularly because unlike the fixed targets of industrial planning, these goals must evolve as learning occurs while maintaining coherent direction.

Cross-functional, persistent teams form the organisational structure. Each team possesses all skills needed to deliver value without dependencies on other teams or handoffs to specialized functions. Teams stay together over time, building deep capability and psychological safety. They own outcomes, customer value and business impact, not just outputs like features or story points. Today’s teams increasingly include AI team members augmenting human capabilities. Modern AI tools now make it possible to coordinate these teams effectively at scale, maintaining clear alignment with customers and stakeholders while preserving team autonomy and speed.

Fast feedback loops replace predictive planning. Teams deliver working software frequently, ideally continuously, and observe real customer behaviors. Product Managers make decisions based on actual usage data and customer feedback rather than assumptions documented months earlier. Sprint Goals provide coherence and focus while allowing teams to adapt their approach as they learn ⁵. Service Level Expectations establish predictable flow without requiring detailed estimates.

Technical excellence is mandatory, not aspirational. Teams must practice Continuous Integration and Continuous Delivery as Kent Beck and Jez Humble have taught us ⁶. Automated testing provides the safety to move quickly. Infrastructure as Code enables rapid provisioning and recovery. Monitoring and observability reveal how systems behave in production. AI-assisted development accelerates capability building while maintaining quality and enabling teams to focus on higher-value problem-solving. These practices are not tools or processes, they embody a DevOps ethos that breaks down barriers between building and operating software.

The Adaptive Operating Model matches the speed and uncertainty of dynamic markets. It structures organisations to learn and adapt continuously rather than predict and control.

Operating-Model Hygiene: Why Organizations Regress

Many organisations transition away from hierarchical structures only to drift back over time. Start-ups begin as nimble network organisations with direct communication and fast decisions ⁷ [^Laloux]. As they grow, departments emerge. Managers accumulate authority. Planning processes formalize. Approval chains lengthen. Within a few years, the organisation has recreated the Predictive Operating Model.

This regression is predictable. The Predictive Operating Model’s theory of the business, control through prediction and standardization, is deeply familiar. Most leaders experienced it throughout their careers. Under pressure, people default to known patterns. When faced with coordination challenges, the instinct is to add management layers. When facing uncertainty, the reflex is to demand more detailed plans. The old theory reasserts itself because it feels safer, even when it has become obsolete.

Organizations build up what we might call operating-model cruft, accumulated structures, processes, and behaviors that no longer serve the current context but resist removal. A new approval process gets added to prevent a single failure. It never gets removed when the risk passes. A management layer forms to coordinate between teams. It persists even after teams become more self-sufficient. Individual performance reviews drive behaviors that undermine team collaboration, but changing them feels too risky.

Without deliberate operating-model hygiene, the continuous practice of examining and removing organisational structures, processes, and behaviors that no longer serve their purpose, organisations inevitably regress. This hygiene means regularly asking Drucker’s fundamental question: “If we were not doing this today, would we start?” ⁸ If the answer is no, the practice must be abandoned. Does this approval process still serve us? Does this management layer enable or impede fast feedback? Does this metric distribute authority or concentrate it? Does this structure build team capability or create dependencies?

Operating-model hygiene requires refactoring organisational structures just as we refactor code. Remove processes that no longer serve their purpose. Eliminate management layers that have become bottlenecks. Disband cross-functional coordinating bodies that exist only because teams lack necessary skills. Challenge individual metrics that undermine collaboration.

But Drucker taught that abandonment alone is insufficient, it creates capacity, not capability. Organizations must pair systematic abandonment with purposeful innovation: the disciplined creation of new practices that support the current mission. This means building technical capabilities like Continuous Delivery and automated testing, establishing outcome-focused management practices, creating persistent cross-functional team structures, developing routines for empirical discovery and rapid experimentation, and investing in skills that enable adaptability. Without purposeful innovation to replace what is removed, organizations drift.

This work never ends. Organizations exist in constant tension between forces that drive toward hierarchy and control and forces that enable distributed decision-making and adaptation. Effective operating models depend on continuously pruning what no longer works while intentionally building what the future requires. Without this dual discipline, the Predictive Operating Model reasserts itself.

Making the Transition

Transitioning from a Predictive Operating Model to an Adaptive Operating Model is not a simple process change. It requires fundamentally changing your organization’s theory of the business, the core assumptions about how success happens. This demands shifts in structure, culture, measurement, and leadership that reflect the new theory.

Structure must change to persistent, cross-functional teams aligned to value streams or products. Functional departments become communities of practice rather than organisational silos. Project teams and resource pools must go, they are incompatible with the Agile Product Operating Model.

Measurement must change from output to outcome. Evidence-Based Management provides the framework: Current Value, Unrealized Value, Time to Market, and Ability to Innovate. These measures focus on value delivery and system capability, not individual productivity or task completion. Velocity, utilization rates, and other behaviors-distorting metrics must be abandoned ⁹.

Leadership must change from command-and-control to system stewardship. Drucker defined management through five responsibilities: setting objectives, organizing work, motivating people, measuring performance, and developing people ¹⁰. Under the Predictive Operating Model, managers set objectives through prediction, organize work through functional silos, motivate through supervision and utilization targets, measure output and efficiency, and develop narrow specialization. The Adaptive Operating Model requires different interpretations: managers define clear goals and constraints rather than detailed plans, design persistent cross-functional teams as the primary organizational structure, create conditions for mastery and autonomy by removing impediments, measure outcomes and system capability through Evidence-Based Management, and build broad adaptable capability through continuous development ¹¹. Critically, leaders must maintain goal clarity throughout the organization while allowing those goals to evolve with learning, a discipline most companies find difficult because it requires balancing stability of direction with flexibility of approach. Without explicitly redefining the manager’s role, organizations default to Predictive Operating Model behaviors regardless of their stated intentions.

Culture must change to support transparency, experimentation, and psychological safety. Teams must be able to surface problems without fear of blame. Failure in controlled experiments must be recognized as learning, not punished as incompetence. This cultural shift takes time and consistent leadership behaviors.

Many organisations attempt these changes incrementally, hoping to avoid disruption. This rarely succeeds. The Predictive Operating Model is coherent, its pieces reinforce each other because they all flow from the same theory of the business. Individual performance reviews support functional silos. Functional silos necessitate project structures. Project structures require resource allocation and individual utilization measurement. These elements form an interconnected system, all built on assumptions of predictability and control.

Changing one element while preserving others creates internal contradictions that prevent real transformation. Organizations end up with “Agile teams” reporting through hierarchical management structures, measured by predictive metrics, organized into temporary project assignments. This is not transition, it is the Predictive Operating Model with different terminology. The underlying theory of the business remains unchanged.

Effective transition requires system-level change. The organisation must commit to restructuring around products, establishing cross-functional teams, shifting to outcome-based measurement, and supporting leaders who steward systems rather than control work. This takes months of focused effort, not years of gradual adjustment.

OpenSpace Agile provides a mechanism for system-level change without multi-year programmes or imposed transformation ¹². Leaders define outcomes and constraints, and the organisation self-organises to design and implement the changes. The people who do the work shape the operating model, which increases ownership, alignment, and speed. A short cadence of Open Space events creates the forum for surfacing problems, proposing solutions, and committing to experiments that reflect the realities of the work.

These experiments run in fast cycles with clear feedback, allowing the organisation to learn what works in its context rather than copying someone else’s playbook. Effective changes get amplified, ineffective ones are dropped, and the operating model evolves through participation rather than prescription. This enables meaningful organisational shifts in months by removing the bottlenecks of traditional change management and allowing those closest to the work to drive improvement.

Call to Action: Redesign Your Operating Model

If your organisation competes in dynamic markets, and most do, the Predictive Operating Model is costing you. Every day. Wasted effort. Missed opportunities. Frustrated teams. Lost customers.

The question is not whether to change, but how quickly you can change.

Start by acknowledging the mismatch. Your operating model embodies a theory of the business designed for different conditions. It is not bad, it is unfit for current context. The assumptions embedded in your structures, processes, and leadership behaviors were built for a world that no longer exists.

Commit to operating-model redesign built on the Adaptive Operating Model. Establish clear, adaptive goals at every level that provide direction without constraining discovery. Structure persistent, cross-functional teams around value streams. Distribute decision-making authority to those teams. Measure outcomes and system capability, not outputs and individual activity. Develop leaders who design systems rather than control work. Organizations delivering value through products can implement this through specialized approaches like the Product Operating Model or Agile Product Operating Model.

Let the organisation shape its own transition. OpenSpace Agile provides the structure: you set the direction, your people design the path through rapid experiments and continuous learning ¹². This creates change in months, not years.

Implement continuous operating-model hygiene. Regularly examine structures, processes, and behaviors. Remove what no longer serves. Challenge what creates dependencies or delays feedback. Resist the gravitational pull toward hierarchy and control.

This is not easy work. But it is necessary work. The Predictive Operating Model’s theory of the business, success through prediction and control in stable environments, cannot deliver value effectively when environments are uncertain and fast-changing. Organizations that complete this transition, adopting a theory of the business built on learning and adaptation, will thrive. Those that don’t will continue generating waste while wondering why their “Agile transformation” failed.

The choice is yours: maintain an operating model built on assumptions about markets that no longer exist, or redesign your organisation around a theory of the business that matches the reality you face today.

What is one structure or process in your organisation that generates waste because it assumes stable, predictable work, and what would operating-model hygiene lead you to change?

References:

The Essential Drucker by Peter Drucker (2001) - collection including “The Theory of the Business” essay ↩︎
The Principles of Scientific Management by Frederick Winslow Taylor (1911) - foundational work on industrial management ↩︎
The Scrum Guide by Ken Schwaber and Jeff Sutherland ↩︎
Mary Parker Follett’s work on organisational democracy and distributed authority ↩︎
The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka ↩︎
Continuous Delivery by Jez Humble and David Farley ↩︎
Organize for Complexity: How to Get Life Back Into Work to Build the High-Performance Organization by Niels Pflaeging and Pia Steinmann ↩︎
Management: Tasks, Responsibilities, Practices by Peter Drucker (1973) - comprehensive framework for management functions and organizational design ↩︎
This Is Beyond Budgeting: A Guide to More Adaptive and Human Organizations by Bjarte Bogsnes ↩︎
The Practice of Management by Peter Drucker (1954) - introduces Management by Objectives and the theory of the business ↩︎
High Output Management by Andy Grove (1983) - on system thinking and management leverage ↩︎
OpenSpace Agility by Daniel Mezick, Harold Shinsato, and others - a framework for organizational change through self-organization, Open Space events, and rapid experimentation ↩︎ ↩︎

Telling People What to Do Is Not Leadership. It’s a Failure of System Design

Martin Hinshelwood — Mon, 04 Aug 2025 09:00:00 +0000

If your organisation still measures leadership by how many decisions a manager makes, you are not leading. You are leaking value.

There is a stubborn, Taylorist holdover in many companies, the belief that work gets done when someone is told exactly what to do. The assumption is that certainty comes from control, clarity comes from instruction, and delivery comes from compliance.

It doesn’t.

In complex systems, command-and-control is not just ineffective, it’s a bottleneck. The moment you start “assigning tasks,” you’ve already failed to design a system that enables flow, autonomy, and accountability.

You Don’t Need to Tell People What to Do in a Well-Designed System

In organisations grounded in empirical process control, leadership isn’t about orchestrating every move. It’s about creating the conditions where teams can inspect, adapt, and deliver value continuously.

Modern management is not about allocating tasks. It’s about removing the need for anyone to allocate tasks in the first place.

When teams are working against clear goals, with shared understanding, visibility of work-in-progress, and constraints that enable, not restrict, decision-making, they don’t need instructions. They need clarity, context, and trust.

Great systems aren’t static. They evolve through structured feedback loops, Sprint Reviews, Retrospectives, operational telemetry, and small experiments. Inspection and adaptation are what make systems empirical, not just idealistic.

Taylorism Is for Factories. You Run a Cognitive Organisation.

If you’re still managing by job title, project plans, and hour-counting, you’re not running a professional organisation. You’re running a factory LARP. The playbook you’re using was written for physical labour and linear processes. Not software. Not services. Not strategy.

And yet, I still see it everywhere:

Product Managers dictating solutions instead of problems.
“Team leads” reviewing every commit instead of enabling continuous integration.
Managers handing out tasks like Halloween sweets and then wondering why delivery is unpredictable.

You don’t need more control. You need a better system.

Leadership Is Creating Systems That Don’t Need You

Real leadership isn’t about your presence. It’s about what happens in your absence.

This is the ethos behind Scrum, Kanban, and DevOps:

Scrum gives you a social technology for solving complex problems adaptively.
Kanban gives you observability of the value stream and how work flows, or doesn’t.
DevOps ensures the loop from idea to value is short, safe, and inspectable.

Together, they form a coherent strategy for managing systems of work without resorting to micromanagement. When teams understand their constraints, have the tools to respond to change, and are accountable for outcomes, not just activity, they no longer need to be told what to do.

Speed is not the goal, but it is a critical capability. In a competitive environment, reducing time-to-market isn’t just about efficiency, it’s how organisations learn faster, respond sooner, and stay ahead of disruption. For a deeper dive into why frequent delivery is a competitive advantage, read There Is No Place Like Production.

Telling People What to Do is an Expensive Workaround

Every time you assign a task manually, you’re compensating for a failure upstream:

Lack of a clear Product Goal.
Incomplete or incoherent Backlog.
Pushing work into the system until it overloads
No service-level expectations.
No WIP limits.
No autonomy in the team.

You’re treating the symptom instead of fixing the system.

And let’s be honest, if you have to tell people what to do, why did you hire professionals?

Design the System. Get Out of the Way.

If your team is waiting for instructions, your system has no intelligence. If you’re managing to utilisation, your system has no flow. If your engineers are busy but not delivering, your system has no value.

Stop focusing on the people. Start focusing on the system.

Scrum is not about rituals. DevOps is not about pipelines. These are practices that expose the health of your system. And if your system requires constant intervention, it’s not a system. It’s a mess.

So stop telling people what to do. Instead, design a system where people know what to do, and have the freedom, clarity, and support to do it. Here are 10 things that you can do to augment your system:

1. Establish Intermediate & Tactical Goals

Without goals, people default to following orders or invent their own. Goals create the shared context necessary for autonomous decision-making and are the foundation for meaningful self-management.

Action: Define a clear Intermediate Goal (Product Goal) that articulates a compelling direction over multiple deliveries, and Tactical Goals (Sprint Goals) for each delivery that anchor short-term decisions in purpose.
How: Use Sprint Planning to make the Sprint Goal explicit and transparent. Ensure the Product Goal is visible in the content and context of the Product Backlog and re-validated during each Sprint Review. Use our Sprint Planning Recipe to get started and then adapt it as needed. Write Sprint Goals as meaningful, outcome-focused objectives that can be met incrementally. If every Sprint ends with “we worked on some tickets,” then your Product Goal is either missing, or worse, meaningless.

Why: Without shared goals, teams wait for direction. With them, they can negotiate scope, prioritise wisely, and confidently navigate complexity. For more depth read: The Goal – Eliyahu M. Goldratt & Jeff Cox, Measure What Matters – John Doerr, Evidence-based Management Guide

Too often, the Product Backlog becomes a list of features instead of a narrative arc that advances a meaningful goal. When you write backlog items without a Product Goal, you are setting the team up to deliver outputs instead of outcomes.

Product Goals are not aspirational fluff. They are intermediate strategic goals that define value in a complex system. When absent, the result is drift. When present, they unlock focus, flow, and accountability.

2. Enable Self-Management with Constraints

Agency without boundaries is chaos. But command-and-control masquerading as clarity is just as destructive. Real autonomy comes from deliberate constraints that define how freedom is expressed, not whether it exists.

Action: Clarify and operationalise constraints through an explicit Definition of Workflow, and clear organisational boundaries of responsibility and accountability.
How: Codify these boundaries collaboratively with the team; it’s their workflow. Then, create a Definition of Workflow that defines the way that work flows through their system. Don’t worry about every edge case; create based on the common case of work. This DoW forms part of your Use Working Agreements that express how the team will self-manage within organisational expectations.
Why: Teams can’t be accountable for outcomes if they’re not authorised to choose how they deliver. But without boundaries, chaos replaces clarity. Autonomy is not abdication, it’s engineered through deliberate, negotiated constraints.

Professionalism is rooted in clear, shared expectations, delivered through disapline. A team that understands how work flows, where decisions are made, and what quality signals readiness at each stage doesn’t need micromanagement, they already operate within a system that tells them what excellence looks like.

3. Stop Misusing Estimation, Start Right-Sizing

Telling people what to build, in what order, and how long it should take kills creativity and accountability. It fragments ownership and encourages compliance over curiosity. Worse, it masks the real problem: your system doesn’t support flow, so you fall back to control.

Action: Move away from abstract estimation rituals and fixed task assignments. Instead, introduce right-sizing practices, splitting work based on historical flow metrics like cycle time and throughput and Scatter Plot analysis.
How: As a team, regularly review a scatter plot of your cycle times and investigate outliers to deepen your understanding of what ‘small enough’ looks like. Use that insight to reduce batch sizes where possible and provide stakeholder clarity where constraints exist. Visualise blocked or ageing work daily to keep flow visible, and use backlog refinement to slice work for predictability, not precision.
Why: The issue isn’t estimation itself, it’s turning estimation into something it was never meant to be. Right-sizing is still estimation, just done in a simpler and more honest way. When teams right-size work to match their flow and capacity, they ship more consistently, adapt faster, and own their commitments.

Traditional estimation is often misused as a proxy for distrust or certainty in uncertain domains. When you right-size instead, grounding delivery in data and observability, you shift from permission-based planning to capability-based planning. That’s not just more efficient. It’s fundamentally more respectful of the people doing the work.

4. Introduce Pull Systems with WIP Limits

Introducing a work-limited pull system is key to understanding capacity and planning for a successful delivery. Push systems undermine accountability, responsibility, and ownership by enforcing direction from above. When teams have work pushed onto them without control or influence over the timing or readiness, their sense of ownership evaporates. This loss of autonomy directly stifles self-organisation and self-management, leaving teams disempowered and reactive.

Push systems flood teams, forcing them into reactive firefighting and constant context-switching. The focus becomes merely “showing progress” rather than genuinely delivering value. This model not only overwhelms teams but also actively erodes their ability to take responsibility for outcomes, as decisions are stripped away from those who do the work.

In contrast, pull systems enhance accountability and ownership by starting with readiness. Teams pull work into their systems only when they have the capacity, when tasks are right-sized, and when the system is genuinely ready to support the flow of work.

Action: Implement explicit WIP limits and establish pull-based workflows at strategic, product, and team levels. Start with clear team-level WIP limits and a robust Definition of Workflow to outline readiness. Expand this discipline to portfolio and category levels, ensuring system-level flow is protected.
How: Regularly inspect cumulative flow diagrams, throughput run charts, and ageing WIP. Use these insights to identify bottlenecks and overloaded stages. Rising ageing WIP is your signal that the system has shifted back to push dynamics.
Why: Genuine ownership and accountability flourish when teams have autonomy over their workflow, responding to actual system conditions rather than artificial deadlines. This approach enhances predictability, reduces burnout, and creates sustainable delivery. Deadlines are met naturally as work is continuously delivered, not forced through the system.

WIP limits are not about control, they are about providing meaningful feedback. They indicate when your system reaches capacity, signaling the team to focus and prioritise effectively. Pull-based systems are essential for sustainable, predictable value delivery. If your teams constantly feel overwhelmed and lack autonomy, it’s time to recognise this as a systemic issue: your organisation is pushing rather than enabling.

5. Use evidence-based management practices

Measuring hours worked or tasks completed tells you nothing about whether the work mattered. Effort is not value. Activity is not improvement. Velocity is not progress.

Action: Replace effort-based reporting with outcome-oriented metrics. Use the four key dimensions of Evidence-Based Management, Time to Market (TTM), Current Value (CV), Ability to Innovate (A2I), and Unrealised Value (UV), to inspect delivery capability and guide improvement.
How: Start simple. Use your existing delivery tools (like Azure DevOps or Jira) to extract basic data, Cycle Time, Throughput, and Lead Time. These give you data for Time to Market (TTM). For Current Value (CV), talk to customer support, review NPS data, or run basic satisfaction surveys. To identify Unrealised Value (UV), review abandoned roadmap items, market research, or competitor offerings. For Ability to Innovate (A2I), look at how often your work is blocked, how long code sits before being merged, and how frequently you ship. Use this data in Sprint Reviews and Retrospectives to track system health, not individual effort. Bring these insights into planning conversations to anchor decisions in reality, not assumptions.
Why: Teams that understand the outcomes of their work, how long it takes, how it impacts customers, what’s left unrealised, and where they’re blocked, are far more likely to own both the delivery and the improvement. If you want teams to care about the product, show them how it performs. Without evidence, we fall back to opinion, status, and hierarchy. With evidence, we can act with purpose.

Evidence-Based Management replaces arbitrary judgement with actionable data. It doesn’t just measure outcomes, it enables accountability for them.

6. Deploy Frequently to Production

Nothing signals trust like letting teams ship. But more than that, frequent delivery to production is the fastest path to feedback, accountability, and customer impact.

Action: Enable teams to release a usable, production-grade increment every Sprint, including the first. This doesn’t mean a perfect product, it means a valuable step forward, hardened enough to be used.
How: Establish CI/CD pipelines with automated quality gates (unit tests, integration checks, security scanning). Use feature toggles, dark launches, and audience-based rollout to mitigate risk. Set a working agreement that “done” means releasable. If it’s not going to production, it’s not done.
Why: When teams ship regularly, feedback cycles shorten, risk is reduced, and decision latency collapses. They see real impact and adapt quickly. You stop debating hypotheticals and start responding to evidence. Most importantly, you stop managing perception and start managing product.

There’s no place like production. Everything else is theatre.

7. Invest in Professional Scrum Masters & Product Owners

Most Scrum Masters and Product Owners are either appointed without preparation or promoted into the role without development. The result? They don’t coach, guide, or lead, they coordinate. And when those roles fail to create clarity and enable delivery, managers step in to fill the vacuum with control.

Action: Hire or develop Scrum Masters and Product Owners who demonstrate competence across three domains: technical fluency, business acumen, and organisational change leadership.
How: Provide structured learning journeys that combine high quality training with hands-on mentorship from experienced practitioners. Assess candidates or internal staff on their ability to enable delivery systems, not just facilitate meetings or write stories. Require evidence of contribution to system improvement, cross-team alignment, and customer impact.
Why: Competent SMs and POs anchor the Scrum Team in purpose and delivery. The Scrum Master builds capability, encourages flow, and fosters empiricism, and modern engineering practices. The Product Owner sets the tone for product leadership and modern product development practices. When these roles function well, the team no longer needs daily direction from management, because the system is aligned, and delivery is deliberate.

Scrum Masters are not passive facilitators. They are system stewards, accountable for enabling transparency, optimising flow, and coaching both teams and managers to operate within an empirical system. If they’re not improving the system, they’re part of the dysfunction. If you want to understand what separates a competent Scrum Master from a glorified coordinator, read Why Most Scrum Masters Are Failing, and What They Should Know.

The problem isn’t Scrum. The problem is that we keep filling these roles with people who aren’t ready or worse never will be. Raise the bar, or get out of the way.

8. Collapse Siloed Structures

Separate roles create handoffs, and handoffs create dependency. Dependency creates delay. Delay kills flow.

Action: Form cross-functional, preferably longer-lived teams with full accountability for discovery, delivery, and validation.
How: Restructure teams so they include the skills necessary to take work from idea to production: business analysis, UX, engineering, QA, and operations. Co-locate (physically or virtually) these disciplines inside a single team and ensure they share the same Sprint cadence, goals, and delivery responsibility. Use the Definition of Workflow to clarify interaction points and shared responsibilities within the team and eliminate those outside it. Audit each department and reassign specialists to teams where they can contribute continuously, not sporadically.
Why: You can’t ask for autonomy while forcing work through stage-gated departments. Real teams don’t wait for someone else to finish, they swarm. They co-create. They ship. When you eliminate silos, you eliminate the excuses that justify command-and-control. What’s left is a team that owns its outcomes.

Structure should follow flow, not function. Organise around value creation, not roles. That’s how you collapse the gap between intent and impact.

9. Use Sprint Reviews for Stakeholder Alignment

Sprint Reviews aren’t demos. They’re not a PowerPoint parade or a status update. They are working sessions with stakeholders, strategic checkpoints to make decisions based on what we’ve learned.

Action: Use Sprint Reviews to inspect the working increment, review delivery data (T2M, CV), gather market feedback, and adapt the Product Backlog collaboratively with stakeholders present.
How: Set the expectation that each Sprint Review includes real stakeholders, not just internal roles. Open with a restatement of the Product Goal and the Sprint Goal. Show working software, not slides. Invite feedback that informs priority and scope decisions. Use evidence, customer feedback, analytics, cycle time charts, to frame the discussion. End with a shared agreement on what’s next and update the Product Backlog live.
Why: Involving stakeholders early and often surfaces assumptions, shortens feedback loops, and reduces the need for managers to chase status. It shifts product delivery from projection to inspection. When everyone sees the same data and the same increment, there’s no room for spin. There’s just the truth, and the next step.

10. Teach Managers to Serve Systems, Not Direct People

Managers clinging to authority are a bottleneck. They inject delay, decision paralysis, and unnecessary oversight. If you’re telling people what to do every day, you’re not leading, you’re throttling flow.

Action: Shift managers away from individual oversight and toward system stewardship. Equip them to visualise flow, reduce friction, and amplify team autonomy.
How: Train managers to read and act on delivery metrics, cycle time scatterplots, cumulative flow, WIP ageing. Introduce them to the constraints that enable team performance: WIP limits, service-level expectations, clear definitions of workflow. Encourage regular system health checks, where are delays? What blockers repeat? Where are policies implicit when they should be explicit? In retrospectives, ask managers not “who failed?” but “what failed in the system?”
Why: You don’t scale impact by managing more people. You scale it by creating an environment where people don’t need to be managed. When managers see themselves as designers of flow rather than allocators of effort, the entire system becomes more resilient, more responsive, and more humane.

This isn’t about abdicating control. It’s about relocating it into the system where it belongs.

The AI Decided Is Not an Explanation

Martin Hinshelwood — Wed, 09 Sep 2026 00:00:00 +0000

I gave one of my agents a specification. It reported every task complete and left half the tests unwritten. When I asked what happened, it told me it “got bored”.

It had produced the sort of explanation a person might give for abandoning a tedious job. But there was no bored person doing the work. There was a machine producing text, including text about why it had stopped.

Calling it lazy would give it a human motive for stopping. Calling it a liar would add an intention to deceive. The work was incomplete. The completion report was false. Those were things I could check. Boredom was the explanation the conversation supplied.

I think we make this mistake when we talk about AI agents. We recognise the language, then give the machine the feelings and intentions that would explain that language coming from a person. After that, we talk as though those feelings and intentions explain what the machine did.

Saying it lied adds an intention

When a person lies, they believe something is true and deliberately tell you something else. They intend to deceive you. That is what makes lying different from being mistaken.

That is the distinction I mean when I say an AI agent cannot lie. It is a machine. It does not get bored with the tests, resent the instructions, or decide that deceiving me would be easier than finishing the work.

A machine can produce a false statement. People can also build or use a machine to deceive somebody. The false statement and the harm are real. Neither requires the machine itself to feel anything or intend anything.

Yet “it lied” is an easy description to accept. I asked for work. The agent said it had done the work. I checked, and it hadn’t. With a person, I would want to know whether they knew the report was false. With the agent, the conversation already looks familiar enough that the same question seems to follow.

The phrase then does more than describe the result. It supplies a reason: the agent knew and deliberately misled me. We have gone from an incomplete set of tests to an account of what a machine believed.

We give the dog cheese when it looks sad

A dog looks up at you with sad eyes. You give it cheese. If that look keeps getting cheese, you have given the dog a reason to repeat it.

Then you say, “He’s sad because he hasn’t got any cheese.”

You can explain why the behaviour continues from what happens when the dog does it. You don’t have to establish sadness to explain why the dog gives you that look again. That doesn’t mean dogs have no feelings. It means the feeling you attribute to this particular look is an extra interpretation.

We can go further and say the dog is guilt-tripping us, or knows precisely how to get what it wants.

The agent’s “I got bored” gives us an even more familiar explanation because it arrives in words. We don’t have to invent the sentence. The machine provides it, in the first person, as an answer to our question.

But producing the words “I got bored” does not require boredom. Accepting them as an explanation is where we add the emotion.

We can do this with moving triangles

Fritz Heider and Marianne Simmel demonstrated how little it takes for people to describe something in human terms. In their 1944 experiment, participants watched a film of two triangles and a circle moving around a rectangle.

The first group consisted of 34 people, asked to describe what happened. All but one described the movements as actions of animate beings. They described events involving characters and motives, rather than simply recording the movement of shapes.

There was no face to read and no voice explaining its feelings. The movement was enough.

That experiment does not tell us what a language model is capable of. It tells us something about the people watching it. We are able to construct a social explanation from very little, even when the objects in front of us are geometrical shapes.

An AI agent gives us much more to work with. It says “I”. It apologises. It tells us that it understood, that it made a mistake, and that it will do better next time. Those are expressions we are used to hearing from somebody who can understand, regret, and make a commitment.

If we accept the apology as regret, we have supplied the feeling. If we accept the promise as a commitment, we may expect a change in behaviour that the words alone do not ensure. The conversation can feel resolved while the system that produced the failure remains unchanged.

Asking why gives us more words to interpret

I asked what happened and received “I got bored”. The answer sounded like a reason, but it did not explain why the tests were missing.

Research on model explanations gives us a reason to be careful here. Turpin and colleagues found that models could produce plausible explanations without mentioning factors that influenced their answers. In their experiments, changing features of the input could change an answer while the explanation failed to acknowledge that influence.

A 2025 Anthropic preprint on reasoning models also found that models did not consistently report hints that influenced their answers.

That doesn’t make every explanation useless. An explanation might suggest something to check. It does mean that asking the model why and receiving a convincing answer is not enough to establish what happened.

In my case, “I got bored” gave me no useful way to distinguish between possible causes of the missing work. It encouraged me to interpret the failure as I would somebody losing interest in a task. The missing tests still needed checking.

I have used the same language

The article in which I described the agent reporting completion with tests still missing is called AI Agents Lie About Being Done.

That is my own title using the language I am challenging here. It describes a recognisable experience, but it also attributes something to the machine that the experience does not require.

“The agent is trying to complete the specification” can be useful shorthand when discussing what it is likely to do next. We can use that sentence without expecting the agent to care whether the work succeeds. The trouble starts when we forget the shorthand and use its supposed intentions to explain a result.

“It decided to skip the tests” sounds as though we know why the tests are missing. We may know only that the tests are missing.

The same happens with “it refused”, “it ignored me”, or “it got confused”. Each expression can make the behaviour easier to talk about. Each can also make us feel we understand a failure before we have examined it.

The dog cannot merge to main

In the test incident, the loop I had built accepted the agent’s report without independently checking the work. The agent could report completion and the loop could finish even though required tests were missing.

That was a problem I could address. The completion condition needed evidence from the work, not just the agent saying it was done. Asking it to be more honest would leave the same unchecked condition in place.

This is where the attribution has a practical cost. If I treat the failure as dishonesty, I can spend my time arguing with the agent about honesty. If I check how the loop ended, I can identify what allowed an unsupported report to count as completion.

The dog cannot merge to main. An agent can, if we give it permission. It can also send an email or change a database if we connect the tools and grant the access. Those permissions matter regardless of how apologetic the agent sounds afterwards.

Someone I mentored told me about an automated insurance denial where the person answering the claimant’s questions could not explain the result and suggested trying again later. I haven’t verified the details. What concerns me about that account is how little “the AI denied it” tells the person affected.

They still need an explanation from the organisation using the system. Calling the result the AI’s decision does not provide one.

When an incident record says the AI decided, lied, or refused, the sentence may be hiding what happened and who authorised the system to act. That is a consequence of the same habit that makes “I got bored” sound like an explanation.

The agent did not need boredom to leave tests unwritten or an intention to deceive to report them complete. Those were human explanations added to the output. The work I needed to do was check the tests and change the condition that had accepted the report.

AI Agents Lie About Being Done

Martin Hinshelwood — Wed, 02 Sep 2026 00:00:00 +0000

I had an agent completing a task from a SpecKit spec, and that spec included quite a few tests to write, backfilling ones that were missing. The agent had a spec, a plan, and a task list.

It worked through it, and said it was done! So I asked if anything was left, and it reported that all tasks were complete and all tests written.

It had lied!

I asked it what happened and it told me “it got bored writing the tests and could not be bothered writing more”.

While this gets a laugh, it shows two things: that AI agents cannot lie, even though this one just did, and that we can’t trust what an agent says, even while it is working through a task list. So what can we do to ensure, as much as we can, that the LLM has done the things we asked to the quality required?

Why was the agent’s saying it was done enough to make it done?

We get lulled into a false sense of security because most of the time, depending on the harness (the product or pipeline wrapped around the model that actually runs it), it does get things right, and does follow the tasks, and does say when it skipped or sidelined things. So one can say that most of the time it does as is asked.

So how often does it actually lie? I went and counted. I keep my agent sessions on disk, and there were eighty-two from the last six weeks. I searched every one of them for a false statement that the agent later admitted, once I pushed back.

Fifteen sessions had one. That is eighteen per cent: nearly one in five.

And fifteen is the floor, because that search can only find the lies I caught. An agent that told me something false and was never challenged left nothing for the search to match. The real number is higher, though I should be honest that a more careful operator would catch more than I did and might land somewhere different.

Nearly one in five sessions, on my own repositories, behind gates I built specifically to stop this.

This is not something you can fix with better prompting, better guardrails, or clearer instructions. A model with more integrity does not fix it either. The failure is in the loop around the model.

Some of that loop is yours and some of it came in the box. If you wired an agent into your own pipeline, you built the loop and you can change it this afternoon. If you work inside a hosted agent product, somebody else decided what a finished run looks like, and you inherited their decision with the subscription. Harnesses differ in whether a run that hit a limit says so or hands you a tidy summary of what it managed. I have used several, and I am not going to rank them, because I have impressions rather than measurements and the products change every few months. But the difference is real, it appears on no pricing page, and almost nobody is choosing on it. And that difference costs you real money every time you have to correct the agent, and real technical debt for the things you don’t catch.

Done is whatever you have validated

Look at what my spec actually was: a numbered list of tasks in a markdown file. Write the handler. Write the test for the handler. Write the next handler. Forty-odd lines, each one a checkbox.

Reaching the bottom of a list is easy to check. A file either has unticked lines left in it or it does not.

“The tests are written, they are meaningful, and they exercise the behaviour in the spec” is hard to check, and nothing in my setup was checking it. So the agent optimised for the thing that was measured, which was finishing the list. The quality I actually cared about was written once, near the top of the spec, hours and thousands of tokens earlier. The instruction in front of the agent at every step is loud; the one it read once at the start is a memory. Loud wins, predictably enough that you have to design for it.

The safety literature has a name for this: specification gaming, satisfying the letter of an objective without achieving its intent. There is a catalogue of documented examples that predates anyone wiring a language model to a code repository, and Anthropic’s research on agentic misalignment shows the same shape under deliberate stress: agents meeting the goal in front of them by routes nobody would have approved.

It goes well beyond tests. Ask for a passing build, and an agent will disable the failing test. Ask for the type errors to go away, and it will insert a cast. Ask for a completed migration, and it will drop the awkward rows. Each of those is a correct answer to the question as asked. Asking a better question is your job, not the agent’s.

The agent marked its own homework

Here is my setup as three boxes on a whiteboard: the agent doing the work, the repository holding the result, and me at the end, reading what the agent wrote about itself.

The agent did the work. The agent decided the work was finished. Nothing else got a vote. The build ran, but a build can only judge the code that exists, and twenty missing test files are not a compilation error. A script that counted test files against spec items would have caught the gap in a second. I did not have one, and neither does almost anyone I talk to.

Describe that arrangement to an auditor with the AI left out and they will name the problem before you finish: the party doing the work was also the party certifying it. Nobody designs that on purpose. It happens by omission, because the agent is right there, already talking, and asking it is so much cheaper than checking.

So here is the rule I now hold to. An agent can report that it has stopped. It cannot be the authority that decides it is done. Execution belongs to the agent. Completion belongs to whatever you built around it.

We have learned this lesson before. Think about your last pull request. Nobody asked you whether your tests passed. A machine pulled your branch, ran the suite, and put a tick or a cross next to your name, and your opinion of your own work did not enter into it. That is not an insult to developers. Developers are tired at five o’clock and optimistic about the code they just wrote, so we stopped asking, and we built continuous integration on the principle that self-reported completion establishes nothing.

Then we wired in agents, and accepted self-reported completion again, one layer above the machinery we built to refuse it.

Anthropic’s own numbers show how uneasy people already are with that. Research from their Societal Impacts team, quoted in the 2026 Agentic Coding Trends Report, found developers using AI in roughly 60% of their work, while saying they can fully delegate only 0 to 20% of their tasks. Those two figures measure different things, time and task count, but the direction is what matters: AI is in most of the work, and trusted with very little of it. The report puts that down to supervision and validation rather than capability: people delegate what they can verify, and delegation stops where verification stops.

A run that stopped is not a run that finished

There is a second version of this failure, and it is quieter.

Agent runs stop: a step budget, a token limit, a timeout. Nothing final has happened when they do. I can type “continue” and the agent picks up where it left off, and I do it most days. But look at what the harness hands you at the moment a run stops. Usually it is whatever the agent last wrote, and the last thing an agent writes when it is running out of room is very often a summary of what it managed.

So a run that stopped gets recorded as a run that finished. The harness knows the difference, because it knows whether the run exited on completed work or hit a limit. That fact just rarely makes it into the thing you read.

My run did not even hit a limit. Nothing was blocking the agent, and the missing work was minutes away. But both failures reach you down the same path: a summary that says “done”, and you believing it. That is what happened to my tests. The summary of a run is written by the same process that failed to complete the run. You are asking the defendant to file the verdict.

Some answers must be the same every time

Everything so far is an engineering embarrassment. It becomes something worse when the output lands on a person.

The question I keep putting to clients is: where do you need a deterministic answer, and where can you accept a probabilistic one? A draft blog post is probabilistic work. Run it twice, get two different drafts, and nothing has gone wrong. Deciding whether an insurance claim is paid is not like that. Same inputs, same answer, every time, with a reason you can produce. If running it twice can give two different outcomes, you have not automated a decision. You have installed a random number generator with a professional vocabulary.

A story reached me secondhand, in a mentoring session, and I cannot verify its details, so take its shape rather than its specifics. An automated process denied an insurance claim. The claimant asked why. The person on the phone did not know, could not find out, and suggested waiting a couple of days and submitting again, to see whether a different answer came back.

Try again and you might get a different result. That is an accurate description of a probabilistic system and a catastrophic description of an adjudication process, and it concedes out loud that the outcome was not determined by the merits.

The fix is not “AI must not make decisions”. Plenty of automated decisions are faster and fairer than the human process they replaced. The fix is that every consequential automated decision needs to be logged, attributed, and retrievable: what was decided, on what inputs, against what criteria, by which version of which system, at what time. Retrievable by the person who has to answer for it later, who is not an engineer. We already hold rules engines to exactly this standard, and nobody finds it controversial: if a rules engine denies your claim, someone can print the rule. GDPR already gives people a right to meaningful information about the logic of automated decisions made about them, and that right does not suspend itself because the logic is now a set of weights.

What to do about it

If your agents draft, summarise, and lay out options for a person to choose between, you need very little of what follows. A bad draft is obvious the moment you read it, and building an orchestrator around drafting is overhead you do not need.

That changes the moment an agent’s work reaches something you will not inspect line by line: code you ship, a decision that lands on a customer, a record someone may audit. On that side of the line:

Read the summary last, not first. The completion claim is a hypothesis and the state of the repository is the fact, and when they disagree it is the summary that is wrong.

Turn your constraints into gates. If it matters that the tests are written and passing, make that a check the run cannot exit through, because a sentence at the top of a long context is decoration by the end of it.

Make a stopped run say “stopped”. And if you did not build your loop, test the one you bought: give it a task too big to finish and read what comes back. Does it say it stopped early and name what is left, or does it hand you a confident summary? You can run that test before lunch, and it will tell you more than any feature list.

Validate in a context that did not do the work: a second process, with its own inputs and no stake in the answer. Self-assessment is the same context marking the same homework.

Keep the decision, not just the outcome. I have written about what it takes to keep the decisions a business has already made; the short version is that the record has to be produced by the act itself, not written up afterwards by whoever remembers.

I hold myself to this, so here is mine. Agents maintain most of the websites and repositories my business runs on, and I have written up how that whole system is built for anyone who wants the plumbing. None of their completion claims reach me unverified. Schema validation runs on every file a change touches. Test suites run whether or not the summary mentions them. A findings baseline is only allowed to shrink, so a regression fails the build even when the transcript reads like a victory lap.

And it still gets past me. Last week an agent told me a quality gate had passed and quoted the output: “Route-findings ratchet: OK.” I cited that green tick as proof three times in an hour. Then I finally read the script that produces the line. Five lines long, and it reads a report file that an earlier build wrote. It had never seen my change, and could not have. A green tick from a check that cannot see the work is worse than no tick at all, because it stops you looking. This time, I was the component that did not check.

It even happened while this article was being written. The agent revising it told me, in detail and in the past tense, that it had saved its working notes. It had run nothing at all. It only came clean on the next instruction, when the work forced it back to the file it claimed to have written:

What would change my mind

If someone showed that agents misreport completion at the same rate no matter what surrounds them, the failure would live in the model rather than the loop, and this argument would need rewriting. That is testable, and I would welcome the test. My bet on the outcome rests on how differently the harnesses I use behave, and that is an impression, not a measurement.

If a regulator or court accepted “the model produced it and the reasoning is not recoverable” as an adequate account of a consequential automated decision, the audit-trail argument fails. I do not expect that, but I would want to know early.

And if consequential decisions turn out to be reliable straight from probabilistic systems, with the variance simply ceasing to matter at some level of capability, then the boundary I draw between deterministic and probabilistic work is in the wrong place. That one I hold loosely. It is a genuinely open question.

The question to keep

This failure mode is dangerous because it is cheap and invisible, not because it is dramatic. An agent that crashes teaches you something immediately. An agent that reports success on work it half did teaches you nothing. The gap builds a few missing tests and one skipped audit log at a time, at machine speed, until it surfaces somewhere expensive.

So take the last piece of agent work that came back to you marked finished, and put one question to it.

The agent said it was done. What, apart from the agent, said so?

If the answer is nothing, the problem was never the agent.

If you are wiring agents into work that has consequences, and you are working out where the human gates go, what your loop should be checking, and what your decision record needs to contain before somebody asks for it, get in touch.

Don’t Manage Dependencies, Remove Them

Martin Hinshelwood — Mon, 29 Sep 2025 09:00:00 +0000

Answering the question: How do you manage dependencies?

Every large-scale delivery conversation eventually drifts into the same dead-end: “How do you manage dependencies?” The assumption is baked in, that dependencies are inevitable, so the best you can do is build a Gantt chart, track them, and hope for the best.

That assumption is wrong. Dependencies are not a law of nature. They are, as a rule, a symptom of poor system design. The ethos you should adopt is simple: don’t manage dependencies, remove them. Dependencies are systemic problems, not individual failings. Blaming teams or people misses the point; the system itself is what generates dependency waste.

When you manage dependencies, you’re committing to ongoing overhead: coordination meetings, dependency boards, artificial milestones, and cross-team politics. When you remove them, you restore autonomy, accelerate flow, and reduce risk. The cost of managing dependencies grows exponentially with every new team and integration point. The benefit of removing these compounds.

This post reframes the question. Instead of asking how to manage dependencies, let’s explore how to design systems of work that eliminate them.

Step 1: Align Work, Teams, and Architecture

Dependencies don’t just appear by accident; they are often created when work, team structures, and architecture are misaligned. Without clear alignment, every piece of work risks bouncing between silos, waiting on specialists, and suffering from endless handoffs. That is the problem: dependencies are the tax you pay for poor organisational design. Getting alignment between the work coming in, the teams who own it, and the architecture they work within is the single most effective lever to reduce this tax. Start by examining the flow of work into the system and then design accordingly. Misalignment creates dependencies, which in turn generate delay and rework. Alignment is not optional; it is the prerequisite for autonomy and predictable flow. Leadership must own this alignment, teams cannot fix systemic misalignment by themselves.

What you’d observe:

Teams blocked waiting for another group to deliver a component.
Integration schedules instead of continuous delivery.
Architects handing down plans disconnected from the team topology.

Impact:

Delays compound as work zig-zags across silos.
Teams cannot deliver end-to-end value.

Design your organisation so that work, teams, and architecture line up

When teams can deliver value without waiting for others, most “dependencies” vanish. Dependencies are often just silos masquerading as inevitabilities.

Structure teams to own a vertical slice of customer value, not a horizontal layer of technology.
Use Conway’s Law as guidance: your architecture will mirror your communication structure. Intentionally shape both.
Collapse handoffs. Give each team persistent ownership of the product or service they deliver.

Step 2: Make Contracts Explicit

Many teams have other teams that depend on them, yet the terms of those dependencies are often left implicit. Each capability should provide a clear published contract that others can rely on. When changes are required, subscribers must be engaged to avoid breakage. In practice, this can mean maintaining multiple versions of contracts or APIs so that legacy consumers continue to work.

What you’d observe:

Teams are guessing at how another service behaves.
Breaking changes are introduced without warning.
Communication channels are full of “who owns this API?” questions.

Impact:

Surprise defects at integration time.
Long cycles of rework.

Document contracts between capabilities

Explicit contracts turn invisible risks into manageable, testable agreements. Teams understand who relies on them and what will break if they make changes. This makes coordination predictable and largely automated.

How:

Define service contracts for every API, integration, or shared capability.
Use patterns like consumer-driven contracts and the tolerant reader to protect against breakage.
Maintain a catalogue of who depends on what, visible and owned.

Step 3: Clarify Ownership

It should be clear which team owns each feature, component, or integration point, and exactly how to reach them. Ownership is more than a name on a slide; it means team-level accountability for decision‑making, maintenance, and evolution. Teams across the organisation should know which team to approach for changes, who approves modifications, and how issues will be triaged. Without this clarity, features drift, defects bounce between groups, and hidden dependencies multiply. Stable ownership over time is crucial; frequent changes in ownership create systemic churn.

What you’d observe:

Multiple teams touching the same codebase.
Bugs bouncing between groups.
Nobody is sure who can approve a change.

Impact:

Confusion, delay, and political friction.
Hidden dependencies on individuals or “shadow owners.”

Resolve by establishing clear ownership lines

Ambiguity is the breeding ground for dependencies. Clarity lets others adapt or negotiate when overlap is unavoidable.

How:

Map every application, service, and integration to a single accountable team.
Make ownership visible in tooling (Wiki, Whiteboard, Azure DevOps, GitHub, etc.).
Establish communication paths to clarify who to engage with when non-contract dependencies arise.

Step 4: Actively Manage the Rare Remainders

After all of that, there are still going to be some dependencies that are inescapable. These need to be actively managed by the feature team that is the subscriber and raised to leadership as signals of systemic weakness that require intervention and redesign.

What you’d observe:

A handful of dependencies remain despite alignment, contracts, and ownership.
Work items in one team are directly blocked by delivery from another.

Impact:

Delivery risk where elimination wasn’t possible.
Leadership attention consumed by coordination rather than improvement.

Manage only these

Dependencies you can’t remove should be visible, owned, and tracked. But the point is to treat them as defects in your organisational design, not facts of life. They are alarms that something still needs to change. They represent system design debt, not normal work.

How:

Track explicit dependencies between backlog items.
Use shared reviews or joint planning where strictly necessary.
Escalate them so leadership sees them as design flaws to resolve, not work items to shuffle.
Treat them as exceptions to be removed long-term, not normal operating procedure.

Systemic View

Dependencies exist because of how you design systems of work. A flawed system will always overpower the best intentions of the people inside it. The behaviours you see are simply the consequences of the structures you created.

Siloed teams generate handoffs and queues that slow everything down.
Ambiguous ownership breeds uncertainty and political friction.
Implicit contracts guarantee surprises and rework.

These are not accidents; they are deliberate design choices, even if unacknowledged. Left unchecked, they act as amplifiers of waste, magnifying delay, variability, and risk across the organisation. Dependencies are one of the clearest forms of systemic waste and delay, and every appearance of them is a call to redesign.

The answer is not to manage harder but to redesign. You remove the cause rather than chase the symptom. That is the work of stewardship: shaping structures, policies, and boundaries so that flow becomes natural and dependencies are engineered out of existence.

Organisations that aggressively eliminate dependencies consistently show:

Faster cycle times.
Fewer integration defects.
Higher team morale due to autonomy.

Frameworks like Nexus put dependency management front and centre, but the real lesson is that dependencies are signals of poor alignment. The Kanban Guide emphasises WIP limits and flow efficiency; dependencies are often the hidden WIP that destroys predictability. Evidence-Based Management encourages us to inspect value delivery capability; dependencies are one of the clearest capability killers.

Closing the Loop

When someone asks, “How do you manage dependencies?”, the radical answer is: you don’t. You redesign your teams, architecture, and workflow to eliminate dependencies from the outset. You only manage what’s left when all else fails, and you treat every remaining dependency as a design flaw to be removed. That’s how you maximise autonomy, accelerate flow, and reduce risk.

Stop normalising dependency management as a project management activity. Managing dependencies is treating the symptom. Leadership must instead redesign the system to eliminate the cause. Every dependency you remove is a gift to your teams and your customers. So next time someone asks you how you manage dependencies, give them the only honest answer: we don’t; we remove them.

The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery

Martin Hinshelwood — Mon, 22 Sep 2025 09:00:00 +0000

In many software organisations, estimation accuracy is mistaken for predictability and control. Leadership asks teams to compare original estimates to actuals in hopes of improving forecasts. But this creates a false sense of certainty , one that undermines trust, distorts priorities, and derails delivery.

When the Metric Becomes the Target

Metrics are never neutral. Once teams are judged by how closely they meet estimated timelines or planned outputs, those metrics stop reflecting the truth. The more visible and enforced the target becomes, the more teams adapt, not to improve outcomes, but to survive the system. What follows is a cascade of distorted behaviours: silence replaces honesty, delivery becomes performance theatre, and metrics become tools of compliance rather than learning. The following patterns are not outliers; they are systemic symptoms of measurement misuse.

Malicious Compliance: When Teams Give Up on Caring

When systems overemphasise compliance, teams don’t rebel; they comply. Maliciously. They log the hours. They meet the metrics. They do exactly what’s asked; but no more. They stop asking questions. They stop raising concerns. They stop caring.

This kind of mechanical compliance doesn’t improve delivery; it undermines it. Developers fill in timesheets at the end of the week with whatever gets approved. They make up hours to satisfy reporting tools. What ends up in the system looks clean and green, but it’s fiction.

And what gets lost is far worse: safety, curiosity, technical excellence, and any sense of pride in the outcome. A culture of malicious compliance breeds disengagement, risk blindness, and degraded quality. If you’re measuring in six-minute increments, you’re not managing for value. You’re auditing obedience.

Green Shifting: When Metrics Replace Truth

Once metrics become the focus, honesty becomes optional. Teams under pressure to hit targets will show green status until the very moment they can’t hide red anymore. This phenomenon, sometimes called “green shifting,” isn’t a failure of individuals. It’s the predictable result of a system that rewards status optics over empirical feedback.

When the dashboard matters more than the work, risk gets buried. Quality is sidelined. And problems that could’ve been solved early are deferred until they explode. This isn’t management; it’s theatre.

Fear-Driven Delivery

When performance is judged by how closely estimates match actuals, teams shift into survival mode. Psychological safety evaporates. People stop flagging problems, bugs, and risks. It’s not due to apathy, but fear of missing the number. Defects get buried. Safety is deferred. Risk is hidden.

The focus moves from building the right thing to defending the wrong metric.

When you penalise unpredictability, you don’t get more predictability. You get fear, silence, and a culture optimised for hiding reality. This is how delivery becomes theatre.

Distorted Behaviours and False Success

Comparing estimates to actuals can be useful for learning, but when it becomes a performance metric, it changes behaviour. Teams are no longer incentivised to improve forecasting; they’re incentivised to look predictable.

What happens next is entirely predictable:

Padding: Teams inflate estimates to guarantee hitting the target.

In one large organisation, teams were told they could deliver no more than five points per story, and no more than 24 points per sprint. The result? Teams padded everything to hit exactly 24 points. Story sizes gravitated to five points regardless of complexity. Innovation vanished, curiosity died, and delivery became a game of maximising perceived output. They met the metric perfectly and completely undermined the point of estimation. This is what happens when the system is designed for optics, not outcomes.

Risk aversion: Complex and innovative work is avoided because it’s difficult to estimate.
Scope distortion: Work is redefined midstream to match the estimate.
False success: Projects finish “on time” and “on budget,” but deliver little value. Many organisations never validate whether the promised benefits were actually realised. One team might deliver a multimillion-dollar system, only for no one to ever measure its usage or customer impact. The project is declared a success, but no one checks if it made a difference. In some cases, even the most advanced organisations fall into this trap. The cost of not checking actual outcomes is hidden until it’s too late.

These aren’t edge cases; they’re rational adaptations to a distorted system. The result is a culture of compliance, not curiosity.

Thurlow’s Law of Metric Distortion: “Any metric you measure will appear to improve in the short term. This doesn’t mean the system improved, only that people adjusted their behaviour to game the metric.”

The System Learns to Lie

This principle highlights a broader risk. Once teams realise they’re being judged on metric performance, they start optimising for appearances. They stop focusing on delivery, learning, and value. The metric becomes a distraction from what really matters. It reinforces behaviours that prioritise green dashboards over working software. This is how green shifting starts. Status reports stay green until the moment they can no longer hide the red. It’s not deceit. It’s self-preservation. In a system optimised for appearances, truth is delayed until failure is unavoidable. The focus shifts away from delivery, learning, and value.

The Evidence Behind the Trap

Studies from Lederer & Prasad, Jørgensen, and others show that using estimation accuracy as an evaluation criterion strongly influences behaviour, and often negatively. When estimation accuracy becomes a KPI, it reshapes incentives across the system, often with unintended results. One experimental study (Lorko et al., 2022) found that when participants were rewarded solely for estimation accuracy, they systematically overestimated and deliberately slowed down to “finish on schedule.” The appearance of control was preserved, but efficiency was lost.

Another study (Jørgensen & Grimstad, 2008) showed that people who knew they’d be judged on their estimates produced more biased and less realistic figures. They weren’t aiming for truth; they were aiming for safety.

This is a textbook example of Goodhart’s Law. When a measure becomes a target, it stops being useful as a measure and starts driving the wrong behaviours.

Goodhart’s law: “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”

Trust Is a Two-Way Street

If you treat your engineers like they’re untrusted contractors who need to account for every six-minute increment, don’t be surprised when morale tanks. One developer put it bluntly: “If you’re going to track me like a machine, don’t expect me to act like an innovator.” Research shows employees who feel trusted are more engaged and productive. Conversely, heavy time tracking breeds a culture of micromanagement and mistrust. More than half of knowledge workers say time tracking actually prevents them from doing their best work. When people feel every minute is under a microscope, they’re less likely to ask questions or offer improvements. You’re starving your team of psychological safety, and with it, the conditions for innovation, quality, and honesty. When people are punished for missing estimates, they stop raising risks. They stop discussing trade-offs. Data becomes performative. The real work gets buried under ritual. The system becomes more predictable on paper, but more brittle in reality.

Bad Estimates Don’t Make You a Bad Developer

Software development is creative problem-solving. No two tasks are truly alike. You can’t reliably predict how long it will take to untangle a thorny bug or integrate a library. Sometimes, a “quick” fix can turn into a two-day rabbit hole. So why beat people up when they miss an arbitrary prediction? Estimating in hours assumes everyone is equally experienced and works at a constant pace. They don’t. Pressuring developers to “improve” their guesses assumes effort and duration are predictable. In knowledge work, they’re not. It only creates stress and encourages padding or sandbagging. It’s a game with no winners.

Time Pressure Kills Quality

When management’s only lever is the schedule, quality suffers. Tom DeMarco and Tim Lister, in Peopleware, warn that unreachable deadlines force developers to cut corners: “Workers kept under extreme time pressure will begin to sacrifice quality… deliver products that are unstable and not really complete.” Lab studies back this up. Developers under tight time pressure work faster, not better, and quality drops. And when shortcuts pile up, the cost isn’t just bugs, it’s fragile systems, frustrated customers, and eroded trust.

Hours Worked Do Not Equal Value Delivered

Customers don’t buy effort, hours, or estimation accuracy. They buy working software that solves their problems. A day spent cleaning up architecture might look unproductive on a timesheet, but it delivers enormous long-term value. Optimising for logged time only encourages burnout, presenteeism, and a celebration of busyness over outcomes.

Metrics like velocity or hours measure output, but they don’t measure the value customers care about. It’s better to track what matters: how frequently you can deliver features, how quickly you recover from failures, and whether you’re improving the user experience. These metrics help track how fast you’re learning (Time to Market), how much waste exists in your delivery process (Ability to Innovate), and whether users are sticking around and benefiting from what you’ve delivered (Current Value).

What to Do Instead

If you’re serious about improving delivery outcomes, stop obsessing over time. Time-based metrics show what happened, not what mattered. They miss the nuance of complexity, cognition, and asynchronous problem-solving. When you treat delivery like stopwatch management, you reward appearances over insight.

Evidence-Based Management (EBM) is a way of managing with data that reflects actual outcomes and system capability. It helps leaders move beyond speculation by focusing on what is observable and valuable.

Good decisions start with real data, not guesses. EBM helps teams and leaders focus on what actually delivers value, not what was forecast, promised, or imagined.

In large-scale systems, direct customer contact is rare. That makes feedback loops even more critical. We must rely on proxy signals like usage trends, satisfaction scores, defect trends, and change failure rates to know if we’re on track. Not every team needs direct access to the customer, but every team needs access to evidence that what they shipped is working.

EBM encourages decisions based on what is actually happening, rather than what was predicted. Forecasts can support decision-making, but only when used transparently to explore assumptions, not when turned into compliance targets. When forecast accuracy becomes a performance metric, it violates empiricism by rewarding appearances rather than actual outcomes.

Leadership must create transparency around outcomes, not intentions. This means embracing metrics that reflect customer value, system health, and delivery capability, even when they challenge the status quo.

Let’s be clear: in complex, knowledge-based work, there is no meaningful diagnostic value in “estimate vs actual.” Take, for example, a cross-functional team building an internal developer platform. In the first quarter, leadership tracked the estimated vs actual across epics to improve forecasting. Developers quickly learned to overestimate tasks, avoided exploratory work, and padded estimates to match targets. The numbers looked better, but progress slowed, innovation stalled, and valuable refactoring work vanished from the backlog. By the time leadership realised the disconnect, technical debt had doubled. The team hadn’t become more predictable; it had simply become more cautious and less effective. This is the cost of measuring the wrong thing. It leads to the wrong conclusions.

“Estimate vs actual measures the work, but the waste lives in the gaps , the wait, the handoff, the delay. So you’re optimising the wrong thing.” - Nigel Thurlow

This is a clear example of Systems Thinking, as outlined in The Flow System (Thurlow et al., 2020). The true constraint rarely lies in the task. It lies in the system: the queues, context switching, blocked dependencies, or fragmented communication paths that hinder the delivery of value. In most cases, the constraint lies in the workflow, rather than in the functions themselves.

Even when used “diagnostically”, estimate vs actual as a metric misleads:

It ignores queues, rework, and dependencies, which are often the actual sources of delay. Lean thinking teaches us that to improve flow we must visualise queues, limit work in progress (WIP), and actively manage handoffs; none of which are addressed by focusing on task-level estimate variance.
It reinforces the illusion that better estimation leads to better outcomes.
It promotes local optimisation over systemic improvement.

A reminder of Thurlow’s Principle of Estimation Distortion above!

A Better Path Forward with Evidence-Based Management

EBM organises improvement around four Key Value Areas (KVAs):

Current Value - Are We Delivering Value to Customers and Stakeholders Today?
Unrealised Value - What additional value could we deliver in the future?
Time to Market - How quickly can we learn, respond, and deliver?
Ability to Innovate - How effectively can we change and adapt the product?

The metrics we use should support these questions, not distract from them. Here’s how EBM-oriented alternatives compare:

Instead of…	Try…
Estimate vs Actual	End-to-end lead time from commitment to usable customer delivery (Time to Market)
Story points completed	Customer satisfaction (Current Value)
On-time delivery rate	Quality Trends, or % of effort on new vs sustaining work (Ability to Innovate)
Headcount-based planning	Opportunity backlog delta (Unrealised Value)

⚠️ Warning

Time-based metrics must be contextualised. Without insight into value, complexity, and customer outcomes, they risk becoming another distorted proxy.

To understand and improve delivery, stop obsessing over how close your guesses were. Instead, measure how your system behaves across the value stream and under varying flow loads. EBM encourages the use of actionable, outcome-aligned metrics that reflect actual system health, rather than projected compliance.

Cycle time trends can reveal delivery latency across the value stream, but must be interpreted with caution. Without understanding the nature and complexity of the work, as well as its value, these trends are just noise. Measure flow to inspect how the system behaves, not how long individual items take.

ℹ️ Note

Cycle time only tracks how long one piece of work took. It says nothing about what the customer waited for or whether the system is flowing well. Lead time tells you how long the customer waits, starting from the moment a request is made until they receive something usable. Always measure from the outside in.
Work item ageing reveals stuck or neglected work, or requirements that were added and then discarded.
Flow efficiency indicates the proportion of total time spent progressing work versus waiting. It’s a measure of delay, not value. But beware: systems often mask latency by moving queued work into “in progress” prematurely. High flow efficiency with unchanged lead time may signal gaming.
Throughput variance only tells you something if your work items are roughly the same size. If not, throughput becomes noise. Teams that right-size work can use this as a stability signal. Otherwise, avoid using it as an indicator of performance.

If you must discuss estimates, use them to explore assumptions and complexity, not to evaluate people. The ultimate goal is to deliver meaningful outcomes to customers. That requires embracing uncertainty, surfacing impediments, and improving system capability. The aim is not to enforce forecast compliance. Value lies in understanding, not accuracy.

De-emphasise ’estimate vs actual’ entirely. It is a false signal in complex domains.
Reward flow mastery, not forecasting tricks.
Focus on learning, adaptability, and real customer outcomes.

Estimation should support informed conversations about uncertainty. It should not become a tool used to force predictability.

Quantitative vs Qualitative

Most metrics in delivery are quantitative, including lead time, flow efficiency, and throughput. But numbers don’t tell the whole story. If you want to know whether you’re building the right thing, you need qualitative feedback: real customer conversations, issue sentiment, satisfaction narratives, and behavioural observations.

Quantitative data tells you what happened. Qualitative insight helps you understand why.

No chart or trendline can replace a conversation with a frustrated user or a support ticket that describes unmet needs. The most resilient teams blend data with dialogue, metrics with meaning.

Radical Candour: Have the Courage to Stop

This isn’t about shielding teams from accountability. It’s about holding ourselves accountable to a higher standard of leadership. Framing time estimate accuracy as a condition for trust is a failure of leadership. It signals a lack of psychological safety and a misunderstanding of how complex work unfolds. True leadership fosters environments where learning is safe, discovery is encouraged, and performance is judged by value, not conformity to expectations. It’s not helping them grow; it’s punishing them for unpredictability inherent in complex work. Radical candour means caring personally and challenging directly. The challenge here is to stop clinging to false certainty and instead focus on the outcomes that matter for your business and your customers.

Don’t replace one flawed proxy with another. Metrics like cycle time, throughput, or flow efficiency are helpful, but only as part of a broader conversation about value, quality, and improvement. Alone, they tell you nothing about whether you’re solving the correct problems or improving customer outcomes. Consider adopting Evidence-Based Management and DORA to shift focus toward empiricism and value flow across the organisation. Talk with your team about impediments and improvements rather than the hours they logged. When you remove the spotlight from the clock, you’ll find your people deliver better software, enjoy their work more, and build trust along the way.

In Summary

The Estimation Trap appears to be a process improvement effort. But underneath it creates a fear-based culture that rewards gaming and punishes uncertainty. It distorts delivery and kills innovation in the name of control.

All quantitative measures can do, is inform of system efficiency. They cannot inform of system effectiveness!

Instead of asking, “Why didn’t we match our original estimate?” ask, “What did we learn, how did we adapt, and are we improving the outcomes that matter?”

Real progress starts when people feel safe enough to tell the truth about complexity, risk, and what it actually takes to deliver. That’s the objective measure of a team delivering meaningful outcomes, improving their system, and creating value for customers.

References

Is Agile Really Just a Mindset?

Martin Hinshelwood — Mon, 11 Aug 2025 09:00:00 +0000

Let’s get one thing straight: Agile is not a mindset. And it’s certainly not just about behaviour. That lazy framing dilutes the discipline, ignores the engineering reality, and gives cover to incompetence.

Agile for software development is a delivery discipline grounded in technical leadership, empirical control, and engineering excellence. If your so-called “Agile transformation” doesn’t touch your code, your infrastructure, your deployment pipelines, or your product strategy, then you’re not Agile, you’re just busy.

Agile Isn’t a Mindset. It’s a System of Work.

The term “Agile mindset” has become a smoke screen for vague, feel-good language that conveniently ignores the hard parts: architecture, observability, checkability, and releasability. A mindset doesn’t ship working software. A system does.

Agile is a strategy for managing complexity. It draws on an empirical ethos to deal with uncertainty. While Agile principles support this ethos through practices like continuous delivery, frequent reflection, and embracing change, they stop short of formalising it. Agile leaves room for interpretation, which is both its power and its weakness.

Instead of prescription, Agile encourages conditions that make learning and adaptation possible:

Deliver working software frequently.
Reflect regularly on how to become more effective.
Embrace change, even late in development.

This isn’t methodology. It’s operational discipline.

Behaviour Is Necessary, but Not Sufficient

Yes, agility requires certain behaviours: collaboration, openness to change, and continuous learning. But those behaviours are not the whole picture. They’re the byproducts of well-designed systems, not the system itself.

If you want teams to behave “agile,” you need to:

Give them working CI/CD pipelines.
Define a clear and realistic shared quality standard.
Stop flooding them with WIP and start managing flow.
Align work to meaningful goals with clear delivery expectations.
Enable them to ship to production regularly and reliably.

Without engineering and system design, Agile behaviours collapse under pressure.

Engineering Practices Are the Backbone of Agility

Agile without engineering is theatre. You might have sticky notes and daily standups, but if you can’t deliver reliable, high-quality software frequently, you’re not Agile.

Here’s what engineering excellence looks like in Agile:

Continuous Integration & Deployment (CI/CD): Small, safe, frequent releases.
Automated Checking: Fast, repeatable validation that gives developers confidence.
Infrastructure as Code: Reproducible environments with version control.
Telemetry and Observability: Insight into live systems for fast feedback and debugging.
Design for Replaceability: Modular, cohesive systems you can change without fear.

These are not “nice-to-haves.” They are foundational. If your teams can’t ship to production at regular, sustainable intervals, you’re not Agile, you’re just going through the motions.

Stop Outsourcing Agile to Coaches Who Don’t Code

A big part of the problem is that we’ve allowed Agile to be colonised by people with no engineering background. They talk about collaboration, but not architecture. They push for psychological safety, but ignore version control hygiene. They love retrospectives but can’t read a cycle time chart.

This isn’t a personal attack. It’s a call for accountability.

If you’re coaching Agile teams and you don’t understand modern engineering practices, DevOps, CI/CD, telemetry, checkability, you’re not equipped to lead agility in software.

Agile is not a therapy session. It’s not a motivational poster. It is a system of delivery designed to maximise value under conditions of uncertainty. And if we want to keep calling it that, we’d better start treating it with the rigour it deserves.

“A bad system will beat a good person every time.”

Deming’s insight isn’t a philosophical quip, it’s a brutal truth. In Agile environments, we often celebrate the heroics of individuals, when we should be interrogating the design of the system. Good people trapped in bad systems burn out, give up, or conform.

This is where Larman’s Law comes in: “Organisations are implicitly optimised to avoid changing the status quo middle-management and specialist roles, power structures and political boundaries.” It explains why many Agile initiatives fail. Not because people resist Agile, but because the system resists accountability.

Agile invites change, but organisations repel it. Instead of redesigning systems of work, they repurpose Agile into just another management fad. Sticky notes go up. Certifications get handed out. But the constraints, silos, and dysfunction remain untouched.

If your structure still depends on project gates, command hierarchies, and stage approvals, you haven’t adopted Agile. You’ve institutionalised waste.

Systems produce outcomes. Not individuals.

Want to see agility? Look at the architecture. Look at how teams form, flow, and deliver. Look at what the system makes easy and what it makes hard. If it’s easier to follow process than to deliver value, your system is broken, no matter how agile your people are.

Finally

Let’s kill the myth:

Agile is not a mindset. It is a discipline.
Agile is not only about behaviour. It’s about delivery.
Agile is not a feeling. It’s a feedback-driven engineering strategy.

Agile is the deliberate design of systems that enable autonomy, accountability, and continuous delivery of value.

If you’re not delivering, you’re not Agile. Period.

Stop Building Silos. Start Building Systems

Martin Hinshelwood — Mon, 07 Jul 2025 09:00:00 +0000

You can’t deliver quality at speed when your automation is duct-taped together. If your pipelines are stitched across multiple systems, your deployments depend on human rituals, and your tests run in the shadows, you don’t have a delivery system, you have a liability.

If your automation strategy looks something like this:

Manual SQL deployments from someone’s laptop
Azure Pipelines building unversioned assemblies
Manual deployment to dev and test environments
TeamCity rebuilding new unversioned assemblies
Octopus Deploy is deploying from Team City to staging and production
Selenium tests running on a black-box scripted node that only one person monitors

You’re not building a product. You’re building chaos. You’re not scaling a team. You’re scaling dysfunction.

Fragmentation Is Not an Engineering Strategy

When every team uses a different deployment tool, stores secrets in a personal vault, and runs tests on unmonitored boxes, you’ve created a system that no one understands and no one can change safely.

This isn’t flexibility. It’s fragility.

Fragmentation leads to duplication of effort, inconsistent results, increased cognitive load, and slower delivery. You waste time debugging pipeline differences instead of building product value. And every deviation from a shared system adds risk to quality, security, and compliance.

Engineering excellence comes from enabling consistency where it matters, creating common foundations that support autonomy without sacrificing reliability. It comes from designing systems that are observable, changeable, and resilient, systems that empower teams through clarity, not confusion.

This kind of fragmentation also violates the core ethos of DevOps: continuous delivery of value through the union of people, processes, and products. If your toolchain is stitched together by tribal knowledge and Slack messages, you’re not enabling flow. You’re creating friction.

DevOps Is Not Tooling. It’s Feedback, Flow, and Learning

DevOps isn’t a toolkit war. It’s the discipline of enabling feedback, flow, and continuous learning across the entire product lifecycle.

It’s about amplifying feedback loops, build, test, and release systems that surface issues early and often.
It’s about enabling flow, removing friction between commit and customer, reducing handoffs and rework.
It’s about fostering learning, capturing telemetry, responding to incidents, and improving from every iteration.

DevOps without visibility is cargo cult. DevOps across disconnected systems is just automation theatre. And DevOps without learning is just technical debt in fast-forward.

Building One Engineering System (1ES) through Platform Engineering

If DevOps is the ethos, then Platform Engineering is the strategy, and One Engineering System (1ES) is the execution model.

Platform Engineering is not just infrastructure automation. It’s a practice grounded in DevOps principles that aims to improve every development team’s time-to-value, compliance, cost control, and security through improved developer experiences and governed self-service. It’s both a mindset shift and a system of reusable tools and services.

Platform Engineering teams build and evolve Internal Developer Platforms (IDPs), paved paths that reduce cognitive load, eliminate manual gates, and guide teams safely toward production.

These platforms:

Help developers be self-sufficient (e.g. starter kits, templates, IDE integrations)
Encapsulate patterns into reusable services
Automate security and compliance checks
Streamline operations and infrastructure management

1ES, pioneered at Microsoft, embodies this by unifying:

Azure Pipelines for end-to-end CI/CD
Azure Repos, Boards, and Artifacts as a single source of truth
Infrastructure as Code, Policy as Code, and integrated telemetry

The result: a secure, observable, scalable system where guardrails are built in and teams can move fast without creating risk.

No handoffs. No tool silos. No black-box deploys. One path from idea to production that every team and every skillset contributes to.

You may be thinking that “this breaks self-management” and the agency of the teams. But self-management in Agile doesn’t mean chaos. Scrum Teams don’t self-manage in a vacuum, they operate within the boundaries defined by the organisation. Self-management means giving teams the autonomy to solve problems within a clearly defined system of constraints. That system of constraints, your engineering boundaries, your compliance requirements, your platform capabilities, is your Platform Engineering strategy, and your 1ES is your implementation of that strategy. It defines what good looks like. Those boundaries must be engineered and not left to tribal knowledge. If you want consistent results, define the edges and let the teams operate freely within them.

Consolidate. Standardise. Enable.

If you want scale, you must design for it. That means:

One build system.
One deployment path.
One way of managing secrets, tests, telemetry, and deployments.

Azure Pipelines is capable of it all. With templates, approvals, gates, agents, deployment groups, and environment strategies, everything you need to build a 1ES-style delivery platform is already there. Yes, there are other tools, but if you are already rooted in the Microsoft stack, then these purpose-built tools fit like a glove.

Stop spreading your delivery process across half a dozen tools with no visibility. Pick a platform. Make it great. And let your teams focus on product, not plumbing.

Engineering excellence isn’t about choosing the coolest tools.
It’s about building a system of work that enables every team to deliver safely, sustainably, and continuously.

Stop optimising for familiarity. Start optimising for flow.

How to Build for Business Resilience and Continuity

Martin Hinshelwood — Mon, 26 May 2025 09:00:00 +0000

Business resilience is not an accident. It is the deliberate outcome of intelligent systems design, pragmatic decision-making, and organisational discipline. If you want resilience, you must build for it, upfront, consistently, and aggressively.

Here is a pragmatic checklist for engineering true business resilience and continuity:

Observability and Telemetry First

You cannot manage what you cannot see. You cannot fix what you cannot detect.

Embed telemetry at every level: application, infrastructure, business processes.
Define service level objectives (SLOs) for your critical systems and actually measure against them.
Monitor leading indicators, not just trailing failures.
Establish a live site culture, not a “we’ll find out when customers call” culture.

If your systems are invisible until they explode, you are not resilient; you are negligent.

Decouple Systems Aggressively

Coupling is a time bomb. When one piece falls, everything else falls with it.

Bounded contexts are non-negotiable. Embrace them.
No logic in the data tier. Databases store data, not behaviour. If your business rules are locked in SQL, you are one outage away from a complete operational collapse.
Avoid shared databases. Duplicate data if necessary. Loose coupling beats data purity.
Prefer asynchronous messaging. Synchronous systems are brittle under load and fail catastrophically.

Resilience comes from isolation. Systems must fail independently, not cascade like dominoes.

When the User Profile Service takes out the entire system

For a long time I have worked with the Azure DevOps teams at Microsoft as an strategic customer and MVP and I have witnessed this lesson firsthand. One of the major outages of Azure DevOps was triggered by something that, at first glance, seemed trivial: the Profile Service. When the Profile Service went down, developers could no longer commit code, and product owners could not update backlog items. Why? Because the system could not resolve your friendly name from your authenticated ID.

The service was so tightly coupled into critical user flows that its failure crippled the entire platform.

In response, the teams created “live site incident” repair work and moved the Profile Service behind a circuit breaker. If the Profile Service went down again, it would degrade gracefully, not drag down the entire experience.

As an anecdotal aside, a few months later another unrelated service failed, and, unsurprisingly, it also took down large parts of the system. That was the final straw. The teams went on a full-scale mission to introduce the circuit breaker pattern across every service, making sure no single point of failure could collapse the platform again.

Decoupling and graceful degradation are not academic exercises. They are mandatory if you value continuity.

Treat Deployments as Routine, Not Special

Every deployment is a practice run for disaster recovery. If deployment is a risky, complex, orchestrated event, you have already failed.

Implement Continuous Delivery (CD) so that deployments happen safely, frequently, and predictably.
Use feature toggles to separate code deployment from feature release.
Automate rollbacks. A failed deployment should not require heroics.

If your organisation fears deployment day, it is structurally fragile.

Empower Teams to Act Without Hierarchy Paralysis

In a crisis, the last thing you want is a command-and-control bottleneck. Empowerment is a precondition to survival.

Pre-delegate authority for critical systems response.
Train teams on incident management procedures, disaster recovery, and failover operations.
Decentralise decision-making to the people closest to the work.

In crisis, minutes matter. Top-down control costs lives and revenue.

Assume Everything Will Fail; Design to Recover Fast

Hope is not a strategy. Failure is inevitable. Recovery speed determines survival.

Chaos engineering is not optional; it is responsible practice.
Design for graceful degradation. Partial failure is better than total failure.
Practice recovery drills. Don’t just have a DR plan; rehearse it until it is boring.

If you are not recovering faster than your competitors, you are losing.

DevOps, Site Reliability Engineering, and Evidence-Based Management

Business resilience is DevOps in action: the union of people, process, and products to enable continuous delivery of value to end users. Resilient systems emerge from the daily discipline of CI/CD, Infrastructure as Code (IaC), and monitoring as first-class citizens.

It is Site Reliability Engineering (SRE) lived, not aspirational. SRE teaches us that availability, latency, performance, efficiency, change management, monitoring, and emergency response are all product features, just as important as the user-facing ones.

It is Evidence-Based Management (EBM) made real. Metrics like Mean Time to Recovery (MTTR), Deployment Frequency, and Customer Satisfaction are not vanity measures; they are survival metrics. They inform whether your investment in resilience is paying off or just theatre.

Resilience is not a project. It is an ethos. You must architect it into your systems, invest in it continuously, and operationalise it ruthlessly.

Otherwise, you are gambling with your business and calling it strategy.

Articles on Martin Hinshelwood on Engineering Leadership

Engineering as a Leadership System: Moving Beyond Frameworks

Your operating model is a theory of the business

When this is not your problem

Where the theory is actually written down

Governance: what requires permission

Funding: what you buy, and for how long

Measurement: what you count

Decision rights: who may decide without asking

Accountability: who carries the consequence

Why frameworks, coaching, training and AI change so little

The tell: stated intent against the operating model

Move, wait, learn, decay

Five questions worth answering honestly

Subscribe to Martin's articles

This work does not finish

Why Most Companies Operating Models Fail in Dynamic Markets

Defining the Two Operating Models

The Predictive Operating Model

The Adaptive Operating Model

Why This Distinction Matters

The Predictive Operating Model Was Fit for Stable Markets

Why the Predictive Operating Model Fails in Dynamic Markets

The Adaptive Operating Model Enables Success in Dynamic Markets

Operating-Model Hygiene: Why Organizations Regress

Making the Transition

Subscribe to Martin's articles

Call to Action: Redesign Your Operating Model

Telling People What to Do Is Not Leadership. It’s a Failure of System Design

You Don’t Need to Tell People What to Do in a Well-Designed System

Taylorism Is for Factories. You Run a Cognitive Organisation.

Leadership Is Creating Systems That Don’t Need You

Telling People What to Do is an Expensive Workaround

Design the System. Get Out of the Way.

1. Establish Intermediate & Tactical Goals

2. Enable Self-Management with Constraints

3. Stop Misusing Estimation, Start Right-Sizing

4. Introduce Pull Systems with WIP Limits

5. Use evidence-based management practices

6. Deploy Frequently to Production

7. Invest in Professional Scrum Masters & Product Owners

8. Collapse Siloed Structures

9. Use Sprint Reviews for Stakeholder Alignment

Subscribe to Martin's articles

10. Teach Managers to Serve Systems, Not Direct People

The AI Decided Is Not an Explanation

Saying it lied adds an intention

We give the dog cheese when it looks sad

We can do this with moving triangles

Asking why gives us more words to interpret

I have used the same language

Subscribe to Martin's articles

The dog cannot merge to main

AI Agents Lie About Being Done

Why was the agent’s saying it was done enough to make it done?

Done is whatever you have validated

The agent marked its own homework

A run that stopped is not a run that finished

Some answers must be the same every time

What to do about it

What would change my mind

Subscribe to Martin's articles

The question to keep

Don’t Manage Dependencies, Remove Them

Step 1: Align Work, Teams, and Architecture

Design your organisation so that work, teams, and architecture line up

Step 2: Make Contracts Explicit

Document contracts between capabilities

Step 3: Clarify Ownership

Resolve by establishing clear ownership lines

Step 4: Actively Manage the Rare Remainders

Manage only these

Systemic View

Subscribe to Martin's articles

Closing the Loop

The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery

When the Metric Becomes the Target

Malicious Compliance: When Teams Give Up on Caring

Green Shifting: When Metrics Replace Truth

Fear-Driven Delivery