Some of them wired up agents whose main purpose was to consume tokens on their behalf. The practice got a name: tokenmaxxing.

Last year, Meta’s Chief People Officer Janelle Gale told employees that “AI-driven impact” would be a “core expectation” in 2026. Employees created a similar leaderboard to Amazon’s, which was only taken down after its existence went public.

These same engineers are concerned about the environmental impact of AI as well as its efficacy. But tokenmaxxing is the rational response to what they are being asked to do.

If you tell a group of clever, busy people that the number on the board is what matters, and you hint that the number might find its way into a performance review, it doesn’t matter what you intended. You’re going to fall foul of Goodhart’s law.

Leadership may want to ensure their engineers upskill in AI. They may have a deeply-held conviction that competitive advantage depends on becoming ‘AI-native’ as quickly as possible. Gamifying usage in this way pretty much guarantees that AI usage will increase, but it will not ensure that anything gets better. A developer who solves a problem with one careful prompt quickly learns that their score is lower than their colleague who has set up an agent to thrash through forty.

The use of leaderboards may seem extreme, but it’s the logical outcome of how companies have been measuring their AI investment.

AI adoption has become close to universal. The 2025 DORA report puts AI use among developers at around 90 per cent. DX’s Q1 2026 AI impact report has it at 93 per cent, with engineers reporting that nearly thirty per cent of merged code is now AI-generated. Using these tools is no longer a differentiator. It has become the standard. The usage war has been won, so how do we measure impact? This is where organisations are struggling.

LeadDev’s AI Impact Report 2025 found that only 18 per cent of organisations are measuring the impact of AI coding tools at all. Sixty per cent of respondents said they lacked clear metrics to evaluate the impact of AI.

So the real issue isn’t that some companies are incentivising AI usage, or that engineers are responding by gamifying a number. It’s the fact that most companies don’t have a number at all.

The companies that do have metrics that may be useful are looking at development time per feature, weekly time saved per engineer, and time spent reviewing AI-suggested or AI-generated code.

Beyond tokenmaxxing, the numbers that make headlines tend to be the amount of code written by machine. Microsoft claims that Copilot now writes 40% of its code, which seems impressive, but if time spent reviewing this code outweighs the time saving, what does it mean for the engineering experience? If AI-generated code quickly becomes seen as technical debt and needs to be rewritten next quarter, what does that say for value created? How do we measure the long-term impact?

We’re not there yet.

DX has published a framework for AI metrics split across utilisation, impact, and cost.

So far, the impact metrics are still process-oriented. This makes sense because AI is an amplifier. AI does not fix a team, it amplifies what is already there. Strong teams get stronger. Struggling teams find their struggles arriving faster and in greater volume.

The DX Q1 report demonstrates this. They find that quality is volatile. Some teams improve as AI use rises. Others see defects climb by as much as half. A team can now produce more code, more confidently, at higher speed. If a team lacks direction, they are getting faster at building the wrong thing; AI is the most powerful accelerant yet bolted to that particular engine.

Laura Tacho, DX’s former CTO, puts it plainly: early metrics, such as acceptance rate, were meant to show whether a tool was fit for purpose, not to measure its impact across an organisation.

In many ways, as we move into a new paradigm, it makes sense to revert to more basic metrics, while looking to attribute step changes in performance to AI. Did the teams deliver more frequently? Did the product reach the user faster, break less, and take less time to restore when it did fail? How do we attribute those changes to AI rather than other improvement? Optimising for token consumption doesn’t help with any of that. As we learn more, we can work out what an AI SPACE programme could look like.

Amazon’s leaderboard is gone. A senior leader reportedly told staff, in the plainest possible terms, ”please don’t use AI just for the sake of using AI”, and the company moved towards a measure of useful code shipped rather than tokens spent.

Valuemaxxing should be the goal. Token usage is like GDP. It tells you everything and nothing. Valuemaxxing will take time to emerge. We’re in the rollout phase of this technological shift. A lot of the metrics we’ll eventually use are lagging, and some don’t exist yet. In the meantime, we can steer clear of targets and focus on the best proxies we have: did throughput and system stability increase? What is happening to the developer experience? We may not have the right numbers yet, but we can do better than count tokens.

If you’ve worked in technology long enough, you’ve heard this sentence. You may have said it. You’ve almost certainly had it said to you.

It accompanied the sonic boom of the dotcom crash, when companies discovered that continuing to raise venture capital might mean they had to be evil after all. It was the sound of the shutters coming down in 2008, when the financial crisis forced entire industries to find the people they could live without. It was the swoosh of the axe falling in 2022, when the pandemic hiring spree corrected itself and tech companies that had doubled their engineering headcount in two years cut tens of thousands of roles in a matter of months.

Each time, the language was different. The meaning underneath was the same. Fewer people. Same output.

Now it’s happening again. “AI-native workflows,” “productivity multipliers,” “agents.” The terminology varies. The meaning stays the same. Fewer people. More output.

There’s no question that AI is going to change software development irrevocably. There’s a strong argument that it already has. Beneath the promises of 10x productivity and podcast talking points, there are questions that every leader is struggling with.

What does our organisation of the future look like?

What does that mean for the people who work here?

When a leader sits down with her current org chart, and reviews the current team compositions and roles, what changes? What doesn’t? What do the people who work here do on Tuesday morning? What about the same Tuesday next year? What is she going to do with the promised productivity gains, assuming that they materialise?

One of the ways in which AI gains have been promised is that it will make engineers deliver more code, faster. But code generation is rarely the bottleneck in software delivery. More time is invested in system design, knowledge transfer, requirements clarification, and understanding the impact of changes on the existing system. AI can help with some of this, but without a strong documentation culture, organisations will continue to rely on engineers’ deep understanding of the business, the users, and the accumulated decisions that shaped the current system.

That’s before we get into the messy reality of workflows. Engineers waiting for designs to be signed off. The PM not available to confirm how something should work. Backend API development lagging behind the frontend. Changes handed off to QA once it’s “code complete.” Pipelines and approvals to navigate before anything reaches production.

AI puts those workflows up for grabs. A strong backend engineer can lean on AI to create React components and compensate for missing design. A strong frontend engineer can describe an API for AI to develop. With each model iteration, the case for siloed specialists weakens. AI drafts stories and handles reporting, so the product manager’s time shifts from administration to strategy. AI enables engineers to generate test cases against acceptance criteria, blurring the lines and reducing the need for dedicated QA. The bottlenecks around the team will surface more obviously, and they can start to address them.

If our engineering leader follows the logic through, a sense of a possible future emerges. If AI makes full-stack work viable, she needs fewer specialists per team. If QA is automated, she needs quality engineers, not testers. The shape of the team changes. If PM admin evaporates, a strategic PM can focus on product strategy and understanding customer needs. Understanding what to build and why becomes more valuable. When everyone is moving faster, the cost of building the wrong thing goes up.

An organisation with a hundred engineers in 14 teams of seven could be reorganised into 14 teams of five and save 30 positions. This is the path being very publicly taken by several organisations. Companies announce AI-driven redundancies, stock prices go up, and the remaining engineers are told to be grateful they still have a job until the models get better.

But the headlines are anticipating a future that hasn’t arrived yet. The productivity gains from AI to date have been around 10 per cent, and that’s roughly where they’ll stay if nothing else changes. This is the Solow paradox playing out in real time: you can see AI everywhere except in the productivity statistics.

Engineering Enablement

AI productivity gains are 10%, not 10x

Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity…

Read more

3 months ago · 28 likes · 12 comments · Justin Reock

The gains are modest because the bottlenecks aren’t inside the team; they’re in the system around it. Approvals, handoffs, coordination overhead, organisational friction. Cutting headcount doesn’t remove these constraints. Investing in AI-enabled teams, accelerating their ability to deliver surfaces those system-level bottlenecks, which forces the organisation to address them. The constraint moves from funnelling work through a team to enabling the whole system to deliver. That’s how the 10x multiples become possible.

The same hundred engineers could be reorganised into 20 teams of five. No positions eliminated. Same people. Better outcomes. The organisation doesn’t shrink; it multiplies its delivery capacity by 40 per cent, and each of those teams is AI-amplified on top of that.

There’s an obvious counter-argument: “what if there’s not enough work to go around?” Everywhere I’ve ever worked, the issue has been we couldn’t get all the things we wanted done. I’m not sure this would change even with the extra capacity. If it does, then reductions will at least be strategic rather than reactive.

None of which makes it easier for the backend Java engineer with eight years of experience who’s told he’s now full-stack. This is going to be a traumatic change, whichever path is chosen.

“I’m a backend Java engineer” is a sentence that carries the weight of years of career investment and hard-won expertise. Telling someone that the organisation no longer needs backend Java engineers, but does need full-stack engineers who work across the whole codebase with AI assistance, isn’t a job description change. It’s an identity disruption.

The same is true for the QA engineer whose role shifts from writing test cases to owning quality strategy, or the product manager who thinks the disappearing admin work is how they deliver value. The engineering manager who was dedicated to a single team now covers two or three, because smaller teams need less day-to-day coordination and more strategic support. And the leader herself, whose scope of responsibility shifts as parts of her job are automated and others are entirely new. Each of these is a genuine career transition. Losing a job is brutal, but at least it’s clear. Losing what your job meant, while learning a new version of it, is harder to grieve because nobody recognises the loss.

The organisations that navigate this future know this isn’t about role changes alone. This is change management writ large. The cultural shift from “I write code” to “I ship valuable software, and AI writes the code” will not happen easily. The destination isn’t fully visible yet, and it’s going to have to be managed carefully.

Octoshark: Product management and other mythical beasts

Making change easier: the key to survival

Why it matters…

Read more

7 months ago · Andrew Keogh

The companies cutting headcount are making a bet that smaller teams will deliver the same or more, and that the models will keep accelerating fast enough to justify the pain. I think this is misreading where we are in the J-curve. The productivity gains haven’t shown up yet because we’re still in the investment phase of the curve. The returns come after the redesign, not before it.

Cutting headcount is easy for a board to reason with. It looks like action. Redesigning the organisation so that the same people, in different configurations, can deliver on the promise of AI amplification is hard. And that’s where the rewards are.

We can do more. It just doesn’t have to be with less.

The revival of taste as a concept has been prompted by the success of LLMs in changing the way we approach work. As we outsource more of our planning and design to LLMs, so more of that work is going to tend toward the mean of the LLM’s training data.

The effect is measurable. A 2024 study found that while generative AI helped writers create better stories, the use of generative AI made outputs more similar to each other. The weakest writers saw the highest improvements in their writing as a result of using generative AI.

In other words, the beneficial effect that people feel of using LLMs is real, but so are the concerns that more LLM usage leads to more similarity, and a loss of originality in creative endeavour. Individual quality increases but collective variety falls. That’s the trade-off that LLM usage encourages, and it’s the one being made when organisations are focused on AI productivity gains, and people are being laid off so that more money can be spent on AI. The danger is that these companies are buying their way out of competitive advantage and investing instead in a new age of homogeneity.

The central reservation

For two decades, execution was a credible competitive advantage because it was expensive and unevenly distributed. Some teams shipped, most did not. Over time, “we can build it” became confused with “we will win.” But what happens when everyone can build it, and it’s almost the same thing?

Previous changes to software development focused on reducing execution costs. Offshoring, open source, no-code, all offered the promise of reduced execution variability while protecting your design. AI seems to offer more of the same.

However, if you’re using AI to compress your product development lifecycle, then you’ve moved beyond execution to design and planning. This may mean you speed up, but when everyone runs the same averaging engine, outputs converge. The thing that used to differentiate companies, the act of execution, has commoditised. What is exposed is the layer that used to be invisible: the choice of what to execute on.

If the engine tends toward the median, you can steer for the outlier. You have to be prepared to be the adversarial partner in the conversation. You need to continually challenge the LLM, enforcing your taste so the engine helps you produce a better result.

Stepping off the median

The choice of what to execute on is a bet, informed by data and by taste.

The best bets will be fuelled by the willingness to step off the central tendency, to be aware of the pull to the median, and to push back. A product manager might pull one of her tool’s suggestions and try the opposite out of curiosity. An engineer might refuse the first plausible answer because something in it feels wrong. A founder might insist on a thing nobody else thinks is necessary because she has lived with the problem long enough to know better. From outside, all three look like contrarianism. From inside, all three are simply paying attention. Paying attention isn’t the same thing as being right.

Another bet is to leave things un-built. When execution was expensive, the “do not build” decision was often made by capacity constraints as much as any customer data. Now that the price of execution is falling, the constraint is weakened, and the filtering has to be done by judgement. An agent will happily build anything you ask it to. You need to know what not to ask for.

Under the hood

Concerns about taste may lead an organisation to train a custom agent on internal data. The PRDs, the retrospectives, the wiki, the way teams document the way they work. The thinking is that the agent will produce outputs that look like the company instead of outputs that look like the internet.

This does not fix the problem. It creates a new one. Assuming the organisation has good documentation, then the LLM will produce a higher-fidelity average. It will reproduce with great confidence the way the company has done things; past-shaped answers to present problems. It will be on-brand and more competent at making the company’s previous output. What it won’t do is solve a novel problem in a novel way. Taste is forward-leaning. It bets on what has not existed yet.

If the organisation has poor documentation, then the internal agent is unlikely to be any better than a generic LLM anyway.

A useful version of the custom agent would do the opposite job. It would interrogate a draft. It would challenge the customer assumption and surface the unstated constraint. This is the agent worth building. The one that draws attention to the trade-offs being made. The agent encodes the rules of engagement. The operator gives the output its taste.

Speed limits

Whether driven by contrarianism or attention, any choice is a bet, and the number of bets that pay off is sobering. According to a review of published numbers, at Microsoft, A/B tests divide roughly into thirds: a third produce the expected result, a third move nothing, a third move metrics in the wrong direction. Google’s and Netflix’s published numbers are far worse (and probably more honest). Those odds don’t improve when the bet is the obvious one. The median choice fails as often as any other, and on the rare occasion it lands, it hands you an advantage everyone already has. It’s unlikely that the savings of faster execution will outweigh the costs of the wrong decision.

Many companies will spend the next few years optimising the cost of execution, congratulating themselves on the savings. The risk is that they will find their products becoming more interchangeable with their competitors’ as the moat of taste disappears.

Other organisations will look slower from the outside, and very different on the inside. They will be paying for taste, protecting it, hiring for it, building tools that help their operators refuse the obvious answer, and testing the bets that come out.

Now that execution is cheap, the price of not having taste could be existential.

A few years ago, an engineer I worked with introduced the ‘gavel log’ to the team. We were recording the moment a gavel came down on a decision. But the point wasn’t to record the decision. That’s self-documenting. The point was to make a record of what we were choosing between, why this option, what we expected. The log lived in a shared document. We could go back to it.

The first time we revisited a decision, the original conversation was a year old. One person had moved teams. Two others had left the company. The log told us what we’d known at the time, what we’d thought about, the alternatives we’d considered. This helped us ground ourselves in our past selves. We could see how the world had shifted; the decision needed to be revisited. Now we knew what we’d been thinking when we’d made it.

What the log actually held

Gavel logs aren’t useful because they record decisions. They’re time capsules. They record the trade-offs, the alternatives we’d rejected and our reasoning. Our hypothesis about how this would play out. The customer request we’d weighed against the engineering effort.

Decisions are made under specific conditions. Six months later, none of those things look the same. Six months later, the team can barely recall the environment that pushed them one way or another. Questioning if the decision still holds isn’t questioning if it was right at the time. The gavel log helps you remember what you thought was right at the time.

The false friends

This goes further than meeting minutes, which record attendance and actions, and sometimes a decision. They rarely record the trade-offs that produced the decision, because trade-offs are messy and minutes tend to summarise, to be politically safe. AI summaries of meetings do the same thing, faster and more politely. They flatten the conversation that produced it.

ADRs come close. Good ADRs name the choice and the alternatives considered. But ADRs often skip the recommendation that kickstarted the debate, the assumptions baked into the decision, and the conditions that would invalidate it. ADRs only apply to a subset of the decisions a team makes, they don’t capture every debate.

Not every decision

The same is true of gavel logs. Most decisions don’t need an entry. Many smaller decisions can be made and everyone can move on. The ones that earn an entry are the ones with perceived consequence. The strategic bet that the next phase of the product will depend on. The team-shape decision that defines how work flows. The customer trade-off that determines what gets built. Anything where, a year from now, the question “why did we do that?” is likely to land in someone’s lap. If it requires more than a comment in your code, if there’s genuine debate about alternatives, then it’s worth creating a gavel log.

What the record needs to record

A useful gavel log captures what was true at the time: the customer evidence, the team configuration, the technology constraints, the competitive position. It captures the alternatives that were on the table and the reasons each was set down. It names the recommendation and the reasoning behind it. It states what you expected to happen, in language specific enough that you’d know if you were wrong. And it names the conditions that would prompt you to revisit; the things that, if they changed, would make the decision worth reopening. Each entry is written for the reader who’ll inherit it, not for the team that’s in the room.

Keeping the practice alive

Any team that’s had to wonder about some legacy code it’s unpicking can be motivated to start a gavel log. It’s a way to protect their future selves from being in the same position. But, just like a summer fitness routine that doesn’t survive a rainy autumn day, it can be easy to let things go if the commitment isn’t there. Many teams who attempt this have only created a graveyard of three-month-old entries. The fix isn’t heroic discipline. It’s a decision about who owns the log and when it gets updated. This in itself can be a record on the gavel log.

What survives the room

When the practice sticks, decisions stop happening behind closed doors, and become artefacts that live in the open. New colleagues see the reasoning behind the structures they’ve inherited. People who haven’t been in the room can comment without re-litigating the conversation. The clarity of who decides what becomes a touchstone for how to think about the team’s choices.

The team that started the gavel log eventually disbanded. A while later, I left the company. Years later, I met a former colleague for a drink. We were reminiscing about the times we’d spent together, and he mentioned the company had just started refactoring a system we’d built. “I opened up the code,” he said, “and our fingerprints were all over it.” There were references in comments to decisions that had been made, and the gavel logs to support them. Nobody in the modernisation project had to wonder why we’d taken a particular approach. The logs told them.

The decision log doesn’t make better decisions. It keeps the reasons available, so the organisation can think about its own thinking when the world changes.

All leaders, sooner or later, have heard that it is better to be feared than to be loved. Few have read the book the line came from. The line gets quoted; the qualifications do not.

It is quoted at leadership offsites and in management books. It is invoked by people trying to sound bracing about power. What Machiavelli actually said is more careful: that the prince should be both feared and loved at once; that fear is the safer fallback when forced to choose; that the prince above all must avoid being hated. The blunt instrument survived. The nuance did not.

“It is far safer to be feared than loved.”

This reading leaves out a crucial qualification.

“It is far safer to be feared than loved, when, of the two, either must be dispensed with.”

For five hundred years that sentence has done useful work for leaders who wanted the cover of a Florentine philosopher while behaving like a middle manager with a temper, and so inviting hatred.

II. Of The World For Which It Was Written

Machiavelli was writing for a prince. A prince held a city. The people of that city were his subjects. They could not, in any meaningful sense, leave. They could revolt. They could endure. Mostly they endured.

The prince’s subjects feared loss of livelihood, loss of standing, loss of liberty, sometimes loss of life. These were the consequences he could deliver. The stronger the consequence and the fewer the alternatives, the harder fear held. Machiavelli wrote for a world where the feudal lord oversaw peasants tied to the land. The pattern continued in the landlord with labourers in tied cottages on his estate, and then the factory owner who ran a company town. They could rule by fear because the door was closed, and everyone knew what was on the other side.

III. Of Subjects Who Can Leave On Monday

The prince’s subjects could not leave. The modern leader’s people can.

They can leave for the competitor down the road, the start-up they have been talking to for months, the firm that reached out to them following a recent meetup. They can leave the industry entirely. They can quietly become detached, staying at their desks and withdrawing the small acts of discretionary judgement that good work depends on. The disengaged employee is the prince’s subject who has quietly revolted.

Fear may keep people in place for a while, but in the end, it is not enough. What worked in a city of subjects fails in a market for collaborators.

IV. Of A Third Path Machiavelli Did Not Consider

The temptation, having argued against fear, is to argue for love. This would be a mistake. Machiavelli’s caution about love stands. He was sceptical of depending on it, because love is given at the pleasure of the giver and withdrawn at the same pleasure. People will say they love you and then ask a recruiter what else is open, especially if they’ve just had a hard quarter or a difficult conversation.

There is a third option. Machiavelli did not consider it because it was not available to him; his prince ruled subjects, not collaborators. That option is trust.

It is, in some sense, what he was reaching for when he said the prince should be both feared and loved. Durability without coercion. Commitment without sentiment. He could not name it as a single thing because it required a relationship his prince did not have.

Trust is harder than love and more practical than fear. It is asymmetric in a useful way; slow to build, fast to lose, near-impossible to fake at scale. It is earned through four things: transparency about what is true, follow-through on what was promised, consistency on hard days as well as easy ones, and willingness to be wrong when the evidence requires it. None of those are difficult to describe. All of them are difficult to sustain. That is why most leaders settle for being feared. Fear takes less work.

Trust on its own is not enough. Trust without consequences is the niceness that masquerades as kindness and produces neither. What durable trust requires is the modern cousin of what the prince had: clarity about what gets rewarded, clarity about what gets moved on, and the consequences of failure. It is not the opposite of trust; it is the foundation trust is built upon.

The leader who is trusted is told things. She is told things early, when they can be fixed. She is told things in detail, including the parts that reflect badly on the people doing the telling. She is told the things that her counterpart down the corridor, who runs on fear, will not learn until too late, and then he will look for someone to blame, other than himself.

V. Of A Book That Has Not Been Rewritten

It is well to remember that The Prince was advice. It was advice for a particular kind of person, holding a particular kind of power, over a particular kind of people. It was good advice, given those constraints.

Modern leaders do not hold cities. They hold the attention, for a while, of people who have their own options and aspirations. The book has not been rewritten for them. The bumper sticker has been kept; the careful original has been quietly retired.

Perhaps it is time the book was rewritten. A short chapter on fear, for completeness; a shorter one on love; the rest about trust and accountability. Trust is the currency that pays in a market the prince did not have to consider. The leader is something else, a prince without subjects.

The inspirational change ones are the worst. They underline half the pages. They start a book club. Six months later, the organisation remains stubbornly in the same position.

Let’s say a director reads Accelerate. She introduces DORA metrics. She tells her teams to ship smaller, learn faster, reduce cycle time. She means it. She oversees the implementation.

The teams improve. Cycle times come down. Deployment frequency ticks up. She creates dashboards with numbers that go up and to the right.

But business performance doesn’t follow. Customer traction measured in quarters, deliveries measured in roadmap promises kept or missed. These numbers remain stubbornly static.

She runs an AI adoption campaign and it’s the same pattern; she’s implementing tooling that makes her teams go faster. But the organisation’s procedures and practises outside the team mean that the bottleneck moves. It’s never resolved.

The director wonders what she’s doing wrong.

The great beyond

Unfortunately for her, the answer is “nothing.”

McKinsey’s 2026 State of Organizations report found that 88% of leaders say they’re deploying AI. “However just as many report no significant bottom-line impact.” A Harvard Business School study documented organisations with near-universal copilot adoption but “the absence of a repeatable path that leads from a proof-of-concept to a standard operating model.”

The annual DORA report tells us that she’s right to want smaller batches and faster feedback. She’s right that cycle time matters more than roadmap fidelity.

There’s a useful idea in David Foster Wallace’s 2005 commencement speech. Two young fish swim past an older fish who asks “How’s the water?” They swim on for a while before one turns to the other and says, “What the hell is water?”

The director can’t see the water either. She sees the metrics and campaigns for change. She does this in an organisation with a quarterly planning cycle, a fixed roadmap, an established reporting structure and cadence. These things create invisible constraints on flow. Our director experiences them as how the organisation works.

The tension nobody measures

Her performance is measured against two things that operate in tension with each other.

Her teams are measured on flow: cycle time, deployment frequency, change failure rate. These metrics reward small batches, fast feedback, and the ability to change direction when you learn something new.

She is measured on delivery: roadmap completion, quarterly commitments, predictable output. These reward large batches, because a large batch is a visible batch. Something you can put on a slide. Something her VP can take to the board and point at.

The metrics she introduced can change the team behaviour, but they don’t influence the organisational water. The organisation’s reward structure hasn’t changed. The planning cadence hasn’t changed. The definition of progress hasn’t changed. Only the teams have changed, and they could only change so far before hitting a ceiling that wasn’t theirs.

What the dashboard can’t show

The director’s DORA metrics are good metrics. The teams’ improvements are real. The problem isn’t the measurement; it’s the boundary.

Flow was never going to move past a certain point, because the ceiling is the operating cadence of the organisation above it.

This is what makes corporate currents persist. The knowledge is correct. The metrics are correct. The intervention is correct. It’s the scope that’s wrong. The director changed the thing she could change and measured the thing she could measure, and both confirmed her thesis. The plateau wasn’t a failure of execution. It was the system absorbing local improvements without changing the behaviour of the whole.

Seeing the water

The fish don’t know they’re in water, but they know how to navigate a reef. We can make local changes, improve our corner of the ecosystem. But the water itself; the operating cadence, the reward structures, the way progress is defined upward; nobody designed it. It evolved. A thousand rational choices, each one a best fit to the conditions of the moment: board expectations, investor rhythms, sales cycles, regulatory reporting. Over time, those choices calcified into an environment that everyone inhabits and nobody owns.

But ecosystems aren't static. Evolution is a continuous process. The director who sees the water is in a different position to the one who doesn't. She can't boil the ocean. But she can stop treating the plateau as a team problem and start making the tension between what she measures and what the organisation rewards visible to the people who set the conditions. That's not a transformation. It's a shift in pressure. And pressure, over time, is how environments change.

Several years ago, as a PM at a well-funded startup, I spent about a month working on a business case to pivot to an underserved section of the market. I had the data: customer and target feedback, competitive analysis, and a business model for the change. I’d run a pilot to validate the model. I presented it to my leadership, sent them on all of the required collateral, and waited.

Nothing happened.

Six weeks later, I discovered the decision had already been made. A director had mentioned a different idea to the CEO over coffee, and they’d agreed to prioritise that. No business case required. No data consulted. A conversation between colleagues reset the business direction.

I’d made the mistake of thinking that the organisation chart showed how decisions were made. I was wrong.

The tribe decides

Every organisation has a decision system. Very few have designed one.

What exists instead is an accumulation. A layer of approval added after a project went wrong. A steering committee set up when two teams clashed over priorities. An escalation path invented by someone who left three years ago, the reasons for which have faded into obscurity. A daily meeting for ‘decisions’ added to leaders’ calendars where no decisions ever get made.

Everything else in the organisational stack derives from how decisions get made. Planning falls apart when the timing of prioritisation decisions don’t align with the planning cycle. Product thinking can’t take root if every pivot requires re-approval from a committee that meets monthly (arguably if it requires re-approval from anyone outside the product team). Flow systems stall when teams are waiting for a decision that’s stuck in someone’s inbox.

Decision systems are the base layer. Organisations obsess over individual decisions but don’t address how decisions get made. When the formal system is unclear, an informal one takes its place. Personal relationships become the decision-making infrastructure.

Nobody is gaming the system. They’re navigating it. People find the fastest path to a decision, and the fastest path is often through a person, not a process. If a tenured engineer knows that a particular VP will say yes to anything framed as a reliability investment, that’s where they’ll go. If there are no written decision processes, then the tribe will draw its own map. Newcomers have to learn it, and frustration follows. Not just for the newcomers, but for the experienced people who have to act as pathfinders.

Five layers of clarity

In another role, I was trying to raise funding with an organisation in China. Very early in the relationship, it was made clear to me that any proposal we made would pass through five layers of approval before a decision was reached. Each layer had a defined scope of authority. Everyone in the organisation knew exactly how much decision-making power rested at each level. The bureaucracy was astounding, but it was accepted by everybody as how the organisation worked.

It had one thing that most Western organisations lack: clarity. Nobody in that organisation wondered who could approve their proposal. Nobody escalated a decision because they weren’t sure whether they had the authority to make it themselves. In many respects, what looks like unwieldy bureaucracy is better than many ‘flexible’ and ‘fast-moving’ organisations, where things still get pushed to the higher reaches. Not because the hierarchy demands it, but because people don’t know how much authority they have. The result is that senior leaders become bottlenecks for decisions they never asked to own.

There’s no getting away from the social aspect of organisations. There will always be informal routes of influence. The trick is to stop them being the default, the only path of decision-making. That’s when things feel broken.

The false fix

The instinct, when decision-making feels broken, is to add process. Write down a framework. Create a RACI matrix. Build an approval workflow. Establish a governance framework.

These things feel like solutions because they’re actions. Something was broken; now there’s a document. But documentation without substance is weight without structure. A RACI chart that nobody reads is not a decision system. An approval workflow that exists because someone got burned once is not risk management, it’s scar tissue.

More process doesn’t solve the problem if it’s another thing that a newcomer will have to decode through trial, error, and the kindness of a colleague with enough experience to know the workarounds.

The flow of clarity

So what’s the alternative? Clarity. Not more governance, but a deliberate effort to make authority visible, to tell people where they stand so they can act with confidence.

The operative word is granted. Clarity about authority is not a loss of control. It’s the mechanism by which control becomes productive.

A simple flow helps: context, trade-offs, dissent, decisions.

Context means being explicit about the opportunity and the cost before a decision is made. What’s the projected upside? Why this and not something else? How is this in the organisation’s interest? Not a business case, a shared understanding of what’s at stake, the thing that prevents pet projects going through unchecked.

Trade-offs means naming what you’re choosing not to do. Every decision to prioritise one thing is a decision to deprioritise something else. Making this visible prevents the fiction that everything is equally important. It also forces the decision-maker to confront the cost, which is the discipline that separates a considered choice from a reaction.

Octoshark: Product management and other mythical beasts

Responding, fast and slow

Don’t react, respond…

Read more

5 months ago · Andrew Keogh

Dissent involves farming for challenge before the decision is final. Invite diverse voices. Score the idea. Solicit objections. If the objections don’t persuade, press ahead; people can complain and commit. But they need to have been heard first.

Octoshark: Product management and other mythical beasts

Don't mistake silence for support

The tyranny of silence…

Read more

a year ago · Andrew Keogh

Decisions are the point of all this. Start recording what was decided, why, and what you expected to happen. Create a decision log, published as requests for comment while pressing ahead, not as a request for permission. Over time, these records become a body of evidence: how many decisions were made, where they originated, what the outcomes were. The decision system becomes visible and improvable.

Designing your decision system

Everyone in the organisation should be able to answer these three questions about their own work:

• What can I decide without asking anyone?

• What needs to be escalated, and to whom?

• How quickly does this type of decision need to be made?

When people cannot answer these questions, it’s not because the answers are complicated, but because nobody has ever made them explicit. Authority in most organisations is discovered through experience.

Making these three questions answerable is not just a question of adding processes and writing documentation. The documentation is the result of a series of conversations between leaders and teams. A director sits with her PMs and says: here are the decisions you own outright. Here’s where I want to be consulted. Here’s where I’ll trust your judgement unless the cost exceeds a threshold we agree on together. When a new type of decision comes up that doesn’t fit these categories, we’ll talk about it and add it.

This doesn’t have to be a massive transformation programme. These three questions are as useful for a new EM to ask of her director as they are for a director to establish with her teams.

It’s deceptively simple: write down how things get done, and then be humble enough to iterate on it. The discipline is in doing it consistently, not in doing it elaborately. To prevent this becoming another instance of tribal knowledge, schedule regular reviews and retros.

Clarity is a kindness

Clarity isn’t without consequence, especially when it first appears. When a leader makes her authority boundaries visible, she also makes visible the places where authority is unclear, contested, or hoarded. The VP who informally approves everything by being in the right meeting now has to decide whether that authority is real or accidental. The director who escalates every hard decision upward has to confront why. Replacing the default may involve discomfort, but the payoff is significant.

Teams that understand their autonomy and its limits move faster. Not recklessly, with confidence. A PM who knows she can commit to a direction after a conversation with her team and a check against the strategic objectives will act on evidence. A PM who doesn’t know the boundaries of her authority will act on relationships, because that’s the only reliable system available to her.

Clarity is a kindness. It tells people how to participate without having to fully decode the tribe first. It turns decision-making from a skill that rewards tenure into a system that rewards evidence. It gives newcomers the same access to the decision system that the tenured director has always had.

Every organisation has a decision system. The question is whether you’ll design one, or leave it to the tribe to map their own.

While the behaviour of software engineers is changing in response to better tooling, there’s little evidence that imminent replacement is underway. What we have been seeing is something we do have evidence for, decades of it, which is that software improves through conversation.

It’s now or never

Pair programming put two developers at one workstation, thinking aloud together. Laurie Williams’ research demonstrated that pairs produced fewer defects and better designs, even when the practice looked wasteful by any measure of individual output. The secret wasn’t doubling the number of engineers solving a problem. It was the conversation: explaining an approach forces clarity, being challenged before an assumption hardens into architecture solves potential problems cheaply, before they manifest as expensive bugs or outages.

Pair programming was championed by XP, but even the organisations that moved toward XP or later agile practices, tended to file pair programming under “nice idea, too expensive.” Two salaries for one keyboard.

So pair programming remained a niche practice, or became refinement, or distillation. Conversations in advance of the work instead of conversations during it. The rest of the industry optimised for individual throughput and absorbed the rework as a cost of doing business.

Surrender

Then copilots arrived. GitHub Copilot, Cursor, Claude Code, Amazon Q. Organisations adopted them with an enthusiasm that would have been unrecognisable to anyone who ever tried to get pair programming funded.

The adoption wasn’t driven by a sudden conversion to the benefits of pair programming. The impetus was the AI arms race. Every competitor was doing it. Every conference was talking about it. Every engineer wanted to get their hands on the tools. The cost was trivial; a copilot subscription is less than a rounding error on an engineer’s salary. Even the more sophisticated tools carry a cost profile well below a second engineering salary.

What we’re seeing now is the beginning of a new iteration of pair programming. The most effective adopters of AI explain what they’re trying to build and interrogate the response. They prompt the copilot to challenge, suggest alternatives, and force them to improve their approach based on feedback.

Ask me

Now, we see organisations that lagged on pair programming rushing ahead into the next stage. Conversations have gone from “we won’t pay for two humans to do this” to “what if we don’t need the human at all?”

Both positions ignore the same evidence.

The conversation that makes software better requires someone who knows what problem is worth solving. Someone who brings taste, context, an understanding of the user that isn’t derived from a training set. The human in the pair isn’t there to type. She’s there because she has organisational context and can represent the views of users, customers, and the history of the codebase. The act of explaining that to a thinking partner, human or machine, is how that idea gets refined into something that works.

Remove the human, and you still have a system that can generate code. Rapidly, fluently, at scale. You also have a system with no one to tell it whether the code is worth generating. Speed is table stakes. Knowing what’s worth building is where competitive difference lives.

The risk isn’t that AI gets too capable. The risk is that the organisation optimises the human out of the conversation before it understands what she was contributing to it.

Suspicious minds

Pair programming was rejected because it was “too expensive.” AI pair programming is cheap by comparison. AI-alone programming would be cheaper still. The price of the conversation has always been driven by the cost of the second participant. The value of the conversation is driven by the person who knows what’s worth building. A little less conversation could end up costing your organisation a lot.

In 1986, Fred Brooks identified two kinds of software problem. Essential complexity is inherent to the thing you’re building; it can’t be simplified away without changing what the thing is. Accidental complexity is everything we pile on top: the tooling, the process, the ceremony we invented to manage the work. Brooks argued that most of the dramatic productivity gains in software had come from removing accidental complexity, and that the essential difficulties would resist any silver bullet.

Forty years on, the distinction holds.

When a director of engineering stares at a roadmap that stopped reflecting reality around week three, her instinct is to fix planning. When a product leader watches teams deliver on time while customer behaviour remains stubbornly unchanged, his instinct is to standardise the product process. When a CTO adopts OKRs and still can’t explain why everything feels stuck, her instinct is to demand more reporting.

These are all attacks on accidental complexity. A better framework here, a new cadence there, a colourful dashboard that shows red, yellow or green against arbitrary targets. Each responds to a question. None address the essential problem, which is that the systems being measured are driven by invisible norms, unclear interdependencies and human relationships.

Stacks all the way down

Software engineers already have a mental model for this kind of layered interdependence. The tech stack is one of the first things a developer learns: a set of layers, each serving a distinct purpose, each affecting the behaviour of the layers above and below it. You don’t debug a slow service by rewriting the frontend. You trace the issue through the layers until you find the causes.

The same structural logic appears elsewhere. The modern data stack breaks data infrastructure into modular layers: ingestion, storage, transformation, analytics. Each layer has a clear responsibility. When something breaks, you know where to look.

I had that same instinct when examining the organisation itself. There’s a lot of agreement about the things generally covered in Octoshark newsletters. If the way that organisations should work isn’t controversial, why don’t they work that way? Tracing the causes, I uncovered five organisational layers, stacked on top of each other, each one shaping the behaviour of the next. These are independent of the organisation chart. This is the structural logic of the organisation, laid out in a way that engineers already understand, and that explains why easy fixes tend to fail.

The five systems

Every software organisation runs on these five systems. They’re rarely documented, and mostly embedded in culture and habit rather than policy. But they’re there, and they determine how the organisation actually runs.

Decision Systems

Who decides, and how fast?

This is the foundation of the stack. Every other system sits on top of how decisions get made. In some organisations, a product manager can commit to a direction after a conversation with her team and a check against the strategic objectives. In others, the same decision requires three meetings, a slide deck, and sign-off from someone two levels up who will forget the context by Thursday.

Decision systems aren’t about whether decisions are good or bad. They’re about latency and clarity. How long does it take from “we think we should do this” to “we’re doing this”? Who has the authority? Is that authority real, or does it evaporate the moment a senior leader has a different opinion?

The decision system is often unclear to newcomers. People expect organisations to make rational decisions, but that’s rarely the case. The decision system often has its own language, and its own politics, which are only understood (if at all) by the initiated. Decision systems shape everything above them. If your decisions are slow, unclear, or concentrated in too few hands, every other system will be impacted by that, and those impacts will manifest as dysfunction at higher layers.

Planning Systems

What do we commit to, and how do we handle uncertainty?

Planning sits directly above decisions. The quality of your planning is constrained by the quality of the decision system underneath it. If decisions take weeks, plans calcify before anyone can act on them, or worse, endless effort goes into plans [while reality gets on with other ideas](https://www.octoshark.net/p/eternal-sunshine-of-the-spotless). As a result, plans become wish lists that nobody owns.

Most planning dysfunction comes from treating uncertainty as a problem to be eliminated rather than a condition to be managed. This manifests as quarterly or annual roadmaps with fixed scope, fixed dates, and no mechanism for learning. When reality diverges from the plan (and it always does), the response is either to ignore the divergence or to panic.

The PandA framework addresses this directly: structuring work across a cone of uncertainty, from the possible to the promised, with built-in appraisal of outcomes. But flexible planning frameworks can only function if the decision system authorises teams to make and own the choices the framework demands. A planning system is constrained by the decision system underneath it. This is why ‘fixing planning’ sounds seductively simple, but usually results in more process to little effect.

Octoshark: Product management and other mythical beasts

PandA

Product teams are expected to deliver on time and innovate, to stay aligned and be autonomous, to be accountable for outcomes while being rewarded for output…

Read more

a year ago · 1 like · Andrew Keogh

Product Systems

How do we define and deliver value?

This is where leadership tends to think the problem lives. Product teams aren’t delivering the right things. The roadmap doesn’t connect to strategy. Teams are shipping but no needles are moving.

Product systems are about the practices, rituals, and habits that determine how a team discovers what to build, validates whether it’s worth building, and measures whether it worked. Outcomes over outputs is the aspiration; product systems are the machinery that either makes that aspiration real or ensures that outputs are rewarded.

A team can have the right instincts about product thinking and still fail if the planning system commits them to fixed deliverables before they’ve had time to discover what matters. Or if the decision system means every pivot requires re-approval from a steering committee that meets monthly.

Flow Systems

How does work move through the organisation?

Flow is about the mechanics of delivery: how work moves from idea to production, where it gets stuck, what creates friction. Value stream mapping, bottleneck analysis, dependency management, team topologies; all of these live here.

Octoshark: Product management and other mythical beasts

Value stream mapping: don't get stuck in the mud

When my children were younger, they loved a book called ‘Stuck in the Mud.’ A chick gets, well, stuck in the mud, and all the other farm animals try to rescue it, only to get stuck themselves. The key line…

Read more

10 months ago · Andrew Keogh

This is the layer that most agile transformations target. Teams adopt Scrum or Kanban, measure cycle time, hold retrospectives. And sometimes things get better. But when flow improvements hit a ceiling, it’s usually because the constraint is in a layer below. Teams are waiting for decisions. Dependencies exist because the planning system didn’t account for them. Handoffs proliferate because the organisation was designed for a world where specialists sat in functional silos and work was thrown over walls.

Improving flow without addressing the systems beneath it is like optimising a database query when the real bottleneck is network latency. You’ll see small gains. You won’t solve the problem.

Measurement Systems

How do we know if we’re improving?

Measurement sits at the top of the stack because it depends on everything below. What you measure is shaped by what your product system values. How you act on measurement is shaped by your decision system. Whether measurement leads to learning or to blame is shaped by the culture that runs through every layer.

DORA metrics, SPACE, DevEx, NPS, OKR achievement rates; there’s no shortage of things to measure. The question is whether the measurement feeds back into the system in a way that produces change. In healthy organisations, measurement creates a feedback loop: we thought X would happen, Y happened instead, here’s what we’re going to do differently. In unhealthy ones, measurement is a reporting exercise. Numbers go up to leadership. Nothing comes back down.

Octoshark: Product management and other mythical beasts

From Developer Productivity to Developer Experience

A short history of engineering metrics…

Read more

a year ago · Andrew Keogh

A measurement system that exists in isolation, disconnected from the planning system, the product system, and the flow of work, is performance theatre. It creates the appearance of rigour without producing any learning.

The stack in action

An engineering director is in a performance review. Her teams are delivering regularly. Cycle times are reasonable. But the business isn’t growing, and her VP is frustrated, and tells her so. Her instinct is to look at what teams are building (the product system) or how fast they’re building it (the flow system).

She starts there. She introduces outcome-based planning. Teams target outcomes based on customer behaviour. They measure results. As a proposal, it looks great.

Six months later, nothing has changed. Teams still can’t act on what they learn because the quarterly planning cycle has already committed them to the next set of deliverables. The planning system overrides the product system. And the planning system is rigid because the decision system above it requires executive sign-off on any scope change, which takes three weeks and a business case.

The symptom was in the product layer. The cause was in the decision layer. The stack makes that visible.

Or take a different organisation. This one has invested heavily in flow: mature Kanban practices, solid CI/CD, team topologies designed to minimise dependencies. Delivery is smooth. But the teams are delivering the wrong things. Measurement shows activity but not impact. Nobody is asking whether the work matters, only whether it shipped.

The flow system is working perfectly. The measurement system is tracking the wrong signals because the product system never defined what success looks like beyond delivery. And the product system is output-focused because the planning system rewards teams for clearing their backlog, not for achieving outcomes.

Every layer affects every other layer. You can’t fix one in isolation.

Reading your own stack

The value of the stack metaphor isn’t in the framework itself. It’s in what it lets you see. And seeing it is harder than it sounds.

Most organisations have a reasonable understanding of their individual systems in isolation. They know their planning process. They know their delivery cadence. They have metrics dashboards. But because they’re living inside the ecosystem, they can’t see how the layers interact, where one system’s design creates dysfunction in another, and where an intervention at the wrong layer will be absorbed by the system without producing change.

There are good reasons for that blindness. The person who owns the decision system is usually senior enough that questioning it feels like questioning them. The planning system was designed by people who have since moved on; it persists because nobody remembers why it works this way, only that it does. Flow systems are often the product of years of accumulated workarounds, each one a rational response to a constraint that may no longer exist. And measurement systems are political: what you choose to measure signals what you value, and changing that signal threatens whoever built their credibility on the old numbers.

Self-diagnosis requires looking at layers you benefit from not examining. That’s why it rarely happens from inside the system. It’s also why, when it does happen, the instinct is to start with the layer that’s easiest to change rather than the one that matters most.

Sometimes that instinct is the right one. Fixing accidental complexity first; a better standup cadence, a cleaner backlog, a dashboard that actually tracks outcomes; can build credibility and momentum, even when it’s not addressing the essential problem. The danger is in stopping there and mistaking the improvement for the solution.

The organisational stack gives you a diagnostic lens for going further. When something isn’t working, trace it through the layers. If teams can’t pivot when they learn something new, is that a product system problem or a planning system problem? If planning is rigid, is that because the decision system requires certainty? If measurement isn’t driving learning, is that because the metrics are wrong or because nobody acts on what the metrics reveal?

The answers will point you to the layer where the real work needs to happen. It’s rarely where you first thought.

Watch the tapes

Why don’t organisations work the way we want them to? Because they’re essentially complex ecosystems. Making the layers coherent with each other is hard. It’s not easy to structure the informal organisation so that decisions flow at a pace that planning can use, where planning leaves room for product thinking, product thinking shapes what gets measured, and measurement feeds back into decisions.

That coherence is rare. It’s rare because nobody looks at the whole stack. They look at the layer that’s causing pain today, attack the accidental complexity, and wonder why the essential problem remains.

Brooks was right. There is no silver bullet. But there is a diagnostic, and it starts with seeing the stack that was always there.

These biases don’t stay in the clothing aisle. They follow us into schools, into hiring panels, into the data we collect and the systems we build. AI is trained on human data, and human data is soaked in the assumptions of the societies that produced it. This isn’t a new observation. What is newer, and less examined, is what happens when that biased system becomes a participant, or even a driver, in how teams think.

The invisible colleague

Most product teams are using at least one AI tool. It may be generating code, summarising research, drafting copy, suggesting approaches, or a combination of all of these. In many teams, it’s become a de-facto team member; one that contributes more lines of code than some of the humans, and whose suggestions carry weight precisely because they arrive fast and fully formed. As agents take on more complex tasks, that influence is only going to grow.

Every person on a team brings a perspective shaped by where they grew up, what they studied, who they’ve worked with, what they’ve failed at. AI brings none of that. Its perspective is an aggregate; the statistical centre of gravity of everything it was trained on. And the internet is not a balanced dataset. It over-represents certain languages, cultures, and viewpoints, and under-represents others. When a PM asks AI to draft user stories, it draws on those patterns. When an engineer asks it to review an approach, it suggests what is statistically likely.

Alex ‘Sandy’ Pentland, writing in Harvard Business Review, argued that individual reasoning and talent contribute far less to team success than one might expect; that the best way to build a great team is to learn how they communicate and to shape the team so that it follows successful communication patterns. So, what happens when the loudest voice in the room has no pattern of its own, only an echo of someone else’s? The internet is not a representative sample of the world. It over-indexes on English-speaking, technically literate perspectives; the cultures that built these tools are baked into them. That’s the echo your team is working with.

Whose voice does the product hear?

When a PM drafts a product brief with AI, they don’t start from scratch any more. They start from the AI’s version of scratch. The tool has opinions about what a good brief looks like, and they’re easy to accept because they’re close enough to right. But the struggle with the blank page is lost.

Over time, the risk is that the PM’s instincts start to bend toward the tool’s defaults. Not dramatically. Not in ways that announce themselves. But the range of ideas she considers narrows, because the first draft is no longer hers.

We talk about AI as an amplifier, but what if the human’s bias and opinions aren’t being amplified? What if the bias and opinion of the AI gradually reshapes the human perspective?

Now multiply that across the team. If everyone is leaning on the same tool for ideation, research, and decision support, the rough edges get smoothed out. The unusual perspectives, the culturally specific insights that make products resonate with people in real contexts, are quietly filed down. Diversity of thought is hard to build and easy to lose.

Organisations adopt AI to be more productive, more innovative, more competitive. But if the tool is compressing the range of perspectives that inform the work, then the organisation is becoming more homogeneous in its responses to an increasingly diverse and atomised market.

It’s what you do with it that counts

Addressing this requires some consideration of how to integrate AI. There’s no question that it’s changing work, and will continue to do so. Successful teams won’t treat AI as an oracle whose first answer is good enough. They will establish ground rules and voice profiles, encoding their taste with explicit instructions about what to challenge and what to preserve. The best teams will invest AI with what good looks like for their team, their product, their users. The poor ones will accept the statistical average.

Consider a product team at a mid-sized SaaS company. Two PMs, both using AI to draft briefs and synthesise research. The first accepts the defaults. Her briefs are clean, well-structured, and indistinguishable from every other AI-assisted brief in the industry. The second has spent time teaching the tool what her team values: how they frame problems, what questions they ask before committing to a solution, where they’ve been burned before by assumptions that went untested. She’s written ground rules that tell the AI to challenge her first instinct rather than validate it, to flag when a brief lacks a clear hypothesis, to push back when a proposed solution doesn’t account for her team’s specific users. Her briefs are messier. They’re also better, because they carry the team’s accumulated judgment rather than the internet’s statistical average.

We know that the best teams are designed for diversity. How do we bake that diversity into our tools, as well as our humans? How do we shape AI so that it doesn’t shape us? The teams that thrive will be the ones that treated AI the way they treat any new hire: with clear expectations, honest feedback. Continuing to encode diversity of thought into the fabric of our teams is not a nice-to-have. It’s the difference between success and failure.

If you’ve interviewed for a product leadership role in the last decade, you’ve more than likely heard this question. If you’ve been hired into one, you’ve probably tried to answer it for real. The question comes from Michael D. Watkins’s The First 90 Days, which remains the standard text on leadership transitions.

One of its most useful ideas is the STARS model, which asks the incoming leader to diagnose the situation they’re inheriting:

• Startup: assembling a team and building a product from scratch, with no existing customers or revenue to anchor decisions.

• Turnaround: the product or business is in trouble and needs to be rescued before the runway disappears.

• Accelerated growth: things are working, but the organisation needs to scale rapidly without breaking what got it here.

• Realignment: the organisation has drifted from its strategy, or the strategy has drifted from the market, and the two need to be reconnected.

• Sustaining success: the business is healthy, and the challenge is to maintain momentum while finding the next source of growth.

The model’s value extends well beyond the interview process. Watkins makes a persuasive case that the first 90 days in a role determine whether a leader will succeed or fail. A strong transition buys forgiveness for mis-steps down the line. A botched one poisons everything that follows.

Product leadership transitions carry a specific kind of complexity that Watkins doesn’t address, largely because he’s writing for general management. In product, you’re rarely entering a clean startup situation. You may be walking into a realignment or a sustaining success situation that’s slowing down and is now seeking accelerated growth in an adjacent market. In a portfolio organisation, you may be dealing with multiple situations at once.

What would a product version of the first 90 days framework look like?

Three slices of 30

The 90 days break naturally into three phases of roughly 30 days each: analysis, experimentation, and execution. Each phase has a different purpose and a different energy. In analysis, you’re listening. In experimentation, you’re negotiating. In execution, you’re asking the organisation to change.

The temptation, particularly for product leaders, is to skip analysis and jump straight to execution. We’re hired to make things happen. The pressure to demonstrate impact is immediate. But a product leader who starts executing without understanding is optimising for speed without context, like jumping into a Formula 1 car without checking whether you’re at the race track or going to the grocery store.

Phase 1: Analysis

The first 30 days are about understanding and synthesis. You’re building a diagnosis of the company, its position in the market, and the system that produces (or fails to produce) value for its customers.

Watkins identifies four pillars for a leadership transition: business orientation, stakeholder connection, cultural adaptation, and expectations alignment. These work well, but I would split the business orientation into business orientation and product orientation.

Business orientation

This is where you understand the business and its competitive position, by asking questions and gathering stakeholder views on issues, such as:

• What kind of STARS situation are you in?

• What market does the company serve, and where is that market heading?

• Is the business profitable, and if so, what’s the shape of that profitability; e.g. is it concentrated in a single product line or diversified?

• Does the company have a DHM (a way of delighting customers in hard to copy, margin-enhancing ways)?

• What is the financial plan, and how does the product strategy connect to it?

• What’s the business’s appetite for risk and how does that affect its current position?

Product orientation

Alongside the business questions, you’ll want to understand how the product organisation itself operates:

• What are the product team(s) currently working on?

• How much of it is connected to a measurable outcome?

• How much is inherited commitments and maintenance?

• How do we embed hypotheses and measurement into the way the business operates?

As you ask these questions, you’ll start to see the gap between the company’s stated strategy and its revealed strategy; the one you can infer from where it actually spends its time and money. Understanding how to address that gap is where you can deliver the most value.

Stakeholder connection

You can use your need to answer your business and product questions to build relationships with the people who matter, inside and outside the building. You’ll need to find out:

• Who are the internal partners to product; who are the key voices in sales, marketing, engineering, and customer success?

• Who are the strategic customers?

You’ll want their help in understanding their perspective on the organisation and its products, as well as finding out the pain points the organisation has already solved, and which ones remain stubbornly unsolved.

This isn’t networking for the sake of it. You are aiming to understand the system of incentives, relationships, and information flows that determine how product decisions get made. Who really decides what gets built, and how? Where does customer feedback enter the system, and where does it get lost?

Consider building a user journey map that captures all the touchpoints between the organisation and its customers. Not as a deliverable for a presentation, but as a diagnostic tool. As you visualise the information you are gathering, it will help you to understand where the most promising experiments can be run in the next phase.

Cultural adaptation

It’s important to understand the way the system operates today, and to gather some insights into what works well and doesn’t. It may be that there are certain cultural shibboleths, which you don’t want to attack too early in your tenure as it will undermine everything else you are trying to achieve. Good questions to ask include:

• How are decisions made?

• How are meetings run?

• How does conflict get surfaced, managed, and resolved?

• What’s the organisation’s actual (not aspirational) relationship with experimentation?

• Is there a culture of learning from delivered work, or does the team ship and move on without looking back?

These questions matter because the most elegant product strategy in the world will fail if it requires a decision-making culture that doesn’t exist yet. You need to know what the system will accept before you try to change it.

Expectations alignment

Among the various stakeholders and the teams, is there a consistent view of where the organisation is heading? Gather information from as wide a range of people as possible on:

• What does success look like in 18 months? Two years?

• Does the organisation have a view of its planning horizons, from the immediate to the speculative?

• Is the current product and engineering organisation structured in a way that can deliver against those horizons, or is there a mismatch between ambition and capability?

These conversations will uncover (regardless of what you were told during recruitment) whether you were hired to execute a plan or to create one. These are very different mandates, and your transition strategy will need to reflect the one you have.

From analysis to strategy

Pulling these answers together in the first 30 days gives you the raw material for a strategy. Richard Rumelt, in Good Strategy Bad Strategy, describes the kernel of good strategy as having three parts: a diagnosis of the situation, guiding policies for dealing with the constraints of that diagnosis, and coherent actions that implement those policies.

The diagnosis has to be honest. If the organisation’s stated strategy is growth but its revealed strategy is maintenance, that needs to be in the diagnosis. If the team structure works against the product strategy, that needs to be laid out. The whole point of a diagnosis is to name the situation as it is, not as anyone wishes it were.

Phase 2: Experimentation

The next 30 days are about testing the hypotheses that emerged from your analysis. Not proving them right, trying to falsify them. The distinction matters. If you approach this phase looking for confirmation, you’ll find it, and you’ll miss the things that would have told you to change course.

Validating the guiding policies

Each of your guiding policies contains assumptions about how the organisation works and how customers respond. Experimentation enables you to challenge those assumptions. For each guiding policy, ask:

• What is the cheapest way to test whether this holds up?

• What would tell us this policy is wrong?

• Where will we see friction first if we try to implement it?

• Do we have the data and instrumentation to measure the result?

Say one of your guiding policies is “transition to a platform-first mentality.” Maybe the cheapest test is running a single cross-team initiative that requires API-first thinking, and observing where friction appears. If a policy is “data beats opinion,” does the organisation have the data capability to support hypothesis-driven decision making? If so, can you test its appetite for it with one team and see whether the culture absorbs or rejects it? If not, you can start thinking about how to build it in the execution phase.

Creating visible momentum

Experiments don’t only produce data. They establish or destroy trust. In the first 60 days, the organisation is forming its opinion of you. Small wins matter, not because they prove you’re a genius, but because they demonstrate that change is possible and that you’re paying attention to things that affect people’s daily lives.

A “Product Experience” initiative is one thing that can help. Think of it as the product equivalent of a Developer Experience programme. Find the frictions that prevent teams from doing their best work, and fix some of them, or, even better, empower the people doing the work to fix some of them. This could be as straightforward as protecting meeting-free time for deep work, or as involved as mapping the decision-making process and removing unnecessary approval gates. The point is to show that you’re serious.

If there are no quick wins available, start by surfacing the invisible frictions:

• Map the actual decision-making process (not the one on the org chart).

• Document the collaboration pain points that everyone knows about but nobody has written down.

• Work out who informally shapes how things get done, because they will have more influence on your success than many of your peers on the leadership team.

• Choose Product Experience champions; people respected by their peers, not only those with senior titles.

Building the roadmap

Using the analysis and early experiment results, start drawing the product roadmap. This isn’t a Gantt chart. It’s a statement of intent, informed by evidence, that connects the guiding policies to specific initiatives with measurable outcomes. Frameworks such as PandA can be helpful in guiding the creation of this roadmap and ensuring that the right people contribute to it, and they can see how it is different to a delivery plan.

The roadmap needs to serve two audiences: internal stakeholders who need confidence that the product organisation has a direction, and external partners or customers who need to understand what’s coming and why. These are different documents with different levels of detail, but they need to tell the same story. Consider what each audience needs to see:

• Internal stakeholders need the strategic rationale, the connection to guiding policies, and the hypotheses being tested.

• External partners and customers need to understand what’s coming, roughly when, and why it matters to them.

• Both need to see how their input shaped the direction.

Metrics that matter

Everything in the experimentation phase needs at least one clear metric attached to it. Every hypothesis needs to be testable, and the data that will prove or disprove it needs to be accessible and reliable. This sounds obvious, but in practice it’s where many transitions stall. Many organisations agree in principle that they want to be data-driven, but often the instrumentation doesn’t exist, or the data is unreliable, or nobody has agreed on what “success” actually means for a given initiative.

Establish the baselines now. Before you start changing things, measure what matters for your specific situation:

• How long does it take to onboard a new partner or customer?

• What are current conversion rates at each stage of the user journey?

• How does the team rate its own collaboration and effectiveness?

• What does partner or customer satisfaction look like today?

Without baselines, you can’t measure improvement, and without measurable improvement, your transition is a story that can be told by anyone in the organisation. The data will ensure it’s your story that prevails.

Phase 3: Execution

The next 30 days are about delivering value while building the habits that will outlast your transition period. This is where the 90 day plan stops being a plan and starts becoming the way the organisation works.

From coherent actions to business as usual

By now, your guiding policies have been tested. Some will have held up; others will need revising. The coherent actions that survived experimentation become the foundation of your ongoing product strategy. The ones that didn’t survive taught you something, and what they taught you informs the next set of actions.

This is the rhythm you’re trying to establish: act, measure, learn, adjust. It’s not a 90 day exercise. It’s a permanent operating model. To embed it, consider:

• Are teams reviewing the outcomes of delivered work, or shipping and moving on?

• Is there a regular cadence for updating coherent actions based on what’s been learned?

• Can every team member draw a line from their work to a hypothesis being tested?

• Are experiments being treated as experiments (with success criteria defined in advance), or are they pet projects with a different label?

The transition is successful when this rhythm continues without you having to personally drive every cycle of it.

The cultural shift

Execution in the third 30 days is as much about culture as it is about shipping. You’re now setting out on a cultural transformation dressed up as a product transformation, and it will meet resistance.

Farm for dissent. Actively seek out the people who disagree with the direction and discover why. Some of their concerns will be legitimate; the diagnosis was incomplete, or an assumption was wrong. Others will reflect the friction that any change creates. Both are useful data. The concerns that reflect genuine gaps in the diagnosis need to be addressed. The concerns that reflect discomfort with change need to be acknowledged and managed, not dismissed.

Transparency matters here. You’ll want to build habits that make the organisation’s learning visible and accountable, for example:

• Share the metrics, including the ones that show where experiments failed.

• Run honest retrospectives that examine what was learned, not who was at fault.

• Publish decision logs that explain the context, the problem, the decision, and the rationale. Treat these as requests for comment while pressing ahead.

• Update the roadmap to reflect what you’ve learned; the organisation needs to see that the plan is a living thing, not a monument.

What success looks like

At the end of 90 days, the goal is not a finished product strategy. It’s a validated direction, a set of practices that connect strategy to execution, and an organisation that knows how to learn from what it delivers. You’ll know you’re in a good place if:

• You have a roadmap informed by evidence, not assumptions.

• Cross-functional alignment comes from shared understanding, not imposed agreement.

• Teams can draw a line from their daily work to the outcomes the business is trying to achieve.

• The people around you describe the change as something that happened naturally, as though the organisation simply started working better.

That last one is the sign it worked. The transition succeeded not because you arrived with a brilliant plan, but because you built the conditions for the organisation to figure out what the right plan was.

The product-specific challenge

Watkins wrote The First 90 Days for leaders in general. The framework holds up, but product leadership adds layers of complexity that the book doesn’t address. Product leaders navigate the tension between sustaining what works and finding what’s next, building strategy while simultaneously delivering against existing commitments, earning the trust of engineering, sales, marketing, and the executive team, all of whom have different definitions of success.

The 90 day framework, adapted for product, is really about establishing an outcomes-oriented culture. Not outcomes as a buzzword in a planning document, but outcomes as the thing the organisation actually optimises for. The diagnosis tells you where you are. The guiding policies tell you what matters. The coherent actions tell you what to do about it. And the measurement tells you whether any of it worked.

“So, what’s your 90 day plan?”

Build the conditions to learn. Then learn. Then act on what you’ve learned. Ninety days isn’t long enough to transform an organisation. It’s long enough to set the direction and prove that the direction is worth following.

There’s possibly no limit to what we can get “the AI” to do. The promise of AI is extraordinary. We are in the foothills of a revolution that will drive changes in how everything works. The organisations that harness AI well will accelerate away from those who aren’t able to leverage it.

But there is a gap between the promise and the reality, and it is not a technology gap. It is a crack in the foundations that prevents us building an AI-driven future.

Unintended consequences

Over the past two decades, organisations moved fast and broke things. They prioritised delivery over documentation. Knowledge lived in people’s heads rather than being systematically available, particularly when things were fixed or a new feature was added to an existing application. Tribal knowledge replaced written understandability.

This wasn’t an intentional hoarding of information. The choice to prioritise the next-most-important-thing over documentation was always rational. Each of these decisions made sense at the time. None of them were malicious. There was pressure to get the next customer, build the next marketable moment. The people who understood the system were still in the building. There was no stress about documentation. Why write it down when you could walk over and ask? Why worry about documenting something you might pivot away from?

Nobody anticipated that one day, in order to keep up, you’d need to be able to feed documentation back to the machines.

LLMs require well-documented systems so they can generate reasonable insights. AI needs something to reason with. The cumulative effect of years of underinvestment in documentation, data quality, and engineering practice has created an environment where AI often has remarkably little to work with. This is particularly impactful in organisations that have been around for over a decade that don’t operate in highly-regulated industries. The organisations most desperate for AI to transform them are often the least able to make the leap. There’s nothing for the AI to leverage. Or worse, the documentation that does exist is outdated and contradictory. Garbage in, garbage out.

The amplifier

AI does not fix problems. It amplifies whatever it finds.

Give an LLM clean, well-structured data and coherent documentation and it will do remarkable things. It will surface patterns humans would miss. It will generate code that respects the architecture. It will accelerate onboarding, speed up incident response, make sense of complex systems. It will do what the pitch decks promise.

Give it a codebase nobody fully understands, documentation that was last updated three years ago, and knowledge that lives in four people’s heads, and it will confidently amplify the confusion. It will generate plausible nonsense. It will produce code that looks right but ignores dependencies that were never written down. It will automate the wrong things faster than you ever could manually.

If there’s not enough information for a human to understand, there’s not enough information for the machine to explain.

An amplifier is only as good as the signal it receives.

The gap

There’s lots of data being published about how AI is failing to make the leap, and that most AI initiatives fail. From a certain vantage point, this looks like a discernible pattern.

An organisation decides it needs an AI strategy. An executive steps up. A team is formed. Tools are procured. A pilot project is selected. And then, the pilot stalls. Not because the AI doesn’t work, but because the team discovers that the data is incomplete, required documentation is missing, the system boundaries are unclear, and nobody can explain how the thing they want to improve actually functions.

The AI holds up a mirror, and the organisation doesn’t like what it sees.

This is the moment where many organisations either retreat (”the technology isn’t ready yet”) or push through with brute force, throwing people at the problem of cleaning up decades of technical and knowledge debt in a matter of weeks. Neither approach works.

In order to succeed, we need to acknowledge that the foundations need work. The model that disregards documentation and written understanding has run its course. We’re moving into a new world of well-documented systems, and that this work has value far beyond generating better AI outcomes. In a particularly nice irony, it’s possible to use AI to generate this documentation.

Clean documentation helps humans too. Well-structured data supports better decisions with or without a model. Clear system boundaries make teams more effective regardless of whether an LLM is in the loop.

The opportunity

For years, the benefits of investing in documentation, data quality, and engineering practice have been undervalued. It’s always been the right thing to do. The value of risk reduction has always been well-understood, but it has struggled to compete with the next feature on the roadmap.

AI changes the calculus. The investment in good practice now has an urgent, concrete business case. The organisations that have clean data will be able to deploy AI effectively. This is why we’ve seen regulated industries report great efficiencies with AI. The organisations that have well-documented systems will be able to onboard AI tools that actually understand what they’re working with. The organisations that invested in the boring fundamentals are about to accelerate in a way unavailable to those that didn’t.

This is not a small advantage. It compounds. An organisation with good foundations deploys AI effectively, which generates better data, which improves the AI, which accelerates the organisation further. An organisation with poor foundations struggles to deploy AI at scale, falls further behind, and finds the gap widening with every quarter.

Good practices have always been the right investment. AI has made them an urgent one. The organisations that treated documentation as a luxury and tribal knowledge as acceptable are about to discover the cost of those decisions. Not because they were wrong at the time, but because the world changed around them.

If you want the AI to do it, you need to give it something to work with.

I watched a talk given by Andrej Karpathy at AI Startup School in June 2025. The talk is called “Software Is Changing (Again).”

Karpathy divides the history of software into three eras, which he calls Software 1.0, Software 2.0, and Software 3.0.

Software 1.0 is what most of us mean when we say software. A human being writes explicit instructions. The computer follows them. The instructions live in files. The files can be read, reasoned about, argued over, version-controlled. If something goes wrong, there is a line of code or data structure that caused it. You can trace failure through your logs. Success and failure operate in predictable, deterministic ways.

Software 2.0 arrived when using weights to program neural networks began replacing those explicit instructions. At Tesla, Karpathy watched neural networks eat the C++ codebase. Rule by rule. Function by function. The engineers who had written the rules did not immediately disappear. They just gradually became less central to the thing. The rules became training data. The training data became weights. The weights became something that could see, driving Tesla’s Autopilot.

Software 3.0 is where we are now. Using prompts we can instruct LLMs, marking a fundamental change as we move into programming in our native language. Karpathy claims that the same replacement will now happen between Software 3.0 and the other paradigms.

I want to be careful here, because “the programming language is English” sounds like a line from a pitch deck at a conference where the coffee is bad and the badges are laminated. It sounds like something someone says before showing you a slide with a very large number on it.

But Karpathy means it structurally. When you write a prompt, you are writing software. It is executed. It produces an output. The difference is that the compiler is a large language model, the syntax rules are loose enough to permit ambiguity and personality and occasional confident wrongness, and the results are probabilistic rather than deterministic.

This is not a metaphor. It is a description.

The uncomfortable implication is that everyone who uses an LLM is writing software. It is uncomfortable because many of the people writing this software would not think of themselves as writing software. They think they are having a conversation.

Meanwhile, the people who think of themselves as programming struggle to shift from a deterministic to a non-deterministic mental framework.

Consider the person writing a prompt right now. They type a sentence. The model completes the thought. The person reads what the model wrote and, finding it almost but not quite right, adjusts their prompt to steer toward what they actually meant. The model reads the adjustment and responds accordingly. With enough of these interactions, the act of creating crosses from the human to the machine and back again.

The black box

There is a black box at the centre of this.

Every revolution in software had one. In Software 1.0, the black box was the computer itself: you fed it instructions and trusted that the transistors did what they were supposed to do, without needing to understand semiconductor physics. In Software 2.0, the black box became the model: you fed it data and trusted the gradient descent, without needing to understand precisely how it learned what it learned.

In Software 3.0, the black box is the large language model. You feed it language. It produces language. Between input and output, something happens that no one, including the people who built it, can fully explain.

Karpathy describes the LLM as a new kind of computer. Not a new application. Not a new framework. A new substrate. He compares it to the early operating systems of the 1960s: expensive, centralised, accessed remotely by many users sharing the same machine, none of whom have full utilisation. We are all, right now, thin clients connected to a mainframe in the cloud.

The personal computing revolution has not happened yet in Software 3.0. We are just about past punch cards.

The persistence of memory

Engineering leaders talk of using LLMs as being like having an army of interns. But interns learn. That is, in some ways, the entire reason for interns to be in the business.

The LLM has a particular property that Karpathy names anterograde amnesia. It cannot form new long-term memories. Its knowledge is fixed at the point of training. After that, it can learn within a conversation, accumulate context within a session, follow a thread for as long as the thread is in front of it. But when the session ends, it ends entirely. The next conversation begins from nothing. The same questions asked again. The same ground covered again. No memory of having been here before.

What comes next are agents. Not the fully autonomous kind, the ones that have leaders talking excitedly of 10x productivity with a tenth of the people. A human remains in the loop. The AI generates. The human verifies. The loop runs. The speed is the thing: not that the human is removed, but that the cycle between attempt and correction accelerates until the combination is faster than either alone.

Karpathy calls the period we are entering the decade of agents. Not the year. The decade. A decade ago, we were told that driverless cars would be on every road by now. They are not. The technology moves at its own pace, indifferent to the urgency of the announcement.

This is, among other things, a warning about impatience.

I have been thinking about what it means to live inside a revolution that you are also trying to describe.

Every previous revolution was easier to see in retrospect. The industrial revolution was not called that by the people working in the mills. They were just working in the mills. The information age was not called that by the people writing COBOL in 1967. They were just writing COBOL.

We are in the unusual position of naming the revolution while it is happening.

There is one thing Karpathy says that I keep returning to. He says that a good software engineer right now should be fluent in all three paradigms. Not just the new one. Not just prompting. They should be able to write the explicit code, train the model, and write the prompt, and know which of the three is appropriate for the problem in front of them. The skill is not mastery of Software 3.0. The skill is knowing which era you are operating in.

This article was written in Software 3.0. Not entirely. Not even mostly. But the black box was present, generating and being corrected, in the way that Karpathy describes: the loop running, the human verifying, the attempt and the correction cycling faster than either alone could manage.

I did not set out to write about my own process. But the thing about living inside a revolution is that it keeps insisting on being noticed.

Software is changing....

I like your manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Who could argue with any of that?

Let’s put it to the test-o!

The Agile Manifesto, reproduced in full above, was written during a meeting in Snowbird, Utah in 2001. The people behind it met to discuss new ways of creating software. They were looking for a better methodology than traditional ‘waterfall.’ They were inspired by the rise of extreme programming (XP) and other approaches that prioritised flexibility and faster delivery over full requirements gathering and change control.

The Manifesto laid the foundations of the Lean Startup movement, and gave rise to a new approach to software development that blended XP with some of the tenets of lean manufacturing pioneered by companies like Toyota. There are few, if any, software development houses today that wouldn't lay claim to being agile.

Victory is ours? Not quite.

What should being agile mean? The manifesto is pretty clear. Looking at it now, I wonder if the authors missed a trick by not emphasising learning over delivery of new features, but overall, the message is clear.

What does being agile mean? In many organisations, it means “we do SCRUM.” We have daily stand ups. We have story points.

A surprising number of people haven’t even read the manifesto. At one organisation, it took me weeks to persuade one senior colleague to read it. I think he thought that it was going to have the length and readability of the Communist Manifesto.

We take foundational knowledge for granted at our peril. Many leaders and organisations are simply adopting practices and imposing them on teams with no understanding of the real issues those teams are wrestling with. Then they get surprised when nothing improves.

There’s nothing in the manifesto about how, and that’s ok. There are a million ways for teams to improve their practices and learn how to improve their ability to deliver software, which in turn should be measured in customer value. That’s the key message from Snowbird in 2001.

It’s alright to say things can only get better

So what went wrong?

A consulting industry spun up, selling practices and certifications. Delivering more things became the promise, an irresistible siren song for organisations looking to “do more with less.” Performative “ceremonies” took the place of doing the right things or removing frictions.

If we were to hold a retrospective on the success of the manifesto now, we’d see that the promised revolution has been suppressed.

Process

Ask many Product Managers to describe how they’re agile, and they’ll talk about Jira. They’ll tell you about their sprint cadence, their story points, their velocity charts. The practices have become the point. The values that may have led to their adoption have evaporated. Organisations wanted to move from waterfall to agile, but the reliance on process prevents learning.

So we get standardisation. Scaled agile. Diagnostic checklists. Cross-functional dependency mapping. There are compelling reasons why these might solve organisational problems, but without a deep understanding of why these things are being adopted and what success looks like, it becomes performative.

Let’s take the daily stand-up as an example. This was described to me by an Engineering Manager as the most important 15 minutes of his team’s day. It’s a brief moment of coordination and establishment of blockers, owned by the team, for the team. In many organisations, it’s a status report. Everyone nods while the other team members give meaningless updates. This opportunity for learning and reflection becomes a form of micro-management.

In many cases, the ringmaster in this circus is called a Scrum Master, an interesting juxtaposition to the idea of servant leadership that is supposed to underpin agile software development. And don’t get me started on the idea that there’s a product “owner.”

Sprints are not sustainable over long distances. Sustainable practices compete with the language. The language wins.

The best teams I’ve worked with evolve their practices. They’ve inspected and adapted so that their way of working fits their context rather than a framework. They’re not precious about their processes. They do what works and discard what doesn’t.

They understand what matters. Individuals and interactions over processes and tools.

Documentation

“Working software over comprehensive documentation” is probably the tenet of the manifesto that has done the most unintentional damage to good practice. I have worked with more than one startup that interpreted the manifesto as permission to stop documenting anything at all. The pain that’s caused by a lack of focus on documentation is incalculable. As many organisations look to step into the brave new world of AI, this lack of documentation is causing real headaches - if there’s nothing for a human to understand, there’s nothing the machine can explain.

Documentation didn’t completely disappear of course. The emphasis shifted away from an explanation of context and how the system delivered value into how to deliver the next shiny feature. Technical documentation devolved into Jira tickets. Confluence documents may get written, but rarely read, and even less often updated in line with the system.

Helpful documentation that could be used as a map generally disappeared. Dependencies became transient, forgotten as soon as the software was delivered. Architecture decision records wasted away. Onboarding guides died of unfashionability. The promise that the code was self-documenting or that change control would be sufficient has proved false. You can see how work was tracked and planned. But that doesn’t tell you why a decision was made or how the system actually works. Working software with working levels of documentation may have been a better aim.

Collaboration

The manifesto envisioned teams working closely with customers, learning from them, and adapting based on what they discovered. What many organisations built instead was an elaborate internal negotiation system.

Story points became a currency for negotiation between product “owners” and delivery teams. The sprint itself, originally conceived as a short cycle for learning and adaptation, became a set of commitments.

The product owner role was conceived to bring the customer’s voice into the team. In practice, it often created a buffer rather than a bridge between the team and the customer. Then stakeholders inserted themselves between the product owner and the customer. Stakeholder wants became more pressing than customer needs and the product role changed from understanding problems to administering a backlog. Collaboration gave way to command and control.

Planning

Planning is probably the area that shows how far we’ve failed to come. Organisations adopted agile’s ceremonies but kept waterfall’s expectations. The roadmap is a gantt chart paved with promised features. The annual planning cycle still dictates what gets built. The teams work in sprints, but all that’s really happened is that the waterfall has become a set of rapids.

The manifesto says “responding to change over following a plan.” Most organisations have built elaborate systems for responding to change by updating the plan. The plan is never questioned. It’s just revised, re-baselined, and all too often, is represented as success, regardless of what is delivered, and how the market receives it.

Where’s me jumper?

How did we get here? The manifesto was written by practitioners. It was written for the people doing the work. The consulting industry repackaged it, created certifications, and sold “transformations” to organisations, marketing faster delivery while disregarding the cultural changes needed to lead to it.

Something the manifesto doesn’t explicitly state but probably should have: the organisation that learns fastest wins. Not the one with the best plan. Not the one with the most rigorous process. The one that treats every cycle as an opportunity to discover something it didn’t know before.

Agile, at its best, is a learning system. Short cycles exist so you can learn what works. Retrospectives exist so you can learn how to improve. Customer collaboration exists so you can learn what’s valuable. Every element of the manifesto points toward an organisation that treats uncertainty not as a problem to be eliminated but as the environment in which it operates.

Every piece of software is, to some degree, an act of invention. It involves creating something that hasn’t existed before, or at least placing it in a new context. This is thrilling and uncertain. Pretending otherwise, pretending that with enough process and enough rigour we can keep the chimerical predictability of waterfall while painting in the colours of agile, makes it so that failure is almost guaranteed.

It’s not agile’s fault. It’s not agile.

Twelve principles

We follow these principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity--the art of maximizing the amount of work not done--is essential.

• The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Who could argue with any of that?

A reminder

This is part of a semi-serious series of words that should be removed from the agile lexicon. Follow the links below for earlier entries.

The only f-word I won’t say: Agile swear words part 1

Commitment-phobia: Agile swear words part 2

My vendetta against the v-word: Agile swear words part 3

Let’s leave grooming at the altar: Agile swear words part 4

Agile swear words part 5: Just

One law that’s often referred to but arguably causes more dysfunction than the rest put together is Conway’s Law.

Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.

In other words, software architecture tends to reflect the way in which work is organised in terms of team boundaries and communication pathways.

Ignore Brooks’ Law, and your late project will be even later. Ignore Goodhart’s Law and you end up with meaningless metrics. Ignore Hofstadter’s Law, and you’ll continue to fall foul of the planning fallacy.

Ignore Conway’s Law, and you can grind your organisation to a halt.

Around 70% of digital transformations fail. Forbes attributes this to organisations treating transformation as a technology project rather than a challenge of human adoption. This is Conway's Law writ large. You can’t change the system architecture without changing the communication architecture.

Inverse manoeuvres

The reverse is also true. Changing the organisation chart or reporting lines without also investing in addressing underlying technological patterns will lead to failure. Moving people around to address the next problems your organisation faces makes complete sense when you’re a startup. When you’re a scale-up, or an enterprise, doing this without accounting for the technical landscape you’ve already built is a recipe for disaster.

This is how most re-orgs also fail. Changes get made to team structures, new projects get divvied out. Little attention is paid to the ownership and technical debt the teams are currently contending with. A monolithic architecture persists while software teams are ‘agile,’ following the ceremonies of Scrum but receiving no benefit from it due to the anchor of the pre-existing software it has to support. This architectural dissonance is a blind spot that prevents organisations from reaching their potential.

Orchestral manoeuvres

If we’re going to overcome this dissonance by design, we’re going to have to organise both sides of the organisation simultaneously. We can’t let digital transformations happen without bearing in mind the organisation structures that birthed them. Equally, we shouldn’t be blithely assuming that moving team members around, or changing reporting lines, is going to result in a re-architecture of our software unless we’re intentional about it. Conway’s Law imposes taxes on re-orgs.

In Team Topologies, Matthew Skelton and Manuel Pais draw out how this dual approach should work. The book treats team design and software architecture as inseparable. They propose a methodology for structuring teams to match the desired software architecture, and then doing the work to evolve both together. It’s a must-read for any leader faced with the question “How do we best organise ourselves?”

All too often, the response falls into a predictable pattern. Teams get re-organised. Maybe the language of Team Topologies is used. A platform function gets created to support product teams, those teams that do boring work that nobody understands are referred to as complicated subsystem teams.

However, the hard work of mapping this new structure against the existing codebase and ensuring clear lines of ownership is rarely completed. Clean reporting structures often disguise dysfunctional approaches to system architecture. At best, there’s a Frankenstein’s monster quality to the organisation, as the mis-matches between the code architecture and the organisation structure make themselves felt. At worst, zombie code wanders the halls, searching for an owner, degrading the organisation’s security posture. Whenever an upgrade is needed or someone needs to change that code, everyone is scared to tread into the danger zone, for fear of what they find, and for fear of becoming responsible for it.

A re-organisation can be a sensible response to challenges the organisation faces as it tries to scale, or get better at launching new products, or any of a thousand decisions it faces. Without mapping desired organisation changes to code ownership, though, the re-org is condemned to, if not failure, then certainly underachievement. Every time the organisation reinvents itself where it doesn’t grapple with this issue, it makes it worse. It only takes a few of these shallow re-orgs to create a challenge that has grown by an order of magnitude.

Wrestling manoeuvres

If the code still couples teams together, then your teams are still tightly coupled, whatever the re-org might say.

Every re-org that ignores the codebase adds a layer of scar tissue. Every unowned service is a future incident. Every domain boundary that exists on a slide but not in the code is a tax on the teams that have to work across it. The compound interest on this debt can turn a scaling challenge into an organisational crisis.

Conway’s Law will assert itself whether you plan for it or not. The only question is whether you’d rather design your way through it or be surprised by it again in your next re-org.

For example

A customer reports that their data export is wrong.

Why?

Because new validation was added to the system last week, reformatting some reports.

Why?

Because a new column was added to the underlying table.

Why?

Because a partner integration required it.

Why?

Because the company is extending its services and the impact of changing the table wasn’t understood.

Why?

Because the team that built the integration were working from outdated documentation and didn’t know about the reporting dependency.

The surface problem was a broken export. The root cause was that nobody knew the systems were connected, and there was no documentation for this reporting dependency. Fixing the symptom will sort out the immediate issue. Identifying and fixing the cause will ensure no repetition of the problem.

What?

Toyota developed the five whys technique as part of its Toyota Production System. It requires no software, no certification, and no consultants. You’d think it would be everywhere.

It isn’t.

Why?

There’s a legitimate criticism that complex problems have more than one root cause; that’s certainly true. There are versions of the technique that acknowledge multiple causes through branching off a fishbone diagram. Some companies have embraced digging deeper than five whys, using seven whys.

However, I don’t think that simplification has been the barrier to adoption. I don’t see any evidence that more complex tools have replaced five whys anywhere. I think that many organisations lack the curiosity to even follow a single thread to the end to fix an issue.

Why?

Why don’t organisations show that curiosity?

Because someone is waiting for an answer. The support ticket needs to be closed, the stakeholder needs a date, the customer needs a response. The pressure to act is immediate. The pressure to investigate underlying causes dissipates once that response is given.

So, short-term fixes get rewarded. Workarounds get created. Sometimes they even get documented. The issue is parked until the next time something similar happens.

Why?

Why don’t we fix the underlying problem?

Tracing a problem to a root cause can be complex. It can take time and consideration. Many organisations don’t allocate time to the possibility of failure. Others don’t give sufficient value to the idea of improvements through retrospective analysis.

These two blind spots prevent the organisation from being able to see how to fix its problems. Without retrospectives, learning takes a back seat. Without scenario planning, the planning fallacy puts the team in conflict with reality, and reality always wins. In organisations that optimise for capacity, and not for flow, teams are always operating under pressure.

Why?

Why don’t organisations plan with slack so that we won’t necessarily have to pivot when the unexpected happens?

Often, it’s about trust. Leaders in low-trust organisations hear of planning to 80% capacity and they see waste. They think that teams will slack off if they’re given slack time.

So every gap is filled. The planning fallacy dictates that we assume perfect conditions, perfect information, and perfect execution. The leader who pretends certainty is rewarded. The leader who presents a plan with deliberate gaps is treated like the dog ate their homework.

Why?

Why does the organisation reward certainty over honesty?

Because certainty is easy to communicate. “We’ll deliver X by March” fits in a subject line and gives an executive something they can report upwards with confidence. “We believe X is achievable by March, assuming no significant unknowns emerge and the dependencies we’ve identified hold, but there’s meaningful uncertainty around the integration layer” doesn't fit easily in a C-suite update.

Over time, the communication becomes the culture. It’s like a fairground mirror version of Conway’s Law. If honest uncertainty never makes it into the room where decisions are made, the organisation is geared to reward certainty, to treat every forecast as a commitment.

As a result, unforeseen challenges are treated as failures of planning rather than features of complex work. The entire operating model assumes that with enough rigour, enough process, enough estimation, we can eliminate surprise. That if we just plan harder, reality will cooperate.

It won’t. Software development is complex work happening in a socio-technical system. Uncertainty isn’t a bug. It isn’t even a feature. It’s the system.

Using five whys to understand why organisations don't use five whys may feel meta. But the technique works. At least one of those roads leads to trust. This is where we leave the whys behind and move onto how. How do you build that trust in your organisation?

The team is drowning. The startup has grown to 25 people, up from 8 a quarter ago. Everyone reports to the founder/CEO, who’s pulled in a million directions. Nobody can get hold of her. Without her, nothing can get decided.

The best engineer at the company has been offered another role and is looking for career progression or a strong reason to stay. The CEO can’t see tomorrow clearly, let alone how to move forward without this engineer.

So she gives him what he asks for. She promotes him to manager, promises he’s on the CTO path as the company grows. But she doesn’t give him any guidance. She just puts him in charge and disappears back into the chaos. Her only instruction? The company can’t keep up with its customer commitments, so hire more people.

Three months later, everyone is miserable. There’s now 40 people at the company, and nobody knows what to do. The Product Manager hired by the newly-minted CTO is tearing her hair out because every customer meeting seems to result in a new pivot. As a result, nothing is getting delivered. The company lost a great engineer three months ago and gained a struggling technical leader. Nobody has been able to step into his shoes because the CTO doesn’t have time to train the next cohort of engineers.

The company’s ability to scale is blocked by its reactive hiring strategy.

You can’t hire for urgency

I’ve written before about the “urgency-industrial complex,” where responsiveness becomes the de-facto product strategy. Startup survival can hinge on being able to pivot based on customer discovery.

As the Agile Manifesto has it, “Responding to change over following a plan.”

That reactive posture can work for product decisions. But it’s catastrophic for hiring, particularly in scaling organisations.

Hiring permanent staff has lead times. Two to three months to interview and onboard. Another month at least to get up to speed on the organisation’s culture, goals, and working practices. If you’re looking to grow leaders, you may need another three months before someone has the credibility to lead.

Most startups are so busy growing, that there’s no time to forecast hiring needs, and growing payroll too quickly can burn up the funding runway. The problem is that, if you wait, by the time you realise you need leaders, it’s too late to create them. If you’re hiring for what you need right now, it’s usually two months too late by the time you get someone in the door, longer before you get them up to speed. You can’t compress these timelines with wishful thinking. You can prevent being blocked by hiring ahead.

Hiring ahead

At a scale-up I worked with, we took a counter-intuitive but more intentional approach. As we achieved product-market fit, we began to see the sales pipeline fill. As a B2B SaaS company, we could use the lead time on deals to review the sales pipeline and forecast when customers would onboard, and how quickly. We used customer feedback and sales intelligence to predict what we’d need to deliver. This allowed us to create hiring plans, where we were able to look at the company we’d be in six months, and hire for that now.

We knew we were taking a gamble that the customers would land, but the alternative was that we wouldn’t be able to meet our customer needs, in which case we wouldn’t survive anyway.

This went beyond just hiring ICs. As we reached 20 employees, we started to actively interview for people who would want to become people leaders. We were explicit about the opportunity in interviews, creating a cohort of people who would be ready to step up as team leaders as the organisation grew. When we needed them to step up, they had the context, relationships and credibility to lead effectively.

Building capability

Hiring ahead was just the first step. We started to embed the structures and practices we wanted the growing organisation to have so that there was support in place for our new leaders. Many ICs fail as people leaders because they’re not given the tools to succeed. The assumption that someone who is good at writing software will be good at leading people who write software is misguided. But even someone who has the talent and motivation to lead is likely to fail if they’re not supported as they step into the role.

We thought about our reporting structures and how we would create team alignment in advance. We asked ourselves how decisions would be made. What should be escalated? How would teams interact as we grew horizontally?

By thinking these decisions through, we were able to develop a structure where people could succeed, and we planned for that success, creating clarity for new leaders when they came into the role.

Clarity is a kindness

Being clear about the organisation’s growth plans makes all the difference.

Let’s say that you have 15 people today, and you forecast that you’ll grow by 50% every six months for the next two years. In six months, you’re going to be a 23-people strong organisation. In a year, you’ll have 35 people.

If you’re aiming for a structure where teams will have 6 - 9 engineers and a Product Manager associated per team, you’re growing from one such team, to two, to three very quickly. You won’t be able to keep directing them in detail. You need to ensure that you give your incoming leaders the tools they need. You need to identify or hire your future leaders now, and you need to create some guardrails for them when they get into position.

Guardrails

What kind of guardrails make sense?

The idea of guardrails is not to create process and bureaucracy. It’s to give clarity and autonomy to leaders so that you can make space for them to lead as the organisation grows. Examples of guardrails include:

• Decision boundaries (what can teams decide independently?)

• Communication rhythms (when do we sync? what’s async?)

• Quality gates (what’s non-negotiable?)

• Ownership clarity (who owns what?)

These guidelines mean that rigid processes, command-and-control, or decision paralysis are avoided. Everyone has clarity on what is within their scope of authority and a quick way to get to a decision.

Install these guardrails before you need them. As you grow beyond one team, institute basic decision-making authority, and establish guidelines around meeting practices. Once you’re beyond two teams, you should have ownership guidelines in place and a RFC process for cross-team decisions. Once you’re at 50+ people, you may need to institute more formal practices, or divide efforts into different departments, e.g. establishing platform or developer experience teams.

Warning signs

Signs that you’re behind where you need to be include:

• You’re involved in every decision, however small

• People are complaining about chaos

• Teams are stepping on each other

• You’re desperately adding process reactively

Beyond 30: When to specialise

Going from 15 to 35 people is about adding your first managers, and creating your first formal organisation structure. The next stage of scale is going from 30 to 100+, becoming a real organisation. For this, you’ll need to think about layers and specialisation. At 30 people, most startups have generalist engineers on product teams. Everyone does a bit of everything - infrastructure, quality, features, support. This works because coordination overhead is still manageable.

At scale, though, the generalist approach creates bottlenecks. If each team is responsible for its own infrastructure, different practices emerge and quality can suffer. Security and compliance starts to become uncoordinated. A solution may be specialist teams, or a developer experience function with platform engineers who build shared infrastructure, establish quality standards, and own compliance. You’ll be reaching the point where you need to build out a proper support function. Up until now, this was probably managed informally or with everyone being on-call.

At the scale-up, we took the difficult decision to split ourselves in two. One half of the business became the support and platform function and the other continued to be the customer-facing product organisation. This took us a few weeks to implement, and it was a big change, impacting everyone who worked for us, but it was also our salvation, making it possible for us to scale and grow.

The six-month rule still applies: if you think you’ll need a platform team at 50 people, start hiring at 40.

The exception

One scenario where reactive hiring can work is bringing in contractors for well-defined, short-term needs.

If you suddenly need five more engineers to hit a critical deadline, contractors can be effective. They come with experience, require minimal onboarding, and can contribute immediately. There’s nothing wrong with buying capacity for a specific timeframe.

Spending wisely

Hiring ahead can feel expensive. You’re paying senior salaries for people who won’t manage for 6-12 months. But reactive hiring is more expensive: lost momentum due to unclear decision frameworks, poor managers put in a position where they can’t succeed, low morale, and quality problems from lack of ownership.

Guardrails may sound like process. You’re adding structure while still small. But lack of structure can lead to chaos. No clear decision-making authority leads to paralysis. Every decision requires coordination, teams block each other constantly, your best people are spending time in low-quality meetings instead of building high-quality software.

Won’t AI fix all this?

You might be tempted to think AI will solve this problem for you. We’ve already seen AI coding assistants increase IC productivity dramatically. The role of software engineer and Product Manager is being reshaped by AI, potentially meaning that you can (to use the dreaded phrase) do more with less. For example, AI might push back the specialisation inflection point - if generalists can maintain infrastructure with AI support, the need for platform teams could be significantly pushed back.

AI can also assist with compressing the recruitment process. But the fundamentals don’t change. High-performing teams operate with trust, which is built through shared experience.

The six-month rule might become a five-month rule, or even a quarterly rule. But it doesn’t disappear.

Hiring ahead remains essential. It just might look slightly different.

The reactive trap

Some organisations operate reactively by design - responding to urgent customer demands, pivoting quickly to market changes. Reactive strategy can work for product decisions where you can pivot in short timescales. More than once in my career, I’ve found myself writing a new product roadmap overnight.

But hiring has real lead times, and deep costs for getting it wrong. Hiring ahead isn’t a luxury - it’s essential.

Related reading

Appendix A - a practical playbook

This appendix is a playbook for hiring ahead at each inflection point. If you’re scaling, bookmark this and check it regularly for how you’re growing.

From 15 to 30 people

The situation:

• One team, everyone knows everyone and can help on most things

• Founder/leader directly manages most people

• Informal decision-making relies on the CEO

• Customer pipeline shows 50% growth every 6 months

Customer capacity forecast:

Currently, 15 people are serving 20 customers, sales pipeline indicates 8-10 new customers per month in the next 6 months. Can you serve 70 customers with 15 people? No. You’ll need 23-25 people at least.

At 25 people, you need 3-4 team leads and some division of ownership between the teams you’ll create.

Actions to take now:

Hiring (Month 1-2):

• Hire 2-3 senior ICs with management potential

• Be explicit in interviews: “IC role now, management opportunity in 6-12 months.” See Appendix B for more details.

Guardrails to install (Month 1 -3):

• Weekly 1-1s between ICs and people leaders

• Basic scheme of delegated authority

• Team size limit (no team larger than 8-9 people)

Leadership development (Month 3-6):

• Give future leaders mentoring responsibilities

• Have them lead small initiatives

• Include them in hiring and onboarding

• Signal explicitly that they are on track for leadership role.

By Month 6 at ~25 people:

• Your 2-3 hires are in team lead roles

• They have context, relationships, credibility

• The CEO is now managing managers, and decisions are made accordingly.

Cost:

3 senior hires × 6 months before they manage = investment in smooth scaling

Alternative cost:

Reactive hiring + chaos + failed promotions + lost momentum = much higher

From 30 to 100 people

Your situation:

• 3-4 teams, each with a team lead

• Teams are generalist (everyone does everything)

• Starting to see coordination overhead

• Specialisation becoming necessary

Customer capacity forecast:

You have 30 people serving 60 customers, growth continuing at 40% every three months.

You’ll hit 50 people serving 100+ customers in the next six months.

At 50 people, you need 6-8 team leads, an additional layer of leadership (managers of managers) and are likely to turn to platform or developer experience teams to lighten the burden on your product teams.

Actions to take NOW at 30 people:

Hiring (Month 1-3):

• Hire 1-2 people who’ve managed managers before

• Hire for specialist roles if you see bottlenecks emerging

• Continue hiring senior ICs with management potential for additional team leads

Guardrails to upgrade (Month 1-3):

• Clear ownership (every service/product has exactly one team that owns it)

• RFC process for cross-team decisions (1-page, 72-hour comment period)

• Formal team splits when teams hit 9 people

• Monthly retrospectives and lightweight, continuous planning ceremonies.

Organisational structure (Month 3-6):

• Create manager of managers role (your team leads now report to them)

• Consider first specialist team to address bottlenecks

• Define career ladders (IC track vs management track)

Leadership development (Month 3-6):

• Train your team leads on managing (don’t assume they know how)

• Create peer support groups (team leads meet regularly)

• Start identifying next cohort who might become managers in another 6-12 months

By Month 6-12 at ~50-60 people:

• Clear organisational structure

• Specialist teams handling platform/developer experience

• Decision-making flows smoothly without everything escalating to CEO

• CEO is focused on strategy, not operations

Warning sign you’re behind:

If your CEO is still making all decisions at 50 people, you’re 6 months too late.

Key principles across all stages

Always forecast 6 months ahead:

• Sales pipeline + close rate = customer onboarding forecast

• Customer load = team capacity needed

• Team size + lead time = hire now

Always hire for potential, not just current need:

• Can they deliver as IC immediately? (first 3-6 months)

• Do they show leadership signals? (months 6-12)

• Do they want to manage? (explicit career interest)

Always install guardrails before your teams get overwhelmed:

• Establish decision rights before teams are blocked

• Create communication ceremonies before meeting overload

• Clarify ownership before territorial conflicts

• Limit team size before co-ordination becomes unwieldy

Always acknowledge uncertainty:

• The customers might not land (but you plan anyway)

• The hire might choose IC path (and that’s fine)

• The structure might need adjustment (build in flexibility)

• Perfect planning is impossible (but some planning beats none)

When NOT to use this playbook

Don’t hire ahead if:

• You don’t have 6+ months runway (solve cash flow first)

• You haven’t achieved product-market fit (focus on survival)

• Your sales pipeline is completely unpredictable (too much uncertainty)

• You’re genuinely in exploration mode (team structure will change radically)

In these cases:

Use contractors for immediate capacity needs, keep team small and generalist, wait until you have clearer visibility before building permanent structure.

But remember, the longer you wait, the longer your scaling will take when you finally need it. The lead times don’t compress because you’re in a hurry.

Appendix B - How do you identify future leaders?

If you're on this growth trajectory, you need someone who can contribute as an IC immediately and can grow to be a manager as you scale. How do you identify potential?

Interviews are imperfect, but, much like democracy, they remain the best system we have when you consider the alternatives. Scale-ups are likely to be placing people in their first leadership role, so they won’t have direct experience. You’ll need to ask candidates for engineering positions about behaviours they have exhibited that indicate leadership traits, for example:

• Tell me about a time you influenced without authority

  • Why: Can they demonstrate the ability to persuade peers and stakeholders?

  • Look for: collaboration, persuasion, building consensus

• Tell me about a time you got things wrong?

  • Why: Managers must be able to admit mistakes and change course without blame

  • Look for: intellectual humility, learning orientation, willingness to take responsibility.

• How do you like to receive/give feedback?

  • Why: The ability to give and receive constructive feedback is fundamental to good leadership.

  • Look for: thoughtfulness about approach, ability to listen and repeat back what is being said.

• Tell me about a project that failed and what you learned

  • Why: Managers must handle failure productively

  • Look for: ownership, learning, systems thinking

You still need strong IC skills. Management potential is necessary but not sufficient. The ideal candidate:

• Can deliver as IC immediately (needed for first 6 months)

• Shows leadership signals (potential for months 6-12)

• Actually wants to manage (explicit career interest)

In the interview, when candidates demonstrate that they might be a good leadership candidate, it’s a good idea to be open with them and see how they react. Telling them that an opportunity to become a people leader may arise within 6-12 months filters for interest and sets expectations clearly.

Three days after the quarter starts, the DM comes from leadership.

“We’ve got a new ask. The team needs to size this.”

The PM argues back the quarter is full. The team are now fully loaded and focused on delivery of the just-agreed work.

“I just need to have a meeting with some of the engineers so that they can give me an estimate. It should only be 30 minutes. Are you really telling me we can’t have some engineering attention for half an hour?”

And this is how the forgetting starts.

The executive asking for something new has forgotten that this 30 minute meeting will likely need an hour’s preparation, as people try to figure out what the new ask might involve, and what the impact on the plan might be - this is the purpose of the meeting after all.

The usual outcome of this meeting is a request for more information as unknowns surface during the discussion. From the exec’s perspective, that’s perfectly reasonable - they need more input to make a decision.

But they’ve forgotten that the decision to interrupt the team has already been made. Now it’s just a question of impact. These unknowns need a day’s investigation. Another meeting is scheduled, spawning more work. And the original plan sits there, unchanged, as if none of this is happening.

The requester’s logic is sound: “I’m not asking you to build it. I’m just asking you to tell me if you could.”

But sizing isn’t free. Understanding the question well enough to answer it honestly is work. And that work isn’t in the plan.

The illusion of zero cost

The exec genuinely believes the ask costs nothing. They get their answer, they make their decision. In the meantime, the team’s planned work falls behind as the ask takes precedence. From their perspective half a week has vanished but their ‘plan’ hasn’t changed. Something has to give. Longer hours, cut corners, or a missed commitment. Any slack the team may have had is gone.

The plan assumed full capacity. Every week was accounted for. Every person was allocated. The organisation could tell itself it was maximising its return on investment.

But plans built to 100% capacity have no flex. No room for questions. No buffer for the unexpected. The moment anything arrives that wasn’t anticipated, and something always does, there’s nothing to move around to account for it. Something has to give.

The failure only surfaces to the exec at the end of the quarter when the team misses its goals. By then, they’ve long forgotten about their ask. The ask and the failure are no longer connected in anyone’s memory.

The spotless plan

The plan continues to sit there, unchanging. If there are progress reviews, it’s never acknowledged that the team is effectively working on something else. Without a mechanism to reflect the interruption and its impact, the capacity taken leaves no mark.

By the time the consequences arrive, the cause has been erased. So the pattern repeats. The team keeps failing to deliver. Their reputation suffers. The asks keep coming, because they appear to cost nothing. Burnout and attrition may appear, but the dots are never joined. Like Joel waking up with no memory of Clementine in Eternal Sunshine of the Spotless Mind, we meet the same failure again and again, wondering why it feels so familiar.

What would need to change

The issue isn’t that questions shouldn’t be asked. Executives should consider alternatives, and often need more information to make the best trade-off. But raising questions while treating the plan as an unchanging and unchangeable artefact ensures failure and frustration.

Interruptions aren’t free. There is always a price to pay.

Here are a few suggestions to rescue yourself from the eternal sunshine of the spotless plan:

Plan for impact, not capacity

Too many plans focus on maximising the utilisation of every engineer. If the plan accounts for every engineer for all of the time, then the plan is a fiction. There’s always invisible work. Add the inevitable asks and distractions, and it’s clear that a plan built to 100% capacity can’t succeed. Organisations that focus on utilisation aren’t giving their full attention to what matters most - changing customer behaviours in ways that impact the bottom line. If your organisation spends more time considering utilisation than impact, the lens needs to shift.

Make the cost visible

You may not be able to change the dynamic around capacity planning, but you can name the cost. When a new ask arrives, call out what it displaces. “We can size this or do that, but it means X slips by a week.” Force the trade-off into the open. Make sure the cost is explicit. This will at least make the exec consider it. Otherwise, the pretence that it is free will persist.

Track the asks

Keep a record of what came in after the plan was agreed. When the quarter closes and performance to plan is reviewed, you’ll have the evidence to connect cause and effect. The pattern becomes visible. The memory is no longer erased.

Not right now

Ask if the request really is urgent and can’t wait. An ask that can’t wait a week probably can’t wait at all. These should be treated as a genuine emergency, not a quiet tax on the plan. Most asks can wait. Make it acceptable to say so. And make it clear that the ones that genuinely can't will blow up the plan.

Memory may fade, but plans remember what we choose to write down. The only way to escape the loop is to make the forgetting visible.

I’ve lost count of the number of articles I’ve read in the past year speculating on Rachel Reeves’s future as Chancellor. Not because of government u-turns or her performance, but because the latest Gross Domestic Product (GDP) figures are due. The same ritual, quarter after quarter: the ONS releases a number, the headlines claim disaster or progress, even on changes as low as 0.1%, as if this single metric is the sole arbiter of economic progress.

But there’s been fierce debate over whether GDP is even a valid metric for measuring economic health. GDP measures the value of goods and services produced in an economy over a quarter. It ignores quality of life, what happens in the home, investments in education, or environmental stability. On the plus side, it’s simple and easy to understand. On the other, even its inventor acknowledged that it wasn’t a useful measure of wellbeing.

But its simplicity is its draw. By boiling all economic activity down to a single figure, economists, politicians and journalists draw inferences on wider economic health. Widening inequality can be celebrated as long as GDP goes up. We’re burning through our planetary resources at an unsustainable rate but that’s ok as long as this measure of growth ticks up.

Widening the lens

There have been many attempts to broaden the focus of economic health measures. One that has garnered widespread attention has been the doughnut, created by Kate Raworth in 2012. The doughnut shows the sweet spot between social foundation, where the needs of all people are met, and the ecological ceiling, which is the capacity of our planet to support us.

The red areas in the ‘hole’ in the doughnut show where countries fail to provide their citizens’ basic needs. In the graph above, we can see that countries, both rich and poor are failing to provide sufficient levels of peace and justice. The poorest 60% are falling behind on energy needs while the richest 40% are overshooting dramatically on causing climate change.

The doughnut looks across 12 measures of social foundation, and nine measures for the ecological ceiling. It’s an elegant overview, but its complexity means it’s a novelty for nerds. We’re unlikely to ever see a headline saying the Chancellor should be applauded because the social foundation gap has narrowed in connectivity.

What you see is all there is

It’s not that stories about such progress go unreported, it’s that they’re not given the same importance as that single number. It’s as if GDP is the pulse of the economy, and heart rate is the only measure that matters, regardless of the overall condition of the patient.

The same fixation plays out in the corporate world, with the quarterly ritual of earnings calls. These follow the GDP playbook: a number is released, analysts react to movements of a few tenths of a percent, and CEOs are declared visionaries or failures based on whether the line went up and to the right. The market doesn’t ask whether the company is building something sustainable. It asks whether revenue or earnings per share meet or beat expectations.

Following a brief reset during the pandemic, growth is back on the agenda with a vengeance. Generative AI has added rocket fuel to the boosterism, as organisations eye dramatic productivity gains and look for opportunities to cut headcount.

The AI gold rush offers a perfect case study. Companies are laying off workers citing AI as the cause while the technology requires massive investment in data centres that consume staggering amounts of energy. Failure to reach the social foundation in one metric, overshooting the ecological ceiling in another. All in the service of chasing growth.

So, what would a corporate doughnut look like? The inner ring would be the social foundation, below which employees and stakeholders suffer. The outer ring would be the organisational ceiling, beyond which it would damage itself and its environment.

Social foundation

The inner ring would include sound business practices that support employee wellbeing and reward institutional health. Categories could include:

• Living wage

• Sustainable workload

• Psychological safety

• Job security

• Voice and agency

• Health and wellbeing

• Learning and development

• Purpose

Other than the living wage, these could be measured through regular employee surveys.

Organisational ceiling

Beyond the outer ring, the key measures would be around customer trust and supplier relationships, or policies that lead to the organisation damaging itself or its environment. Categories could include:

• Environmental footprint

• Poor supplier relationships

• Customer trust erosion

• Market monopolisation

• Community harms

• Extractive pricing

• Employer reputation

• Underinvestment

These don’t tend to get much airtime in an earnings call, but they’re strong predictors of whether your company will still be thriving in five years.

Doughnuts all round?

While we can imagine what a doughnut for corporate responsibility might look like, it’s hard to beat the simplicity of a single metric. Below the corporate growth headline, a lot of product organisations have “One Metric that Matters”, a guiding light for making decisions. That’s not necessarily a bad thing if other signals are also being taken into account, but if growth is the only thing that matters, well, growth is the only thing that gets measured.

Engaging with the doughnut demands attention and a cognitive load to understand the interrelationships that affect the sweet spot. It’s a great picture, but it doesn’t have the immediacy of a single figure. It remains a fantastic economic idea for nerds to noodle on, while the world continues to obsess over GDP.

It’s a fool’s errand to ask executives to put limits on their companies’ growth so they can stay in the doughnut’s sweet spot. They are subject to market and shareholder demands to deliver better financial results quarter on quarter. The doughnut is intellectually superior. The market pays the bills. The market wins.

Growth wins. It doesn’t win because it's right, but because it fits in a strapline. Simplicity beats complexity at the altitude of a country or a company. The doughnut advocates may be right, but the reasons they are right are also the reasons they won’t win.

When people come to me with problems, I often hear myself saying “You know, I was thinking about this...” At one point, some of the engineers I was working with started making fun of me for it.

It’s not that I’m a know-it-all (I hope!). It’s more that I keep the fragments of conversations and the things-we-should do next rattling around in my head. I don’t look to build beautiful long-term solutions without others. I’m not trying to invent the future on my own. I am constantly playing with Lego in my head, trying to understand what we could make with the blocks I see lying around.

I like to test and prototype ideas, looking for feedback on half-baked theories quickly. The availability of generative AI as a thought partner and collaborator should be amazing for people like me, and in many ways it is. When you sit bolt upright at 5 a.m. because a potential idea or solution has popped into your head, how cool is it to be able to not only jot it down, but quickly iterate on it, and have some conversation about the idea with a willing partner?

There’s huge excitement among leadership about the changing face and pace of collaboration. Rather than having engineers and product people work together, AI can now be used to rapidly prototype. Agentic AI is coming to take over entire workflows. The future belongs to one-person startups who can change the world with nothing more than an idea and a $20 per month Claude subscription. Or so the pitch goes.

There’s no question that prototyping is unrecognisable from a year ago. AI enables us to get to a higher fidelity faster than ever before. The technology is improving all the time and the promise is that implementing software all the way to production will eventually become frictionless.

There’s only one problem with this narrative. AI doesn’t tell you when your idea is terrible.

Rapid iteration only works if you’re building on a strong foundation. AI can help you build faster, but it won’t tell you if you’re building the wrong thing. Your 5 a.m. ideas will always be warmly received, however poorly-formed they might be in reality.

You could be on a fast-track to mediocrity, clarifying your thinking, but not getting any push back or challenges to your premise. AI is wonderful at helping you develop your idea, but it’s terrible at disagreeing with it.

Some LLMs are more sycophantic than others, but generally, responses are primed to be positive rather than adversarial. You can miss out on the leaps that come from debates and disagreement from people with different perspectives.

Without that early friction, ideas that should be forged on the anvil of debate instead get built to high fidelity before being exposed to any real challenge. By then, you’ve invested time, effort, and ego. The sunk cost makes pivoting harder. You’re at risk of creating something beautiful that won’t survive contact with the world.

Rather than embracing AI as a co-creator, it seems many people have given up thinking and outsourced the creative act, losing their voices in the process. The phrase AI slop has passed into common parlance to describe the generic AI-generated articles that have started to appear everywhere, from social media to entertainment sites.

Good ideas become great products and implementation through the push-pull of debate, and the friction of trade-offs. You can share a 5 a.m. moment of inspiration with AI, but you can’t expect it to generate one itself. An AI is never going to laugh at you for playing with Lego, and sometimes you need that.

The efficiency gains we will make with AI are already astonishing and will accelerate. There’s going to be unimaginable change as work gets automated and orchestrated by machines in ways we never thought possible. But I think the spark of innovation remains innately human. Share your Lego with people with different perspectives.