specshop.dev / Journal / Opinion
Opinion 13 min read

The Question That Stopped Updating

Why your best engineer became the bottleneck — and how to spot the same freeze in yourself.

Janaka Ediriweera
CEO & Co-founder · specshop.dev

I. The legend

In 2006, Naveen was the best engineer in the building, and everybody knew it.

When a release wouldn’t ship, people called Naveen. When the payment service buckled under load on the last day of the quarter, people called Naveen. When a junior couldn’t find the bug after two days, Naveen found it in twenty minutes, and he was kind about it, which made him impossible to resent. He had built half the architecture the company still ran on. He could hold the entire system in his head. He had never shipped a Friday-night fix that didn’t hold, and he said so once, quietly, the way a man states a fact he’s proud of but won’t brag about.

Naveen was excellent. Hold onto that, because the story isn’t about a man who was bad at his job.

It’s about a man who was so good at a job that quietly stopped existing that nobody noticed when it disappeared — least of all him.

§

Of course he got promoted. He was the safest pair of hands in the company, he’d been there longer than almost anyone, and he had never shipped a fix that didn’t hold. So they made him VP of Engineering, and then CTO. Tenure and trust earned him the chair — not evolving capability, because at the time those looked like the same thing.

And here is the trap, stated plainly: the company rewarded him for the exact instinct that was about to become the bottleneck. His whole value was built in an era when the hard part of technology was making fragile things not break. He was a master of execution in a world where execution was scarce and expensive and slow. That world paid him in promotions. It never sent him the memo when it ended.

Now the man whose mental model of technology was forged in the era of don’t let it break sits in the chair where the company decides its technological future. Someone proposes a new customer platform and he evaluates it the only way he knows how: Is it secure? Will it scale? Who gets paged when it goes down? These are not wrong questions. They are the questions of a previous era, asked with great seriousness about a decision they were never designed to answer.

The business needs someone who looks at technology and sees growth. It has, instead, someone who looks at technology and sees risk to be contained. So the guardian, with no malice and no laziness, becomes the gate. Every genuinely transformative idea now has to pass through a person whose trained reflex is to keep things from changing — because for fifteen years, keeping things from changing was the job.

He is not stupid. He is unupdated — running excellent 2006 judgment against a 2026 problem. And the cruelest detail is that he can’t see it, because the faculty he’d need to notice the gap is the same faculty that stopped developing the day he stopped asking what the new world needed.

The question is: needed for what? To answer that, you have to look at the actual ground he was standing on while it moved.

§

III. The first map: where his thinking stopped

Gartner’s Digital Business Maturity Model describes the terrain most engineering organisations crossed over the last two decades. It runs through five stages: Initiating, Experimenting, Scaling, Transforming, and Digital Leadership. It’s worth saying what each one actually means, because the stages are not difficulty levels — they are changes in what technology is for.

Initiating is the first websites and internal tools — technology bolted onto a business that still runs on paper and meetings. Experimenting is isolated digital projects, often heroic, rarely connected. Scaling is the one most engineering leaders are quietly proud of: systems integrated, processes automated, things that used to break now reliably don’t. This is where uptime becomes a number you can promise. This is where the guardian is at his absolute best.

And this is exactly where Naveen stopped.

Because the next stage, Transforming, asks a different question entirely. Scaling asks how do we run technology well? Transforming asks how does technology create value the business couldn’t create before? — new products, new revenue, new business models that didn’t exist until the software made them possible. It’s the stage where technology stops being the thing that supports the business and becomes the thing that is the business.

And Gartner’s own data tells you how few organisations make that leap.

48%
Only 48% of digital initiatives meet or exceed their business outcome targets — according to Gartner’s 2025 survey of 3,186 CIOs and technology executives across 88 countries. The high performers, what Gartner calls the “Digital Vanguard,” hit 71%. Their distinguishing trait is not better tooling or bigger budgets. It is that they co-own digital delivery with the business, rather than treating technology as an IT function the business “sponsors.” (Gartner, 2025 CIO & Technology Executive Survey)

Read that finding again, because it’s the leap stated in survey form. The companies that move from Scaling to Transforming aren’t the ones with the best engineers. They’re the ones where technology stopped being a department someone “sponsors” and started being the thing the company is.

Naveen never made it. He got the company to Scaling — connected, automated, reliable — and then he guarded that achievement the way he’d once guarded a release. From inside the chair it didn’t feel like stopping. It felt like maintaining excellence. The system was up. Nothing broke. By every metric he’d been trained to value, he was winning.

He froze at Scaling. And then a second map appeared — and he froze at the very same coordinate, one map over.

§

IV. The second map: the freeze, reproduced

The AI maturity space is a mess of competing models, and I’m not going to pretend otherwise by handing you a vendor’s ladder and calling it settled. So here’s my own lens, and I’ll own it as mine. I think enterprise AI adoption only has three stages that matter, and the labels for the in-between rungs are mostly noise:

Assistive — AI helps a human do the existing task faster. Copilot finishes your function. ChatGPT drafts your email. The work is unchanged; the human is quicker.

Autonomous — AI does the task, under human review. It writes the code, runs the analysis, drafts the spec — and a person confirms before anything moves. The work itself is now being done by the machine; the human has moved to judgment and direction.

Agentic — AI orchestrates whole processes end to end. Not a faster typist, but a system that takes an outcome and produces all the work required to reach it — the build, the docs, the tests, the rollout — with humans setting direction and holding the gate.

The distance between Assistive and Agentic is not a distance in tooling. It’s the same leap as Scaling to Transforming: a leap in what you believe the technology is for. Assistive AI makes the old work faster. Agentic AI changes what work is possible.

Now watch what the frozen guardian does with it. He opens Copilot. He types a prompt into ChatGPT. He gets an answer back, and he tells the board — tells the all-hands, tells LinkedIn — that the company is “doing AI now.”

This is the moment the whole pattern snaps into focus. Because it is precisely the same move he made at Scaling. He has taken the most transformative technology of his career and shrunk it to the size of a faster keyboard. He’s using the new map’s tools to do the old map’s job. He has not advanced to a new stage — he has reproduced his freeze at the identical coordinate, one map over. He stalled at “run technology well” on the first map, and he’s stalling at “do the existing work faster” on the second. Same posture. New clothes.

And the data on this is brutal.

95%
MIT’s NANDA initiative found that roughly 95% of enterprise GenAI pilots delivered no measurable P&L impact. Only ~5% achieved rapid revenue acceleration. The cause MIT identified was not model quality. It was a “learning gap”: generic tools like ChatGPT “excel for individuals because of their flexibility, but stall in enterprise use since they don’t learn from or adapt to workflows.” That is the assistive trap stated in a footnote — the tech helps an individual go faster while the business transforms nothing. (MIT NANDA — The GenAI Divide: State of AI in Business 2025)

This is why “we do AI now” is not evidence that he’s keeping up. It’s the tell that he isn’t. The freeze has a signature, and the signature shows up identically on both maps:

Use the new thing to make the old thing faster; never to imagine the new thing.

§

V. What actually moved underneath him

Here’s the part that should keep an engineering CTO awake, because it reframes the whole career.

For most of Naveen’s life, the binding constraint in software was execution. Building was slow, expensive, and risky. The scarce resource was people who could make complex systems work and keep them working. That scarcity is precisely what made his vigilance valuable — guarding fragile, hard-won execution was the highest-leverage thing a technical leader could do.

That constraint has collapsed. And the collapse is measurable.

7 mo
METR found that the length of software tasks frontier AI agents can complete autonomously is doubling roughly every seven months — and has been for six years. As of March 2025 the frontier 50% time-horizon was around 50 minutes; their January 2026 update suggests the doubling may have accelerated to ~4 months. (Read it as a trend, not a law — the curve has a serious published critique around log-bucketing and the long-task tail. But the direction is not in dispute.) (METR — Measuring AI Ability to Complete Long Tasks)

That’s the external read. The firsthand read is sharper. At specshop.dev, the studio I co-founded in late 2025, builds that took 4–6 months a year ago now ship to production in 2–3 weeks. The GTM admin panel for our own ops? One day. Not because we’re faster typists. Because the spec is doing the work the people used to do, and the agents are doing the work the spec used to ask people to do.

When an agentic workflow produces a working build in days that used to take a quarter, execution stops being the bottleneck. And when execution is no longer scarce, the thing that is scarce becomes the only thing that matters: imagination. Clarity about what’s worth building. The judgment to point capability at the right outcome. The ability to look at a technology and see what the business and the customer actually need from it.

Naveen’s entire identity was built around execution scarcity. So when the scarcity evaporated, it didn’t just make his skills less relevant. It quietly relocated the whole job to the one muscle he never had to develop, because for twenty years the work in front of him never required it.

He’s not behind on a tool. He’s standing at the wrong end of a constraint that moved while he was guarding the old one.

§

VI. What evolving actually means

So what should Naveen have done?

Here’s the trap, because it’s seductive: he should have learned the new tools. Learn the cloud, learn the new architectures, get certified in AI. But that’s the same mistake in a better outfit. Chasing tools is just guarding a faster-moving cupboard — you stay perpetually one release behind, and you’re still measuring the wrong thing. A CTO who “knows all the AI tools” and still uses them to make the old work faster has learned nothing. He’s just frozen in a more current vocabulary.

The thing that needed to keep evolving was never the toolkit. It was a single question, asked relentlessly and never assumed to be answered:

What does the business and the customer actually need right now — and what can technology do about it?

That question is permanent. The tools that answer it change every eighteen months. The guardian who stays valuable is not the one with the most current skills; it’s the one who never stopped asking that question and never let last year’s answer calcify into this year’s strategy.

Master the question and you can pick up any tool. Master only the tools, and you are one collapsed constraint away from becoming the gate.

That reframe is the entire job. Not keep things from breaking, but find where technology can create something the business and its customers need. It’s the difference between a Head of Engineering who guards uptime and a CTO who architects advantage. It’s the difference between a company that runs technology and a company that is a technology business — which, increasingly, is the only kind that wins.

§

VII. The mirror

I’d be doing you a disservice if I let you close this thinking it’s a story about Naveen.

Because the freeze never announces itself. Nobody decides to stop evolving. It happens the way it happened to Naveen — gradually, invisibly, while you are being rewarded for the very thing that is about to become the bottleneck. The competence that makes you valuable today is the thing most likely to convince you that you don’t need to update. That’s not a flaw in weak leaders. It’s a trap that specifically catches the strong ones, because they have the most evidence that their current map works.

So the real question this leaves isn’t how do we handle the people who stopped evolving. It’s quieter, and it’s pointed at you:

Which map am I still navigating by — on terrain I’m certain I’ve already mastered?

You’ve crossed to Scaling and you’re proud of it. Fine. Have you crossed to Transforming, or are you guarding the achievement? You’ve “started AI.” Fine. Are you using it to do the old work faster, or to imagine work that wasn’t possible before? One of those is progress. The other is the freeze, wearing this year’s clothes.

Naveen never asked himself any of that. He was too busy keeping things running, and he was excellent at it — right up until the day the constraint moved and keeping things running stopped being the point.

The system is still up. He’s still guarding it.

The only thing that changed is what guarding it costs.