Read Part 1 here

In film, the shoot becomes the easy part when everything else is done. It’s an absolute breeze compared to post-production. The edit suite is where the film moves from content to product: the cut, the grade, the sound, the thousand invisible corrections that turn footage into something an audience will sit through to the end. The hardest parts of software development happen in the equivalent of the edit suite. The earlier parts, getting to the prototype, are like creating a storyboard.

A demo answers one question. Does this idea have potential? If we take SVPG’s four big risks of feasibility, viability, user value and usability, the demo helps to address usability, and potentially feasibility. The biggest risks of viability and user value are still out there. Can you turn this into a live, scalable product? Will users get sufficient value out of it for you to make returns on your investment?

The chemistry read

The ability to generate a high-quality, high-impact prototype accelerates the feeling that you’re on the right track. People leave the demo believing they are most of the way to delivering a product that survives contact with the world. The distance, though, hasn’t narrowed.

Scalability, security, reliability are all bills that are yet to fall due. The customer who does something you never anticipated with the product hasn’t appeared on the horizon. What has changed is that the demo used to be more obviously unfinished, so you could feel the weight of what was still coming. Now it feels done, and the remaining work stops feeling pending, or at least seems heavily discounted.

Then it arrives, unannounced, anyway.

A demo is a chemistry read. Two actors read a single scene, the room feels a spark, and the spark is real. But it cannot tell you whether the film gets financed, whether the performances hold across two hours and a difficult shoot, whether anyone will sit through the whole film. Everything that makes it a film is still ahead.

When the product is the model

And here the hard work may change, because we’re now building different types of products, and only one of them maps onto the way we have done things before.

If you are developing a traditional software product, you’re building something deterministic. You can build the way you always did, or use AI to accelerate. You test it the way you always did whether using AI or not. Your tests are there to ensure it does what you told it to, or it does not, and you can prove which, and the tests will return the same results until something in the code changes.

In traditional software, a green test stays green; one passing run is a promise about every identical run to come. A model makes no such promise. Its output is a sample from a distribution you have not measured, so a passing run tells you the distribution is not empty, and nothing else. A demo that works is evidence the way a single coin flip is evidence about a coin: it proves heads is possible, and tells you nothing about how often it lands tails, or which inputs send it there. The failures that cost you aren’t yet visible: the inputs you would never have thought to try, and the cases where the model is fluent and wrong at once.

In a hybrid, where AI is being embedded in a traditional app, the old rules still hold everywhere the code is deterministic; the new ones take over the moment the path runs through the model. A model in the middle of deterministic logic is not half the problem; it is a new one, because the code downstream cannot tell a right answer from a plausible one, and acts on both the same way.

So the hard part moves. Deterministic testing asks whether the code does what you intended, and ends in a green light. Evaluation asks whether the model is good enough, and how badly it fails when it is not, a question with no green light at the end. The work becomes the harness that scores it, the guardrails that fence it, the monitoring that catches it drifting; most of the engineering is now around the model, not in it. An AI product is not a reel you can print and screen unchanged. It is a live show that varies with each performance. It needs a stage manager standing in the wings because there is no take you can lock.

And the same system has to be able to say why it did what it did. A model returns an answer, not a reason, and “the model decided” is fast running out of road as an explanation. A lender in the United States has not been permitted to hide behind an algorithm too complex to interpret since 2022; from August 2026 the EU gives anyone subject to a high-risk AI decision a right to a clear and meaningful explanation of it. So alongside proving the product behaves well enough, often enough, you have to be able to reconstruct after the fact why it reached the conclusion it did on the one occasion that mattered, for a customer, or for a regulator who will not be impressed by a shrug.

That work is nowhere in the demo. It needs to be in the product.

From chemistry read to premiere

The demo makes people believe, and the belief is valuable. It can help guide the team through the path to ten thousand concurrent users, all interacting with the system in different ways. It becomes dangerous when it allows people to imagine that they’re at a premiere rather than a chemistry read.

Pinocchio didn’t become a real boy overnight. He had to put in the work to learn how to exist in the world.

I spent a couple of years working in film production. I used to joke that the hardest part of any endeavour was finding something worth producing. Then the hardest part became polishing the screenplay. Then the hardest part was raising finance. Realising the director’s vision from the screenplay in actual production? So much harder than anything else, but an absolute breeze compared to post-production. Then, depending how the finance was raised, you have to sell the thing you’ve made and get it into festivals, which is, as you’ve probably guessed, harder again. You can fail, and your project can die at any of these stages.

I learned that film production is both ruthless and the preserve of wild optimists.

The thing that kept optimism grounded is that you always knew whether you were looking at a rough cut or a finished picture.

It Looks Done

She built it in two afternoons.

It works. You ask it a question in plain English and it answers. It reaches into the right data, comes back with something sensible, and does it while the room is watching. When she finishes, a Senior Director says the hard part is behind us, and everyone believes him. Including her.

The demo is a real milestone. The thing she built in two afternoons would have taken a team a quarter not long ago. It’s a notable achievement.

But the truth is that the hard part is not behind us. It has barely started. The trouble is that the demo was convincing enough that nobody in the room remembers the difficult part is still ahead. There’s a lot of work remaining to turn Pinocchio into a real boy.

The afternoon that looks like a quarter

For most of the history of software, the prototype looked like what it was. A wireframe was obviously a wireframe. A click-through prototype was obviously a fiction in the same way as a storyboard is obviously a guide to how to shoot a particular scene; you tapped the one button that worked and everyone understood the rest was painted on.

You could not mistake the sketch for the building, because the sketch looked like a sketch. Turning it into high-fidelity software was obviously a future step.

Figma started this change. The quality of prototyping Figma made possible is the silent movie era of the current moment. AI has pushed us into Technicolor.

The thing you build in an afternoon now looks like the thing that takes ten weeks. It speaks fluently. It handles the path you walk it down. It makes all the right noises while the room is watching. It does not look like a sketch; it looks like a product.

A convincing prototype used to be expensive, and the cost kept everyone honest. Now the convincing version is an afternoon’s work.

Speed of discovery

The speed at which you can discover if an idea is worth pursuing has always been the part worth speeding up. Learning what might work matters more than the race to market, because most ideas do not deserve to be built and the cheapest thing you can do is find that out early. AI has promised to make that work nearly free. You can stand up something real enough to test a hypothesis in an afternoon.

A demo tells you that you have understood the problem well enough to fake a solution. It tells you that you haven’t failed yet. That is all it tells you. It does not tell you the solution holds when the data is missing half its fields, what happens at scale, what edge cases are going to keep your development teams and support teams awake at night. It says nothing about the guardrails required for operation in the real world, or how a particular experience can be explained to a regulator.

That distance, between a thing that works in the room and a thing that works in the world, is the same size that it has always been. We’ve made getting to the room faster, but the hard part is still ahead of us.

A beautiful prototype is a matte painting. From the one angle the camera is allowed, it is a whole city; step sideways and it is plywood and paint.

The ten months of development work do not vanish. They become a surprise. The surprise becomes a “delay.” The delay becomes a problem that gets escalated. The escalation slows the development team further as they are subject to a cycle of progress reviews. All because an assumption was allowed to take hold that the hard work was already done.

The order of difficulty

I have spent a long time defending discovery, warning about teams that skip the qualifying step and rush to build. Now, something else is happening: the fidelity of the prototype lets the qualifying step be mistaken for the product itself.

There’s still a benefit when the demo is used to inform customer discovery. The discovery and learning are real. The danger is that the demo can enable a room of insiders to talk to itself and call it research. Nobody has been near a customer; the organisation has admired its own reflection and recorded the self-admiration as discovery.

The same admiration then becomes the roadmap. One beautiful thing, standing in for the two hardest conversations there are: the one with your customers, and the one with reality. The organisation mistakes finding something that could work for something that works.

It’s always been hard to understand whether or not to build something, harder still to build it, and harder again to validate the hypothesis that drove you to build it. The demo looks done, the room exhales, and the work that was always hard goes quietly on being hard, somewhere downstream, on someone else’s roadmap.

She built it in two afternoons. It works. It is not yet a real boy.

Gender equity isn’t a women’s issue. It’s everyone’s issue. As Hillary Clinton once put it: “Women’s rights are human rights.” The fairer the world gets for women, the better it gets for men, for kids, for anyone who’s ever felt boxed in by what they’re “supposed” to be. That’s the idea International Women’s Day was built on, and it’s the idea we think deserves a proper home.

That home is, ultimately, UN Women. But over the last decade or so, the day’s work has too often been reduced by other agents to platitudes, purple cupcakes, and bland hashtags. The real work of change has stalled, if it was ever truly moving at the pace it needed to.

So a few of us built IWDforALL.org to redress the balance, and drive meaningful change at pace. We went live today.

It’s a free, open home for the stories, evidence, and arguments that make the case for equality; not just for women, but for everyone who benefits when the people around them, and they themselves, are treated fairly. Told straight. Told free. Told by the people actually doing the work, in classrooms and factories and courtrooms and kitchens across the globe.

Six of us built it: Clare Willetts, Michelle Minnikin, Sam Plant, Emma Thomas, and Andrew Keogh, alongside me. None of us were paid to. All of us were tired of watching something that should unite people get quietly fenced off and devalued.

• Doing The Work: an interview series with women and men actually moving the needle, not just talking about it. We’re launching with Georgina Worrall, Head of POWERful Women. Four more equally impactful conversations with impressive individuals will be published over the coming days, too.

• An evidence archive: real accounts of the gap between what’s said about equality and what’s lived, gathered the way the Everyday Sexism Project once did it: openly, without a gatekeeper.

• The full origin story: what International Women’s Day actually is, where its “home” sits today, what’s happened to it, and why it matters regardless of your gender.

• A directory of people doing the work: if you’re a female founder, a business owner, or an ally driving gender equity, you can register with us to gain visibility with companies looking to do the work and improve their DEI, which, let’s be honest, strengthens the P&L too. Everyone wins.

It’s free. It always will be. If you want to back the running costs, there’s a Ko-fi. No pressure, no strings.

Suffragette energy. Minus the suffering. That’s the whole idea.

Read it, share it, and if you’ve got a story that belongs in the archive, we want to hear it and put it in front of others.

👉 iwdforall.org 👉 iwdforall@gmail.com

Please share and socialise with your networks. We want to grow together, to make positive change for everyone, regardless of gender, sooner.

Share

These investments are pressure-tested as the company’s being asked to make a bet that they will return more value than they cost. The review is not bureaucracy. It’s a sensible ritual when done well. Plenty of organisations do this badly. Renewals roll over on autopilot, and nobody checks whether the saving ever arrived.

That ordinary, everyday slackness is nothing next to what we are seeing now.

Carl Sagan popularised the phrase that extraordinary claims require extraordinary evidence. Generative AI has proved the opposite. The claims made for it by its vendors were so large that no evidence was deemed necessary.

When the promise is that a technology will out-think us, write our software, and stand in for whole functions, the usual tests stop applying. Nobody runs a ten per cent rate-of-return calculation against a singularity. As the conversation about AI strategy moved out of the back corridors of engineering and into the boardroom, so the pressure to invest heavily in AI came.

This is not a failure of knowledge. Nobody in the room has forgotten how to write a business case. They have decided that this is not the moment to insist on one.

Fear of being left behind features frequently in the rhetoric around why companies invest. When every competitor is announcing that they are now an AI company, it takes a brave chief executive to tell her board she is not convinced. The cost of being wrong about a revolution feels existential; the cost of overspending on a revelation is a line in next year’s accounts. The benefit is assumed, the evidence is a formality we’d attend to later, and the only real question on the table is how much.

In 1841, Charles Mackay catalogued what happens when a claim gets big enough. Extraordinary Popular Delusions and the Madness of Crowds tracks schemes that swept up careful people who could each give you a careful reason for joining. Through tulip mania and the South Sea bubble, the shape is always the same. The claim is large enough that standing aside looks like an irrational act, and the cost of being the lone sceptic who turns out to be wrong is unbearable.

But signs are emerging that the crowd is getting restive.

As subsidised subscriptions are replaced with token-based cost models, cost discipline is back on the agenda. While productivity gains are being documented, the transformative impacts of AI on the economy haven’t arrived yet and the economics fuelling the AI vendors have come under scrutiny. The valuations have floated free of the revenues meant to justify them. Ed Zitron, who has built a following warning that the arithmetic doesn’t add up, sets combined AI revenue in the tens of billions against capital expenditure in the hundreds. Man Group reports that ”AI technology is transformative and here to stay. But the inflated financial architecture supporting it may be unsustainable.” Mainstream news sites carry articles anticipating the end of the AI bubble.

Deloitte has found that ROI on generative AI investments takes longer than traditional technology investments in part because AI rarely delivers value in isolation. It is typically introduced alongside efforts to improve data quality, reconfigure teams or streamline operations. This opens the question of how much return is the result of AI, and how much in updating historically inefficient practices. Separately, an MIT study found that 95% of generative AI projects fail because organisations aren’t doing enough to modernise their processes to support the investment.

The thing is, the usefulness of generative AI does not depend on the survival of the companies selling it. Open models lag only slightly behind closed models, having all but closed the gap in 2024. These models run on a company’s own hardware, against its own data, rather than being metered by the token. If the labs that burned the capital go under, the majority of the capability survives them.

The tension of rising costs and limited successful applications means that AI investments are now being subjected to the same tests we apply to everything else. Deloitte has seen organisations prioritising ROI and focusing their investments on high-confidence initiatives.

If the vendor valuation bursts, the technology will still be available. The companies that thrive will be the ones with something to show for the spend, the ones still asking what problem this solves, for whom, and how we will know it worked, while everyone around them buys on faith.

Extraordinary claims, once they get extraordinary enough, stop being asked for any evidence at all. That is precisely the moment to keep asking.

Peter Drucker never said that culture eats strategy for breakfast.

The line turns up on slides, on office walls, on websites, as often as not credited to the man himself. It seems to have been popularised at Ford by Mark Fields around 2006, and from there it travelled, picking up Drucker’s name along the way because a good line tends to find a famous author.

I’ve come to believe the line is true at a certain elevation, but that there’s a more useful truism sitting beneath it: the employee experience eats the customer experience for breakfast. Keep going down and you reach the thing that does the actual cooking, quieter and far less quotable than either; the way the work itself is organised.

Where the cutlery goes

Walk into most organisations of any size and you’ll find the customer experience has been built with real care. There are journey maps on the wall. Response times are recorded and watched. Someone reports on customer NPS every month, and people’s bonuses move up and down accordingly.

There are voice-of-the-customer programmes, advisory boards, a CX team with a remit and a budget, perhaps a Chief Customer Officer. The vocabulary is rich and the instrumentation is good. Every touchpoint has been tailored.

The customer pays the bills. Customer numbers are how companies live and die, and if you can’t see revenue, churn and sentiment, and can’t move when they move, you’re in a world of hurt.

The trouble is that almost all of it is set at the table. The meal arrives there. It was cooked somewhere else.

One step removed

A customer experience is not generated at the point of contact. It’s delivered there. It was started earlier, by people working under conditions the customer will never see but will nonetheless taste.

Consider a support agent who can see exactly what a frustrated customer needs and cannot give it to her without a change that can only go on an engineering backlog following a battle with product. The customer doesn’t experience the backlog or the battle. She experiences a slow, hedged reply from someone who clearly understood the problem and then went quiet. The friction the agent lives with all day is invisible to the customer, but the customer feels every inch of it.

Or take a product manager handed a roadmap she didn’t shape and doesn’t believe in, to be delivered to a deadline set in a meeting she wasn’t in. She ships what she’s told to ship, and is rewarded for it. The customer never sees the PM, never gets to influence the roadmap. He gets a product that doesn’t quite fit the way he works, a thing built to be announced rather than used.

Neither of these is a touchpoint problem. Neither, quite, is a culture problem. They are problems with how the work is arranged: who can act, who has to ask, who owns the roadmap, where the power sits. The importance of the operating model being aligned has a lineage back to the service-profit chain, written up in the Harvard Business Review over thirty years ago: internal service quality shapes employee satisfaction, which shapes loyalty and productivity, which shapes the value customers receive, which shapes their loyalty, which shapes the revenue. A chain, with the customer near the end of it and the conditions of the work near the start. In most organisations the investment is all at the end, polishing the last link while the early ones rust.

What culture is made of

Which brings us to the word everyone reaches for. When the customer experience is poor and the touchpoints are already polished, someone says the problem is culture. They’re not wrong. But culture is not a thing you can write up on a slide deck and share. It’s the result of a thousand decisions about how work is organised: who gets to act, who has to ask, what gets rewarded, whose name is on the roadmap. Change those and the culture changes, whether you meant it to or not. Leave them, and no values poster, no offsite, no engagement survey will shift it.

Culture brings the meal to the table. The customer experience is where it’s served.

Set both places at the table

So the employee experience matters, and it rarely gets the attention the customer’s does. Often it’s handed to HR and turned into a perks programme; better snacks, a wellbeing app, an engagement survey nobody acts on. That isn’t the employee experience. That’s the décor around it.

The employee experience that actually feeds the customer is the operating model. It’s whether the work makes sense. Whether a person can act on what she sees without filing a request and waiting a fortnight. Whether decisions sit with the people closest to the problem. Whether the roadmap belongs to someone who believes in it and has the autonomy to change it. These are operating-model questions, not morale questions, and they are the ones that settle into a culture and surface, in the end, as a customer experience.

I ran operations for a fast-scaling business through a long stretch of growth, and I learned this the slow way, by getting it right and not understanding why until later. I cared about the customer, but caring was the easy part; everyone says they care about the customer. What made it real was that I designed the work to match. The touchpoints were documented, and so were the processes feeding them. People could act on what they saw. Decisions sat close to the problem. The operating model let the teams be good at what they did, and they became fiercely proud of it. The customers felt the difference in every interaction. I used to think I’d built a culture, but I realise now that I built an operating model, and the culture was what grew in it.

Get the work right and the customer experience follows, not because culture is magic but because the customer experience is a downstream reading of how the work is done. Fixing it at the customer’s end, with a new CRM or a better script or a tone-of-voice guide, is treating a symptom where it surfaces. Satisfying, visible, and not addressing the underlying condition.

Another contested attribution: John Lennon wasn’t the first to say “Life is what happens to you while you’re busy making other plans.” Your customer experience is what happens while you’re busy deciding how the work gets done.

A government client in the United States came to their company wanting a new communication platform to connect a state with its constituents. The client’s goal was to reduce the millions it spent on postage every year by enabling services electronically. They arrived with a long list of the things they wanted built, by a date, and an assumption that the list would deliver the saving.

So far, so typical.

Then, Gothelf and Seiden did something most suppliers never would. They proposed being measured on the saving rather than the list. They wanted to run experiments to test the assumptions, then build toward the outcome the client actually wanted. They wanted to be measured on the reduction in postage costs rather than by what got delivered.

This doesn’t usually happen.

The thing we actually reward

Why doesn’t this happen more often? How is it that organisations don’t look for the outcomes their customer wants?

Often, it’s because, like in this situation, the customer turned up with a list of features, assumptions and a timeline. Work often comes in like this, and not only in government contracts. It is the default almost everywhere, and it runs in both directions.

Inside a typical product organisation, throughput is a key measure of success. Emphasis is placed on delivery. Customer value is harder to measure, and, thus, often isn’t. John Cutler found that in many organisations, where stakeholders prescribe work, “they are trying to make things easier for YOU — easier for YOU to staff your teams, plan your workload, and make reasonable commitments.”

In consultancies, the incentive is billable hours. A customer turns up with a budget and a list of requirements, the conversation instantly moves to “how much” rather than “how do we know if we’ve achieved your desired outcome?”

The customer wants the certainty of price and deliverables; the consultancy wants to bill based on time and materials. Utilisation, the share of a consultant’s time that is billable, is the number every firm watches. It rewards keeping people on the clock regardless of whether the clock is pointed at anything that matters. The engagement closes when the work is delivered, not when the client succeeds.

Gothelf and Seiden’s client declined their offer. Budget approval sat with the state’s attorney general, an elected position, and it was an election year. They didn’t want to focus on outcomes. They wanted a fixed set of deliverables they could point the electorate to. So the supplier who offered to tie its fee to the customer’s success was sent away, and the work presumably went to whoever would promise the list.

The caution looks like guarding public money, but buying a list of deliverables commits the taxpayer to paying for whatever gets built, regardless of whether the postage bill ever falls. So why does this approach win out?

Both hands reach for the deliverable

The attorney general reaches for a list because a list is something that can be defended in an electoral race. The internal sponsor defining a roadmap is doing the same thing. Both reach for the deliverable because the deliverable is the thing you can point to when someone asks what you got for the money. Output is legible. It survives an audit. The customer’s outcome can be slow and contested. How do you draw a straight line between output and an outcome? Given the pressure of budgets and performance reviews, it makes sense to reach for the legible number.

Why the safe thing wins

If we accept Marty Cagan’s warning that at least half of our ideas won’t work will fail, then output becomes the thing you can reliably show. The incentives for stakeholders and customers to measure output instead of outcomes are clear.

Output is safe and outcomes are not.

Owning an outcome means agreeing, in advance, to be measured on something you do not fully control, and then carrying the loss if the world doesn’t cooperate. When I ran a small company, I set the prices and I owned whether the work paid: survival is the base measure of success for a startup. Paying the bills and keeping the lights on is existential. People’s appetite for this kind of risk is small.

Shared success

A shared success model ensures that everyone is aligned around the goals of the customer, with some aspect of the engagement allowing for discovery and experimentation. The supplier wins when the customer wins. The fee, the engagement, the team’s rewards, are all tied to the result the customer is pursuing. Experimentation and learning enable you to work out the path. The idea is to move away from guaranteed deliverables, to discover what works.

It is rare to see this model implemented, and this is because of incentives. When output is the goal, then a flawless execution of that output is rewarded, regardless of customer value. This is safe for stakeholders and suppliers. Shared success forces both sides to define the outcome and to share the risk of missing it. That is harder than it sounds. An outcome is never wholly in either party’s gift; a supplier can do everything right and still miss it if the client does not act on the work, and the buyer signs up to a price she cannot fix in advance. The reluctance is rational, not timid.

However, this approach can build partnership across engagements and contracts. The supplier can demonstrate their commitment to the client by aligning some elements of their pricing with achieving outcomes while the buyer accepts that some parts of a project cannot be fully predicted. Trust follows when both parties are willing to take a risk.

It also has real value in ways that may not be initially obvious. When you are on the hook for the customer’s outcome, work that produces no outcome stops being someone else’s problem or billable hours, and starts being your loss. The thing that keeps people busy but is going nowhere now costs you directly, so you end it, not out of virtue but out of self-interest.

On the hook

We worry about the supplier who builds too much and bills for it. We worry far less about how few people, on either side of any deal, are ever paid for the customer actually winning. The product team is paid to ship. The consultancy is paid for its hours. The buyer wants a list she can defend. Everyone is paid for the deliverable, and the customer’s success is left to look after itself.

Gothelf and Seiden offered to be paid only if the customer won. The customer said no. We worry about people taking money for nothing. The stranger thing is that when someone offers the opposite, almost nobody can take it.

A product organisation that once knew exactly what it was doing is now spread across nine things. It had a WIP limit of four, but nobody talks about that now. Growth is king, all of the demands are urgent, and each is sponsored by someone who matters.

So the teams try to do all nine and struggle to finish any of them. From above, where the stakeholders are waiting for their specific thing, it looks like sluggishness. Leadership starts to worry that the product development organisation has become slow.

It hasn’t. It has lost focus, and there’s no recognition that this lack of focus is what causes drag.

Starting out

A startup that survives does so by adapting to one environment. Focus is not a virtue it chooses; it is the condition of survival. Do one thing, for one kind of customer, better than the alternatives, or die. Then the thing works, the company grows, and it looks to reach beyond its niche. Growth demands that it develops new products, new customers, new markets.

But reaching out takes attention off the core, and every new bet is uncertain. The organisation wants both to keep owning its niche completely, and to grow past it. It refuses to give up either, so it never chooses. It commits to everything at once and calls it ambition. The teams get overloaded, and focus suffers. From the outside, this doesn’t look like the result of a choice. It looks like slowness, and the obvious answer to a team slowing down is that they should go faster.

Accelerants

Then AI comes along, promising easy acceleration. Investment in AI goes up, and the organisation expects order of magnitude improvements.

Unfortunately, AI adoption also involves some speed bumps. A study of 22,000 developers across two years has found that output may be rising, but bugs and rework are rising with it, suggesting that total cost of ownership isn’t improving.

That’s before we get to the speeding tickets. Costs are running well ahead of gains. Uber spent its entire 2026 AI coding budget by April. The heaviest users of these tools may be twice as productive, but they’re burning ten times the tokens of their colleagues.

In a matter of months the conversation has turned from going fast to working out how to rein the spending in, or at least to demonstrate ROI.

And still, the organisation tries to do everything, all at once, avoiding the inconvenient truth about product management: at least half of these initiatives are never going to work. AI can speed up finding the few that pay and killing the rest before they are built.

Survival of the focused

AI did not lift the constraint that matters: the limit on what you can commit your attention and money to. It lowered the cost of finding out what to commit to. Discovery, experimentation, a prototype in an afternoon: telling a good bet from a bad one has never been cheaper or faster.

There’s no need to drown, using AI to build everything at once. Use it to choose what to build. The nine things the team is spread across should be bets, not commitments. They can be reinvented as cheap experiments; most of them can be killed before they cost anything.

Pointed at commitments, AI floods you and bills you. Pointed at discovery, it makes choosing easier than it has ever been.

Growth depends on new bets, and you can chase more of them than ever, because trying them is nearly free now. The WIP limit is a cap on committed work, not a cap on curiosity. Don’t confuse experiments with commitments. Help stakeholders to understand that their requests require prototyping and research; not everything has to go to production.

Explore widely. Commit narrowly. The team that looked slow was never slow; it was a focused organisation that had stopped deciding what not to build.

AI offers the illusion of having it all. The reality is the organisations that thrive will be the ones who use it to explore more and commit to less.

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

5 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

8 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

7 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

a year 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....