Part 1: Strategy. Why We Designed It This Way

Every other part of this handbook is a set of operating rules. This part is the reasoning those rules operationalise. Skim if you must, but when a rule in Parts 2 through 5 seems arbitrary, the explanation almost certainly lives here.

Our Vision and Optimising Goal

Company Vision

Our Company Vision describes the future we are building for our customers. For a product-technology organisation it should be short enough to repeat from memory and concrete enough to falsify.

A well-designed example, for an imagined logistics company: we’re building a future where any independent retailer can promise next-day delivery as confidently as the giants do, and keep that promise on a customer’s first order and their hundredth. Growing our retailers’ businesses is how we grow ours.

Notice what makes that example work: a named customer (the independent retailer), a promise you can measure (next-day delivery, kept), and a business model stated in one sentence. When you adopt this handbook, replace the example with your own vision.

Organisational Perfection Vision

To fulfil the externally-facing Company Vision, we have adopted an internal Organisational Perfection Vision from Large-Scale Scrum: to create an organisation capable of delivering or changing direction at any moment without incurring additional costs.

Perfection visions are not targets to hit; they are north stars that guide our daily navigation decisions. Larman and Vodde make the distinction precise: the goal of a vision is to achieve it, whereas the goal of a perfection vision is to channel improvements. Eli Goldratt’s line from The Choice applies: every situation can be substantially improved; even the sky is not the limit.

Optimising Goal

What will we optimise to realise that vision? Our primary Optimising Goal is adaptiveness: our capacity to rapidly innovate, pivot, and respond effectively to opportunities and challenges, rather than conventional efficiency or utilisation measures.

By contrast, optimising for traditional metrics like efficiency or resource utilisation compromises our ability to deliver value. Those metrics may produce a “lean” organisation on paper while sapping the long-term agility we need to seize new opportunities. The research backs the choice: Forsgren, Humble, and Kim’s Accelerate (2018) found that high-performing technology organisations achieve speed and stability together, refuting the folk belief that you must trade one for the other. Adaptiveness is not the enemy of reliability; it is how reliability survives changing conditions.

The primary adaptiveness metrics, via Craig Larman and Large-Scale Scrum, are:

• Ease of changing prior large-direction decisions: how cheaply the organisation can revisit big bets it has already made (which products and initiatives to pursue) when new information arrives; the course lists this separately from the easier act of making the original call.
• Adaptiveness to re-prioritise from data: whether fresh delivery and market data actually changes what gets worked on next, rather than the plan rolling forward on inertia.
• Adaptiveness of teams to change direction at the global level: how readily the whole group of teams swings onto newly discovered highest-value work, which the course glosses as the transaction-cost, switching-cost, and cost-of-change variable.
• Adaptiveness of allocations (people, money, …): how quickly staffing and budgets follow the highest-value work, instead of the work bending to fit last year’s allocations.

Underneath all four sits the same economics: adaptiveness is low transaction costs plus low switching costs, a pair Larman notes is accurate but hard to measure directly. The course’s proxy measure is the percentage of items in Sprint Planning and refinement that did not exist before the last Sprint Review, and he notes the irony that most organisations say they want agility and never actually measure it. Note what is absent: “fast” and “efficient” are not adaptiveness, and treating them as if they were is how the utilisation trap reopens.

Our Core Philosophy

Companies fail by clinging to outdated paradigms, often celebrating their competency while delivering a service no longer valued by the market. Companies thrive by recognising emerging paradigms and disrupting themselves (and then the market) before others do it to them.

Organisations often collapse under the weight of their own success and efficiency.

Complexity-science researcher Dave Snowden calls this “competence-induced failure”: excelling within an outdated paradigm breeds complacency, and the better you are at the old game, the harder it is to see the new one.

The speed of this shift is unprecedented. AI is not about adding a new capability to existing roles. It is restructuring what the roles are, and ultimately the entire organisation’s structure. The competitive threat we face is not from other incumbents transforming at a similar pace. It is from companies that do not exist yet, built agent-native from day one, with fundamentally different cost structures, speed, and adaptability. A regulated industry’s moat buys time, but it does not buy safety. The organisations that survive will be those that built the new operating model before the old one became uncompetitive.

The five design levers (Strategy, Structure, Processes, Rewards, People) are the key levers for creating organisations that can thrive. We focus heavily on Structure to influence our Culture.

“Culture eats strategy for breakfast.”

— Professor, Author, and Consultant Dr. Peter Drucker

“In big established groups, culture/behaviour/mindset follows and is influenced by changes in the organisational system and design.”

— Coach, Author, and Trainer Craig Larman

Because an organisation’s Structure so strongly shapes Culture, we pay close attention to how every role and hierarchy drives daily behaviours. Flattening unnecessary layers or combining specialised groups often unlocks deeper cultural change than any abstract policy.

Rather than a “last resort,” structural redesign is frequently our primary tool for real behavioural shifts, and, as Craig Larman warns, the tool organisations most resist, because it threatens existing power structures. In short, Culture changes matter, but they depend on meaningful Structural changes.

Leadership engagement is rare and decisive for successful transformation, and this handbook assumes you have it.

[To a CEO] “Come yourself or send no one.”

— Professor, Author, and Consultant Dr. W. Edwards Deming

Deming taught us that 85–95% of problems in any organisation are systemic, and leaders own all systems. Leadership is therefore ultimately responsible for solving the problems and transforming the organisation. If your executive team intends to delegate this handbook to a working group and check in quarterly, stop here; the design will not survive that. Adopt it when your leaders are prepared to be at the forefront, actively ensuring cultural and structural changes take root.

This handbook represents our shared current state. We need everyone’s help to evolve and sustain it.

The handbook has a steward (our Enterprise Performance Coach), but it is not their document; it reflects our collective approach. Your informed contributions matter. Identifying improvements or new constraints helps us evolve quickly.

Different Kinds of Problems Need Different Approaches

The operational implication first: this is why our teams are not required to follow any framework, why our Definition of Done sets a floor without dictating methods, and why some rules in this handbook are firm while others are explicitly negotiable. Different kinds of work need different kinds of rules.

Treating Complexity like Complication won’t make it predictable, only more disastrous when reality strikes.

Modern software development is largely Complex, not merely Complicated. We are evolving (through organisation-wide Processes, Structure, and the resulting Cultural changes) into an organisation better suited to thrive in a primarily Complex context.

We rely heavily on Dave Snowden’s Cynefin framework, a sense-making model that helps us determine whether we face a Clear, Complicated, Complex, or Chaotic problem:

Different solutions work in different contexts. We avoid forcing a “one-size-fits-all” approach.

The trivial strategy that wins tic-tac-toe guarantees failure at chess. What wins chess loses at poker. Choosing the wrong type of solution for the problem at hand produces Disorder or Chaos, especially when Simple assumptions are applied to Complex problems. Snowden’s own formulation is the sharpest statement of the principle: there are few if any context-free solutions, but many valid context-specific ones (Snowden et al., Cynefin: Weaving Sense-Making into the Fabric of Our World, 2022). This is why the rules in this handbook state where they apply and when we revisit them, and why “we will always X” experiments should raise an eyebrow at any retrospective.

The Cynefin volume adds a warning we take seriously: the boundary between Clear and Chaotic is not a gentle slope but a cliff, a catastrophic fold. An organisation confidently applying rigid best-practice rules while its context drifts into Complexity feels fine right up until everything breaks at once. When an incident review shows a sudden transition from “all is well” to “everything is on fire,” the question to ask is what we had stopped questioning.

Governing constraints work for Complicated problems; enabling constraints work for Complex problems. We have both types of problems, so we are thoughtful about how we apply each type of constraint.

Governing constraints are fixed rules: they prescribe behaviour and limit options. They suit Complicated problems, where predictability and control are possible.

Enabling constraints guide without dictating: a framework loose enough for exploration and self-organisation. They suit Complex problems, where the right answer has to emerge.

Most “Agile” frameworks were intended to act as enabling constraints. However, as most people see the world through a Complicated lens, these frameworks have been coopted and misapplied as “cargo-cult” governing constraints.

We are therefore framework-informed, not framework-bound. Our goal is to increase our organisation’s value by improving its performance and adaptiveness, not to “do Agile” or implement any framework.

Faced with both Complicated and Complex problems, we maintain both governing and enabling constraints. This handbook articulates both.

Governing constraints examples:

• We primarily conduct planning as a Value Stream, not as independent domain teams
• We place some restrictions on how Shortcut can be used by teams
• We follow all applicable laws and ethical considerations

While teams must generally comply with these constraints, some can be renegotiated as we learn and evolve.

Enabling constraints examples:

• Our Definition of Done sets a minimum quality standard for all teams without constraining how they realise it
• Acceptance Criteria give Builders autonomy over the solution for a particular set of requirements
• A preference for self-managing and perhaps even self-organising teams

Systemic Optimisation vs. Local Optimisation

We recognise that focusing on local efficiency, like making one team “faster” at the expense of the entire flow, will paradoxically degrade our ability to deliver value. Instead, we focus on overall organisational throughput and adaptiveness, not on whether one group meets a local target. By orienting each decision around the entire system, we reduce the friction that arises from well-intentioned but siloed “micro-optimisations.”

One of the most pervasive threats to an effective, minimum viable bureaucracy is local optimisation, where subgroups fixate on their own metrics (perhaps “resource utilisation” or the “velocity” of a solitary individual or team) and inadvertently undermine the global goals of the organisation. Put simply, a perceived improvement in one node of the network can worsen throughput across the entire network, resulting in organisational gridlock, rework, or hidden queues that stall innovation.

We combat this by constantly asking, “What is best for the entire flow of value?” rather than “What is best for me (or my team) right now?” This question shapes how we decide priorities and how we adapt our Strategy, Processes, Structure, Rewards, and People practices. For instance:

• Processes: We watch for any sub-process that might bottleneck the larger system flow. If “internal QA” is efficient but delays development teams or compliance, we question that arrangement rather than forcing dev to “speed up.”
• Structure: We avoid isolating knowledge or skill sets in specialised units that only serve “their backlog.” Cross-functional teams own broader outcomes, so it’s natural to align decisions with bigger goals.
• Culture: We celebrate synergy (cooperation yielding greater results than individual efforts combined) over heroics. A single team racking up “record outputs” is less valuable if it creates a logjam elsewhere. By rewarding collaborative solutions, we systematically undermine the impetus for local optimisation.

Any sign of friction or backlog buildup prompts the question: “Is this a byproduct of local optimisation?” If so, we realign.

Theory of Constraints: Focus on THE Constraint

Every system has one constraint that limits its throughput at any given time. Improving non-constraints does not improve system performance.

This is not intuitive. Most organisations spread improvement efforts across many areas, mistaking activity for progress. Eli Goldratt’s Theory of Constraints teaches us that system performance only improves when we improve the constraint; everything else is waste. His chain analogy carries the whole argument: a chain’s strength equals the strength of its weakest link, and adding strength to non-weakest links does not strengthen the chain.

The Five Focusing Steps:

• IDENTIFY the constraint (where work piles up, what people wait for)
• EXPLOIT the constraint (maximise its output with current resources)
• SUBORDINATE everything else to the constraint (non-constraints adjust to support it)
• ELEVATE the constraint (only after exploitation, add capacity)
• REPEAT (the constraint shifts when elevated; this is continuous)

The constraint is usually a policy, not a machine or a person: in his own telling, “the real constraints, even in our plant, were not the machines, they were the policies.” Before proposing to hire or buy your way past a bottleneck, check whether an operating policy is creating it. Beware inertia, too: a practice introduced to exploit one constraint becomes friction once the constraint moves. Our regular Department and Value Stream Retrospectives exist precisely to catch practices that have outlived the constraint they were built for.

In our experience, the binding constraint in a multi-team product organisation rarely lives inside any single team. It lives at the boundaries between teams: the integration points, the handoffs, the gaps that nobody owns. Better tracking of individual team velocity does not fix incidents caused by groups doing their thing separately. This is why so much of Part 3 concerns cross-team events and why Part 2 organises teams to minimise handoffs in the first place.

Our Structural Evolution

Thinking split from doing: the plan drawn upstairs behind glass, the work done blind below, each hand at its own station, none seeing the whole or one another. The separated planner sits in a WHOLE-1 archetype and the workers most likely in a TASKS-1 archetype, in the Org Topologies language introduced below.

We think of our organisational evolution as moving through three main Organisational Topologies: a Resource Topology (where many incumbent organisations start), the Delivery Topology this handbook describes, and the Adaptive Topology we aspire to reach.

A detailed comparison of the three topologies is in Appendix A.

We suggest downloading and reading the Org Topologies Primer for more details. The following chart illustrates the archetypes we draw on, which we reference throughout this handbook to ground our structure in the Org Topologies language.

Org Topologies archetype grid: Scope of Work vs Scope of Skills Mandates. ©2025 Org Topologies™, incorporated here under a CC-BY-NC-SA license.

This handbook describes the Delivery Topology we now operate (see Part 2), with regular references to the Adaptive Topology we are aiming towards.

The Adaptive Topology is not a long-term aspiration. It is the minimum viable structure for a world where AI compresses what 10,000 people do into what 10 people orchestrate. Those 10 people are already WHOLE-4: full scope of skills, full scope of work, unbounded. They will come out of nowhere, and a conventional organisational design is (frankly) not built to compete with them. Every layer of coordination overhead we carry is a layer they don’t have. The pace of our evolution toward the Adaptive Topology is a strategic priority, not an optional improvement.

We’re aiming for humans supervising fleets of AI agents. Agents are delivery participants (Part 3 defines how they work inside our standards); Builders direct and review them; and the engineer’s profile bifurcates toward one of two depths, expertise in the AI platform itself or deep domain expertise, with the undifferentiated middle thinning as agents absorb it. Teams get smaller and more capable as this lands (see Part 2 on smaller, builder-heavier teams). Every process in this handbook is written to still make sense on the other side of that shift: encoded standards, WIP limits sized to review capacity, and Stories as specifications are agent-era mechanisms, not ceremony carried forward purely out of habit.

Waste, and the Bureaucracy Worth Keeping

Efficiency creates the illusion of progress; adaptiveness and flow take you where you need to go.

Waste is anything the customer doesn’t want and isn’t willing to pay for. Most processes are wasteful, but sometimes the waste is necessary to deliver value to the customer.

Meetings are waste. Epics are waste. Stories are waste. In fact, virtually everything described in this handbook is waste. None of our customers would say to us, “That’s a very nice operating handbook you’ve got there, here’s 5% more money.”

That said, there’s waste that is necessary to deliver value to the end customer and waste that isn’t. If we cast a piece of metal for sale using a single-use mould, we eventually discard the mould: the customer wants the final product, not the intermediary artefacts. We would still seek to eliminate this waste, but the technology available to us today doesn’t allow it. Painting an attractive design on the mould only to discard it entirely is a different category of waste altogether.

It is almost impossible to create totally independent and well-formed software development teams in a company of meaningful size. Thus, we need enabling constraints in the form of systemic Processes to promote interoperability and flow between teams.

We keep our systemic Processes as lightweight as possible so that teams spend more time delivering value to end users and less time on process-related waste.

For example, we do not require that teams use Scrum, Kanban, Extreme Programming (XP), or any other framework within their own team, though we do require a few practices that keep teams interoperating effectively (such as meeting every two weeks to synchronise and roughly plan the next batch of work). We suggest teams study XP, BDD, and TDD techniques, as these are the most useful for an individual team and the least likely to produce cargo-cult behaviours.

We do not enforce governing constraints without cause. We reflect regularly on our systemic Processes to keep them lean. We ask every member of the organisation to challenge and improve them.

This handbook contains undiscovered errors, inaccuracies, and waste. Once discovered, not all deficiencies can be resolved with one person’s intelligence alone. We therefore request the sincere cooperation of all team members to help identify and resolve issues with the handbook and the Strategy, Processes, Structure, Rewards, and People practices it describes.

We encourage each team and leader group to examine where new red tape or “bloat” may be creeping in, then remove or refine it. Everyone is empowered to propose small experiments and retire ones that no longer help.

Illegible natural vs scientific forests

James C. Scott’s contrast between the illegible natural forest and the legible “scientific” monoculture is the cautionary tale we keep in mind. The forest on the left is illegible: a tangle that resists counting and frankly unnerves the managerial eye. It is also the healthier forest, diverse and therefore resilient. The forest on the right is orderly, countable, and fits neatly on a PowerPoint slide. That same neatness is the fragility. With no diversity as insurance, one pest, one disease, one bad season can take the whole stand.

Better to let complex, organic ecosystems flourish and observe them first-hand (go see) than to impose neat, easily measured structures from afar that eat away the resilience underneath.

A Note on Behaviours and Culture

The causal chain is straightforward: the five design levers (Strategy, Structure, Processes, Rewards, People) shape behaviours. Behaviours, repeated over time, constitute culture.

Culture is not a sixth lever. It is not directly adjustable in any larger organisation. If we don’t like the behaviours we see (if people hoard knowledge, blame individuals, or optimise locally) we don’t fix that by asking people to change. We fix it by changing the system design: the Strategy, Structure, Processes, Rewards, and People practices described in this handbook. The Accelerate research reaches the same conclusion from the data side, citing John Shook’s reflection on the NUMMI plant turnaround: the way to change culture is to change what people do, not to first change how they think. (Executive leadership is the exception: they own the system design, so their mindset does have to change first.)

This is why the handbook talks about more than just Process, the whole organisational design has to change. Change that, and behaviours follow. Behaviours, sustained, become culture and performance, which ultimately turns into increased Net Promoter Scores and revenue if fit for the context.