We keep building things nobody can name

I’ve built the kind of thing that doesn’t fit on a slide more than once. A small team, a short timeline, a capability that works, and is new enough that almost no one around it can say what it actually does with much confidence. It tends to happen whenever you build at the genuine edge of what an organisation has done before.

What follows is almost always the same, which is why it’s worth writing down rather than grumbling about. The building fills with AI fanfare, agents, chatbots, prompt libraries, the announcements and town halls to match. Plenty of energy, plenty of enthusiasm for the new technology, and the one genuinely new thing, the thing that doesn’t resemble anything already on a roadmap, is the thing nobody quite talks about. Too unfamiliar to fit on a slide, so it gets handled less like a capability than like something to keep quiet until someone works out what to do with it.

What they work out, sooner or later, is to move it somewhere legible. Into a delivery squad. Under tooling, or automation. Onto a cadence built to ship predictable work on a schedule, which would be the right call, if it were predictable work. It usually isn’t.

If you’ve been anywhere near disruptive work inside a large organisation, you’ve watched some version of this, and that it repeats is the whole point. It isn’t one company’s mistake; it’s a pattern in how organisations meet the genuinely new, and patterns can be named and once named, shifted.

Our obsession with frameworks  

We love to obsess over structures. It isn’t only Agile. Design Thinking, Lean, OKRs, SAFe, we reach for frameworks the way nervous people reach for a handrail, and then we forget they were ever optional. A method that started as one good answer to one specific problem slowly hardens into the way things are simply done. Agile is just the clearest example, because it’s the one we’ve canonised hardest. It was built to solve a real problem in enterprise software delivery.

However, it’s worth remembering the room it came from. Seventeen people, nearly all of them white, middle-aged, Western men, writing for enterprise software delivery as they knew it in 2001. That doesn’t make their thinking wrong. It makes it situated, and a situated snapshot is a strange thing to treat as universal law, decades later, across contexts those authors never had in front of them.

Genuinely new work, especially in AI, especially now, doesn’t behave like that. The roadmap is often unclear. The most valuable outcome is sometimes learning what not to build. Progress can look like disproving an assumption before it turns into an expensive mistake.

Why we freeze too early

Most organisations, understandably, still try to run this uncertainty-heavy work on delivery models built for far more predictable conditions. We freeze the process too early simply because the urge to impose structure on ambiguity is deeply human.

We are pattern-making creatures. The genuinely new, the undefined, the unrestrained, anything that lives in that unformed, in-between space, makes us uncomfortable, and the instinct is to resolve the discomfort quickly. Give it a squad, a schedule, a label, a place on the board, so it stops feeling like a risk. 

The harder discipline is holding it open

Reaching for a familiar cadence when the work gets hard to read is the most natural move there is. The harder discipline, the one this era actually asks of leaders, is the opposite. It asks you to hold the question open a little longer than is comfortable, and to protect the unformed work from the machinery that would tidy it away before it has taken shape.

That isn’t patience for its own sake. It’s a judgment about where value comes from. Call it conscious leadership if you want the term, but only if it means something concrete. It is the capacity to stay clear-eyed and unreactive while everyone around you wants the ambiguity resolved, and the judgment to keep a decision in suspension while the evidence is still arriving. The quality of a leader’s attention in that exact moment, when the new thing is illegible and every instinct says make it legible, is what decides whether it survives.

The most valuable work can look like nothing

The problem was never the technology. It’s treating genuinely new, exploratory work as though it were enterprise software delivery, when it never behaved like delivery in the first place.

The most valuable output of an exploratory week is often the discovery that an assumption you were about to build on was wrong. On a board, that looks like a sprint with nothing shipped. In practice it’s the most expensive mistake you didn’t make, and there’s nowhere to record it as anything but a blank.

That gap, between what the work actually is and the model we keep trying to measure it with, isn’t really an AI problem. It’s an operating-model problem that AI has simply made too obvious to keep ignoring.

Different work wants different rules

The fix was never a better single method. It’s giving up the idea that one method should cover everything and that turns out to be the hardest move for a large organisation to make, because one method is far easier to govern than three.

Most large organisations are already running at least three kinds of work at once, and only resourcing one of them honestly.

• There’s delivery work with mature systems, known requirements, predictable execution. Agile is genuinely good here, clear milestones, incremental shipping, low drama, and frankly a pleasure to manage.
• There’s discovery work, where the outcome is real but unknown with smaller teams, faster loops, success measured by how many assumptions you tested rather than how many features you shipped.
• Then there’s the genuinely new, the emergent work that doesn’t have a shape yet, which needs protected time, a small trusted group, and room to think before being marched onto a roadmap.

The failure is rarely choosing the wrong mode. It’s pretending the whole organisation is doing the first kind while a growing share of its most valuable work is quietly the second and third and then measuring all of it as though it were the first.

Why the new needs a room of its own

This is the part most transformation conversations skip. New work doesn’t just benefit from protection; it tends to die without it, because the metrics that run the rest of the business are the most hostile to it.

Clayton Christensen gave an name to this pattern decades ago and well-run companies fail at breakthrough work not despite good management but because of it. They allocate rationally, toward today’s customers and today’s numbers, and the genuinely new always looks worse on those numbers at the start. So the organisation, sensible at every step, starves the thing that might have saved it. It rarely feels like a decision. It feels like prioritising.

Nokia is the case that still breaks my heart. They made genuinely good phones, we all had one. They ran a genuinely good company, and did very little that was wrong by the standards they were being measured against, and they lost the market anyway, almost without a single identifiable mistake. That’s the unnerving part of this pattern, it doesn’t require anyone to fail. It punishes companies for succeeding at the wrong thing slightly too long.

Which is why “give it space” can’t just mean time and goodwill. It means its own measure of success, judged by someone who isn’t also on the hook for this quarter’s delivery. Without that, the delivery machine absorbs the new work, grades it against the wrong scorecard, and quietly grades it to death. The tell is when something built to explore gets filed under “tools”, because a tool is something you’re expected to ship, not something you’re allowed to still be figuring out.

It’s also why bolting an “innovation sprint” onto a delivery team so seldom produces anything new. Same people, same cadence, same scorecard. The label changed but the structure didn’t.

None of this is a licence to skip rigour. “We’re still exploring” is a real answer and a comfortable place to hide, and I’ve watched it used as both. Exploration has its own discipline, a clear question, honest evidence, short cycles, a real decision at the end of each. It simply measures something different, how fast you can be wrong cheaply, rather than how reliably you can be right on time. The discipline doesn’t vanish when you leave delivery. It moves.

An operating model decides what counts

Underneath all of this is something simpler than process. An operating model tells people what counts, and people are very good at reading what counts.

When the only thing that counts is delivery, a team slowly stops telling you what it’s learning, because learning has nowhere to be logged and naming uncertainty starts to feel like confessing failure. That isn’t a gap you can close in a retro. It’s a culture being taught, two weeks at a time, to perform a certainty it doesn’t have.

Startups worked this out a long time ago. The whole point of Lean Startup was to treat validated learning as the real output, in the early days you aren’t building a product so much as buying knowledge about what will and won’t work, as cheaply as possible. A disproved assumption isn’t a wasted sprint; it’s the deliverable. The work is almost identical to what an enterprise team does in a genuine discovery phase, the only thing that differs is whether the operating model treats that learning as something gained or something missing.

This is where the leadership part stops being abstract. A leader doesn’t just choose a methodology; they choose what the organisation is allowed to notice. Holding space for the unformed isn’t softness, it’s deciding, against every instinct in the room, that “we don’t know yet” can be a legitimate thing to report. The quality of that judgment, made in the exact moment the new thing is still illegible, is most of what determines whether it ever becomes legible at all.

We can shorten this for each other

Here is the part I most want to say to anyone who recognises themselves in this. If you’re the person trying to protect something new inside a system built to run the old thing well, you are not failing, and you are not alone. A lot of us are running the same experiment in parallel, in different companies, mostly without comparing notes.

That’s the waste that’s easiest to fix, the isolation around it. When someone works out how to win a separate scorecard for exploratory work, or how to keep a new capability out of a delivery squad long enough to find its feet, or how to make “we invalidated five assumptions” land as a result rather than a blank, that’s hard-won knowledge most of us are currently learning alone, one painful quarter at a time.

So name the pattern when you see it. Say it plainly to the people who can move it, and say it to each other. Trade what actually worked, not the sanitised version for the case study. The shift doesn’t need a new framework or another manifesto. It needs enough of us describing the same thing clearly, at the same time, that protecting the genuinely new stops looking like eccentricity and starts looking like basic competence in an AI era. That’s not a movement. It’s just people who have been in the room telling the truth about what they saw, until the truth is common.

What to upgrade next

Twenty-five years is long enough to honour what Agile did, to say thank you, and still ask the obvious question.

Part of what makes this kind of work hard to plan is that you often don’t know, week to week, what the thing has even become. A capability that didn’t exist on Monday changes what’s worth building by Friday. The model improves, the data shifts, someone finds the tool being used for something nobody designed it for and the plan you defended in the steering committee is uncomfortably out of date. To a system tracking predictable progress, that looks like falling behind but it isn’t. The schedule was guessing.

Then there’s a cost that shows up on no board at all, the people. While leadership debates sprint velocity, teams are quietly absorbing real uncertainty about what AI means for their own roles, and the operating model has no row for that either, so it goes the way the invalidated assumption went, recorded as a blank. We’ve become precise about what the technology ships and stayed vague about what it’s doing to the people asked to live alongside it.

Plenty of good ideas end up in the quiet graveyard every organisation keeps and rarely admits to simply because they were measured by the wrong clock. So the question worth sitting with, before the next planning cycle, is a simple one. Of the work your best people are doing right now, how much is delivery and how much is discovery and which of those is your operating model actually built to see?