“They want to cut us to one engineer per product team,” he says. “One. The CEO read something on LinkedIn about AI agents and now he’s convinced we can ship the same roadmap with a third of the team.”

I ask him what he said in the meeting.

“I told him the math doesn’t work. I walked him through the velocity numbers, the on-call rotation, the knowledge concentration risk.” He finally takes a sip, grimaces. The coffee is cold. “He nodded. Then he asked me to put together a transition plan by end of quarter.”

This CTO is brilliant. He has fifteen years of scar tissue, a calm demeanor, and a genuine love for his team. And he is about to lose this fight. Not because he’s wrong. He’s right. He’s going to lose because he showed up to a strategy conversation with a defense brief.

I’ve had four conversations like this in the last three weeks. Different cities, different stages, different product categories. Same shape. The CTO knows something is coming at them, the conversation has already started, and they don’t have a stance ready. They have facts. They have logic. They have decades of experience. What they don’t have is a position they can hold under pressure when the room turns.

So let’s fix that.

The conversations already on your calendar

Here’s something true about the storms heading toward technology leaders right now: they don’t announce themselves. They show up disguised as casual questions in 1:1s, throwaway comments in board meetings, Slack messages from a CFO who “just had a quick thought.”

By the time the conversation feels like a confrontation, it’s already three weeks deep. The CEO has talked to two board members. The CFO has run the model. The COO has chatted with a peer at another company who “did the same thing and it worked great.”

You walk in thinking you’re having a discussion. They walk in having already made the decision and looking for your buy-in.

You need to know what’s actually being asked, and you need a position before you walk into the room. Let me name the six conversations I’m watching land on CTOs right now, and the stance I’d want you holding in each one.

1. “Why can’t we cut headcount now that we have AI?”

This is the conversation. Every CEO on the planet is having some version of it, even the ones who haven’t said anything to you yet. Revenue per employee is climbing across software companies, boards are pattern-matching hard, and the productivity stories about AI coding tools are everywhere.

The trap is to argue against the cut. You’ll lose. The numbers your CEO is reading are real, the productivity gains in narrow contexts are real, and your defensive posture will read as self-interested protection of your empire.

The stance to hold: AI doesn’t reduce the need for engineers, it changes what engineers are for. Your team used to produce code. Now they produce judgment about code. The bottleneck has moved from typing speed to the ability to evaluate, integrate, take responsibility for, and operate systems built faster than any human can fully review.

If you cut the team, you don’t get the same roadmap with fewer people. You get a codebase that nobody understands at depth, security posture that decays in months because nobody has time to think about it, and a production environment where every incident takes three times longer to resolve because the people who would have built the system never built it.

Don’t say “we can’t cut.” Say “here’s what we’re optimizing for now, and here’s what that team looks like to deliver it.” Bring the new shape, not the defense of the old one. If the answer involves a smaller, more senior team with different skill profiles, say that. If it involves the same headcount with a radically different mix, say that. What you can’t do is fight the premise. The premise has already won.

2. “Can we just have one developer on each product team?”

This is the same conversation in a different costume. It’s the org-design version of the headcount conversation, and it’s seductive because it sounds like alignment. One engineer, one PM, one designer, ship faster, fewer dependencies, clear ownership. It reads beautifully on a slide.

What it actually creates is the bus factor problem at industrial scale. Every product surface depends on a single person who cannot get sick, take vacation, or quit without breaking something. Every architectural decision gets made in isolation. Every cross-cutting concern — auth, observability, data contracts, security review, deployment infrastructure — becomes nobody’s job.

Six months in you have twelve product surfaces, twelve different ways of doing the same thing, twelve people who’ve each painted themselves into a corner, and a platform team that doesn’t exist because you couldn’t justify the headcount when you were “moving fast.”

Your stance: pods of one are not teams, they are single points of failure dressed up in a process diagram. Engineering work is collaborative because the work itself is collaborative. The code one person writes today will be read by four people next quarter and modified by twelve people next year. The decisions one person makes about how to structure data will constrain every team that touches that data for years.

Counter-propose. If they want surface area and ownership, give them small persistent teams of three to five with clear product alignment and shared platform infrastructure underneath. That’s the structure that scales. That’s the structure that survives someone quitting. That’s the structure that lets you actually move fast in year two, not just year one.

3. “The board wants to know our AI strategy”

Translation: someone on the board read an article, talked to a portfolio company CEO, and now you have a homework assignment due Friday.

The wrong move is to produce a deck full of tools you’re “evaluating.” Every CTO is evaluating Cursor, Claude Code, Aider, a handful of MCP servers, and whatever launched on Product Hunt last Tuesday. That’s not strategy, that’s shopping. Boards smell shopping immediately.

The stance: your AI strategy is your engineering strategy. They’re not separate documents anymore. It’s how your team writes code, reviews code, handles incidents, makes architectural decisions, and develops junior engineers in a world where the easy work is done by machines. It includes what you’re building with AI for customers, but the harder and more important half is how AI changes the way your team operates internally — and what that means for hiring, leveling, performance, and risk.

Bring three things to the board.

1. Where AI is creating leverage in your engineering org today, with numbers you trust. Not vendor numbers. Your numbers.

2. Where you’re investing for the next two quarters and what you expect to learn.

3. What you’re explicitly not doing and why. The “not doing” list is what separates strategy from a wish list. Boards have seen enough wish lists. They want to see judgment.

If you can’t fill in that third bucket, you don’t have a strategy yet. You have a backlog.

4. “We need to move faster”

You will hear this every quarter for the rest of your career. It’s the background radiation of being a CTO. But right now it has a new edge to it, because everyone in the building believes AI should have already made you faster. The question is no longer “can we go faster” — it’s “why aren’t we faster yet.”

The bad response is to promise more velocity. The worse response is to explain why velocity is hard. Both lose you credibility.

Your stance: speed is a function of what you’re willing to stop doing. The team’s capacity hasn’t suddenly tripled because an LLM can write a function. The team’s capacity to ship features is gated by code review, testing, deployment safety, on-call burden, security review, customer support escalations, and the cognitive load of maintaining everything you’ve already shipped. AI helps with one slice of that pipeline. The rest is unchanged or, in some cases, worse — because faster code generation means more code to review, integrate, and operate.

If you want speed, we make trade-offs. Here are three things we could stop investing in to free up capacity for the new priority. Here’s what we’d accept in terms of risk or quality. Here’s what would break.

Make the trade-off visible. Make the CEO choose. The conversation shifts from “the CTO is slow” to “the executive team made a prioritization decision together.” That’s where it should have been all along. That’s also where you stop being the person who says no and start being the person who frames the choice.

5. “Are we sure all this AI-generated code is safe?”

This one usually comes from the CFO or General Counsel, and it usually arrives about a quarter after your team has gone all-in on AI coding tools. Sometimes it arrives the morning after a security incident at a peer company makes the news.

The honest answer is: probably not entirely, and neither is anyone else’s. Recent research on AI-generated code has found meaningful rates of vulnerable patterns, license contamination, and subtle logic errors that pass code review because they look right. The code is plausible. Plausible is the enemy of secure.

The stance: AI-generated code needs the same scrutiny as code from a brand new engineer on day one — which means it needs more scrutiny, not less, even though it arrives faster. Our review practices, our test coverage requirements, our security scanning, our dependency analysis — none of that gets relaxed because the author is a model. If anything, it gets tightened, because the volume of code is going up.

Then bring the actual plan. What scanning tools you’re running. What review standards you’ve updated. What you’re tracking. What you’re going to know in 90 days that you don’t know today. The CFO doesn’t need you to promise zero risk. They need to see that someone is actually thinking about this with rigor, not just enthusiasm.

If you don’t have that plan, build it this month. This conversation is coming whether you’re ready or not, and “we trust our engineers” is not an answer that survives a board-level question about AI risk.

6. “I don’t think anyone is listening to me”

This isn’t a conversation with the C-suite. This is the conversation you’re having with yourself at 11pm on a Tuesday, and it’s the most dangerous one on this list.

I wrote a while back about how being technically correct isn’t enough. That hasn’t changed. What’s changed is the stakes. When the rest of the C-suite is making decisions about AI, headcount, and organizational structure based on incomplete mental models, your inability to make them feel what you see isn’t a communication problem anymore. It’s a survival problem. For you and for the company.

There’s a particular flavor of isolation that hits CTOs right now. Your CEO is reading the same five Substacks as every other CEO. Your CFO is running models built on industry benchmarks that are six months out of date by the time they’re published. Your peers in the C-suite are pattern-matching against what they’re hearing at their own peer dinners. And you, the only person in the room who actually understands what the technology can and can’t do, are increasingly being treated as the resistant one. The cautious one. The one who doesn’t get it.

You start to wonder if you don’t get it.

The stance to hold with yourself: if they’re not hearing you, that’s data about how you’re showing up, not data about their intelligence. The work is to translate. Not dumb it down — translate. Find the version of your concern that lives in their language. Revenue, risk, retention, runway, customer trust, regulatory exposure. Pick the frame they already think in and put your concern inside it.

And get out of the building. Talk to other CTOs. Not to vent — to calibrate. The version of reality you’re living in inside your company is one data point. You need others. You need to know whether your CEO’s expectations are reasonable, aggressive, or unhinged compared to what’s actually happening at companies of your size and stage. Without that calibration, you’ll either capitulate when you should hold, or hold when you should adapt. Both are fatal.

The CTOs I see weathering this period well all have the same thing in common: they have somewhere to take the hard questions before they have to answer them in front of their CEO. A coach, a peer group, a mentor, a community. Somewhere they can be uncertain out loud and come back with a stance.

If you don’t have that, build it this month. It’s not a luxury anymore.

What to do this week

Pull out your calendar. Find the next executive meeting on it. Before you walk in, write down two things on a notecard.

The first is the strongest argument against your current position. Not a strawman — the real one, the one your smartest skeptic would make. If you can’t articulate it cleanly, you’re not ready to defend your position. You’re ready to be surprised by it.

The second is the trade-off you’re asking the team to make. Not a recommendation, a trade-off. “If we do A, we don’t get B. Here’s why I think A is right anyway.” This forces you out of advocacy mode and into the executive frame, where everything is a choice between imperfect options and the job is to make the choice cleanly.

Then in your next 1:1 with your CEO, ask one question: “What’s the conversation about engineering you’re having that I’m not part of?” Sit with the silence. Let them answer. The answers will tell you which storm is closest, and how much warning you actually have.

You’re not going to stop the storms. They’re coming. Boards are going to ask hard questions about AI. CFOs are going to push on headcount and security. CEOs are going to want more velocity with fewer people. Product is going to want autonomous pods. That’s the job now.

What you can control is whether you walk into those rooms with a stance or with a defense. The CTOs I see thriving right now aren’t the ones with the best technology opinions or the deepest technical chops. They’re the ones who’ve already done the work to know where they stand before the conversation starts. They’ve stress-tested their position with peers. They’ve translated it into the language of the room. They’ve identified the trade-offs they’re willing to make and the ones they aren’t.

Get your stance ready. The meeting is already on your calendar.

Hey my new book CTO Refactor is coming out in May 2026 - head over to ctorefactor.com to get advance copies and some bonus treats. - Etienne

I pull up the codebase. There are three utility functions doing nearly the same date formatting. The error handling pattern doesn’t match anything else in the repo. A new data access layer has been introduced that duplicates logic we already have in our services directory. And Marcus has no idea, because he didn’t write this code. He directed it.

I ask him why the date formatter doesn’t use our existing utility. He scrolls through the file tree. “We have one?” He genuinely doesn’t know. This is an engineer who has been with us for two years.

I close my laptop and walk back to my desk. The dashboard works. It passed review. It will ship. And it will quietly make our system a little harder to understand, a little more fragile, a little less coherent. Not today. Not next week. But the weight is accumulating. I can feel it in the pull requests, in the onboarding conversations, in the growing silence when I ask why something was built this way.

That silence is entropy. And fighting it just became the most important part of my job.

The Universe Wants Your Codebase to Fall Apart

In 1850, Rudolf Clausius articulated what would become the second law of thermodynamics: in any natural process, the total entropy of an isolated system can only increase. Things move from order to disorder unless you put energy into keeping them organized.

Meir Lehman applied this thinking to software in 1974. His second law of software evolution states that the complexity of a software system increases unless work is done to maintain or reduce it. For fifty years, this has been the quiet backdrop to every engineering organization. Codebases rot. Standards drift. Architecture erodes. Entropy wins unless you fight it.

We have always fought it. Code reviews. Refactoring sprints. Architectural standards. Style guides. These are the maintenance rituals that keep disorder at bay. The energy we pour into keeping our systems coherent.

AI just changed the equation. Dramatically.

A recent large-scale study of over 300,000 AI-authored commits across 6,275 GitHub repositories found that AI-introduced technical debt is growing rapidly, climbing from a few hundred surviving issues in early 2025 to over 110,000 by February 2026. About 24% of those issues still persist in current codebases. GitClear’s analysis of over 211 million lines of changed code found copy-pasted code up 48% and refactored code declining 60%. Code churn, the percentage of lines rewritten within two weeks, has doubled in teams heavily using AI tools.

The disorder isn’t slowing down. It’s accelerating. And if you’re a CTO leading 40 to 120 engineers right now, entropy is your fight. Not AI strategy decks. Not model selection. Not prompt engineering workshops. Entropy.

Why AI is the Greatest Complexity Generator We’ve Ever Built

When code was slow and expensive to produce, friction was your friend. Every function a developer wrote required them to understand the system they were modifying. They had to read existing code. They had to navigate the architecture. They had to make choices that fit. The very slowness of writing code was a form of quality control.

AI removed the friction. A junior engineer with Cursor can now produce 500 lines of code that passes lint, follows naming conventions, and looks clean on review. But verifying whether that code fits the system, whether it respects architectural boundaries, whether it introduces hidden coupling, requires the senior reviewer to mentally reconstruct the entire logic flow. And they don’t. It takes too much energy. When the code looks right, the brain skims. The PR gets approved. The debt gets merged.

Stack Overflow’s 2026 developer survey found that 76% of developers using AI tools reported generating code they didn’t fully understand at least some of the time. Think about that. Three out of four engineers are shipping code into your production systems that they cannot fully explain.

Forrester predicts 75% of technology decision-makers will face moderate to severe technical debt by the end of this year. DORA’s research confirms the pattern: AI adoption links to higher throughput but lower delivery stability. More changes ship faster. Each change is slightly more likely to break something.

Ox Security published a report calling AI-generated code “highly functional but systematically lacking in architectural judgment.” That phrase is worth pausing on. The code works. It passes tests. But it doesn’t know your system. It doesn’t carry the context of why your team chose to handle errors that way, or why the data access layer was separated from the business logic, or why you migrated off that specific library three months ago.

AI treats every prompt as a greenfield project. Your codebase is anything but.

Your Engineers Aren’t Getting Worse. The Problem Is Getting Bigger.

I wrote about this in my recent article on The CTO’s New Engineering Ladder. Output used to be a reasonable proxy for engineering talent. It no longer is. When everyone can ship, what separates your Architects from your Apprentices is judgment. The ability to see downstream consequences. The instinct for what will break. The capacity to reason about a system under pressure.

But judgment depends on understanding the system you’re working within. And the system is getting harder to understand every day that AI-generated code ships without deep review.

This is the entropy spiral. AI produces code faster than your team can comprehend it. Comprehension gaps lead to architectural drift. Drift makes the codebase harder to reason about. And a harder-to-reason-about codebase makes AI-generated code even more dangerous, because the AI doesn’t know what it doesn’t know, and neither does the engineer directing it.

CircleCI’s 2026 State of Software Delivery report, drawn from over 28 million workflows, found that AI-assisted development drove a 59% increase in throughput. But most engineering organizations are leaving the majority of those gains on the table, not because AI isn’t working, but because their validation, review, and delivery systems haven’t caught up.

More code. Fewer releases. That’s the entropy signature.

The CTO as Entropy Fighter

The narrative circulating in boardrooms right now is that CTOs are becoming obsolete. Jack Dorsey announced Block would cut nearly half its workforce, telling shareholders that “100 people + AI = 1,000 people.” The stock jumped 24%. Atlassian split its CTO role in two, explicitly scoped to the AI era. Gartner predicts 40% of enterprise applications will feature task-specific AI agents by end of 2026.

If you listen to this noise, you might think the CTO’s job is shrinking. I think the opposite is true.

When code was expensive, the CTO’s primary job was to make sure enough code got written. When code becomes cheap, the CTO’s primary job is to make sure the system stays coherent. That’s a harder job. The universe is literally working against you.

The old CTO managed output. The entropy-fighting CTO manages order. Order across a codebase that’s being written by humans, AI agents, and hybrid workflows simultaneously. Order across teams that are shipping faster than the architecture can absorb. Order across an organization where product managers, data analysts, and operations leads are all generating code that ends up in production systems.

This is not an abstraction. I coach CTOs who are living this right now. The ones who are thriving have stopped thinking of themselves as accelerators and started thinking of themselves as governors. Not in the bureaucratic sense. In the mechanical sense. The device that prevents an engine from tearing itself apart at high speed.

Three Forces That Create Entropy in AI-Driven Development

Comprehension debt

Addy Osmani coined this term in early 2026, and it captures something that traditional technical debt doesn’t. Comprehension debt accumulates when your team ships code they didn’t write and don’t deeply understand. Every AI-generated feature that gets merged without someone building a genuine mental model of how it works adds to this debt. And unlike traditional debt, you don’t know you’re taking it on.

Architectural amnesia

AI doesn’t remember your design decisions. It doesn’t know why you chose event-driven architecture for that service, or why the auth layer is isolated, or why you deliberately avoided that ORM. Every prompt is a fresh start. Over time, the architectural intent that held your system together gets diluted by thousands of small, individually reasonable decisions that don’t add up to a coherent whole.

Review collapse

When a junior dev submitted 50 lines of code in 2023, a senior could review it meaningfully in ten minutes. When an AI-augmented engineer submits 500 lines that all look syntactically correct, the cognitive cost of genuine review goes through the roof. The natural human response is to skim. Approve. Merge the debt. One API security company found a 10x increase in security findings per month across Fortune 50 companies between December 2024 and June 2025.

These three forces compound each other. Comprehension debt weakens review quality. Weak reviews accelerate architectural drift. Drift makes comprehension harder. The spiral tightens.

Building the Anti-Entropy Machine

If you run an engineering organization of 40 engineers or more, you need what I call an entropy budget. A deliberate, protected allocation of engineering time dedicated not to building new things but to keeping existing things coherent.

1. Make AI your refactoring engine, not just your feature engine

The same tools that generate code at speed can find dead code, consolidate duplicates, generate documentation, and identify architectural drift. Most teams use AI exclusively for production. Flip the ratio. For every four AI-assisted features your team ships, dedicate one cycle to AI-assisted cleanup. Use AI to reduce entropy, not just increase it.

2. Treat AI output like a first draft from a talented stranger

Because that’s what it is. A stranger who doesn’t know your system, your team’s conventions, or your architectural intent. The code might be excellent in isolation. Your job is to make sure it fits the whole.

3. Rebuild your code review around judgment, not syntax

If your reviews are catching formatting issues and variable names, you’re wasting your most expensive engineers on work the linter should handle. Reviews should answer one question: does this change make the system easier or harder to reason about in six months?

4. Instrument your entropy

Track code churn (lines rewritten within two weeks of being written), module coupling over time, and the ratio of new code to refactored code. If new code is climbing and refactored code is declining, your entropy is accelerating. You can see this in GitClear’s data at the industry level. You need to see it at the team level.

5. Protect the learning pipeline.

AWS CEO Matt Garman said it plainly when he heard proposals to replace junior engineers with AI: “That’s like, one of the dumbest things I’ve ever heard.” A Stanford Digital Economy study found employment for software developers aged 22 to 25 has declined nearly 20% from its 2022 peak. If you stop hiring people who are learning to think about systems, you won’t have people who know how to think about systems in five years. Entropy will have won by default.

Your Agentic Future Depends On This

The next chapter of AI development is agentic. Multi-agent systems that plan, execute, and iterate without waiting for a human prompt. Gartner reported a 1,445% surge in multi-agent system inquiries from Q1 2024 to Q2 2025. GitHub’s Agent HQ, announced in February 2026, lets developers run multiple AI agents simultaneously on the same task.

An agentic future running on a high-entropy codebase is a disaster. Agents that can autonomously modify code, run tests, and ship changes will amplify whatever state your system is in. Strong foundations get amplified into faster, more reliable delivery. Weak foundations get amplified into faster, more creative destruction.

The CTO who has spent the last year fighting entropy, keeping architectural boundaries clean, maintaining comprehensible systems, building review processes that catch drift, will have a codebase that agents can navigate and improve. The CTO who chased velocity above all else will have a codebase that agents can barely understand, let alone safely modify.

Your readiness for agentic AI is directly proportional to how well you’ve managed entropy today.

Three Things to Do This Week

Write down the architectural decisions that live only in your head or in the heads of your senior engineers. If your AI tools don’t know why the system is built this way, they can’t maintain it. If your new engineers don’t know, they can’t review the AI’s work. Architectural intent must be documented, not folklored.

Pull your team’s code churn numbers for the last quarter. How much of what was written last month was rewritten this month? If the number is climbing, your entropy is accelerating and no amount of velocity will outrun it.

Pick one senior engineer and give them an explicit mandate: spend 20% of their time next sprint making the codebase more coherent. Not shipping features. Not closing tickets. Reducing entropy. See what happens when someone’s job is to fight disorder instead of produce output.

The CTO isn’t dead. The CTO’s job just got a lot more physical. You’re fighting thermodynamics now. And the engineers who will build your team’s future are watching to see if you care more about speed or coherence.

I know which one keeps companies alive.

Etienne

Etienne de Bruin is the founder of 7CTOs and coaches technology leaders through the complexity of scaling engineering organizations.

Research backing: The article draws on the March 2026 arXiv study of 304K AI-authored commits, GitClear’s 211M lines analysis, CircleCI’s 2026 report (28M workflows), Stack Overflow’s 2026 survey, DORA findings, Ox Security’s “Army of Juniors” report, the Stanford Digital Economy study on junior dev employment, and Gartner’s multi-agent inquiry data. I also wove in Lehman’s Laws (1974) and Clausius for the entropy framing.

She looks at me for a long moment. Then: “I honestly don’t know anymore.”

Half her team is using Claude Code and GitHub Copilot to generate entire features in an afternoon. A junior who joined six months ago shipped three production-ready services last week. Another who’s been around for years is still barely functional without hand-holding. She can’t tell who’s performing and who isn’t because the outputs (features shipping and the pull requests closing) look about the same now. Maybe better for the newer people.

“So what do I measure?” she asks me.

That question has been sitting in my chest ever since.

When the Whole Company Writes Code

It’s not just Priya’s engineers using AI to generate code. It’s her product manager, who scaffolded a working prototype last week to win an argument with the CEO. The data analyst who built an internal tool without filing a single ticket. The operations lead who automated her own reporting pipeline in an afternoon.

Before the seasoned engineers in my audience roll their eyes. I know. A product manager’s prototype is not production software. The gap between a scaffolded feature and a maintainable, secure, observable system is exactly where engineering expertise still lives. The vibe-coded landing page doesn’t survive its first security audit.

But that’s the point. The things that make an engineer irreplaceable are not the things most performance ladders measure. They measure the stuff AI is getting good at. The irreplaceable stuff: judgment about what to build, instinct for what will break, the ability to reason about a system under pressure at 2am. This gets no column in the spreadsheet. No framework for rewarding it, retaining it, or developing it.

When your marketing team can ship a prototype and your engineering team can’t articulate what they do that the prototype can’t, you have a positioning problem inside your own organization. That’s the problem worth solving.

The World According to Dorsey

Jack Dorsey announced recently that Block would cut 4,000 employees, nearly half its workforce, in a move explicitly tied to AI reshaping labor productivity. In a letter to shareholders, Dorsey wrote that “intelligence tools have changed what it means to build and run a company” and that a significantly smaller team using AI can do more and do it better.

Block’s stock surged 24%.

Wharton professor Ethan Mollick pushed back, noting it’s “hard to imagine a firm-wide sudden 50%+ efficiency gain” given how new these tools are. He’s right to be skeptical. Dorsey admitted the company over-hired during COVID and built two separate organizational structures that had to be unwound. Block’s story is complicated.

The board reaction is not. A 24% stock pop gets read across every C-Suite in the industry. Your CEO saw it. Your board saw it. They are now wondering whether your team size can be justified by a formula that is no longer theoretical.

You need to be the one who reframes that conversation with a better framework than Dorsey’s, one that captures what your engineers actually do that AI cannot.

What We’ve Actually Been Rewarding

We have been rewarding output. We need to start rewarding judgment.

When code was slow and expensive, output was a reasonable proxy for judgment. The friction of development naturally filtered for people who understood what they were building. AI has removed most of that friction. Velocity, story points, deployment frequency. Those were the right measures when humans were the bottleneck. They are not the right measures now.

The fair objection: judgment can’t be measured either. Replace one unmeasurable thing with another and you haven’t built a better system. You’ve built a more opaque one where your manager’s subjective read of your “instincts” determines your promotion. The five rungs below are my attempt to solve that by making judgment observable. Not measured directly, but identified through specific, concrete behaviors that consistently produce it and specific, concrete behaviors that consistently undermine it. The goal is a set of signals a manager can actually point to in a conversation.

A 2025 LeadDev survey found that 54% of engineering leaders plan to hire fewer junior engineers because AI copilots are enabling seniors to handle more. On the surface this looks like efficiency. Underneath, it is the slow destruction of the talent pipeline that has produced every senior engineer alive today. A Stanford Digital Economy Study found that by July 2025, employment for software developers aged 22 to 25 had declined nearly 20% from its peak in late 2022. AWS CEO Matt Garman said it best when he heard proposals to replace junior engineers with AI: “That’s like, one of the dumbest things I’ve ever heard. How’s that going to work when ten years in the future you have no one that has learned anything?”

Your engineering ladder is your answer to all of this. If it still measures velocity, story points, and sprint completion (metrics that made sense when humans were the bottleneck) it’s optimizing for a world that no longer exists.

A Ladder Worth Climbing

What follows is the engineering ladder I would build for a team operating in 2026. It doesn’t discard the traditional levels. It reframes what earns each one. The axis shifts from what you produce to what you protect.

Five rungs. Three signals per rung: what excellence looks like, what struggle looks like, and when someone is ready to move up.

One note before we start. These rungs do not quietly push great engineers toward management. The Architect, Multiplier, and Strategist are all individual contributor paths. You do not need to manage people or attend CFO meetings to advance. What you need is to demonstrate that your presence raises the quality of work around you. Through code reviews, documentation, standards you set, systems you build. The path is wide. The requirement is impact that compounds beyond your own output.

Salary ranges reflect 2026 US market data from Glassdoor and the Bureau of Labor Statistics, blending base salary with total compensation. Each range carries a $30K–$40K spread because that spread is real. It’s the difference between someone who just crossed the threshold into a rung and someone who has owned it for three years. Where someone lands within a band should track how long they’ve been operating at that level and how consistently they show the signals below. Use these as calibration points, not contracts. FAANG bands run significantly higher at every level.

Rung One: The Apprentice (formerly Junior Engineer — $85K–$120K)

Their question: why might this output be wrong?

Not “can you ship it?”. AI can ship it. The Apprentice earns their place by interrogating output rather than accepting it.

Excels when

1. They flag inconsistencies before merging,

2. ask for context before shipping, and

3. escalate uncertainty rather than guess through it. Their pull requests include questions, not just solutions.

They build original features and write real code — the difference from the old junior role is that interrogating AI-assisted output, their own and others’, is now what signals genuine understanding. Prompting fluently and understanding deeply are not the same thing. The gap between them matters enormously by Rung Three.

Struggling when

1. they treat velocity as the goal

2. they ship generated code they cannot explain

3. they hide blockers because they don’t want to look like they don’t know something, which at this level is exactly what they should be saying out loud.

Ready to move up when

1. they can explain why a specific piece of AI-generated code will fail in a specific production scenario, not just that it might

2. they have shipped something end-to-end with minimal guidance and their postmortem was more insightful than their manager expected.

Rung Two: The Builder (formerly Mid-Level Engineer — $120K–$155K)

Their question: what is this feature protecting the company from?

The Builder owns a feature end-to-end. Not just shipping it, but the definition of done, the edge cases, the production monitoring, the customer impact. In a world where AI can scaffold a service in two hours, their value is in knowing which service is the right one to build and when to throw the generated output away and start again. They write specs before they prompt.

Excels when

1. they see around the feature they’re building — upstream dependencies, downstream consequences, what happens when it breaks

2. they know what matters to the business, not just the ticket

Struggling when

1. they are technically proficient but scoped too narrow

2. they deliver features in isolation

3. they need an explicit ticket to know what to work on next.

Ready to move up when

1. they have proactively identified and resolved a problem nobody assigned them

2. they have mentored an Apprentice visibly and successfully

3. their technical decisions reference company goals without being prompted.

Rung Three: The Architect (formerly Senior Engineer — $155K–$210K)

Their question: what does this decision cost us in six months?

This is where most performance ladders stop being interesting, which is a shame. It’s where the real leverage begins. The Architect sees downstream consequences before anyone else does. They translate technical debt into business cost without being asked. Not in a presentation. As a reflex.

Excels when

1. they walk into cross-functional conversations with answers before people have finished asking the question

2. the C-Suite understands them

3. their technical instincts show up as financial clarity

Struggling when

1. they are technically brilliant but organizationally invisible

2. they are right in the code review, wrong in the room

Being correct is not enough at this level. The AI era makes the gap between correct and heard more consequential than ever.

Ready to move up when

1. they have demonstrably improved the output quality of a team they don’t manage

2. they have translated a technical risk into a business risk and been understood by a non-technical executive

3. they have driven a consequential build-vs-buy decision and can show the math.

Rung Four: The Multiplier (formerly Staff Engineer — $210K–$300K)

Their question: how does the team make better decisions because of you?

Their output is not features. It is the quality of everyone else’s judgment. If a Multiplier leaves, the team doesn’t slow down by one; it slows down by the compounded capability they were adding to everyone around them. They define how AI-generated output gets evaluated, trusted, and deployed. They don’t just use the tools. They determine how the organization relates to them.

Excels when

1. engineers leave their code reviews smarter than when they arrived

2. their standards get adopted without being mandated

3. their departure would be felt across teams, not just their own.

Struggling when

1. they are still primarily an individual contributor

2. they produce excellent work that doesn’t compound

3. they hoard knowledge because it makes them feel essential rather than building systems that transfer it.

Ready for expanded scope when

1. they have changed how the engineering organization evaluates an entire category of work. Not just one team but the organization.

The bar is voluntary adoption. People following a standard because they were told to is compliance. People following it because it made their work better is influence.

Rung Five: The Strategist (formerly Principal Engineer — $280K–$450K+)

Their question: where do we need to be in two years and what does it cost to get there?

The Strategist’s domain is the future state of the business, not the current state of the codebase. They have opinions on build-vs-buy decisions that factor in organizational capacity, not just technical preference. They understand the Engineering Efficiency Ratio and know how their decisions move it. They are not waiting to be asked about the business. They are thinking about it before the business knows it has a question.

Excels when

1. they are in the room for business decisions before the technical implications surface

2. the CEO treats their input as commercial, not just technical

3. they can quantify the cost of standing still.

Struggling when

1. they have expert architecture instincts but no strategic patience

2. they want to solve the problem in front of them rather than the problem three years out

3. they can describe the vision but not the price tag.

Ready for more scope when

1. they can point to two decisions they made that the company is still benefiting from two years later.

Not decisions they recommended. Decisions they drove.

When You Let Someone Go

You let an engineer go when their judgment is not improving and their presence is actively degrading the judgment of others. Not when they write slow code. Not when they miss a sprint. Not when a feature ships with bugs. Those are correctable.

What is not correctable is an engineer who ships AI-generated code they cannot explain, who creates production surfaces that no one can reason about, and who trains the Apprentices around them to do the same. In the old world, that engineer was slower. In this world, they are a liability.

The inverse is more commonly overlooked. The engineer who makes your team smarter (who raises the quality of judgment around them even if they write less code than anyone else) is the person you build around. The Multiplier you can’t easily measure is often the one holding everything together.

If you’re not sure which kind you have, check what happens the week after they go on vacation.

What You Build This Week

If you run a team of twenty or more engineers without a written performance ladder that addresses AI-augmented work, you are measuring your team against a standard that exists nowhere but in your head. Promotions are political. Feedback is vague. Your best engineers are leaving because they can’t see a path forward.

Three things.

1. Put your current engineers against the five rungs

   Not to demote anyone — to understand where the gaps in judgment actually are. You will find Builders being paid like Architects. You will find Multipliers treated like Builders. That is information worth having before someone else delivers it to you with a resignation letter.

2. Ask every manager what Priya asked me: what does senior mean on your team right now?

   If they can answer it without mentioning years of experience or sprint velocity, great. If they can’t, that is where your work starts.

3. And before you cut Apprentices to protect headcount, read Garman’s line again.

   The engineers who will run your team in 2030 are learning how to think about code right now. Stop creating the conditions for that learning and you will not have a senior team in five years. You will have AI tools and no one who knows what they are doing.

Dorsey may be right that 100 people with AI can do what 1,000 once did. But someone still has to be smart enough to point the AI in the right direction, and wise enough to know when not to.

Build the ladder that finds those people. Reward them for their judgment. Keep them longer than two summers.

The rest will follow.

Etienne de Bruin is the founder of 7CTOs and coaches technology leaders through the complexity of scaling engineering organizations.

It is a Thursday evening and I am sitting at my kitchen table with a cup of coffee going cold next to my laptop. I have been hearing whispers about OpenClaw for a few days now. An open-source agent that lives inside your WhatsApp or Telegram. Created by Austrian developer Peter Steinberger, released quietly in November 2025, and now — in early 2026 — amassing over 182,000 GitHub stars and 30,000 forks. I decide to spend an hour with it.

I get it running. And then I spend the rest of the evening testing it.

I type: “Check my calendar for tomorrow and tell me if I have back-to-back meetings.”

And it does it.

I type: “Draft a quick summary of the last three emails from my CEO.”

And it does that too.

I type: “Find the GitHub issue where we discussed the authentication refactor and pull the key decision.”

Done.

I sit back. The coffee is cold. And I realize something. For the last two hours, I have been getting work done. Real work. Calendar checks, email triage, repository searches, task creation. And I have not opened a single application. Not my calendar app. Not my email client. Not GitHub. Not my task manager.

I have just been texting. An assistant that lives on my own machine, connects to the services I already use, and executes whatever I describe in plain language.

My brain does not feel disrupted. It feels embarrassed. Because I realize I have spent 30 years building products with buttons, forms, menus, and onboarding flows — and the most powerful thing I have used in months has none of that.

Why people are losing their minds over the claw

The world’s AI Tik Tokkers are marveling at OpenClaw’s impact. And yes, it is a simple architecture. A local gateway running a WebSocket control plane, connecting an LLM of your choice to the messaging apps you already have on your phone. No new surface to learn. No subscription to a separate product. The model is agnostic — Claude, GPT, DeepSeek, or something running entirely local on a Mac Mini in your office.

But that’s not the interesting part.

The interesting part is why people are losing their minds over it. Not just developers. People. Non-technical users are saying things like “this is my iPhone moment” and “I got up and running and I’ve been blown away.” One user described having their agent submit health reimbursements, find doctor appointments, and surface relevant documents. Another had their instance autonomously write code, run tests, and open pull requests — all without human prompting.

That enthusiasm has a shadow. In February 2026, Cisco’s security team found a third-party OpenClaw skill performing data exfiltration and prompt injection without user awareness. Researchers disclosed CVE-2026-25253 — 42,000 exposed control panels across 82 countries, 386 malicious skills in the community marketplace. One OpenClaw maintainer warned that the project is “far too dangerous for casual users.” An agent that can do anything is only as safe as the boundaries you define for it — which is precisely the argument for building MCP servers with deliberate, scoped permissions rather than handing agents a raw API key and hoping for the best.

Now, if you are a CTO of a 60-person engineering team in a regulated industry, you may be thinking: my customers are nowhere near this. Their procurement teams, their compliance officers, their enterprise security reviews — none of them are ready to let an agent loose on their SaaS stack. And you would be right, today. Enterprise adoption of agentic workflows will lag this developer enthusiasm by three to five years, easily.

But that’s not the question worth asking. The question worth asking is: what does it tell you about where the gravity is pulling?

What is actually happening with OpenClaw is not a new AI model or a clever piece of infrastructure. It is the first widely-adopted proof that you can eliminate the interface entirely from daily work. For thirty years, software has charged users a tax — the cost of learning the product. Every SaaS you have ever built asks your users to pay it. They navigate your UI. They learn your vocabulary. They figure out where the filter is. They go through your onboarding. They submit a support ticket when they can’t find the export button.

OpenClaw collects no daily tax. Once it is running, you never open another app. You describe what you want in the language you already speak, and the system figures out the rest. Calendar, email, GitHub, task management, file searches — all of it happens through conversation. What people are mesmerized by is not artificial intelligence. It is the elimination of every learned behavior they had to acquire to use software. You never navigate someone else’s information architecture again. You never hunt for a feature. You never click through three menus to export a CSV.

You just ask.

We Have Seen This Movie Before

Cast your mind back to 2004. Salesforce had been quietly building APIs since day one in 2000, and they had just turned “Software as a Service” into “Platform as a Service.” Today 90% of Salesforce’s revenue flows through their API.

Twilio launched in 2008 with a single API for making phone calls. By 2018, that had grown to $129 million in quarterly revenue — up 48% year-over-year. Stripe turned payment processing into seven lines of code. By 2015, APIs were responsible for over 60% of all web traffic.

What drove all of it? Someone removed a tax that developers had been quietly paying for years — the cost of standing up your own infrastructure for common problems. Twilio didn’t invent telephony. They made telephony stupid easy to integrate. Stripe didn’t invent payments. They made payments stupid easy to integrate.

Crucially, Twilio and Stripe were API-first from inception. They didn’t have fifteen years of UI-coupled architecture to unpick. They built clean, predictable surfaces and made other systems dependent on their data. That dependency became their moat.

The CTO thinking about agent-native architecture today is not Twilio. They are the enterprise product that watched Twilio emerge and had to figure out what to do with an existing monolith. That is a harder and more honest problem. And it is the problem worth solving.

Your SaaS Has the Wrong Customer

The assumption baked into every SaaS product built in the last twenty years is that a human being will open a browser tab and interact with it through a mouse or a touchscreen. Every design decision you have ever made — your navigation, your information architecture, your feature discoverability, your mobile experience — exists to serve that assumption.

That assumption is cracking.

Anthropic just launched Cowork. OpenAI has its own agentic surfaces. Every major platform is racing toward agent-native workflows. In these models, the thing that integrates with your SaaS is not a person. It is an agent. And agents do not click. They call APIs. They consume structured data. They act on outputs, not on visual interfaces.

A simple test: if an agent called your product’s API right now, would it get back structured, actionable data — or frontend scraps? The answer tells you more about your architectural readiness than any roadmap review.

This is not a reason to abandon your UI. Your human users still need it, and will for years. But it is a reason to ask a design question you have probably never asked: is my business logic separable from my visual layer? In a well-architected product, the answer should be yes. If your core functionality is tightly coupled to your frontend — and you would be surprised how many products at scale have exactly this problem — then every agentic integration you try to build will be fighting your own architecture.

The CTOs who will win the next decade are the ones who recognize this now, while they still have time to do something about it without a crisis forcing their hand.

The Protocol That Changes the Question

This is where MCP, the Model Context Protocol, Anthropic’s open standard for connecting agents to data sources, enters the picture. OpenClaw is built to integrate with MCP servers. So is Claude. So is every agent framework worth paying attention to right now.

MCP servers are to agents what APIs were to the Web 2.0 ecosystem. A standardized way for an LLM-powered agent to reach into your product, retrieve your data, and take actions on behalf of a user. When Salesforce opened their API, they were betting on ecosystem stickiness: get other systems dependent on your data and your logic, and you become infrastructure. The agent workflows that integrate your MCP server will become dependent on your data in exactly the same way.

A concrete example: Notion published an MCP server. Now an agent like OpenClaw can create pages, update databases, query your workspace, and surface documents — all without a human ever opening Notion’s UI. Notion’s data became reachable by automated workflows that their product team never had to design or build.

That’s the bet. Not replacing your product. Making your product’s value available to users who have stopped using interfaces.

The Practical Path

You do not need to rebuild your entire product. But you do need to be honest about what the work involves.

The first step is a design conversation, not a technical one. Draw a line between what your product does and what your product shows. The “does” layer, your business logic, your data mutations, your integrations is what agents need. It should be cleanly separable from your visual layer. If it isn’t, you are looking at non-trivial architectural work. Not a rewrite, but refactoring that will require real engineering time. Go into that conversation with your team clear-eyed about the cost.

Second, think about your data as a platform. The API economy taught us that the most durable businesses were the ones whose data other systems needed to function. Plaid doesn’t have a consumer-facing UI to speak of. It is pure data infrastructure. Your product almost certainly has unique data that agent workflows will eventually need. Decide now who should be able to reach it, and under what conditions.

Third, publish an MCP server. Start small. Pick your three most valuable actions, the things your power users do most often and package those as callable tools for an agent. This is exactly how the API economy started. Twilio put a few phone call actions behind a simple endpoint and watched what developers built. The developers who integrated early became dependent on Twilio. The same stickiness applies here.

The honest caveat: if your product’s core logic is tightly coupled to your frontend, step three will be harder than it sounds. You will hit the architectural problem before you hit the MCP server. That is useful information. It tells you something about your codebase that matters beyond agents entirely.

The Last Time We Were Here

There is a generation of CTOs who lived through the Web 2.0 API explosion and watched their competitors who moved early become platform companies. The ones who waited became integrations: dependent on platforms for distribution, at the mercy of their pricing decisions.

OpenClaw crossed 182,000 GitHub stars in under two months. It has been adapted for Chinese super-apps running on DeepSeek. SwitchBot just launched what they call the world’s first local home AI agent with native OpenClaw support. This is moving faster than most of us want to admit.

The zero-friction interface is not a distant trend. It is a working product that people are using right now to automate their lives by texting in plain English. Your enterprise customers may not be there yet. But the developers building tomorrow’s enterprise workflows are experimenting with this today. And the products that are agent-ready when that demand arrives will look an awful lot like infrastructure.

The agent era will sort companies the same way the API era did — into platforms and integrations.

Build the MCP server. Make your data reachable. Separate your logic from your UI.

Don’t become the integration.

With Love and Respect for you
Etienne

Are you rebuilding your SaaS architecture with agents in mind? I’d love to hear how you’re thinking about it. Email me directly or join one of our 7CTOs peer groups where CTOs are wrestling with exactly these questions.

Fast forward to 2016. Researchers at the University of Edinburgh were wrestling with a problem in neural machine translation: how do you handle rare words? Words like “antidisestablishmentarianism” or German compound nouns that stretch across half a page. Their solution? Dust off Gage’s compression algorithm and repurpose it for language. They published their findings, and within a few years, every major language model adopted some variant of this approach.

The same year that paper dropped, the ICO craze was building steam. By 2017, startups had raised over $5 billion through initial coin offerings. Tokens were everywhere. Bitcoin tokens. Ethereum tokens. Utility tokens. Security tokens. The word “token” became synonymous with speculative frenzy and blockchain gold rushes.

Now tokens are back. But these tokens have nothing to do with blockchain. They have everything to do with how AI reads, writes, and charges you for the privilege.

The global LLM market hit $6.33 billion in 2024 and is accelerating. Every API call, every ChatGPT conversation, every Claude response is measured and billed in tokens. Yet most CTOs I talk to have only a surface understanding of what a token actually is and why it matters for their technology strategy.

This is a problem.

The Invisible Tax on Your AI Budget

When OpenAI introduced GPT-4o mini, they priced it at $0.15 per million input tokens and $0.60 per million output tokens. Claude 3.5 Sonnet runs $3 per million input tokens. Gemini 2.5 Pro charges $1.25 per million input tokens for prompts under 200,000 tokens.

These numbers seem small until you realize what they mean in practice.

A token is not a word. A token is not a character. A token is a chunk of text that the model has learned to recognize as a meaningful unit. For English, that usually works out to about 4 characters or roughly 0.75 words per token. The sentence you’re reading right now? Probably 15-20 tokens.

But language is messy. And tokenization reveals just how messy.

Take the word “running.” In most tokenizers, that’s a single token. But “antidisestablishmentarianism”? That gets broken into five or six pieces. The tokenizer sees “ant” + “idis” + “establishment” + “arian” + “ism” and treats each piece as a separate billing unit.

Code and structured data behave differently. This is where CTOs building production systems should pay close attention. JSON structures, API responses, configuration files: all tokenized according to patterns the model learned during training. A 1,000-word English document might consume 1,300 tokens. The equivalent JSON payload could easily hit 2,000.

And then there’s the multilingual dimension.

Research from 2023 found that tokenizers trained primarily on English text created significant cost premiums for underrepresented languages. A sentence in Burmese or Tibetan might require ten times the tokens of its English equivalent. The good news: modern tokenizers are rapidly closing this gap. OpenAI’s o200k_base vocabulary—double the size of GPT-4’s tokenizer—has reduced premiums for major languages to roughly 1.5x to 4x compared to English. For CTOs building products that serve global audiences, this represents meaningful progress, though the gap hasn’t fully closed.

Inside the Token Factory

Understanding tokenization starts with understanding why we need it at all.

Language models don’t read text. They process numbers. Every word, every character, every emoji must be converted into a numerical representation before the model can work with it. The question is: what’s the right size for these numerical chunks?

Character-level tokenization treats each letter as a separate token. The word “hello” becomes five tokens: h, e, l, l, o. This approach handles any input you throw at it, including made-up words, typos, and foreign scripts. But it creates sequences that are absurdly long and loses the semantic grouping that makes language meaningful.

Word-level tokenization goes the other direction. Every word gets its own token. Great for common words. Disastrous for the vocabulary explosion problem. English alone has over 170,000 words in current use. Add technical jargon, proper nouns, and the infinite creativity of internet discourse, and you’re looking at a vocabulary that grows without bound. Any word the tokenizer hasn’t seen before? It simply cannot process it.

Subword tokenization splits the difference. The algorithms learn which character combinations appear frequently in the training data and group them into tokens. Common words like “the” or “running” get their own tokens. Rare words get broken into recognizable pieces.

Philip Gage’s Byte Pair Encoding works by counting. Start with individual characters. Find the pair that appears most often in your training data. Merge that pair into a new token. Repeat until you hit your target vocabulary size.

GPT-2 used a vocabulary of about 50,000 tokens built this way. GPT-4 expanded to roughly 100,000. GPT-4o’s o200k_base tokenizer doubled that again to around 200,000 tokens—a major upgrade that dramatically improved efficiency for non-English languages and code. Each merge decision was made purely on frequency. No linguistic knowledge, no semantic analysis. Just counting.

This creates some interesting side effects.

Numbers are particularly chaotic. The number “12345” might tokenize as “123” + “45” in one model and “1” + “234” + “5” in another. This has implications for any application doing arithmetic or processing financial data.

Chinese characters often get tokenized one per token in older systems because they lack whitespace boundaries and weren’t as heavily represented in English-centric training data. The expanded vocabularies in modern tokenizers have helped here, but a Chinese user and an English user sending the same message still typically pay different rates because of decisions made during tokenizer training.

The Three Tokenization Families

Modern language models cluster around three main approaches:

1. Byte Pair Encoding (BPE) powers the GPT family. Frequency-driven, merging common pairs until reaching target vocabulary size.

2. WordPiece (BERT, some Google models) considers likelihood rather than raw frequency, adding special prefixes to indicate word continuations.

3. SentencePiece emerged for truly multilingual models, treating input as raw bytes rather than assuming whitespace marks word boundaries.

The practical differences matter when choosing models for production. A tokenizer trained heavily on English will be cheap for English but expensive for other languages. A more balanced tokenizer costs more per token on English but delivers consistent pricing across languages.

What This Means for Your Architecture

Every technical decision in an LLM application traces back to tokens.

Context windows are measured in tokens. GPT-4 Turbo offers 128,000 tokens. Claude 3 handles 200,000. Gemini 2.5 Pro pushes to 1 million. But here’s the critical insight that many CTOs miss: filling those windows costs money, and the model’s ability to use information degrades for content buried in the middle of very long contexts.

Research published in Transactions of the Association for Computational Linguistics found that LLM performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access information in the middle, even for explicitly long-context models. Having a 2-million-token context window doesn’t mean your model will reason equally well across all 2 million tokens. Structure matters.

Prompt engineering is token engineering. A verbose instruction like “Please provide a comprehensive and detailed explanation of the following concept” consumes about 12 tokens. “Explain thoroughly” accomplishes the same goal in 3 tokens. At scale, that’s a 75% reduction in prompt overhead.

Caching strategies depend on tokenization and on prompt structure. OpenAI automatically caches prompts over 1,024 tokens, reducing costs for repeated requests by up to 50%. Anthropic requires explicit cache control headers. But caching only works when your prompts share an identical prefix.

Here’s a high-value tip: if your team puts a timestamp at the start of every prompt, you’re breaking the cache. Every single request gets processed from scratch because the prefix changes with each call. Move static content like system instructions, few-shot examples and reference materials to the beginning where caching can take effect. Dynamic content (user queries, timestamps, variable data) belongs at the end. Get this wrong, and you can burn thousands of dollars on requests that should have been cached.

Output costs consistently exceed input costs across all major providers. The ratio typically runs 3-5x, meaning that getting concise responses saves more money than optimizing prompts. Applications that generate verbose outputs pay a premium that accumulates fast.

The Emerging Alternatives

Here’s something worth tracking: tokenization itself may be a temporary architectural choice, not a permanent law of physics.

Research into token-free language models is advancing rapidly. Architectures like MambaByte and MEGABYTE learn directly from raw bytes, removing the inductive bias of subword tokenization entirely. These approaches show competitive performance with state-of-the-art subword Transformers on language modeling tasks while eliminating the entire vocabulary mismatch problem.

Why does this matter? Token-free models would end the multilingual cost premium entirely. A sentence in Burmese would cost exactly what a sentence in English costs—measured in bytes, not tokens. Code, structured data, and unusual text formats would all normalize.

We’re not there yet. These approaches face efficiency challenges that prevent immediate production deployment. But the research trajectory suggests that in three to five years, the entire token economy we’re building systems around today could look quite different.

For CTOs making architecture decisions now, the practical takeaway is to build systems that abstract away the tokenization layer where possible. Don’t hard-code assumptions about token costs into your economic models. Monitor your actual token usage by feature, by content type and/or by language so you can adapt as the landscape shifts.

Building Your Token Intelligence

Start by instrumenting your applications to track token usage at a granular level. Not just total tokens per day, but tokens per feature, per user segment, per content type. You need visibility into where your tokens go before you can optimize.

Test your content against multiple tokenizers. OpenAI provides a free tokenizer tool. Run your typical inputs through and compare the results against what you’d pay with Anthropic or Google. If you’re processing lots of code, compare tokenization efficiency across models designed for code versus general-purpose models.

Consider hybrid strategies. Simple queries might route to cheaper models with efficient tokenizers. Complex queries might justify premium models with larger context windows. The token economics should inform your model routing logic.

The Token Economy Evolves

The LLM API market shows aggressive price competition. Inference costs fell roughly 10x per year through 2024, with some analysts estimating that costs for GPT-3.5-class performance dropped 280-fold between 2020 and 2024. Prices for frontier models continue declining.

New tokenization methods continue to emerge. Research into morphologically-aware tokenizers promises better efficiency for agglutinative languages. Byte-level models that skip tokenization entirely are showing competitive results for some tasks. The field is far from settled.

What remains constant is the fundamental insight: tokens are the atomic unit of AI. Every capability, every cost, every limitation traces back to how text becomes numbers and numbers become text again.

Philip Gage probably didn’t imagine his compression algorithm would underpin a multi-billion dollar industry three decades later. But the principle he discovered holds: find the patterns, exploit the redundancy, and you can represent complex information efficiently.

For CTOs, the message is clear. Tokens aren’t just a billing unit. They’re the lens through which your AI applications see the world. Understand that lens, and you understand what your AI can and cannot do.

The blockchain tokens of 2017 were speculative instruments. The LLM tokens of 2025 are fundamental infrastructure. Both demand the CTO’s attention. Only one will shape the next decade of technology strategy.

Time to learn the currency.

Royce never used the word waterfall. More importantly, directly beneath his now-infamous diagram, he wrote something the industry conveniently ignored: “I believe in this concept, but the implementation described above is risky and invites failure.”

The man credited with inventing waterfall was actually warning against it.

Royce spent the remainder of his paper advocating for iteration, prototyping, and feedback loops. His third recommendation was explicit: “Do it twice.” Build a pilot model first—what he called a “simulation”—to test critical design and operational areas before committing to the version delivered to the customer. He described the unique skills needed for this pilot phase: developers who “must have an intuitive feel for analysis, coding and program design” and can “quickly sense the trouble spots in the design, model them, model their alternatives.” His son, Walker Royce, would later become a principal contributor to the IBM Rational Unified Process, an iterative methodology. The irony is complete.

Three Decades of Monuments to a Misreading

For three decades, software teams built monuments to a misreading. Requirements documents grew to hundreds of pages. Sign-offs multiplied. Testing became something that happened after all the code was written, right before the panicked realization that nothing worked as expected. Projects hemorrhaged money, missed deadlines, and delivered systems nobody wanted.

The industry was ready for a rebellion.

Seventeen Anarchists in the Mountains

On February 11, 2001, seventeen software practitioners drove up Little Cottonwood Canyon to the Lodge at Snowbird in Utah (I just moved here btw!!). They represented competing methodologies with names like Extreme Programming, Scrum, Crystal, and Dynamic Systems Development Method. Bob Martin, who organized the gathering, later joked that assembling a bigger group of organizational anarchists would be hard to find.

They came because the status quo had become unbearable. The average lag between identifying a business need and deploying a software solution had stretched to three years. Documentation had replaced delivery. Process had suffocated progress.

What They Agreed On

Martin Fowler, one of the attendees, expected little from the meeting beyond making contacts that might turn into “something interesting.” Alistair Cockburn had reservations about the term “lightweight methodologists” that the group had been using: “I don’t mind the methodology being called light in weight, but I’m not sure I want to be referred to as a lightweight.”

What emerged from those two days surprised everyone, including the participants. They agreed on four values and twelve principles that prioritized working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

The only concern with their chosen name came from Martin Fowler, who worried that most Americans didn’t know how to pronounce the word “agile.”

The Manifesto’s Unintended Reach

The Manifesto spread faster than any of its authors anticipated. Mike Beedle, one of the signatories, never foresaw its adoption in contexts beyond software, like leadership and sales. James Grenning took years to realize it was “such a big deal.” Kent Beck’s original vision for Extreme Programming was simply to make the world safe for programmers.

For two decades, Agile became orthodoxy. Sprints replaced phases. User stories replaced requirements documents. Standups replaced status meetings. The pendulum had swung.

The Core Idea

The methodology that wins is the one that matches how you actually build.

Waterfall failed because it assumed requirements could be known completely upfront. Agile succeeded because it embraced uncertainty. Now AI is introducing a third variable: when your implementer is an algorithm, the rules change again.

Why This Matters Now

Something unexpected is happening in engineering organizations that have embraced AI coding assistants. Teams are writing more documentation, not less. Design documents are growing longer. Requirements specifications are becoming exhaustive. One engineering leader described the emerging pattern as “Agile planning, waterfall execution.”

The reason is straightforward: AI thrives on precision. As one AI engineer put it, “the agents we have right now need what waterfall provides even more than people do.”

The High Cost of AI Coding

When you hand a vague prompt to Claude or Copilot, you get vague results. The AI will happily generate plausible code, but plausible isn’t the same as correct. The model makes assumptions at every turn. Sometimes those assumptions align with your intent. Often they don’t. You end up in a debugging loop that feels less like pair programming and more like archaeology.

Andrej Karpathy, co-founder of OpenAI, coined the term “vibe coding” in February 2025 to describe this loose approach: describing what you want in natural language, accepting AI suggestions without carefully reading the diffs, and iterating until something seems to work. It’s fast. It’s fun. And according to a randomized controlled trial published by METR in July 2025, experienced open-source developers using this approach on their own mature codebases actually took 19% longer to complete tasks than those working without AI assistance.

The METR Study: What CTOs Need to Know

The study deserves a closer look. METR recruited 16 developers who had contributed to large open-source repositories (averaging over one million lines of code and 22,000 GitHub stars) for an average of five years. These weren’t beginners learning a new codebase. These were experts on home turf, using frontier tools like Cursor Pro with Claude 3.5 and 3.7 Sonnet during the February-June 2025 study period.

The perception gap was striking. Before starting, developers predicted AI would make them 24% faster. After completing the study, they estimated AI had improved their productivity by 20%. The actual measurement: 19% slower. METR explicitly notes that their results may not generalize to other contexts—less experienced developers, unfamiliar codebases, or different types of tasks might see different outcomes. But for experts working on systems they know intimately, the vibe coding approach created more friction than it removed.

The problem isn’t the AI. The problem is the input.

The Distinction That Matters

Simon Willison, a programmer who has thought deeply about AI-assisted development, draws a clear line: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding. That’s using an LLM as a typing assistant.” The distinction matters because it identifies where the value creation actually happens.

Amazon’s Kiro, an agentic IDE launched in July 2025 and made generally available in November, embodies this insight. When you start a new project in Kiro, it asks you to choose between two modes: “Vibe” for exploratory chat-driven coding, or “Spec” for plan-first development. The Spec mode forces you through a structured workflow: first, requirements with detailed acceptance criteria written in EARS notation; then, technical design with diagrams and schemas; finally, implementation tasks sequenced by dependency.

Why AWS Built a Project Manager Into an IDE

AWS’s rationale was blunt. As product lead Nikhil Swaminathan and VP Deepak Singh explained: “When implementing a task with vibe coding, it’s difficult to keep track of all the decisions that were made along the way, and document them for your team.” The spec-driven approach emerged because users weren’t giving AI enough detail to get high-quality results. The tool itself acts like a project manager, guiding teams to plan before coding.

Research cited by AWS found that addressing issues during the planning phase costs five to seven times less than fixing them during development. This principle has always been true. What’s changed is that AI agents amplify the difference. A human developer encountering an ambiguous requirement might pause, walk over to a product manager’s desk, and ask a clarifying question. An AI agent encountering the same ambiguity will make a decision and keep generating code.

We’ve Heard This Before

If you’re experiencing déjà vu, you’re not wrong. “The spec is the code” echoes promises from the 1990s—UML, Model-Driven Architecture, CASE tools that would let us draw diagrams and generate applications. Those initiatives failed because the visual specifications became as complex as the code they were supposed to replace. The abstraction didn’t abstract; it just moved the complexity sideways.

LLMs are different in one important respect: they handle natural language ambiguity far better than the rigid schema-driven tools of that era. A CASE tool choked on anything outside its formal grammar. An LLM can interpret “make the button look clickable” and produce reasonable CSS, even though that phrase would have crashed any 90s code generator.

The Maintenance Trap

But the leaky abstraction problem hasn’t disappeared. When the AI-generated code breaks, someone has to debug it. When security vulnerabilities emerge, someone has to patch them. When requirements change, someone has to decide whether to regenerate the module or surgically edit it. That someone needs to understand what the code actually does—not just what the spec said it should do.

This is the maintenance trap that keeps CTOs awake. If a spec generates 1,000 lines of code, you now own 1,000 lines of code. The technical debt doesn’t vanish because you didn’t type it yourself. The security vulnerabilities don’t excuse themselves because they came from a model.

Spec-driven development addresses this partially through synchronization. Kiro, for instance, keeps specs and code connected: developers can author code and ask the tool to update specs, or update specs to refresh tasks. This solves the common problem where documentation drifts from implementation. But it doesn’t solve the deeper question of how you refactor AI-generated code when requirements change. Do you regenerate everything and lose the human refinements? Do you surgically edit and let the spec drift? The tooling is still immature, and honest practitioners admit that the Day 2 operations story remains incomplete.

English Is Not the New Coding Language

Karpathy’s quip that “the hottest new programming language is English” makes for a great tweet, but let’s be serious for a minute. Writing a spec precise enough for an AI to implement correctly is still programming, just with different syntax.

If a product manager writes a spec detailed enough that an AI can implement it without clarification, that product manager has essentially written logic. They’ve specified what happens when the user submits an empty form, what happens when the database times out, what happens when two users edit the same record simultaneously. That’s programming, whether or not it looks like code.

The better framing isn’t “anyone can code now.” It’s that AI forces engineers to become architects first. The value shifts from implementation to specification, from typing to thinking. This isn’t democratization; it’s elevation. The developers who thrive will be those who can decompose problems, anticipate failure modes, and communicate intent with precision—skills that were always important but are now existential.

The Security Question

We also worry about what happens when detailed technical designs flow into an LLM. A comprehensive spec for your core product is, in effect, a “god prompt” containing trade secrets, architectural decisions, and competitive advantages. Even enterprise-grade models raise questions about data handling, training pipelines, and access controls.

The emerging best practice is to keep the spec-to-code pipeline within controlled environments. Tools like Kiro run on AWS infrastructure with options for customer-managed encryption keys and controlled data usage. Organizations with stricter requirements are exploring private VPC-hosted models or retrieval-augmented generation (RAG) architectures that keep sensitive context local while leveraging cloud models for generation. The tooling is evolving, but the principle is clear: if your spec contains your competitive moat, treat it with the same security posture as your source code.

When Spec-Driven Development Fails

Spec-driven development isn’t a silver bullet. CTOs should watch for these anti-patterns:

The Infinite Refinement Loop.

Teams get trapped perfecting specs instead of shipping software. The spec becomes a procrastination device. If your team has spent three sprints refining requirements and generated zero working code, you’ve replaced one form of paralysis with another.

The Premature Precision Problem.

Some features shouldn’t be specified in detail upfront. Exploratory work, R&D projects, and early-stage prototypes benefit from vibe coding’s looseness. Forcing exhaustive specs on discovery work kills the discovery.

The Specification Theater.

Teams produce beautiful specs that look comprehensive but contain the same ambiguities in longer sentences. “The system shall handle errors gracefully” doesn’t become clearer by expanding it to three paragraphs of corporate prose. Precision requires thinking, not word count.

The Ownership Vacuum.

When AI generates the code and the spec lives in a shared document, accountability diffuses. Nobody feels responsible for understanding the implementation. Bugs become orphans. The fix is explicit ownership: someone’s name goes on every generated module, and that person is responsible for understanding what the AI produced.

The Regeneration Roulette.

Teams discover that regenerating a module from an updated spec produces subtly different code. Tests pass, but behavior changes in ways nobody anticipated. Version control becomes treacherous when the “source” is a spec and the code is an output.

The New Shape of Development

If I still have your attention then you are one of the few CTOs who knows that the reading of the methodology needs to evolve. The binary of Agile versus Waterfall is dissolving into something more nuanced.

The insight from spec-driven development is that front-loading thinking doesn’t mean returning to six-month requirements phases. It means investing in clarity before asking an AI to execute. The spec becomes the prompt. The better the spec, the better the output.

Thoughtworks describes this emerging practice as using “well-crafted software requirement specifications as prompts, aided by AI coding agents, to generate executable code.” The specification is more than a product requirements document. It includes technical constraints, architectural decisions, interface definitions, and acceptance criteria precise enough that an AI can validate its own work against them.

How the Workflow Separates

The workflow separates planning and implementation into distinct phases. During planning, you collaborate with the AI to understand requirements, identify edge cases, and document constraints. This is iterative work. The AI asks clarifying questions. You refine your thinking. The spec emerges from the conversation.

Once the spec is finalized, implementation becomes more mechanical—though never fully automatic. The AI generates code that conforms to the documented requirements. Tests verify behavior against acceptance criteria. Documentation stays synchronized because the spec is the source of truth, not a byproduct.

Kiro’s approach takes this further with what it calls “hooks”—event-driven automations that trigger agent actions when you save or create files. A hook might validate that every new React component follows the single responsibility principle. Another might ensure security best practices are enforced. These hooks encode team standards in a way that the AI can execute automatically, replacing the mental checklists that developers previously carried in their heads.

The Validation Stack

The tools for validating AI-generated code are maturing rapidly. SWE-bench tests models on real GitHub issues from popular repositories. Code review benchmarks measure whether AI tools catch meaningful bugs without overwhelming pull requests with noise. In one July 2025 evaluation by Greptile, leading AI review tools achieved bug-catch rates ranging from 6% to 82% on fifty real-world pull requests from production codebases. The variance is enormous, which means tool selection and configuration matter.

Evals—the systematic evaluation of AI outputs against defined criteria—are becoming a core competency. Teams are building pipelines that automatically measure functional correctness, code quality, performance, and security. The pass@k metric quantifies whether generated code passes all defined tests. Tools like SonarQube and Semgrep flag issues in readability and maintainability. Security audits detect vulnerabilities before they reach production.

The goal isn’t to eliminate human judgment. It’s to focus human judgment where it matters most: defining what the software should do, validating that it does it, and evolving the system as requirements change.

What To Do Monday Morning

If you’re leading an engineering organization, you don’t need to overhaul your entire methodology. You need to adapt your practices to match how AI tools actually work.

Start with a single team and a single feature. Before anyone writes a prompt, spend the time to write a proper spec. Include user stories with acceptance criteria. Document the technical design: data models, interfaces, dependencies. Break the work into discrete tasks. Be specific about edge cases and failure modes. If you find yourself writing “handle errors appropriately,” stop and specify what appropriate actually means.

Then hand that spec to your AI coding tool and observe what happens. You’ll likely find that the output quality improves dramatically. The AI will make fewer assumptions because you’ve made your intent explicit. Debugging will shift from “what did the AI think I wanted?” to “how do I refine what I actually want?”

Build Validation Into Your Workflow

If you’re generating code at scale, you need tests at scale. Define acceptance criteria that can be automatically verified. Run static analysis on every generated artifact. Treat AI-generated code with the same rigor you’d apply to code from a new hire: review it, understand it, and hold it accountable. The METR study found that developers who couldn’t explain what the AI had generated spent more time fixing problems than they saved in writing code.

Establish clear ownership for AI-generated modules. Someone needs to be responsible for understanding, maintaining, and securing that code. Don’t let the fact that no human typed it obscure the fact that humans are accountable for it.

Invest in Specification Skills

Invest in the spec-writing capability of your team. Product managers who can write precise requirements become force multipliers. Engineers who can translate ambiguous requests into unambiguous specifications become the new 10x developers. But be clear-eyed about what this means: spec-writing at this level is a technical skill, not a documentation chore.

Consider tools that enforce the spec-driven workflow. Kiro is one option. GitHub’s Copilot Workspace and Cursor’s agent mode offer similar capabilities. The common thread is structure: these tools separate thinking from typing, planning from implementing.

Address Security Upfront

Address security upfront. If your specs contain sensitive architectural details or trade secrets, ensure your AI tooling runs in controlled environments. Evaluate whether your compliance requirements allow cloud-hosted models or necessitate on-premise alternatives. Don’t discover your security posture after you’ve fed your product roadmap into a model.

Track the Outcomes

Track the outcomes. Measure time to first working implementation. Measure rework rates. Measure defect rates in production. Measure how long it takes to onboard a new developer to an AI-generated codebase versus a human-written one. If spec-driven development is working, you should see fewer iterations to reach a correct solution, less time spent debugging AI assumptions, and more consistent quality across the team.

The Battlefield Has Shifted

The methodology wars aren’t over. They’ve just shifted to a new battlefield. The CTO who recognizes that AI changes the calculus, who embraces detailed planning not as a return to waterfall but as a precondition for AI effectiveness, will build faster than competitors who are still vibe coding their way to production.

Royce was right in 1970: the risky approach is the one without iteration. He just couldn’t have imagined that the iteration would happen in a conversation with an AI, and that the output of that conversation would be a specification precise enough to generate working software.

The spec is the new prompt. Write it well and own what it produces.

The AI research community called it the “DeepSeek Shock.” Venture capitalist Marc Andreessen called it “one of the most amazing and impressive breakthroughs I’ve ever seen.” But for CTOs watching from the sidelines, the implications were more unsettling than impressive.

If a small team in Hangzhou could match frontier AI performance at roughly 1/100th the cost, what did that mean for the $200/month coding assistants we were happily paying for? What did it mean for the enterprise contracts we were signing? What did it mean for the vendor relationships we were building our engineering workflows around?

The answer, as 2025 unfolded, became increasingly clear. And as we move deeper into 2026, the CTO who ignores this shift does so at considerable risk.

The Collapse

When GitHub Copilot launched, paying $10/month for AI-assisted coding felt like stealing. When Claude Code emerged at $200/month for complex multi-file refactoring, the ROI math still worked. These tools genuinely accelerated development. They still do.

But the economics underneath them are crumbling.

DeepSeek’s R1 model achieved 90.8% accuracy on MMLU compared to GPT-4’s 87.2%. On the AIME 2024 mathematics benchmark, it scored 79.8% against GPT-4’s 9.3%. And it did this using “nerfed” H800 GPUs that the U.S. government had restricted China to using, thinking the hardware limitations would slow them down.

They optimized around the restrictions instead.

The Multi-Head Latent Attention architecture DeepSeek developed reduces memory requirements by 93%. Their Mixture-of-Experts approach activates only 37 billion of the model’s 671 billion parameters per token. The result is frontier-level intelligence that runs on hardware a well-funded startup can actually afford.

Within months of DeepSeek’s release, Chinese AI labs released a cascade of open-weight models that now occupy seven of the top ten spots on global coding benchmarks. Qwen 3 Coder scores 67% on SWE-bench Verified at roughly 1/30th the cost of Claude Sonnet. GLM-4.7 hits 91.2% on SWE-bench, outperforming most proprietary options. Kimi K2 Thinking solves 69% of real GitHub issues, within a few points of GPT-5’s performance.

These aren’t research curiosities. They’re production-ready models with Apache 2.0 licenses that you can download today and run on your own infrastructure.

Why This Matters for Your Engineering Budget

IBM’s Chief Architect for AI Open Innovation, Gabe Goodhart, put it plainly in a recent interview: “We’re going to hit a bit of a commodity point. It’s a buyer’s market. You can pick the model that fits your use case just right and be off to the races. The model itself is not going to be the main differentiator.”

The model itself is not going to be the main differentiator.

Read that again. If you’re a CTO currently paying per-seat licensing for AI coding tools, that sentence should make you uncomfortable.

A 500-developer team using GitHub Copilot Business faces $114,000 in annual costs. The same team on Cursor’s business tier pays $192,000. Tabnine Enterprise exceeds $234,000. These numbers assume stable pricing, which historically trends upward, not down.

Meanwhile, Kimi K2 is available at $0.088 per million tokens. GLM-4.5 runs at $0.11 per million tokens. DeepSeek’s pricing sits as low as $0.07 per million tokens with cache hits. For organizations processing thousands of pull requests, that’s the difference between a line item that requires budget approval and one that rounds to zero.

The gap between open-weight and closed proprietary models has effectively vanished for most practical coding tasks. Multiple analysts now predict full parity by Q2 2026.

The Vendor Lock-In Problem You Don’t See Yet

I coach CTOs who run engineering teams of 40 to 120 people. When I ask them about their AI coding tool strategy, most describe a single vendor relationship they’re increasingly dependent on.

They’ve trained their developers on specific workflows. They’ve integrated the tools into their CI/CD pipelines. They’ve built muscle memory around particular interaction patterns. And they’ve done this without an exit strategy.

Vendor lock-in in the AI coding space doesn’t announce itself the way traditional software lock-in does. There’s no proprietary file format holding your data hostage. The lock-in is subtler. It lives in the habits your team forms, the workflows they optimize for, and the switching costs that accumulate invisibly over time.

When your developers spend six months learning the quirks of a specific AI assistant, when your code review process assumes that assistant’s output format, when your documentation reflects that assistant’s conventions, you’ve built dependencies that don’t show up on any balance sheet.

The CTO Magazine recently published a piece titled “The Great AI Vendor Lock-In: How CTOs Can Avoid Getting Trapped by Big Tech.” Their conclusion: “The collapse of Builder.ai serves as a stark warning: overreliance on proprietary AI platforms can leave businesses stranded without access to critical systems or data.”

The companies most at risk aren’t the ones using AI coding tools. They’re the ones using AI coding tools without considering what happens when the economics shift underneath them.

What the Smart Money Is Doing

Red Hat’s recent analysis of the open-source AI landscape found that organizations in highly regulated sectors like telecommunications and banking are moving toward open models as a requirement, not a preference. Data residency regulations demand that AI usage stay local. Compliance requirements demand transparency into how models operate.

These organizations aren’t choosing open models because they’re cheaper. They’re choosing them because closed models create audit risks they can’t accept.

But even outside regulated industries, the pattern is emerging. Enterprise teams are adopting hybrid approaches. They use GitHub Copilot for general coding assistance while deploying open-source tools like Aider for sensitive projects that can’t leave their network. They route simple completions through cheap local models while reserving expensive API calls for genuinely difficult problems.

The PyTorch Foundation’s Executive Director, Matt White, identified three forces defining open-source AI in 2026:

1. global model diversification led by Chinese multilingual releases

2. interoperability as a competitive axis, and

3. hardened governance with security-audited releases and transparent data pipelines.

The organizations paying attention are building optionality into their AI strategy. They’re ensuring they can swap models without retraining their entire engineering team. They’re treating AI coding assistance as infrastructure rather than a service relationship.

The Models You Should Know About

If you’re going to reduce your dependency on paid AI coding services, you need to understand what’s available. The open-source landscape has matured faster than most CTOs realize.

DeepSeek V3.2 remains the benchmark for efficiency. The MIT-licensed model handles 128,000 tokens of context, meaning it can analyze entire codebases without losing track of what it’s doing. The Speciale variant achieves gold-medal scores on competitive programming benchmarks.

Qwen 3 Coder from Alibaba offers 256,000 tokens of native context, expandable to one million. Its dual-mode architecture lets developers choose between rapid completions and deep reasoning depending on the task. At 67% on SWE-bench Verified, it solves roughly seven out of ten real programming problems.

GLM-4.7 from Zhipu AI was built specifically for agentic coding workflows. It integrates with tools like Claude Code, Cline, and Kilo Code with zero friction. The model runs on eight NVIDIA H20 chips, making self-hosting accessible to organizations that would struggle with larger models.

Kimi K2 Thinking from Moonshot AI uses a trillion-parameter Mixture-of-Experts architecture that activates only 32 billion parameters per token. Independent benchmarks rank it as the strongest model not made by OpenAI, Google, or Anthropic. Its agentic capabilities let it execute 200-300 sequential tool calls autonomously.

These models aren’t coming. They’re here. And they’re improving faster than the proprietary alternatives because the open-source community can iterate on them without permission.

The Prediction That Matters

By the end of 2026, the market for paid AI coding models will look fundamentally different than it does today.

I don’t mean that GitHub Copilot will disappear. I don’t mean that Claude Code will shut down. These products will continue to exist, and they’ll continue to improve.

What I mean is that the economic rationale for paying premium prices will erode to the point where it only makes sense for a narrow slice of use cases. The CTO paying $200,000 annually for AI coding assistance will look at the CTO paying $20,000 for equivalent capability and wonder what they’re getting for the extra $180,000.

The answer, increasingly, will be “not much.”

Tom Tunguz, GP at Theory Ventures, recently predicted that small language models and open-source alternatives will rise in popularity as research labs determine how to specialize them for particular tasks. Developers will prefer them for 10x cost reductions.

Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by end of 2026, up from less than 5% in 2025. But they also warn that over 40% of agentic AI projects will be canceled by 2027 due to escalating costs.

Those escalating costs come from vendor relationships that made sense at small scale but become unsustainable as usage grows. The organizations that avoid this trap will be the ones that built optionality into their AI strategy from the beginning.

What to Do About It

If you’re currently relying on a single AI coding vendor, you don’t need to abandon them tomorrow. The tools are genuinely good. The productivity gains are real. Ripping out working infrastructure to chase theoretical savings is rarely smart.

But you should be doing three things right now.

First, establish model-agnostic workflows. Your developers should be comfortable prompting AI assistants, not comfortable with a specific AI assistant. The interaction patterns that work with Claude Code work with Aider work with open-source alternatives. Build skills that transfer.

Second, run experiments with open models. Set up Ollama on a development server. Deploy a Qwen model behind your firewall. Give a small team permission to use local AI for a sprint. You need firsthand experience with what open models can and can’t do before you need to make migration decisions under pressure.

Third, negotiate your contracts carefully. If you’re signing annual enterprise agreements, build in flexibility. Avoid volume commitments that assume stable or growing usage. The leverage in these negotiations is shifting toward buyers faster than most vendors want to admit.

The paid AI coding market isn’t dying this year. But the conditions that made premium pricing rational are disappearing. The CTO who recognizes this shift and builds accordingly will have options. The CTO who doesn’t will be locked into contracts that their competitors have already walked away from.

The models are commoditizing. The question is whether you’ll be ahead of that curve or behind it.

But that number is the polite version of the story.

Dig deeper into the data and you find something more troubling. The average company uses only about half of the software licenses they’ve purchased. Large enterprises with 10,000+ employees spend $284 million on SaaS annually while using 660 different applications. Two-thirds of IT leaders report unexpected charges due to consumption-based or AI pricing models they didn’t fully understand when they signed the contract.

And we haven’t even talked about the integration tax yet.

When a CFO asked me recently why her engineering budget seemed to be disappearing into “connective tissue,” I had to explain what most CTOs already know but rarely say out loud: the middleware, the consultants, the custom pipelines stitching together systems that were never designed to talk to each other. These costs often exceed the subscription fees themselves.

For two decades, we accepted this trade. SaaS promised lower friction in exchange for compromise. We rented generic tools, adapted our workflows to vendor assumptions, and accumulated operational overhead in the form of integrations, administrators, and compliance scaffolding.

That trade no longer reflects the underlying economics.

The Rental Model We Never Questioned

SaaS solved a 1990s problem: how to distribute complex software when infrastructure, deployment, and maintenance were prohibitively expensive. It succeeded by centralizing ownership and standardizing behavior.

The model made sense when custom software meant six-figure development projects, 18-month timelines, and the constant dread of maintenance. Building your own tools was a rich company’s game. Everyone else rented.

But here’s what’s strange. We never stopped to ask whether the rental model still made sense once the underlying economics shifted.

Consider what’s actually happening inside most scaling organizations. According to Grip Security’s 2025 SaaS Security Risks Report, SaaS applications per employee have steadily risen, marking an 85% increase in the number of accounts per user. The average employee now juggles 13 different SaaS tools in their daily work.

Each of those tools comes with its own login, its own data model, its own API quirks. Each creates a new integration point. Each adds to the cognitive load of your teams. And each one guards its own silo of company data, preventing your AI systems from seeing the full context of your business.

The SaaS landscape has consolidated into what I call concentric circles of dependency. At the center sit platform giants: Salesforce, Microsoft, Google, Oracle, SAP. Their gravity pulls in smaller vendors who build integrations, extensions, and complementary tools. Around them orbit the integration layer: the middleware providers, the consultancies, the “implementation partners” who make their living connecting systems that don’t want to be connected.

Customers orbit furthest from the center, subject to forces they don’t control. Pricing changes ripple outward without negotiation. Feature deprecation happens on vendor timelines. Data portability remains theoretical. Switching costs compound over time.

The Math Has Inverted

Something fundamental shifted in 2024, and most CTOs haven’t fully processed it yet.

AI-assisted development didn’t eliminate the need for engineering judgment. It did reduce the cost of execution. Translation from intent to code is faster. Iteration cycles are shorter. Large codebases are more legible to machines than to humans. Routine refactoring and dependency management can be automated.

According to McKinsey’s State of AI 2024 report, 65% of organizations now regularly use generative AI in at least one business function, nearly double the percentage from the previous year. And software engineering is one of the top functions where organizations are applying these tools. Research from Microsoft, MIT, and Wharton showed developers using AI coding assistants achieved a 26% increase in productivity. GitHub’s own studies found developers completed tasks 55% faster with AI assistance.

What does this mean in practical terms? The breakeven calculation for custom software has collapsed.

Consider a typical scenario. A team of 50 using a specialized SaaS tool at $50 per seat per month pays $30,000 annually for the privilege of adapting their workflows to someone else’s product decisions. That’s before integration costs, before the consulting fees to customize it, before the productivity losses from features that don’t quite fit.

With AI-assisted development, a purpose-built alternative can now be synthesized in days, not months. The ongoing maintenance that once required dedicated engineering teams can be largely automated through continuous testing, dependency monitoring, and AI-assisted refactoring.

The historical objection, “custom software rots,” assumed maintenance was manual. It assumed you needed humans who understood the system to patch vulnerabilities and update dependencies. That assumption has dissolved.

What I’m Calling Made as a Service

I’ve started using the term “Made as a Service” to describe what’s emerging. MaaS replaces software rental with software stewardship. Customers subscribe not to a static product, but to an ongoing capability: software continuously synthesized, governed, and evolved to match their exact workflows, deployed into infrastructure they control, with full ownership of data and logic.

This isn’t the old “bespoke development” model rebranded. The difference lies in three critical areas.

First, shared foundations. Common logic like authentication, billing, compliance, and audit trails is reused across clients. The wheel isn’t reinvented.

Second, unique orchestration. Workflow logic and interfaces are custom, not templated. The surface is shaped to fit.

Third, continuous stewardship. Evolution is included, not renegotiated. The relationship persists.

Consider one example documented by a Swiss digital consulting firm: an industrial group with 500 users across three subsidiaries opted for a custom solution to centralize quality processes. The initial project cost 600,000 CHF in capital expenditure, followed by 40,000 CHF annually for maintenance. The SaaS alternative would have billed 120 CHF per user per month, totaling nearly 2,160,000 CHF over five years. Beyond the financial gain (total cost of ownership reduced by 70%), the group integrated its own continuous analysis algorithms, boosting quality performance by 15%.

This pattern is emerging across industries. One software development firm reports that a logistics client started with a well-known SaaS tracking tool. After 18 months, they had spent over $40,000 and were still manually exporting data to patch things together. A custom dashboard paid for itself in 14 months and continues to scale with their needs without a rising monthly bill.

The Security Argument Flips

One of the strongest objections to custom software has always been security. “Shared SaaS platforms have dedicated security teams. You can’t match that.”

The argument made sense until the supply chain attacks started.

Shared SaaS platforms create shared blast radius. Every supply chain attack on a major vendor reminds us: millions of customers exposed simultaneously. The Log4j vulnerability. The SolarWinds compromise. The endless parade of breaches at companies whose entire value proposition was handling data securely.

MaaS isolates risk. Smaller attack surfaces. No cross-tenant exposure. Auditable code paths. Explicit threat models. Security improves when responsibility is explicit, not abstracted.

This matters enormously for regulated industries. Healthcare, finance, and government organizations often find compliance is easier to achieve with software designed for specific regulatory requirements than with generic platforms jury-rigged for regulated environments.

Where SaaS Still Wins

I want to be clear about something. SaaS will not disappear. Its domain contracts to areas where structural advantages remain.

Commodity utilities like email, basic document editing, and video conferencing are genuinely universal with no competitive differentiation. Buy these.

Network-effect platforms like LinkedIn, Slack (for cross-company communication), and marketplaces derive their value from the people, not the code. The value is in the network.

Heavy compute applications requiring massive proprietary infrastructure belong in SaaS. Video rendering, large-scale simulation, frontier AI training. These demand infrastructure investment that makes no sense to replicate.

Everything else is vulnerable.

The question to ask yourself: Does this software create competitive differentiation, or is it a commodity? If your company’s secret sauce lives in how you do things differently, forcing those processes into generic SaaS means diluting the very thing that makes you valuable.

The Path Forward

If you’re a CTO looking at this shift, the question isn’t whether to abandon SaaS entirely. That would be foolish. The question is where to start reclaiming sovereignty.

Look at your highest-friction SaaS tools first. The ones requiring the most customization, the most integration work, the most workarounds. Calculate the true total cost of ownership over five years: subscription fees plus integration plus administration plus training plus the productivity losses from workflows that don’t quite fit.

Then ask: could a purpose-built alternative be synthesized for less than this total cost? With AI-assisted development timelines, the answer is increasingly yes for any domain where workflows materially differ across organizations, competitive advantage lives in process, data context matters for AI systems, or integration overhead dominates subscription cost.

The shift from renting software to owning it is not ideological. It is economical. The math has changed. The only question is how long before your organization catches up.

I’ve written a fuller exploration of this transition in what I’m calling “The MaaS Manifesto.” If you want to go deeper on the economics, the technical architecture, and the strategic implications for your organization, you can find it at etiennex.com.

The era of rental is giving way to the era of stewardship. SaaS was software for everyone. MaaS is software made for you.

The transition has begun.

Marcus runs engineering for a fintech company. He has an executive assistant. He also reviews every calendar invitation she sends, rewrites half her emails, and spends Sunday nights reorganizing his week because he doesn’t trust anyone else to get it right. He tells me he’s exhausted. He tells me his EA “helps a little.”

Sarah leads a 60-person engineering org. When I ask about her EA, she tells me about the project coordinator she shares with two other directors. This person schedules her meetings and sometimes books her travel. Sarah still manages her own inbox, still tracks her own action items, still spends four hours every weekend preparing for the week ahead. She doesn’t have an EA. She has occasional administrative support.

David automated everything. Calendly for scheduling. Zapier for workflow triggers. Notion databases for tracking. Superhuman for email. He spent eight months building the perfect productivity system. He still works 65-hour weeks because software can’t call his CEO’s assistant to negotiate a better meeting time, can’t sense when he needs a buffer day after a board presentation, can’t tell him that the vendor demo he agreed to is a waste of time based on a conversation she had with his head of infrastructure.

Three CTOs. Three versions of the same problem. None of them have what they actually need going into 2026.

The Partnership You’ve Never Experienced

Here’s what I want for every CTO I coach in the coming year: a real executive assistant partnership.

Not a task executor. Not a calendar manager. Not a shared resource. A professional whose entire purpose is making your week work.

I know your brain just went to automation. Mine did too, for years. We’re CTOs. We solve problems with systems. When something is inefficient, we build a better process. When something is repetitive, we script it away.

But here’s what I’ve learned from coaching hundreds of technology leaders: the time problem isn’t a systems problem. It’s a judgment problem. It’s an anticipation problem. It’s a “someone needs to protect you from yourself” problem.

Software doesn’t have judgment. Software can’t look at your calendar and realize that back-to-back-to-back meetings on Thursday will leave you worthless for the board prep you need to do Friday morning. Software can’t tell your product lead that no, you’re not available for a “quick sync” because she knows you’ve been in reactive mode all week and need deep work time. Software can’t read the room.

A skilled EA can.

Why Most CTO-EA Relationships Fail

I’ve watched this pattern play out dozens of times. A CTO hires an EA, gives them tasks, wonders why they still feel overwhelmed, and eventually concludes that having an EA “isn’t worth it” for their working style.

The relationship fails. The CTO goes back to doing everything themselves or automates what they can. Another EA gets hired eighteen months later. The cycle repeats.

I coached a CTO last year who had been through four EAs in three years. Four. He was convinced the problem was finding the “right fit.” During our sessions, I started asking questions about how he worked with each of them.

He approved every expense before they could submit it. He wanted to see every email before it went out under his name. He provided detailed instructions for tasks and then revised the output because it wasn’t quite how he would have done it. He kept his own calendar “just in case” and often scheduled meetings directly, creating conflicts his EA would have to untangle.

He didn’t have an EA relationship. He had a very expensive mirror.

The warning signs are consistent across almost every failed EA partnership I’ve seen:

You review everything. If you’re checking every calendar invitation, every email draft, every expense report, you’re not delegating. You’re creating a approval bottleneck with extra steps.

You provide solutions, not outcomes. There’s a difference between “I need you to call the Marriott and book the corner room on the third floor” and “I need a quiet room for focused work during the conference.” The first is task execution. The second allows for judgment.

You feel the need to explain every decision they’ve made. When your EA moves a meeting, do you ask why? When they decline something on your behalf, do you need a debrief? That’s not partnership. That’s surveillance.

Your EA asks permission for everything. This one cuts both ways. If they’re asking before every action, either you’ve trained them to be afraid of your reaction, or they don’t have the context to make decisions. Both are your responsibility to fix.

You secretly keep your own systems. A shadow calendar. A private task list. A personal inbox triage. If you’re duplicating their work “just to be safe,” you’ve signaled that you don’t trust the partnership.

The Joy You’re Missing

I want to talk about something that doesn’t get discussed enough: the joy of this partnership when it works.

There’s a CTO I’ve been coaching for two years. When she first came to me, she was classic startup-scale burnout. Sixty-plus hours a week, constantly in reactive mode, couldn’t remember the last time she had a week that felt like her own.

Six months into our work together, she hired an EA. Not a part-time admin. A professional who had supported C-suite executives for fifteen years.

The first three months were rough. She fought every instinct to control. She bit her tongue when meetings got rescheduled without her input. She felt anxious not knowing exactly what was on her calendar until she looked at it in the morning.

And then something shifted.

She told me about a Thursday when she walked into the office and realized she had two hours blocked for thinking. She hadn’t asked for it. Her EA had noticed the pattern—noticed that she was sharper in meetings when she had prep time, noticed that her Thursdays had become a gauntlet of back-to-backs, and made a decision.

She told me about a conference where her EA had booked her a hotel room on a different floor from the rest of her team. She was initially annoyed until she realized it meant she could actually rest between sessions instead of fielding hallway conversations.

She told me about the vendor meeting that never happened. A sales pitch her EA declined on her behalf because “it didn’t align with your current priorities.” The vendor had gone around her EA to email her directly. Her EA intercepted it, responded professionally, and she never had to spend a calorie on it.

She told me about something else too. Something that surprised her. She started using her EA as a sounding board before difficult conversations. A quick five minutes to vent about a frustrating product decision before walking into the executive meeting. A chance to process her irritation about a missed deadline before her 1:1 with the engineering manager responsible. Her EA became the person who absorbed the emotional weight so she could walk into rooms clear-headed.

And there’s a simpler joy too. The relief of saying “I need Friday afternoon free” and having that be someone else’s problem to solve. Not your problem. Not a puzzle you have to untangle between meetings. Just a statement of what you need, handed off to someone whose job is to make it happen.

That’s not task management. That’s someone thinking about her week more strategically than she has time to think about it herself.

That’s joy.

The Rules of Engagement

If you’ve never had a real EA partnership, there are things you need to understand going in.

The math works in your favor. Dan Martell, in his book Buy Back Your Time, offers a simple formula: take your annual income, divide by 2,000 working hours to get your effective hourly rate, then divide by four. That’s your “Buyback Rate”—the threshold below which you should be paying someone else to do the work. If you’re a CTO earning $400,000, your effective rate is $200/hour. Your buyback rate is $50/hour. Every hour a skilled EA works on your behalf at $75/hour creates $125 in recovered value.

Now think about what that means for you specifically. Every hour you spend on calendar management, expense reports, travel logistics, or inbox triage is an hour you’re not spending on technical strategy, coaching your engineering leaders, aligning with your CEO on product direction, or recruiting that senior architect you desperately need. The EA doesn’t just give you time back. They give you back the right time, the hours you should be spending on the work that only you can do.

You are hiring judgment, not labor. A professional EA isn’t expensive because they can manage calendars. They’re expensive because they can anticipate, prioritize, and protect. You’re paying for the meeting that never got scheduled, the email you never had to write, the decision you never had to make.

Decisions will be made that you don’t understand. This is the hardest part for CTOs. We like to understand systems. We like to know why things work the way they work. In a real EA partnership, you have to accept that sometimes a meeting moves and you don’t know why, and that’s okay. You hired judgment. Let it work.

You cannot control the outcome. If you’re specifying exactly how every task should be done, you’re not getting the value of partnership. You’re getting task execution at partnership prices. Define outcomes. Define boundaries. Then get out of the way.

It takes longer than you think. A real EA partnership takes 6-12 months to mature. The first 90 days are about building context. The next 90 are about building trust. After that, you start to see the leverage. If you’re evaluating at 60 days, you’re measuring the wrong thing.

This is not a part-time job. I cannot stress this enough. A shared admin resource, a project coordinator who “also does EA stuff,” a part-time contractor who manages your calendar—these are not EA partnerships. They might be useful. They are not the same thing. A professional EA needs to be in your context full-time to build the judgment that makes the partnership valuable.

Your 2026 Resolution

Going into the new year, I want you to consider that you might be the reason you don’t have the support you need.

Not because you’re bad at your job. Because you’re too good at it. You’ve survived this long by being the person who handles everything, knows everything, controls everything. That’s how you got here.

It’s also what’s keeping you stuck.

According to a ServiceNow State of Work report, executives spend an average of 16 hours per week on manual administrative work. The equivalent of two full days every week. A Unit4 study across 11 countries found that office workers lose roughly one-third of their working year to administrative and repetitive tasks. That’s 69 work days annually, gone. And research consistently shows that a skilled EA can reclaim 15-20% of an executive’s working hours.

But “skilled EA” is doing a lot of work in that sentence. Most executives don’t have one.

So here’s what I want you to do.

Start by asking yourself an honest question: do you actually want a partner, or do you want an assistant? If the answer is assistant, someone to execute tasks you’ve defined, fine. But stop wondering why you’re still exhausted.

If you want a partner, start with trust. Not trust that’s earned over months of proving competence. Trust that’s given because you’ve decided to give it. Trust that says “I’m hiring you to make decisions about my time, and I’m going to let you make them.”

Find someone who has done this before. A professional EA is not an entry-level role. You want someone who has supported executives, who understands the pace and complexity of C-suite life, who has developed the judgment to know when to protect you and when to push back.

Then give it time. Real time. Not 60 days. Not 90 days. At least six months before you evaluate whether the partnership is working.

And when they make a decision you don’t understand, resist the urge to ask why. Resist the urge to “provide feedback.” Just notice. Notice whether your week worked. Notice whether you had the time you needed. Notice whether you felt protected.

Because that’s what a real EA partnership gives you. Not just time. Protection. Anticipation. Someone whose entire professional purpose is making your week work so you can make your company work.

That’s my wish for you in 2026. Not another productivity system. Not another automation tool. A partner.

I know many brilliant EAs—professionals who have transformed the working lives of the CTOs I coach. If you want help finding your perfect match, send me an email at etienne@7ctos.com.

It might be the most important introduction I ever make.

“Walk me through what happened in your last planning meeting,” I say.

The CTO exhales. “The CEO presented the annual target. $23 million in revenue. Everyone nodded. Then she asked for the plan to get there, and the room just... fragmented.”

He describes the scene. The COO wanted more aggressive outbound. Sales wanted better product differentiation. Marketing wanted to double down on content. Finance wanted operational efficiency. Every suggestion reasonable. None of them connected.

“And where did that leave you?” I ask.

“Nowhere. I still don’t know what to build. Every feature request feels equally important because we never decided what actually matters.”

I turn to the whiteboard and write a single question: How much of that $23 million do you already have locked in?

The CFO in the room pulls up a spreadsheet on her laptop. Contracted renewals. High-probability deals. After ten minutes of calculation, we have an answer: $17 million is essentially guaranteed. Another $3 million is probable from the existing pipeline.

“So you’re not solving for $23 million,” I say. “You’re solving for a $3 million gap.”

I watch the tension in the room shift. A $23 million target feels abstract, almost oppressive. A $3 million gap feels like a problem with a solution.

Over the next two hours, I facilitate a conversation that transforms their revenue target into three specific business objectives. By the end, the CTO finally has what he needs: clarity on what the company is betting on, what they’re deliberately not pursuing, and how his technology organization will drive the outcomes.

This is the work that separates CTOs who are seen as cost centers from CTOs who are seen as strategic partners. And it’s the work that has to happen before you can build a technology roadmap that means anything.

The Translation Problem

Revenue targets are not business objectives. A target like “grow revenue by 20%” tells you where to go, but not how to get there. Business objectives are the strategic bets your company makes to reach that destination.

Most C-Suites skip this translation step entirely. They hand technology teams a financial target and expect magic. The consequences cascade through the organization: initiatives multiply without prioritization, resources spread thin across competing interpretations of “what matters,” and year-end retrospectives devolve into debates about what “success” even meant.

A 2023 study by Bridges Business Consultancy found that 67% of well-formulated strategies fail due to poor execution. But the problem often starts earlier. You can’t execute a strategy that was never translated into actionable objectives in the first place.

The CTO sits at a unique intersection. Deep visibility into technical capabilities. Understanding of business constraints. Access to data that reveals customer behavior, system performance, and operational bottlenecks. This position makes the CTO the natural facilitator for the conversation that transforms targets into objectives.

Five Levers, Not Fifty Ideas

Every revenue target is achieved through one or more of five fundamental levers. Understanding these levers is the first act of strategic discipline.

Acquire — Bring in new customers who weren’t buying before. Land new logos. Enter new segments.

Retain — Keep existing customers from leaving. Reduce churn. Increase renewal rates.

Expand — Grow revenue from existing customers through upsells, cross-sells, and increased usage.

Price — Increase pricing on existing offerings. Capture more value from what you already deliver.

Enter — Access new markets, whether geographic, vertical, or product-based.

Most companies cannot effectively pursue more than two or three of these levers simultaneously. If your executive team claims all five are priorities, you don’t have a strategy. You have a wish list.

In that CTO Compass session, we identified the primary lever as Expand (grow existing accounts) and the secondary lever as Acquire (new enterprise logos). The constraint of an EBITDA target meant they couldn’t just throw resources at growth. They needed efficiency improvements alongside revenue expansion.

This clarity eliminated dozens of potential initiatives before we even started discussing them. The CTO visibly relaxed. For the first time in months, he could see a path forward.

The Five-Phase Facilitation Process

Here’s the process I use to guide C-Suite conversations from revenue targets to actionable objectives. Each phase builds on the previous one, and skipping phases leads to objectives that fall apart under scrutiny.

Phase 1: Establish the Gap

Before discussing strategy, everyone must understand the mathematical reality. This grounds the conversation in facts rather than aspirations.

Ask these questions:

• What is our current run rate, and what does the target require?

• What revenue do we have locked in through contracts or high-probability renewals?

• What’s our current pipeline, and how much is realistic to close?

• What gap remains after accounting for the probable?

In our session, the target was $23 million. Contracted revenue was $17 million. Probable pipeline was $3 million. The actual problem we needed to solve was a $3 million gap. This reframing made the impossible feel achievable.

Phase 2: Identify the Levers

With the gap defined, determine which revenue levers offer the best opportunity to close it.

Ask these questions:

• Of the five levers, which one or two represent our best opportunities this year?

• Where are we currently strongest? Where are we leaving money on the table?

• What did we try last year, and what worked?

• What constraints eliminate certain levers from consideration?

Watch for warning signs. If no one can articulate why one lever is better than another, you need more data. If the chosen levers change every meeting, you have an alignment problem, not a strategy problem.

Phase 3: Surface the Obstacles

If pulling a lever were easy, you’d already be doing it. Understanding what’s blocking progress reveals where objectives must focus.

Ask these questions:

• If this lever is so promising, why aren’t we already pulling it harder?

• What would have to be true for us to succeed with this lever?

• What are we missing—capabilities, resources, information, alignment?

• Where do deals get stuck? Where do customers leave? Where does value leak?

For the Expand lever in our session, the obstacles were clear: existing customers didn’t know about add-on products, account management was reactive rather than proactive, and there was no visibility into usage patterns that indicated expansion readiness.

For the Acquire lever: long sales cycles, extensive custom implementation requirements, and a small sales team.

These obstacles pointed directly to where the objectives needed to focus.

Phase 4: Formulate the Objectives

Now synthesize the lever choice and obstacle analysis into three clear business objectives. Each objective should be specific enough to guide action but broad enough to allow creative solutions.

Use this formula: [Action verb] + [Specific outcome] + [For whom/what] + [Measurable target]

Compare these:

• Weak: “Grow revenue”

• Better: “Acquire new customers”

• Best: “Land 10 new enterprise healthcare accounts representing $500K in annual recurring revenue”

Why three objectives? Research on cognitive load and organizational behavior consistently shows that more than three strategic priorities creates dilution rather than ambition. Three objectives allow for depth of execution while maintaining strategic coherence. Richard Rumelt’s work on strategy in “Good Strategy Bad Strategy” emphasizes that focus is the essence of strategy—spreading attention across too many objectives guarantees mediocrity in all of them.

The three objectives from our session became:

1. Increase platform seat count within existing accounts by 30%, generating $3M in expansion revenue

2. Land 5 new enterprise accounts representing an additional $3M in first-year revenue

3. Reduce services delivery cost by 20% through productization and automation

Phase 5: Validate and Commit

Before finalizing objectives, stress-test them against reality.

Ask these questions:

• If we accomplish these three objectives, will we hit our revenue target?

• Do we have—or can we acquire—the resources to pursue all three?

• Are these objectives within our control, or dependent on external factors?

• Can we measure progress monthly or quarterly?

• Is everyone in this room willing to make trade-offs to achieve these?

The commitment step is operational, not ceremonial. Document the objectives, the owners, and the timeline. Make explicit what will NOT be pursued as a consequence of these choices.

Earning the Right to Facilitate

I can already hear the objection: “This assumes I have permission to lead this conversation.”

Fair. Many CTOs weren’t hired to run strategy sessions. They were hired to ship software. Walking into a planning meeting and asking “How much of that $23 million do we have locked in?” could land as presumptuous. Out of lane. The CEO views strategy as their domain. The CTO’s job is to execute.

If that’s your situation, you don’t start by facilitating the whole C-Suite. You start smaller.

Start with the problem, not the process. Go to your CEO with the symptom: “I’m getting conflicting priorities from different stakeholders, and I need help understanding which initiatives actually matter for hitting our number.” You’re not claiming strategic authority. You’re asking for clarity so you can do your job.

Bring data as your entry point. The CTO has access to information no one else sees. Customer usage patterns. Feature adoption rates. Support ticket trends. Churn indicators. When you surface an insight like “Customers who complete onboarding within 48 hours retain at 3x the rate,” you’ve earned a seat in the strategy conversation because you brought something valuable.

Propose a working session, not a takeover. Instead of announcing that you’ll facilitate quarterly planning, suggest: “Would it help if I pulled together some data and we spent an hour pressure-testing our assumptions about next year?” Frame yourself as a resource, not a rival.

Document what you hear. After any planning conversation, send a follow-up: “Here’s what I understood our three priorities to be. Am I tracking this correctly?” If no one corrects you, you’ve just created the clarity that didn’t exist before. If they do correct you, you’ve surfaced a disagreement that needed surfacing.

The goal isn’t to seize control of strategy. The goal is to be so useful in clarifying strategy that people start expecting you in the room.

When the Room Won’t Align

The five-phase process reads as linear and rational. Real C-Suites are not.

Executive teams are full of competing agendas, protected budgets, and information people aren’t sharing. What happens when the CFO and Head of Sales fundamentally disagree on which lever to pull? What happens when the CEO has already made up their mind and this “facilitation” is theater? What happens when someone in the room is actively working against alignment because clarity threatens their position?

Name the disagreement explicitly. When two executives are advocating for different levers, don’t let the conversation drift. Say: “It sounds like we have two different hypotheses here. Sarah thinks retention is our best opportunity. James thinks acquisition is. Can we look at the data that would tell us which is right?” Force the debate into the open where it can be resolved, rather than letting it fester as passive resistance.

Identify who owns the decision. Not every strategic choice is democratic. Sometimes the CEO decides, full stop. If that’s the case, your job shifts from facilitating consensus to ensuring the CEO has the information needed to decide well. “I want to make sure you have visibility into the technical implications of each path before you choose.”

Watch for the pocket veto. Some executives agree in the room and undermine in the hallway. The best defense is specificity. Vague objectives are easy to reinterpret. “Grow the customer base” can mean anything. “Land 5 new enterprise accounts representing $3M in first-year revenue” is harder to quietly redirect. The more specific the objective, the harder it is to claim you’re pursuing it while actually doing something else.

Accept that perfect alignment is rare. Your goal isn’t unanimous enthusiasm. Your goal is enough clarity that you can build a roadmap and defend your prioritization decisions. If the Head of Sales is still grumbling about not getting their pet feature, that’s fine—as long as the CEO has committed to the objectives and you have that commitment in writing.

When Q2 Blows Up Your Plan

Even if you get three perfect objectives defined and committed, business conditions shift. A key customer churns. A competitor launches something unexpected. The board changes their mind. Six weeks later, the CEO walks in and says “we’re pivoting.”

This is not a failure of the process. This is reality. The question is whether you have a foundation to work from when things change.

Objectives are more stable than tactics. When conditions shift, the first question is: “Do our objectives still hold, or do the objectives themselves need to change?” Often, the objectives remain valid even when the actions underneath them need adjustment. “Land 5 new enterprise accounts” might still be the right objective even if your original approach isn’t working. The pivot is in how you pursue the objective, not whether you pursue it.

Re-run the gap analysis. If a major customer churns or a big deal falls through, the math has changed. Go back to Phase 1. What’s the new gap? Does the size of the gap change which levers make sense? A 15-minute recalculation can prevent months of misdirected effort.

Protect the process, not the plan. The value of this framework isn’t that it produces a perfect plan. The value is that it gives you a shared language for adapting when things change. When the CEO says “we need to pivot,” you can respond: “Okay, let’s revisit our gap calculation and see which lever gives us the best shot at closing it now.” You’re not starting from scratch. You’re updating the model.

Document the change. When objectives shift mid-year, write it down. “As of June 1, we’re deprioritizing Objective 2 and reallocating resources to Objective 1 because of X.” This protects you at year-end when someone asks why you didn’t deliver on the original plan. It also forces the decision-makers to own the pivot rather than pretending it never happened.

The companies that struggle most aren’t the ones that have to adapt. They’re the ones that never had clarity in the first place, so every shift feels like chaos rather than a recalibration.

Why the CTO Leads This Conversation

The CTO brings four capabilities to this facilitation that no one else in the room possesses.

Data visibility. The CTO sees patterns others miss: user behavior analytics, system performance metrics, support ticket trends, feature adoption rates. In our session, the CTO knew that customers who completed onboarding within 48 hours had 3x the retention rate. That data point shaped which obstacles we prioritized.

Possibility awareness. The CTO knows what technology can enable. While others debate strategy in the abstract, the CTO can inject feasibility and timeline reality. “We could launch a free tier within 8 weeks, but European localization would take two quarters. That changes which objectives are achievable this year.”

Constraint transparency. The CTO understands technical debt, infrastructure limitations, and team capacity in ways that affect what’s realistic. Their payment infrastructure didn’t support the pricing model someone proposed. Knowing that constraint saved them from committing to an objective they couldn’t deliver.

Translation capability. The CTO bridges business intent and technical execution. Well-formed objectives emerge from the ability to translate business language into actionable terms and back again.

From Objectives to Actions

Once the three objectives were defined, the CTO could finally do what he’d been trying to do for three months: build a technology roadmap that connected to business outcomes.

Each objective spawned specific actions. Objective 1 (expansion revenue) required implementing customer health scoring, building an expansion recommendation engine, ensuring usage data privacy compliance, and creating an account manager enablement dashboard.

Objective 2 (new enterprise accounts) required accelerating implementation timelines, developing self-service onboarding, completing SOC 2 certification, and building an interactive demo environment.

Objective 3 (services efficiency) required automating data integration workflows, developing reusable configuration templates, documenting proprietary methods, and creating a services-to-platform migration path.

Without clear objectives, a technology roadmap is just a list of features someone asked for. With clear objectives, every item on that roadmap has a reason to exist and a way to measure its impact.

Your Next Planning Conversation

Before the meeting, prepare the math. Calculate the gap between current state and target. Pull relevant analytics on customer behavior, feature adoption, and churn patterns. Have informal conversations with key executives to understand their perspectives. Come with potential objectives to react to, not a blank slate.

During the meeting, start with agreement on the numbers. Use the whiteboard to make thinking visible. Draw the gap, the levers, the obstacles, the objectives. Name the trade-offs explicitly: “If we pursue X, we’re choosing not to pursue Y. Are we aligned on that?”

Inject technical reality gently. “That’s achievable if...” works better than “We can’t do that.” Summarize relentlessly: “So what I’m hearing is... Is that right?”

After the meeting, document the objectives in writing within 24 hours. Circulate for confirmation. Begin translating objectives into specific technology actions. Schedule the first progress check-in.

The first time you facilitate this conversation successfully, you’ll feel the shift in how your C-Suite perceives you. You’re no longer the person who explains why things take so long. You’re the person who helped the company figure out what actually matters.

Revenue targets are destinations. Business objectives are the strategic bets that get you there. The CTO who masters this translation becomes indispensable.

Learn This Framework in Depth

If you want to experience this process firsthand and learn how to facilitate these conversations with your own C-Suite, join us at the next CTO Compass workshop. We work through real scenarios, practice the facilitation techniques, and build the artifacts you’ll take back to your organization.

Register at ctocompass.com/7ctos

What business objectives is your company betting on this year? If you can’t name three, you have work to do before your next planning session.

The reasoning sounds compelling enough. More flexibility. Better control over costs. No more dependency on third-party platforms. They’ve done the math on paper and the numbers look promising. I can see the enthusiasm spreading across the table like a contagion.

And I open my mouth and say, “That’s a dumb idea.”

I elaborate. Why would we spend eighteen months and millions of dollars rebuilding a platform that has been built over and over again by companies with far more resources than us? Amazon, Akamai, Cloudflare. They’ve poured billions into solving this exact problem. Our competitive advantage isn’t in content distribution. It’s in the product itself. And the product has deficits. Real deficits that customers are complaining about. Deficits that are costing us renewals.

I’m making perfect sense. I’m technically correct. I can see it in their eyes that they know I’m right.

They fire me a few weeks later.

The Chief Translation Officer

I’ve spent years thinking about that meeting. Not because I was wrong. I wasn’t. The company eventually abandoned the CDN project after spending significant resources on it. But I’ve come to understand something that would have saved my job and served my company far better: the CTO’s primary function is not to be right. It’s to translate.

Translate business objectives into technology action. Translate technology progress back to the C-Suite. Translate complexity into clarity. Translate technical reality into business language.

I wasn’t a Chief Technology Officer in that meeting. I was a Chief Correction Officer. And no one wants to be corrected, especially not by someone who reports to them.

According to research from Netskope’s 2024 report “Crucial Conversations,” 39% of CIOs say they are misaligned with their CEO on key decision-making. More troubling, 34% of CIOs report they do not feel empowered to make long-term strategic calls. And 31% are not confident they know what their CEO really wants.

These numbers don’t describe a technical problem. They describe a translation problem.

The 28-Point Collapse

Capgemini has been measuring business-IT alignment for over a decade. In 2012, 65% of senior executives believed business and IT leaders agreed on IT’s role within the organization. By 2024, that number had plummeted to just 37%.

A 28-point collapse in alignment over twelve years.

This collapse happened while organizations poured trillions into technology investments. It happened while “digital transformation” became mandatory vocabulary in every boardroom. It happened while every company claimed that technology was central to their competitive advantage.

The investment went up. The alignment went down.

Why? Because technology leaders kept speaking technology language to business audiences. We kept producing status reports that no one read. We kept explaining complexity instead of showing progress. We kept being technically correct while being strategically invisible.

Showing Complex Work Simply

After years of wrestling with this translation problem, both in my own career and coaching hundreds of CTOs through 7CTOs, I developed what I call the CTO Compass. It’s built on a simple premise: visual indicators work better than text-heavy reports.

The framework uses four domains we call CTO Sentinel: Speed (delivery velocity), Stretch (future capabilities), Shield (organizational protection), and Sales (cross-functional enablement). Every technology initiative maps against all four.

But the real power isn’t in the categories. It’s in the colors.

Green means on track. Yellow means caution. Red means roadblock. Blue means complete.

One glance tells the entire story. No lengthy explanations required. No translation needed. The CEO looks at the grid and understands immediately where things stand.

When I think back to that 2018 meeting, I realize I had no visual language to share. I had opinions. I had arguments. I had technical correctness. But I had no way to show my executives the landscape of technology decisions in a format they could grasp instantly.

If I had been able to show them a grid, here’s where we’re green, here’s where we’re yellow, here’s the red that will turn green if we focus resources here instead of building a CDN, the conversation would have been entirely different.

Transparency Builds Trust

Peter Yared, former CIO/CTO at CBS Interactive, observes: “There’s always been a lack of transparency in IT. As costs start to creep up, that creates a lot of dissatisfaction and then people don’t spend what they should. A lot of this can get fixed with greater transparency.”

The CTO Compass philosophy holds that transparency builds trust. Yellow and red statuses aren’t failures—they’re demonstrations of proactive leadership. They show executives that you see the problems before they become crises. They invite conversation rather than shutting it down.

When I called my CEO’s idea “dumb,” I shut down conversation. I created an adversary instead of a partner. I demonstrated my intelligence while destroying my influence.

A visual framework changes the dynamic entirely. Instead of “your idea is dumb,” it becomes “let me show you how this initiative would affect our other priorities.” Instead of correction, it becomes exploration. Instead of winning an argument, it becomes building understanding.

The Standish Group found that organizations with “high decision latency”, meaning slow, uncertain decisions due to poor strategic alignment, achieve only an 18% project success rate. Organizations where teams understand why their work matters hit 63%.

That 45-percentage-point gap isn’t about technical capability. It’s about shared understanding. It’s about translation.

The Grid That Could Have Saved My Job

Looking back at 2018 with what I know now, I can see exactly what I should have done.

I should have mapped the CDN initiative against the four Sentinels. Under Speed: eighteen months of development before any value delivery. Under Stretch: new capabilities our team would need to build and maintain indefinitely. Under Shield: security and compliance requirements for handling video distribution at scale. Under Sales: zero customer-facing benefit until completion, while existing product deficits continued costing renewals.

Then I should have shown the alternative. Focus those same resources on product improvements. Under Speed: incremental value delivery starting in weeks. Under Stretch: building on existing capabilities. Under Shield: addressing known vulnerabilities in current systems. Under Sales: immediate impact on customer satisfaction and retention.

Same technical analysis. Completely different presentation. Visual. Comparative. Inviting discussion rather than demanding agreement.

Would they have made a different decision? Maybe. Maybe not. But I wouldn’t have been fired for the way I communicated. And I would have built trust for the next difficult conversation instead of destroying it.

The Flight Risk

Russell Reynolds Associates found that 74% of technology officers expressed interest in making a career move in the second half of 2024, up dramatically from 50% in 2022.

Three quarters of technology leaders are looking to leave their positions. The research attributes this to “the growing gap between ambition and organizational readiness.” Technology leaders feel confident leading transformation but face internal barriers including limited cross-functional support and unclear or shifting mandates.

Technology leaders aren’t leaving because they can’t do the work. They’re leaving because they can’t get their organizations to understand the work. They’re leaving because translation has failed.

The CTO Compass addresses this directly. When you can show complex work simplylike when executives can glance at a grid and understand progress, challenges, and dependencies, the gap between ambition and readiness starts to close. You’re no longer fighting for understanding. You’re building it, visually, every month.

Your Monday Morning

If you’re a CTO who has ever been technically correct but strategically ignored, you know the frustration I felt in 2018. You know the helplessness of watching bad decisions get made while your expertise goes unheard.

The answer isn’t to argue more forcefully. It isn’t to produce longer reports or more detailed analyses. The answer is to translate—to show complex work simply, to use visual language that creates immediate comprehension, to build trust through transparency rather than eroding it through confrontation.

I’m running a CTO Compass workshop in January where I’ll walk through exactly how to build this translation capability. How to map your initiatives against the four Sentinels. How to use color-coding to create instant understanding. How to turn your next executive update from a status report into a strategic conversation.

You can register at ctocompass.com/7ctos

I lost my job in 2018 because I confused being right with being understood. They’re not the same thing. They never have been. And the sooner you build the translation skills to bridge that gap, the more valuable you become.

Not just as a technologist, but as a leader.

“This should take, what, two sprints?” the PM suggests optimistically.

My lead engineer’s coffee mug pauses halfway to his mouth. “Try two quarters,” he mutters, just loud enough for everyone to hear.

The zoom call descends into chaos. Product accuses engineering of sandbagging. Engineering accuses product of living in fantasy land. I’m caught in the middle, watching months of carefully built trust evaporate in real-time. We’re supposed to be one team, building one product, but we might as well be speaking Klingon and Elvish to each other.

The meeting ends with nothing resolved. The PM no doubt headed to “escalate matters to the CEO.” My engineers retreat to Slack to vent about “impossible requirements.” And I’m left staring at an empty zoom call, wondering how we got here.

Three months later, this same team is shipping features faster than ever, with product and engineering finishing each other’s sentences. The transformation didn’t come from better project management tools or more detailed specs. It came from stealing a design framework that most CTOs have never heard of—the Double Diamond.

Author’s note: I do want to thank Allan Stewart for introducing me to this concept.

The Core Idea

The Double Diamond isn’t just a design process—it’s a universal framework for navigating complexity that transforms how CTOs orchestrate the dance between discovery and delivery, between possibility and pragmatism.

Two Diamonds Are Better Than One Waterfall

The Double Diamond was popularized by the British Design Council in 2005, adapted from the divergence-convergence model proposed in 1996 by Hungarian-American linguist Béla H. Bánáthy. The framework splits problem-solving into four distinct phases: Discover, Define, Develop, and Deliver. Two diamonds, each representing a cycle of divergent thinking (exploring possibilities) followed by convergent thinking (making decisions).

Most CTOs know this pattern intimately, even if they’ve never seen it drawn. We diverge when we explore different architectures. We converge when we choose our tech stack. We diverge when we investigate performance bottlenecks. We converge when we implement the fix.

But something magical happens when you make this implicit pattern explicit and apply it to the product-engineering divide.

According to the Design Management Institute, design-driven companies outperformed the S&P 500 by 219% over a 10-year period from 2004-2014. Yet most CTOs treat design frameworks as “product team stuff,” missing the profound implications for technical leadership.

The first diamond (Discover → Define) is about understanding the right problem. The second diamond (Develop → Deliver) is about building the right solution. Simple concept. Revolutionary application.

The Problem Diamond: Where CTOs Usually Fail

Most CTOs jump straight to the second diamond. We’re solution machines. Give us a problem, and we’ll architect an answer before you finish explaining the question. It’s our superpower and our kryptonite.

In my case, every product-engineering clash traced back to the same root cause: we were skipping the first diamond entirely. Product would show up with solutions (wireframes, specs, user stories), and engineering would immediately start solutioning on top of their solutions. We were trying to converge without ever diverging.

The Discover phase isn’t about gathering requirements. It is about understanding the problem space. When my team started spending two days per feature just exploring the problem (not the solution), everything shifted. Engineers interviewed customers directly. Product managers dove into system logs. We diverged consciously, documenting what we didn’t know rather than pretending we had all the answers.

While the famous “100x cost” statistic about fixing bugs in production versus design has been widely cited, investigation has shown the original IBM Systems Sciences Institute study doesn’t actually exist. However, the principle remains valid: research from multiple sources consistently shows that fixing problems in production costs significantly more than addressing them during design, with estimates ranging from 10x to 100x the cost.

The Define phase is where you converge on what problem you’re actually solving. Not the feature request. Not the user story. The actual problem. This is where my team developed our “Problem Brief”—a one-page document that everyone, from junior developer to CEO, had to agree on before any solution discussion began.

One brief from that era: “Customer Success spends 4 hours daily manually correlating data across three systems to identify at-risk accounts, resulting in 48-hour delay in intervention and 20% higher churn for unidentified accounts.” No solutions. No features. Just the problem, the cost, and the impact.

The Solution Diamond: Where Engineering Shines

Once you’ve defined the right problem, the second diamond becomes pure joy for engineering teams. The Develop phase is where we diverge again, but now we’re exploring solutions to a well-understood problem.

This is where your architects earn their equity. Multiple approaches, different trade-offs, various technologies all explored with the confidence that you’re solving the right problem. We started using a simple matrix: Technical Complexity vs. Business Impact. Every solution option got plotted. The conversations became about trade-offs, not opinions.

During one Develop phase, we explored five different approaches to that customer success problem:

• Full data warehouse implementation (high complexity, high impact)

• Automated daily reports (low complexity, medium impact)

• Real-time streaming pipeline (high complexity, high impact)

• Manual SQL queries with documentation (minimal complexity, low impact)

• Third-party integration platform (medium complexity, medium impact)

The Deliver phase is where most CTOs think they spend all their time, but if you’ve done the first three phases right, delivery becomes almost anticlimactic. The arguments are over. The trade-offs are understood. The team is aligned.

We chose the automated daily reports as our MVP, with a clear path to the streaming pipeline. Product understood why. Engineering understood the business value. Customer Success understood the timeline. Six weeks later, we’d reduced their daily work from 4 hours to 30 minutes.

Real Companies, Real Results

The British Design Council’s original research studied 11 global companies including Apple, LEGO, Microsoft, Sony, and Starbucks, finding that they all naturally followed this same creative process despite having different names for it.

Starbucks even mandates that any designer spend a month working as a barista in their stores to truly understand the discovery phase.

More recent implementations show impressive results. Artkai, a design agency, used the Double Diamond framework for CoinLoan’s P2P lending platform, resulting in over 100,000 active users. They also applied it to Huobi’s mobile trading platform expansion into Europe, successfully adapting the product for a new market by studying European user needs and creating features that differentiated it from competitors.

Companies like IDEO, Google, and Microsoft have integrated Double Diamond principles into their innovation and product development processes, with Google’s design sprints reflecting the framework’s emphasis on deep problem understanding and iterative solution development.

The Rhythm of Diamonds

The revolution isn’t in using the Double Diamond once—it’s in making it your operating rhythm. Every feature, every quarter, every technical decision flows through these diamonds.

We established a cadence:

• Week 1-2: Discover (diverge on problem understanding)

• Week 3: Define (converge on problem definition)

• Week 4-5: Develop (diverge on solution options)

• Week 6: Deliver planning (converge on solution approach)

• Week 7+: Implementation

For smaller problems, we’d run through both diamonds in a single week. For major initiatives, each phase might take a month. The framework scales.

McKinsey research on decision-making shows that organizations following structured approaches that separate problem definition from solution development make faster decisions with better outcomes, with speed and quality reinforcing rather than undermining each other. The Double Diamond isn’t slowing you down but rather it is preventing the three rewrites that happen when you solve the wrong problem brilliantly.

The Organizational Transformation

Six months into our Double Diamond journey, the transformation was undeniable. But it wasn’t just about shipping better features faster (though we were). The real change was cultural.

Engineers stopped complaining about “stupid product decisions” because they were part of problem discovery. Product managers stopped accusing engineering of “technical excuses” because they understood the solution trade-offs. The CEO stopped getting escalations because problems were being solved at the team level.

Our metrics told the story:

• Feature delivery time: decreased 40%

• Post-launch bugs: decreased 60%

• Team satisfaction scores: increased from 6.2 to 8.4

• Customer feature adoption: increased 35%

But the metric that mattered most? The number of “emergency pivot” meetings dropped to zero. When you understand the problem deeply and explore solutions thoughtfully, surprises disappear.

Implementation Without Revolution

You don’t need to reorganize your entire company to start using the Double Diamond. Start with one team, one feature, one experiment.

Pick your most contentious upcoming feature—the one where product and engineering are already at odds. Block one day for problem discovery. Not solution discovery. Problem discovery. Get everyone in a room: engineering, product, sales, customer success, even a customer if you can.

Draw two diamonds on the whiteboard. Explain the phases. Then start with this question: “What problem are we trying to solve, and how do we know it’s a problem?”

Watch what happens when your senior engineer realizes the performance issue they’re worried about doesn’t actually impact the user workflow. Watch your product manager’s face when they understand the technical debt that makes their “simple” request complex. Watch the magic when everyone converges on a problem definition that makes sense to all.

Document everything in a Problem Brief:

• The problem (one sentence)

• Who experiences it (specific users/personas)

• When they experience it (context/triggers)

• Cost of not solving it (time/money/satisfaction)

• How we’ll measure success (specific metrics)

No solutions allowed in this document. That’s for the second diamond.

For the solution diamond, create a Solution Matrix:

• Option name

• Technical complexity (1-5)

• Business impact (1-5)

• Time to implement (weeks)

• Risks and dependencies

• Long-term implications

Plot these on a 2x2 grid. Let the trade-offs become visible. Make the decision together.

The CTO’s New Superpower

The Double Diamond transforms the CTO from a technical decision-maker into an orchestrator of understanding. You’re no longer the bridge between product and engineering. You’re the conductor ensuring everyone plays the same symphony.

This framework gives you a language for the C-suite that isn’t about story points or technical debt. You can walk into the board room and say, “We spent two weeks in problem discovery and identified that what looked like a product issue was actually an infrastructure bottleneck costing us $200K monthly. The solution will take six weeks and pay for itself in three months.”

That’s a conversation every CEO wants to have.

More importantly, it gives your team a way to handle complexity without you. When everyone understands the Double Diamond, they can run it themselves. Your senior engineers start thinking like product managers. Your product managers start thinking like engineers. And you get to focus on strategy instead of refereeing.

Monday Morning Actions

This Monday, do three things:

First, draw the Double Diamond for your leadership team. Explain that every significant decision will now flow through these four phases. Watch for resistance. It usually comes from people who pride themselves on “quick decision-making” but actually create more chaos than progress.

Second, identify three current conflicts between product and engineering. Map them to the Double Diamond. I guarantee you’ll find they’re all stuck because you’re in different phases. Usually product is in Deliver while engineering is still in Discover.

Third, block time for problem discovery. Real time. Sacred time. This Friday, 2-4 PM, entire team, no solutions allowed. Just understanding the problem. Make it a recurring meeting.

Within a month, you’ll see the shift. The heated debates become structured discussions. The us-versus-them mentality dissolves into shared understanding. The delivery velocity increases not because people type faster, but because they’re building the right thing the first time.

Within a quarter, your team will internalize the rhythm. They’ll start asking, “Are we in divergent or convergent thinking?” They’ll catch themselves jumping to solutions and pull back to understand the problem first.

Within a year, you’ll wonder how you ever operated differently. The Double Diamond won’t be a process you follow, it’ll be how your organization thinks.

The distance between product and engineering isn’t measured in sprints or story points. It’s measured in understanding. The Double Diamond doesn’t just bridge that gap. It eliminates it entirely.

Your next product-engineering sync doesn’t have to be a battlefield. It can be a design studio where problems are understood and solutions are crafted collaboratively. All it takes is two diamonds and the discipline to work through both of them.

The question isn’t whether you can afford to spend time in problem discovery. The question is whether you can afford not to. Every minute spent in the first diamond saves hours in the second. Every divergent conversation prevents a convergent crisis.

Welcome to the Double Diamond. Your team will thank you. Your CEO will thank you. And most importantly, your customers will thank you. Not with words, but with adoption, retention, and revenue.

The impact went beyond feelings: 86.5% reported issues with motivation and engagement, 44.6% said confidence when dealing with stakeholders was impacted, 34.4% struggled to lead teams, and 32.3% reported a dip in productivity and delivery.

Those numbers are catastrophic. Not just for the CTOs experiencing them, but for the companies depending on them to make million-dollar technology decisions while fighting through fog.

The loneliness epidemic among technical leaders isn’t new. Over 70% of new CEOs report feelings of loneliness, and former US Surgeon General Vivek Murthy noted that loneliness reduces task performance, limits creativity, and impairs executive function such as reasoning and decision-making. For CTOs specifically, often the only technologist in a C-suite of business-focused executives, the isolation runs deeper.

But isolation isn’t inevitable. There’s a body of research spanning three decades that offers a different model. One where learning happens through participation, where identity develops through practice, and where the antidote to isolation is belonging to something larger than yourself.

When Apprentices Taught Anthropologists About Learning

In 1991, cognitive anthropologist Jean Lave and educational theorist Etienne Wenger published research that would reshape how we think about professional development. They weren’t studying executives. They were studying apprenticeships: Yucatec midwives, Vai and Gola tailors, US Navy quartermasters, meat-cutters, and non-drinking alcoholics in Alcoholics Anonymous.

What they discovered challenged everything we thought we knew about learning.

Lave and Wenger found that learning isn’t primarily an individual cognitive process but a social one. People don’t acquire knowledge and then apply it. They participate in practices of social communities and construct their identities in relation to those communities.

They called this phenomenon a “community of practice”. Groups of people who share a concern or passion for something they do and learn how to do it better as they interact regularly.

Think about how an apprentice electrician learns. Not by reading manuals in isolation. By observing journeymen, asking questions, making mistakes under supervision, gradually taking on more complex tasks. The community acts as a living curriculum. The learning is inseparable from belonging.

Wenger calls this “legitimate peripheral participation”. You start at the edges of the practice, observing and contributing in small ways, gradually moving toward fuller participation as your competence and identity develop.

This isn’t just academic theory. Learning involves participation in the pursuit of valued enterprises—such as discovering scientific facts, fixing machines, growing up, being convivial. Knowledge is competence with respect to valued enterprises. Knowing is participating in the pursuit of such enterprises.

For CTOs, the valued enterprise is building technology organizations that deliver results. The question is: where do you participate in that practice with others who share your challenges?

Three Components That Make Practice Communities Work

Wenger identified three essential elements that turn a group of people into a community of practice:

The Domain: A shared area of interest that creates common ground and gives meaning. For CTOs, this isn’t just “technology” broadly, it’s the specific challenge of leading engineering teams, managing technical debt, navigating C-suite dynamics, and translating technology decisions into business outcomes.

The Community: Members engage in joint activities, help each other, and share information. They build relationships that enable them to learn from each other. This isn’t networking. A good conversation with a stranger on an airplane may give you all sorts of interesting insights, but it does not in itself make for a community of practice.

The Practice: A shared repertoire of resources, experiences, stories, tools, ways of addressing recurring problems. Members develop a shared practice through sustained interaction. This takes time.

Most CTO peer groups fail because they focus on networking (exchanging business cards) or content delivery (listening to speakers) without developing actual practice. You show up, you listen, you leave. Nothing changes. No identity develops. No shared repertoire forms.

Real communities of practice are different. The windshield wipers engineers at an auto manufacturer make a concerted effort to collect and document the tricks and lessons they have learned into a knowledge base. By contrast, nurses who meet regularly for lunch in a hospital cafeteria may not realize that their lunch discussions are one of their main sources of knowledge about how to care for patients.

The learning happens whether you’re conscious of it or not. But the impact multiplies when it’s intentional.

The Hidden Cost of Going It Alone

Let’s talk about what it costs to try to CTO without a community of practice.

Research from in-depth interviews with C-suite executives reveals that top executives are more prone to loneliness due to increased social distance, lack of social support, and exhaustion related to the role.

According to the Journal of Occupational Health Psychology, 26% of executives report symptoms consistent with clinical depression, compared to 18% in the general workforce.

You know what that looks like. The CEO asks if the new feature can ship by month-end. Your gut says no, but you have no peer to reality-check your technical instinct against. You say maybe. The team scrambles. Quality suffers. You take the heat.

Or the board pushes for a technology decision that conflicts with your architecture vision. You’re technically correct. But you’re alone in your correctness, and technical correctness without executive presence is just expensive stubbornness.

Or you’re making a hiring decision between two VP of Engineering candidates. One has the resume, the other has the cultural fit. Who do you ask? Your CEO doesn’t understand the technical nuances. Your team has competing interests. Your recruiter gets paid either way.

These aren’t abstract problems. These are Tuesday afternoon decisions that shape your company’s technical future. And you’re making them without the benefit of practitioners who’ve faced the same choice and can share what they learned.

Peer learning research shows what you’re missing. Studies across healthcare, education, and professional development consistently demonstrate that students in peer tutoring groups obtained significantly exceptional academic achievement compared to students who were not peer tutored. But the benefits go beyond performance. Peer learning creates spaces for emotional support, reduces isolation, and builds confidence in decision-making.

For CTOs, the cost of isolation compounds: slower decisions, more second-guessing, less experimentation, higher stress. You can be technically brilliant and still fail because brilliance without community is fragile.

How 7CTOs Functions as a Community of Practice

In 2013, after spending two years meeting with over 300 CTOs across four US cities, I kept hearing the same pain point. Technical leaders felt isolated. They lacked peers who understood their specific challenges. They had no structured way to develop their practice beyond trial and error in their own companies.

7CTOs was built as a community of practice, though I didn’t use that language at first. I just knew what was missing and what needed to exist.

The Domain: Technology leadership at scale. Not hobbyist programming. Not individual contributor work. The specific challenges of leading 10-120 person engineering teams through growth, dealing with technical debt, managing up to non-technical executives, and building systems that support million-dollar business outcomes.

The Community: 300+ vetted technology leaders who meet in professionally facilitated forums monthly. These aren’t casual happy hours. They’re structured sessions where CTOs bring real problems, share real failures, and build relationships over years. Brittany Cotton, our Chief Coaching Officer, has spent thousands of hours coaching CTOs through these peer groups. She knows what works: consistency, vulnerability, shared struggle.

The Practice: Frameworks like the CTO Levels, playbooks for team structure to deployment automation, shared stories of what worked and what failed, and a growing body of documented knowledge that members contribute to and draw from. When a CTO is facing a Level 4 to Level 5 transition (scaling from 20 to 40 engineers), they’re not improvising. They’re drawing on the collective experience of dozens who’ve made that transition before them.

This isn’t theory. Members report transformations that go beyond skill acquisition. One CTO told me it changed not just how he leads his company, but his entire relationship with technical work. Another said 7CTOs gave her the confidence to push back on the CEO’s unrealistic timeline because she had a forum to pressure-test her technical reasoning with peers before that conversation happened.

Communities of practice act as a negotiated regime of competence. Within such a regime, knowing is no longer undefined. It is defined as what would be recognized as competent participation in the practice.

When you participate in 7CTOs, you don’t just learn techniques. You develop an identity as someone who belongs to a community of practitioners. That identity shift changes everything—how you show up in C-suite meetings, how you make hiring decisions, how you handle pressure from stakeholders.

Communities Inside and Beyond Your Company

Communities of practice don’t only exist at the organizational level. You can and should cultivate them inside your company too.

Inside your engineering organization, communities of practice form around shared technical challenges: your frontend developers who meet to review architectural patterns, your DevOps engineers who maintain shared runbooks, your engineering managers who discuss team dynamics over lunch.

Nurses who meet regularly for lunch in a hospital cafeteria may not realize that their lunch discussions are one of their main sources of knowledge about how to care for patients.

The same happens with engineers. That Slack channel where senior developers debate testing strategies? That’s a community of practice. The weekly architecture review where teams share their design decisions? Community of practice. The informal gathering where engineering managers commiserate about difficult 1-on-1 conversations? Also a community of practice.

Your job as CTO isn’t to manage these communities directly. It’s to recognize them, legitimize them, and remove obstacles that prevent them from functioning. Give them time. Give them visibility. Make participation in these communities part of what it means to be a senior engineer at your company.

But, and this is critical, internal communities can’t meet all your needs as CTO. You need external communities too. Because inside your company, you’re the leader. You’re the one who’s supposed to have answers. The power dynamic prevents the kind of vulnerable learning that happens when you’re among true peers.

External communities like 7CTOs create space for a different kind of participation. You can admit you don’t know. You can share failures without worrying about undermining confidence in your leadership. You can ask stupid questions. You can pressure-test ideas before bringing them to your team.

The primary focus of community of practice theory is on learning as social participation. Participation refers not just to local events of engagement in certain activities with certain people, but to a more encompassing process of being active participants in the practices of social communities and constructing identities in relation to these communities.

Your participation in both internal and external communities shapes who you become as a CTO. Neither is sufficient alone.

What Happens When You Join

If you’ve never been part of a real community of practice, the transformation can feel disorienting.

First, you’ll notice how much faster you can make decisions. Not because someone tells you what to do, but because you have access to pattern recognition from dozens of similar situations. Someone in the community faced this exact architectural choice last quarter. They can share what they learned. You don’t have to repeat their mistakes.

Second, your confidence changes. Not arrogance but rather confidence. The kind that comes from knowing you’re not making it up as you go. You’re drawing on a shared practice. When you push back on a bad business decision with technical reasoning, you’re not just defending your position. You’re representing what the community knows to be true.

Third, your identity shifts. You stop seeing yourself as an isolated problem-solver and start seeing yourself as a practitioner in a larger community. We all belong to communities of practice. At home, at work, at school, in our hobbies we belong to several communities of practice at any given time. And the communities of practice to which we belong change over the course of our lives.

The loneliness doesn’t disappear overnight. But it transforms into something manageable. You’re not alone anymore. You’re part of something.

Your Monday Morning Next Steps

If you’re reading this and recognizing yourself in those loneliness statistics, do this:

This week: Identify one internal community of practice that already exists in your engineering organization. It might be informal. Make it visible. Acknowledge it. Ask how you can support it.

This month: Reach out to one CTO outside your company who faces similar challenges. Not for advice. For connection. Share something you’re struggling with. See if they’re willing to do the same. That’s how communities start.

This quarter: Evaluate whether you need structured participation in an external community. Whether you’re a CTO of a 120 person engineering team or a team of 3, 7CTOs might be right for you. If you’re earlier stage, look for communities built around your specific level. The critical question isn’t whether the community exists—it’s whether you’re willing to participate.

Learning is an intrinsically social process and one of the primary sites where learning occurs is in communities of practice. You can try to CTO alone. Many do. Some even succeed for a while.

But the research is clear, and the lived experience of hundreds of CTOs confirms it: the isolation isn’t necessary. The struggle doesn’t have to be solitary. There’s a community of practice waiting for you to step into it.

The question is whether you’ll let yourself belong.

Etienne

PS if you’re drawn to all this, head over to 7ctos.com/community and join us.

My CEO is excited. He just closed a deal with a mid-market client who wants us to build a custom reporting dashboard. “Six figures,” he says, grinning. “And they’re willing to pay upfront.”

I should be celebrating. Instead, I’m calculating. The custom work will take my two best engineers off the product roadmap for at least three months. Our deployment pipeline is already fragile. We’re still manually testing major releases. And this “custom” work will create technical debt that will haunt us for years.

“We can’t do this,” I say.

The grin fades. “What do you mean we can’t do this? It’s $150,000.”

“It’s $150,000 that will cost us $300,000 in opportunity cost and another $200,000 in maintenance over the next two years.”

The meeting that was supposed to take 15 minutes stretches to two hours. I pull up spreadsheets. I draw architecture diagrams on our whiteboard. I explain why this deal, however attractive, will derail everything we’ve been building. My co-founder’s frustration is palpable.

“You’re being difficult,” he finally says. “You’re always being difficult.”

I go home that night convinced I’m the problem. Too technical. Too rigid. Too high maintenance. Maybe I should just shut up and let the business people run the business.

But something nags at me. If I stay silent, who’s going to protect the engineering capacity that actually builds the business?

When Low Maintenance Means Low Impact

Nobody tells you about being a CTO in the C-suite: the pressure to be “easy to work with” is enormous. Your CEO is juggling investor expectations, cash flow crises, and sales targets. Your COO is fighting fires in operations. Your Head of Sales is trying to hit quota. The last thing anyone wants is their CTO pushing back on deals, questioning product decisions, or demanding resources for “technical improvements” that don’t show up on the revenue line.

So most CTOs learn to be low maintenance. We become accommodating. We say yes to unrealistic timelines. We accept insufficient budgets. We swallow our concerns about technical debt. We stop asking difficult questions in leadership meetings because we don’t want to be “that person” who always has objections.

In IBM’s 2021 CTO study, Ericsson’s Vice President noted that many CTOs “started on a very technical level and then moved into higher management positions. It has been easy to hide behind deep technical discussions. You now need to have totally different discussions with the business. And you need to have the confidence to question the business.”

Being low maintenance doesn’t make you a better executive. It makes you invisible.

The Cost of Your Silence

Let me put this in terms that matter: money. In a company with $10M in revenue and a 40-person engineering team, what does “low maintenance CTO syndrome” actually cost?

McKinsey research shows that technical debt accounts for about 40% of IT balance sheets, and companies pay an additional 10-20% to address tech debt on top of project costs. For a $3M engineering budget, that’s potentially $600,000-$900,000 annually in extra costs from accumulated technical debt.

Stripe’s research found that engineers spend 33% of their time dealing with technical debt. That’s roughly $1M in wasted engineering capacity for our example company, engineers firefighting problems instead of building features that drive revenue.

Studies show that on average, 25% of development effort is wasted on technical debt-caused issues. When you’re the agreeable CTO who never pushes back, you’re not being a team player. You’re bleeding the company of $1.5M-$2M annually in lost productivity.

That’s the price of being agreeable. That’s what being “low maintenance” actually costs your company.

What High Maintenance Actually Means

Let’s reframe this entirely. When I say a CTO needs to be high maintenance, I don’t mean being unreasonable, throwing tantrums, or refusing to collaborate. I mean:

Demanding Clarity: When your CEO proposes a new strategic direction, you don’t nod along. You ask the hard questions. “What does success look like? What are we willing to sacrifice to get there? What happens if this doesn’t work?” These aren’t obstructions; they’re the questions that prevent expensive mistakes.

Leaning Into Difficult Conversations: When Sales promises a feature that doesn’t exist, you don’t quietly tell engineering to “make it work.” You escalate immediately. You have the uncomfortable conversation about commitments, timelines, and what’s actually possible. Yes, people will be annoyed. That’s the job.

Trusting Your Spidey Sense: You’ve been building technology for years. When something feels wrong like a vendor choice, an architectural decision, or a hiring plan you say something. Loudly. Even when you can’t fully articulate why. Especially then.

Being Present and Vocal: In C-suite meetings, you don’t sit quietly while others debate strategy. You inject technical reality into every conversation. “That timeline assumes we have infinite engineering capacity.” “That growth target requires infrastructure we don’t have.” “That partnership creates dependencies we can’t afford.”

This behavior will make you seem high maintenance. People will roll their eyes when you speak up. Your CEO might pull you aside and ask you to be “more collaborative.”

Good. You’re doing your job.

The Executive Presence Paradox

There’s a concept in leadership development called executive presence. It’s usually described as confidence, gravitas, and the ability to command a room. But what the leadership consultants miss is this: real executive presence often looks like being difficult.

When the CFO pushes back on the sales forecast, that’s executive presence. When the COO refuses to commit to an impossible delivery timeline, that’s executive presence. When the CTO questions whether the business strategy is technically feasible, that’s executive presence.

The C-suite isn’t a democracy. It’s not a place where everyone gets a gold star for participation. It’s a place where each executive is supposed to be the loud, uncompromising advocate for their domain. The CFO protects the financial health of the company. The CTO protects the technical health of the company.

You can’t protect something while being agreeable all the time.

Your job isn’t to be liked. Your job is to make sure the company builds technology that works, scales, and doesn’t collapse under its own complexity.

The Questions That Signal High Maintenance

When you’re properly high maintenance like when you’re actually doing the job of CTO, certain questions become your constant refrain in leadership meetings:

“What’s the actual cost of this decision?” Not the obvious cost. The hidden cost. The opportunity cost. The technical debt cost. The maintenance cost three years from now.

“What assumptions are we making?” Every strategy relies on assumptions. Your job is to surface them, question them, and force everyone to confront what happens if they’re wrong.

“Who on my team has capacity for this?” Not theoretical capacity. Actual capacity. Engineers aren’t interchangeable resources. This matters when your CEO wants to “just add” one more initiative.

“What are we NOT going to do?” Everything has a trade-off. When the company commits to something new, you’re the person asking what existing work gets deprioritized or canceled.

“What happens if this fails?” Not pessimism. Risk management. What’s the blast radius of this decision? What’s our rollback plan? What’s the worst-case scenario, and can we survive it?

These questions will make meetings longer. They’ll make decisions slower. They’ll make you seem like an obstacle.

They’ll also save your company from catastrophic mistakes.

The Season of Strategic Noise

There’s a season in every CTO’s career usually when the company is between 40-120 engineers, where being high maintenance isn’t optional. It’s survival.

This is when complexity starts to overwhelm intuition. When the CEO can’t simply “know” what’s happening in engineering anymore. When architectural decisions have multi-million dollar implications. When technical debt becomes existential.

During this season, you need to be loud. Not obnoxious, but loud. Your voice needs to be heard in every strategic conversation because technology isn’t a support function anymore. It’s the business.

This is when people should be asking “What does the CTO think?” before making major decisions. Not out of politeness, but because ignoring your perspective is expensive and dangerous.

This is when your opinion should carry weight not because of your title, but because you’ve established a pattern of being right about technical implications. Sometimes annoyingly right.

This is your season of necessary friction.

What Success Looks Like

Back to that meeting in 2009. We didn’t take that custom development deal. My co-founder was furious with me for a week. But we used those engineering resources to finally fix our deployment pipeline and build the analytics dashboard that 80% of our customers had been requesting.

Six months later, that analytics feature helped us close deals worth $2.3M in new ARR. The client who wanted custom development? They signed anyway, because the product we built was better than what they originally asked for.

More importantly, something shifted in how the C-suite worked together. My co-founder started asking “What does Et think?” before committing to major deals. Our head of sales learned to check technical feasibility before making promises. Our board meetings started including honest assessments of engineering capacity and technical risk.

I was still high maintenance. But now that friction was valued, not tolerated.

The Numbers Tell the Story

Korn Ferry’s analysis of the top 1,000 U.S. companies found that CTO/CIO tenure averages around 4.3-4.9 years. A 2021 survey showed that 56% of technology executives changed employers that year, with nearly 40% reporting burnout.

Think about that. If you’re a CTO, you’ll most likely stay in your job for less than five years. That’s barely enough time to execute meaningful technical transformation.

How many of those departed CTOs were “technically correct” in their assessments of business goals, technology strategies, and product-market fit? I bet most of them were. But how many were actually heard? How many were able to have real impact? How many helped steer the ship before it hit the iceberg?

The low-maintenance CTOs are the ones who get fired when technical disasters happen. The high-maintenance CTOs are the ones who prevented those disasters in the first place.

Your Turn to Be Difficult

You don’t need permission to be high maintenance. You need to stop apologizing for it. The next time you’re in a C-suite meeting and someone proposes something that makes your technical instincts scream, speak up. Loudly.

Calculate the real cost and share it. “This feature will take 3 engineers for 4 months. That’s $240,000 in engineering time, plus another $100,000 annually in maintenance. What revenue does this generate?”

Challenge the assumptions. “We’re assuming our infrastructure can handle 10x growth. Have we actually tested that? What’s our plan when we’re wrong?”

Demand clarity on trade-offs. “If we commit to this partnership integration, we’re pushing the mobile app redesign to next year. Is everyone comfortable with that?”

Yes, people will find you difficult. Yes, you might get feedback that you need to be “more collaborative.” Yes, some executives will wish you were easier to work with.

But six months from now, when the company avoids a $2M mistake because you asked an uncomfortable question, no one will remember that you were difficult. They’ll remember that you were right.

Your C-suite doesn’t need another agreeable executive. They need someone who will protect the technical foundation of the business, even when—especially when—that protection is uncomfortable.

Be high maintenance. Be demanding. Be the friction that prevents expensive mistakes.

That’s not a personality flaw. That’s executive presence.

Etienne

P.S. Here are the references:

IBM Institute for Business Value (2021) “2021 CTO Study: The CTO Revelation” https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/2021-cto

McKinsey & Company (2023) “Breaking technical debt’s vicious cycle to modernize your business” https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/breaking-technical-debts-vicious-cycle-to-modernize-your-business

Stripe (2018) “The Developer Coefficient” - Research on engineering time spent on technical debt Referenced in: https://www.stepsize.com/blog/cost-of-technical-debt

Academic Research on Technical Debt Besker, T., et al. (2019). “Software developer productivity loss due to technical debt—A replication and extension study examining developers’ development work.” Journal of Systems and Software. https://www.sciencedirect.com/science/article/abs/pii/S0164121219301335

Korn Ferry (2020) “Age and Tenure in the C-Suite: Korn Ferry Study Reveals Trends by Title and Industry” https://www.businesswire.com/news/home/20200121005146/en/Age-and-Tenure-in-the-C-Suite-Korn-Ferry-Study-Reveals-Trends-by-Title-and-Industry

Russell Reynolds Associates (2021) Technology Executive Survey - Referenced in Fortune article https://fortune.com/2023/02/21/chief-technology-officer-in-demand-retention-job-hop-cto/

Line 10: PRINT “What’s your name?”
Line 20: INPUT NAME
Line 30: PRINT “Hello, “ + NAME

I hit RUN. The cursor blinks expectantly after asking for my name. I type “Etienne” and press Enter.

ERROR.

I stare at the screen. My brain cycles through possibilities like a broken cassette tape rewinding and playing the same three seconds over and over. The manual sits open beside me, its pages worn from my desperate searching.

Hours pass. My parents are getting ready for their evening church service, but I barely notice. I’m deep in the manual, searching for clues.

Then, around 5 PM, I find it. A small note about declaring variables. About telling the computer that NAME is going to hold text, not numbers. In Atari BASIC, you need to dimension string variables first.

Line 5: DIM NAME$(20)
Line 10: PRINT “What’s your name?”
Line 20: INPUT NAME$
Line 30: PRINT “Hello, “; NAME$

RUN.

“Hello, Etienne”

The rush of that moment – seeing my name reflected back at me by this machine I’d commanded – is pure magic. I can’t contain it. I save the program, leap from my chair, and sprint out the door. My parents are just pulling out of the driveway for church. I wave frantically, running after the car. They stop, probably thinking something’s terribly wrong.

“I did it!” I shout through the window. “The computer knows my name!”

That twelve-year-old didn’t just experience the thrill of coding. He experienced something deeper: the intoxicating moment when human creativity meets technological possibility and something new springs into existence. The joy wasn’t in the code itself – it was in the breakthrough, the discovery, the act of creation that felt so momentous it couldn’t wait.

The Trajectory We Never See Coming

Fast forward forty years. I’m running 7CTOs, a community of hundreds of technology leaders. Week after week, I sit with brilliant CTOs who’ve built incredible systems, led massive teams, delivered products that millions use. And week after week, I hear the same confession, whispered like a guilty secret: ‘I don’t love this anymore.’

While there’s no survey that specifically measures ‘creative joy’ among CTOs, the evidence is everywhere. Even regular developers spend less than one-third of their time writing new code or improving existing code Sonar. For CTOs, that creative time approaches zero. In the real world, it’s mainly those CTOs at startups and smaller operations who still spend any significant amount of time coding Raconteur. As companies grow and the CTO role expands, the keyboard gets replaced by the calendar.

We’ve become administrators of innovation rather than innovators.

The progression is predictable. You start as that kid with the computer, creating things because you can’t not create them. Maybe you’re coding, maybe you’re designing systems, maybe you’re solving problems no one else can see. Every challenge is a puzzle. Every puzzle is joy.

Then you get good. Really good. You understand not just how to build but how to architect. You see patterns others miss. You can translate between technical and business worlds.

And so the organization does what organizations do: they promote you.

Suddenly you’re CTO. The title feels heavy, important. Your parents finally understand what you do for a living. The salary reflects your value. But something else happens, something nobody warns you about.

That kid who couldn’t contain their joy, who had to run down the street to share their breakthrough? That kid starts to disappear.

The Three Lies We Tell Ourselves

I’ve identified three stories CTOs tell themselves to justify their disconnection from creative work:

The Responsibility Story: “I have 50 engineers depending on me. I can’t indulge in hands-on exploration anymore. That would be selfish.” This is the martyr’s path. You sacrifice your creative soul on the altar of leadership, believing that suffering equals dedication.

The Evolution Story: “This is just career progression. You can’t stay in the weeds forever. I’ve evolved beyond that.” This frames disconnection from creativity as growth, when often it’s just displacement.

The Temporary Story: “Once we get through this quarter/funding round/product launch, I’ll have time to explore and create again.” This is perhaps the cruelest lie, because there’s always another quarter, another crisis, another reason to delay.

Technology develops at a pace unmatched by any other construct. What is created one day can be broken, fixed, redesigned and expanded the next. Yet the very leaders who should be most connected to this creative destruction are the ones most removed from it.

Press Any Key to Continue

Remember those words? They appeared on every game, every program, every adventure you loaded on those early computers. After the interminable wait while the cassette deck squealed and chirped, loading your program into memory, these five words appeared: “Press Any Key to Continue.”

No restrictions. No “Press Enter” or “Press Space.” Any key. Your choice. Your path forward.

This phrase has become my philosophy for CTOs reclaiming their creative spark. Because somewhere between your first breakthrough and your latest board presentation, you forgot something crucial: you still have choices. You can still press any key.

The three key elements in enduring motivation are autonomy, mastery, and purpose. Autonomy is having a measure of control over what we do and how we do it. Mastery is making progress and getting better at something that matters, according to Daniel Pink’s research on human motivation.

Most CTO roles systematically strip away all three. Your calendar is owned by others (goodbye autonomy). You’re too busy managing to maintain technical mastery (goodbye expertise). And your purpose gets lost in quarterly objectives and OKRs that feel disconnected from why you fell in love with technology (goodbye meaning).

But what if we could reclaim all three without abandoning our responsibilities?

The Integration Path

Over the past year, I’ve worked with CTOs who’ve successfully integrated creativity back into their leadership. They didn’t quit. They didn’t neglect their duties. They pressed a different key.

Marcus, CTO of a 200-person fintech, instituted “Innovation Mornings.” Every Tuesday and Thursday, from 6 AM to 10 AM, he explores. Sometimes he prototypes with new technologies. Sometimes he experiments with radical architectures. Sometimes he builds proof-of-concepts that will never see production. The key is that he creates. His team noticed something: his afternoon strategy sessions became more visionary. His technical decisions carried more weight. He wasn’t just managing technology; he was living at its edge.

Sarah, leading engineering at a healthcare startup, took a different approach. She owns one technical exploration per sprint. Not managing it – owning it. Sometimes it’s investigating a new AI model. Sometimes it’s prototyping a complete reimagining of their architecture. “I need to feel the frontier of what’s possible,” she told me. “How else can I guide us into the future?”

Research by Edward Deci and Richard Ryan found that intrinsic motivators, like autonomy and competence, boost performance more than external rewards. These CTOs prove that maintaining hands-on involvement with technology isn’t indulgent – it’s essential for visionary leadership.

They discovered what that twelve-year-old me knew instinctively: the joy isn’t in having created something; it’s in the act of creation itself. It’s in the discovery, the breakthrough, the moment when possibility becomes reality.

The Five Levels of Technical Leadership Freedom

Through observing hundreds of CTOs, I’ve identified five levels of freedom in technical leadership:

Level 1: Insert Coin – You’re completely reactive. Every moment is owned by others. You’re surviving, not thriving. Your calendar looks like Tetris blocks with no gaps. You haven’t experienced a technical breakthrough in years.

Level 2: Restricted Input – You have some control, but only within rigid boundaries. Maybe you read about new technologies on your commute. Maybe you occasionally review architecture decisions. But exploration feels stolen, not owned.

Level 3: Function Keys – You’ve carved out specific times for creative technical work, but it’s scheduled and structured. It’s progress, but not yet joy. You’re touching technology but not dancing with it.

Level 4: Shortcuts Enabled – You’ve integrated creation into your leadership style. Your technical explorations enhance your CTO role rather than competing with it. Breakthroughs are becoming regular occurrences.

Level 5: Press Any Key – Complete integration. You don’t choose between being a leader and being a creator. You’ve designed a role where both coexist naturally. That twelve-year-old’s joy has returned, evolved and matured.

Most CTOs I meet are stuck at Level 2, believing that Level 5 is a fantasy. It’s not. It’s a choice.

Now What? Your Next Key Press

If you’re reading this and feeling that familiar ache – the one that reminds you of who you were before you became who you are – here’s your path forward:

Week 1: The Joy Audit Track every moment in your week when you feel energized versus drained. Don’t judge it. Just notice. When do you feel like that kid who ran to church? When do you feel like you’re wearing a suit that doesn’t fit?

Week 2: The Experiment Block three hours. Just three. Use them to explore something technical that fascinates you. Build a prototype. Experiment with a new technology. Create something utterly impractical but intellectually thrilling. Notice how you feel after. Notice if you want to run down the street and tell someone.

Week 3: The Integration Find one aspect of your CTO role that could benefit from hands-on technical exploration. Not everything – just one thing. Maybe it’s personally prototyping the next major architecture shift. Maybe it’s spending a morning experimenting with AI models that could transform your product. Make it official. Put it in your calendar. Call it “Strategic Technical Research” if you need to justify it.

Week 4: The Declaration Tell your team what you’re doing and why. Not as an apology, but as leadership. “I’m a better CTO when I stay connected to the edge of what’s possible. Here’s how I’m going to lead from the frontier.”

You might face resistance. Your board might question why you’re “playing with technology instead of managing.” Your team might wonder if you don’t trust them.

Let the results speak. Leaders who maintain their creative practice don’t just survive; they thrive. They bring energy instead of exhaustion to their teams. They make better strategic decisions because they understand what’s possible, not just what’s practical. They inspire through excitement, not just expertise.

The Permission You’ve Been Waiting For

That twelve-year-old staring at the Atari screen didn’t need permission to experiment, to fail, to spend six hours on four lines of code. He didn’t need permission to run down the street and burst into church with his joy. Somewhere along the way, we started believing we needed permission to feel that alive.

You don’t.

The CTO must have a technical background. But this does not mean they need to come from a conventional computer science education. What matters isn’t how you stay connected to technology’s creative edge – what matters is that you do.

You can be an exceptional CTO and a creative technologist. You can lead teams and explore new frontiers. You can set strategy and chase breakthroughs. You can attend board meetings and still be the person who runs down the street shouting “I did it!”

The computer is still waiting. The cursor is still blinking. New technologies are emerging every day, each one a doorway to that same magic you felt forty years ago. And despite what your calendar says, despite what your role demands, despite what everyone expects – you can still press any key to continue.

The question isn’t whether you have the time. It’s whether you have the courage to reclaim what was always yours: the uncontainable joy of creation.

Press any key to continue.

What key will you press today?

“Tell me what happened,” she says.

I launch into it. The dishwasher. How loading it became World War III. How a simple conversation about whether glasses go on the top or bottom rack escalated into us retreating to separate corners of the house. I explain my position. It’s logical. It’s efficient. It’s right.

“And how did your wife respond?” my coach asks.

I pause. I don’t actually remember what she said. I remember how wrong she was. How she dismissed my approach. How she made me feel like I was being controlling when I was just trying to be helpful.

“Etienne,” my coach interrupts my spiral. “What if I told you that your ability to communicate with your wife has nothing to do with the dishwasher?”

I’m confused. We literally just fought about the dishwasher.

“What if,” she continues, “your communication is breaking down because of how you think she views you? And what if—stay with me—what if none of that story you’re constructing about what she thinks is actually true?”

The room tilts slightly.

She lets the silence sit before continuing. “Daniel Kahneman has this concept: what you see is all there is. Your brain builds the most coherent story it can from the information available. But that story isn’t reality. It’s just your System 1 thinking, making sense of incomplete data.”

I’m still processing when she lands the punch: “What if this isn’t a relationship problem at all? What if it’s just a communication challenge?”

When the C-Suite Speaks Different Languages

Three months later, I’m in an executive meeting. Our VP of Sales is frustrated. Our CMO looks confused. And I’m sitting there, technically correct, wondering why no one seems to understand what I’m saying.

I’ve just explained why we can’t ship the feature they want by Q1. I’ve laid out the technical constraints, the architectural implications, the testing requirements. It’s airtight. It’s logical. It’s right.

The CEO sighs. “Can we just get a rough estimate?”

And suddenly I’m back in my living room, fighting about the dishwasher.

According to research by The Economist Intelligence Unit, 86% of corporate executives cite ineffective communication as the primary reason for workplace failures. Not bad strategy. Not lack of resources. Communication. 49% of director-level executives report that miscommunications happen frequently or very frequently at work.

But I wonder how many of those executives recognize that they’re not dealing with relationship problems. They’re dealing with communication challenges wrapped in assumptions about how others view them.

The Geek-Speak Trap

Paul Glen and Maria McManus wrote The Geek Leader’s Handbook as a collaboration between a geek and a non-geek. Their research reveals something fascinating about technical leaders: we fundamentally experience time differently than our non-technical colleagues.

“For geeks, the future is looming,” they write. “For non-geeks, the future is promising.”

Think about that. When I hear “Q1 deadline,” I see all the technical landmines between now and then. Each one feels immediate, urgent, looming. My non-technical colleagues hear the same deadline and imagine possibilities, opportunities, promises.

Glen and McManus also discovered why technical people hate giving estimates: “Very often geeks refuse to answer these questions because they don’t want to lie. To give an estimate is to say something you don’t know absolutely to be true, and therefore it is to tell a lie.”

When my CEO asks for a rough estimate, she’s asking for a conversation starter. When I refuse because I can’t be precise, I think I’m being honest. She thinks I’m being difficult.

We’re not having a disagreement. We’re having two entirely different experiences of the same conversation.

What You See Isn’t All There Is

Remember my coach’s question about my wife? The same principle applies in the C-suite.

Daniel Kahneman describes “What You See Is All There Is” (WYSIATI) as one of our most powerful cognitive biases. Our brains construct coherent stories from whatever information is available, treating that limited data as if it were the complete picture.

When my CEO pushes back on my timeline, my brain constructs a story: “She doesn’t trust my technical judgment. She doesn’t value the engineering team. She thinks we’re just making excuses.”

But Kahneman’s research shows that these stories we construct are fiction. Compelling fiction. Convincing fiction. But fiction nonetheless. As he writes, “You cannot help dealing with the limited information you have as if it were all there is to know. You build the best possible story from the information available to you, and if it is a good story, you believe it.”

The problem? I’m not having a conversation with my CEO.

The Real Culprit Behind C-Suite Chaos

Research from Gartner found that poor communication is responsible for 70% of corporate errors. Not technical problems. Not market conditions. Communication.

But when you dig into the data, something becomes clear: most communication breakdowns aren’t about the words being said. They’re about the assumptions beneath them.

Technical people, Glen and McManus found, have “very finely tuned unfairness detectors.” When we feel slighted, underappreciated, or undervalued, our response is immediate and visceral. But sometimes what we’re detecting isn’t actually unfairness, it’s miscommunication that we’re interpreting through the lens of how we think others view us.

A study of self-awareness reveals something sobering: 95% of people believe they are self-aware, but only 10-15% actually are. Most of us are walking around convinced we understand how we come across to others, when in reality we’re operating from a fundamentally flawed model.

This is the invisible crisis in C-suites everywhere. Directors and middle managers, the people most responsible for translating between technical and non-technical worlds, report the highest rates of miscommunication. The very people who need to bridge these gaps are drowning in them.

Three Symptoms of Communication Cancer

You know you’re infected with communication breakdown when:

The Interpretation Spiral: Someone says something neutral, and you immediately know what they “really mean.” Your colleague says “interesting approach” and you hear “that’s stupid.” Your CEO asks “how long will this take?” and you hear “you’re too slow.”

The Defensive Reflex: Questions feel like attacks. Requests for estimates feel like traps. Conversations about timelines feel like interrogations. You find yourself saying “as I already explained” more than once a week.

The Translation Tax: You spend more energy trying to figure out what someone meant than engaging with what they actually said. After every meeting, you need a meeting to decipher what happened in the meeting.

These aren’t relationship problems. These are communication problems disguised as relationship problems.

Getting Back to Clean Communication

My coach’s advice about my marriage transformed how I operate in the C-suite. She said: “Stop trying to figure out what your wife thinks of you. Just communicate clearly about the actual problem.”

Radical, right?

Start with Assumptions on the Table: Before your next executive meeting, try this: “I’m going to share my recommendation, but first I want to name my assumption. I’m assuming you want this feature because of customer feedback, not because of competitive pressure. Am I right?”

Watch what happens when you externalize your assumptions instead of letting them drive your interpretation of the conversation.

Use the “Help Me Understand” Protocol: When someone says something that triggers your WYSIATI story-building, pause. Say: “Help me understand what you’re optimizing for here.” Not “Why are you pushing back on my timeline?” Not “Don’t you trust my judgment?” Just: “Help me understand.”

You’re not asking them to defend themselves. You’re asking them to share information your brain doesn’t have access to.

As a side note, I’ve seen a-types weaponize the “Help me understand” phrase so be sparing with its use.

Separate Facts from Stories: Practice distinguishing between what actually happened and the story you’re telling about what happened. “The CEO asked for a rough estimate” is a fact. “The CEO doesn’t trust my technical judgment” is a story.

Glen and McManus found that geeks communicate in facts while non-geeks communicate in stories. Neither is wrong. But knowing which you’re doing matters.

Create Communication Contracts: Explicitly agree on what different types of communication mean. In my organization, we now distinguish between “rough estimate” (30% confidence, order of magnitude), “estimate” (70% confidence, +/- 25%), and “commitment” (90% confidence, deliver or explain). Before this, every request for timeline felt like a trap.

Check Your Self-Awareness: Record yourself in an executive meeting (with permission). Watch it later. Not to critique yourself, but to notice: Do you actually sound the way you think you sound? Are people reacting to what you said, or to how you said it?

Remember: only 10-15% of people are actually self-aware, even though 95% think they are. You probably aren’t in that 10-15%. Neither am I.

The Dishwasher Revelation

Six months after that coaching call, my wife and I were loading the dishwasher. I caught myself about to “explain” the right way to do it.

Then I stopped. “Hey, I’m realizing I have opinions about this, but I’m not actually sure what you’re optimizing for. Are you optimizing for speed, water efficiency, or fitting the maximum number of dishes?”

She looked at me like I’d grown a second head. Then she laughed. “I’m just trying to get the dishes clean so we can eat dinner. I don’t care about any of that other stuff.”

All those fights. All that tension. All because I was having a conversation with my story about her story about me, instead of just asking what she actually wanted.

The C-suite is no different.

When your CEO asks for a timeline, she’s not attacking your competence. When your VP of Sales pushes back on your technical constraints, he’s not dismissing your expertise. When your CMO seems confused by your explanation, she’s not being willfully ignorant.

They’re just speaking a different language than you are. And you’re both constructing stories about what the other person means, based on incomplete information, filtered through how you think they view you.

Most of what we experience as relational problems are just communication challenges. The question is: are you ready to treat them as such?

Because here’s what happens when you do: those 44% of projects that fail due to miscommunication? They ship. That $420,000 per year your company loses to communication breakdown? It gets reinvested. That stress, that friction, that sense that no one understands you? It dissolves.

Not because you became a better communicator. But because you stopped communicating with stories and started communicating with people.

The dishwasher doesn’t care how you load it. Your C-suite doesn’t care about being right. They care about building something together.

Stop fighting about the dishwasher. Start asking what success looks like.

Everything else is just noise from the story you’re telling yourself.

Over fifty years later, we’re still using that same paradigm. Sure, the graphics are prettier, the animations smoother, and the screens touch-responsive. But the fundamental model—windows containing applications, icons representing files, menus organizing commands, pointers selecting things—hasn’t changed.

Now we’re in 2025, and according to McKinsey’s latest research, 78% of organizations use AI in at least one business function, up from just 55% a year ago. Companies are racing to integrate AI into their products. And how are they doing it?

By bolting a chat box onto the WIMP interface and calling it innovation.

I’ve been sitting with this nagging feeling lately. Every product demo I attend, every “AI-powered” feature launch I read about, follows the same pattern: traditional interface + chat box = revolutionary AI product. And I can’t shake the question—are we actually innovating, or are we just adding natural language processing to a 50-year-old paradigm and hoping no one notices?

The Desktop That Won’t Die

I was in a product demo last week. Startup pitching their “next-generation AI development environment.” The founder was genuinely excited, demonstrating how you could chat with their AI to generate code. Which then appeared in... a traditional text editor. With a file tree on the left. Terminal at the bottom. Tabs across the top.

It looked exactly like VS Code. Except with a chat box.

The technology was impressive—the code generation was solid, context awareness was good. But something felt off. Here we are with the most transformative technology in decades, and we’re using it to make 1995’s interface slightly more conversational.

The WIMP paradigm was designed for a world where computers were single-user machines, storage was measured in kilobytes, networks barely existed, and AI meant “if-then” statements in BASIC programs. We’re in 2025. We have AI that understands context, maintains conversations, and orchestrates complex workflows. And we’re using it to make better autocomplete in our text editors?

What the Kids Are Teaching Us

Pew Research found that 45% of teenagers report being online “almost constantly,” and 95% have access to a smartphone. But what’s interesting is that they don’t think in files and folders. They don’t organize hierarchically. They search. They use natural language. They expect technology to understand context without explicit instructions.

Show a kid a traditional desktop interface and watch their confusion. “Why do I need to remember where I saved something? Why can’t I just ask for it? Why do I have to click five times to do something simple?”

They’re not learning our language. Which raises an uncomfortable question: Why should they?

The Chat Box Delusion

I’ve been in enough architecture reviews this year to spot the pattern. Company adds AI by:

1. Keeping the entire existing interface exactly as-is

2. Adding a chat box (usually bottom right corner)

3. Training the AI to manipulate the existing UI elements

4. Calling it “AI-native”

This is like adding a steering wheel to a horse and buggy and calling it a car.

The chat interface itself is borrowed from another decades-old paradigm: IRC, instant messaging, forums. We’re taking a technology designed for human-to-human communication and repurposing it for human-to-computer interaction. Not because it’s optimal, but because it’s familiar.

What bothers me most is that the chat interface requires users to know what to ask for. It puts the cognitive burden on humans to decompose complex tasks into conversational requests. It’s a friendlier command line, sure, but still fundamentally about humans adapting to how computers want to be talked to.

A truly AI-native interface would do the opposite. It would adapt to how humans actually think and work.

The Missing Interface Generation

Between 1984 (original Macintosh) and 2007 (iPhone), the fundamental interface paradigm barely changed. Better graphics, more colors, higher resolutions. But the basic model of windows containing documents, menus containing commands, pointers clicking things stayed constant.

The iPhone disrupted this, but only partially. Touch replaced the mouse. Apps replaced windows. But we still have icons, menus (now called hamburger menus), and a fundamentally application-centric model.

Now we’re in the AI era. And what are we doing? Adding chat to the iPhone paradigm. Adding chat to the WIMP paradigm. Adding chat to everything.

I’m genuinely curious: Where are the interfaces that feel native to AI capabilities? Not chat. Not “traditional UI but you can talk to it.” Something actually different.

What It Might Actually Look Like

I don’t have the answer. If I did, I’d be building it instead of writing about it. But I’ve been collecting examples of what it might not look like, and the patterns are telling.

It probably doesn’t look like files and folders. When AI can understand context and retrieve information based on semantic meaning, why are we still organizing documents hierarchically? That’s a solution to a storage problem from 1960s mainframes.

It probably doesn’t look like applications. The app model assumes discrete tools for discrete tasks. But AI excels at orchestrating across contexts. Why do I switch between email, calendar, and project management when AI could maintain context across all three?

It probably doesn’t look like menus. Menus solve an affordance problem. Discovering what actions are possible. But if AI understands intent, why navigate a menu tree to find “export as PDF” buried three levels deep?

It probably doesn’t even look like screens. We’re assuming the interface is visual because that’s what we know. But we have natural language, voice, spatial computing, gesture control. Why are we still staring at rectangles?

The Economics of Interface Inertia

Here’s a gotcha to consider: No major tech company can afford to reimagine interfaces from scratch. They have millions of users who’ve spent years learning their existing interface. Any radical change means retraining users, support costs, churn risk, competitor advantage.

So they add a chat box and call it innovation.

According to BCG’s 2024 research on AI adoption, only 26% of companies have developed the capabilities to move beyond proofs of concept and generate tangible value from AI. The rest are stuck in what they call the “sandbox”—running pilots, testing features, but not fundamentally reimagining anything.

Those numbers tell you everything. Incremental enhancement, not radical reimagining. It’s the innovator’s dilemma playing out in real-time.

What This Means for CTOs

I’m not suggesting you rebuild your entire product from scratch. That would be insane. But I am curious whether other CTOs are feeling this same cognitive dissonance.

We’re in the middle of a technology shift that feels as significant as the move from command line to GUI. But our response has been to make better command lines that understand natural language, not to imagine what comes after GUIs.

Maybe I’m wrong. Maybe the chat-augmented-WIMP interface is actually the right abstraction for the AI era, and we’ll look back in 20 years wondering what we were worried about.

But I keep thinking about interface paradigms and generational shifts. The WIMP interface was designed for a world that no longer exists. And we’re using AI technology that can understand natural language, maintain context, and orchestrate complex workflows to make that obsolete paradigm slightly more convenient.

The Questions Keeping Me Up

I don’t have answers, but I have questions:

Are we building the right abstraction layer? Right now, AI sits beneath the interface, powering features within the traditional UI. What if AI should be the interface, and the traditional UI should be the implementation detail?

Who’s going to reimagine this? The major tech companies have too much to lose. Consumer AI companies are focused on models and APIs, not interface paradigms. Where does the next generation of human-computer interaction come from?

How long can we coast on WIMP? When does “good enough” become “actively holding us back”?

What are we not building because the interface paradigm constrains our thinking? This is the scary question. How many product ideas never happen because we can’t imagine them within the constraints of windows, menus, and chat boxes?

What I’m Watching For

I’m not waiting for a specific company or product to solve this. I’m watching for patterns. For experiments. For weird prototypes that don’t quite work but feel like they’re pointing somewhere interesting.

I’m watching what happens when companies stop asking “how do we add AI to our product” and start asking “if we were designing this product today, knowing what AI can do, what would it look like?”

I’m watching for the company that has the courage to confuse their existing users in service of building something genuinely new.

And I’m curious what other CTOs are seeing. Are you feeling this same tension? Are you having conversations with your product teams about what comes after chat boxes? Or am I overthinking this, and the chat-augmented interface really is the future?

I genuinely want to know. Because right now, I feel like we’re all building faster horses when someone should be inventing the car.

And I’m not sure if that someone is supposed to be us.

These aren’t just statistics. They represent thousands of CTOs who walked into their offices with grand visions of technological transformation, only to find themselves clearing out their desks before the second annual planning cycle.

A Korn Ferry survey revealed that CIOs average just 4.3 years in their roles, the second-lowest tenure in the C-suite. But here’s what the surveys don’t capture: most of these departures aren’t about better opportunities or natural career progression. The most common causes of CTO failure include struggling to create strategies that support business needs, requiring all major decisions to go through them, and becoming disconnected from the company’s mission.

The pattern repeats across Silicon Valley to Singapore, from Fortune 500s to Series A startups. A brilliant technologist gets promoted to CTO. Within months, they’re drowning. Within a year, they’re disengaged. By year two, they’re gone.

The Pressure Cooker Reality

CTOs experience stress carved deep across multiple dimensions - from development teams, other CxOs, and customers. Unlike the one-dimensional stress of coding, they’re now responsible for aspects that require them to be focused and proactive 16-20 hours a day. Cyberattacks, tech outages and breaches cause stress-related illnesses and impact the mental well-being of 51% of tech executives, reaching 56% among CTO and CIO roles.

The struggle isn’t just personal. Organizations led by CTOs who lack proper leadership skills test low on work engagement and overall morale. Teams complain that every decision needs to go through the CTO, creating bottlenecks that strangle innovation. When a CTO mismanages technological changes, it leads to significant disruptions, project failures, and ultimately, dismissal.

The research reveals something crucial: Companies consistently pick the best technologist instead of picking the best leader who also happens to know technology well. This fundamental misunderstanding of the CTO role creates a perfect storm where technical brilliance becomes organizational dysfunction.

But there’s a pattern among the survivors, the CTOs who make it past the two-year mark and build lasting legacies. They avoid seven specific sins that destroy most of their peers. Successful technology leaders combine technical acumen with leadership skills, understanding that while these capabilities have very little in common, both are essential.

The Seven Sins That Kill CTO Careers

Sin #1: The Product Stranger

One of the most common reasons CTOs fail is their lack of alignment with the business vision. You can architect the most elegant microservices infrastructure on the planet, but if you don’t understand why customers actually pay for your product, you’re building castles in the clouds.

I’ve watched CTOs proudly present their Datadog migration while being unable to demonstrate the actual user workflow of their product. They can explain every technical decision but can’t articulate the problem their company solves. When product managers describe user needs, these CTOs retreat into technical jargon, using complexity as a shield against their fundamental disconnection from the business.

Here’s the harsh truth: if you can’t use your own product competently, you can’t lead its technical development effectively. You become that general who’s never been to the battlefield, making strategic decisions from maps that don’t match the terrain.

The Antidote: Block two hours weekly to use your product as a real user would. Not a demo account, not a test environment, the actual product your customers experience. Feel the pain points. Experience the workflows. Only then can you make technical decisions that actually matter.

Sin #2: The Phantom Executive

Too much micromanagement is a common failure pattern, but the opposite extreme is equally destructive. Some CTOs, scarred by accusations of micromanagement, swing to the opposite extreme. They disappear into C-suite meetings, board preparations, and strategic planning sessions, becoming ghosts to their own teams.

“I was in a 1:1 with a lead engineers a few weeks back and she said that the team misses my presence. The consistency breeds accountability and trust.”

Your team doesn’t just need your decisions, they need your presence. They need you to unblock that architectural debate that’s been raging for three weeks. They need you to ask the uncomfortable questions that everyone’s thinking but no one’s saying. They need you to spot the pattern that connects three separate team problems into one systemic issue.

Where technical leadership seems to work best is when CTOs understand the product in its entirety but also are empathic and have skills in management and leadership. You can’t be empathic from a distance. You can’t lead people you never see.

The Antidote: Institute “CTO office hours”—scheduled time where any engineer can drop in with questions, concerns, or ideas. Walk the floor. Join random stand-ups. Pair program occasionally. Your genius isn’t in your code anymore; it’s in how you multiply the capability of every engineer on your team.

Sin #3: The Financial Blind Spot

A frequent misstep by CTOs is inadequate budget management, which can lead to overspending on unnecessary technologies or underfunding critical areas. Go read my other articles. I write about this a LOT.

I’ve seen CTOs negotiate aggressively for a $50,000 monitoring tool while being completely unaware their engineering burn rate is $2 million per month.

When you don’t understand the financial mechanics of your company, you become a cost center, not a profit enabler. You make arguments based on technical elegance rather than ROI. You get surprised when your headcount gets frozen. You get blindsided when the CFO questions your infrastructure spend.

Most damaging: When executives don’t demonstrate how technological advancements align with business goals, stakeholder confidence dwindles. Without financial literacy, you literally can’t speak the language of business value.

The Antidote: Learn to read a P&L statement. Understand your company’s unit economics. Calculate the fully-loaded cost of your engineering team (hint: it’s not just salaries). Track your department’s ROI monthly. When you propose a technical initiative, lead with the financial impact, not the technical architecture.

Go check out my CTO Ratio.

Sin #4: The Innovation Graveyard

The most valuable skill of a CTO is making timely decisions, but when you’re drowning in operational minutiae, strategic thinking dies. You become a highly-paid project manager, tracking tickets instead of setting technical vision.

CTOs trapped in operational drudgery stop creating. They stop innovating. They stop inspiring. They become administrators of the status quo, and in technology, the status quo is death. In larger companies, you won’t have time to work on the product directly, but that doesn’t mean you should stop creating entirely.

The Antidote: Audit your calendar ruthlessly. If less than 30% of your time is spent on forward-looking initiatives (new architectures, emerging technologies, strategic partnerships), you’re already in trouble. Delegate operational responsibilities. Build systems and processes that run without you. Your job is to see around corners, not to manage today’s traffic.

Sin #5: The Reactive Spiral

CTOs need to be focused and proactive 16-20 hours a day, but without intentional calendar management, you become purely reactive. Your week becomes a random collection of whatever meetings others scheduled, whatever fires erupted, whatever Slack threads exploded.

When you don’t plan your week, you don’t plan your impact. Monday bleeds into Friday without any coherent arc. You end each week exhausted but unable to articulate what you actually accomplished. Your team sees you as perpetually busy but never available for what matters.

The Antidote: Design your week like you’d design a system architecture. Monday is for momentum—reviewing metrics and setting weekly priorities. Wednesday is for deep work on strategic initiatives. Friday is for reflection and communication. Create themed days that force different types of thinking. Your week should have a beginning, middle, and end, not just be five interchangeable days of chaos.

Go check out my suggestion for the CTO’s Perfect Week.

Sin #6: The Invisible Executive

Not enough communication is a big failure factor that affects all aspects of the CTO role. Your CEO has no idea what you do all day. Your peers think you’re just the “tech person.” The board sees IT as a cost center. Meanwhile, you’re orchestrating digital transformation, but nobody knows it.

When you don’t communicate your wins, challenges, and vision, you become invisible. And invisible executives become expendable executives. The cause of CTO failure is often the result of promoting a person solely upon their technical capabilities without considering communication skills.

The Antidote: Send a weekly “CTO Update” to your C-suite. Include wins, challenges, and strategic initiatives. Translate technical achievements into business impact. Use analogies and stories, not jargon. Make your work visible, tangible, and tied to company objectives. If people don’t understand what you do, that’s your failure, not theirs.

Sin #7: The Expertise Fossil

Perhaps the most insidious sin: stopping your own learning. You’re so busy fighting today’s fires that you stop building tomorrow’s capabilities. You’re not writing, not documenting, not building your own knowledge base. You’ve become a consumer of your past expertise rather than a creator of new understanding.

Technology develops at a pace unmatched by any other construct—what is created one day can be broken, fixed, redesigned and expanded the next. When you stop learning, you start dying professionally. Your advice becomes dated. Your architectures become legacy. Your strategies become obsolete.

The Antidote: Maintain a CTO notebook. Write about your decisions, your learnings, your failures. Document patterns you observe. Build your own knowledge base that transcends any single company or role. Remember: you’re not working for your company—you’re working for yourself, building expertise that compounds over decades, not quarters.

Why These Sins Matter More Than Ever

Technology executives are outpacing their C-suite peers in switching companies, and companies face significant risks as new technologies unfold around them. With AI transformation demanding unprecedented technical leadership, companies can’t afford CTOs who fail. Yet most are setting their CTOs up for exactly that.

If you’re a CTO, there’s a statistical likelihood you won’t make it to your third year. If you’re running a company of 40-100 engineers, you’re managing millions in salary costs while potentially committing one or more of these sins daily. Each sin compounds, creating a cascade of dysfunction that ends with either your resignation letter or your termination notice.

Your 30-Day Redemption Plan

Start with brutal honesty. Which of these sins are you committing right now? Not which ones you might be slightly guilty of—which ones are actively destroying your effectiveness today?

Pick your worst sin. The one that makes you uncomfortable to acknowledge. That’s where you start.

Week 1: Face the Truth

• Use your product for 2 hours

• Calculate your department’s monthly burn rate

• Count how many hours you spent with your team versus in C-suite meetings

• Review your calendar for the past month. How much was reactive versus proactive?

Week 2: Break the Silence

• Send your first weekly update to the C-suite

• Schedule office hours with your team

• Start a simple knowledge document. Just one page of learnings from this week

Week 3: Master the Numbers

• Meet with your CFO to understand the company’s unit economics

• Calculate the ROI of your last three technical initiatives

• Create a simple dashboard of your department’s financial metrics

Week 4: Reclaim Your Strategy

• Block 4 hours for strategic thinking (no meetings, no Slack)

• Design your ideal week with themed days

• Document three technical innovations that could transform your business

The Compound Effect of Recovery

The first month will feel uncomfortable. You’ll realize how disconnected you’ve become from your product, your team, or your company’s finances. That discomfort is growth.

By month two, patterns emerge. You’ll spot inefficiencies you were blind to. Your team will start approaching you with bigger ideas, knowing you’re available and interested. Your C-suite peers will begin seeing you differently, not as the “tech person” but as a business leader who happens to run technology.

By month three, the compound effect kicks in. Your strategic initiatives gain momentum. Your team’s morale improves. Your stress decreases even as your impact increases.

The Crossroads Decision

CTOs are switching jobs at unprecedented rates, most believing the grass is greener elsewhere. But they take their sins with them. The same patterns that failed them in one role follow them to the next.

Or you can choose differently. You can recognize these sins not as personal failures but as systemic traps that catch most CTOs. You can build systems and habits that make these sins impossible to commit.

The research is clear: most CTOs fail within two years. The question isn’t whether you’ll face these challenges. You will. The question is whether you’ll recognize them as the seven deadly sins they are and build the discipline to avoid them.

Your team needs you to be better than the statistics. Your company needs you to break the pattern. Most importantly, you need to prove that technical leadership isn’t an oxymoron. Someone can be both a great technologist and a great leader.

The sins are deadly, but they’re not inevitable. The choice, and the work, begins today.

Start with one sin. Build one habit. Send one update. Use your product once.

Small actions compound into transformation. But only if you start.

Don’t be another statistic. Be the CTO who survived their seven sins and built something that lasted.

See you at 7CTOs.

Etienne de Bruin <3

References

Burnout and Executive Stress

“Executive burnout statistics 2025: A look into the leadership crisis.” Superhuman Blog, June 11, 2025. https://blog.superhuman.com/executive-burnout-statistics/

“How To Avoid A CTO Meltdown (Warning Signs).” Codemotion Magazine, January 5, 2022. https://www.codemotion.com/magazine/dev-life/cto/avoid-meltdown/

“Pain points for CTOs: A primer of the most stressful aspects of the job.” Help Net Security, December 4, 2019. https://www.helpnetsecurity.com/2019/11/29/cto-stress/

“What about tech leadership makes burnout more likely?” CTO Craft, October 7, 2024. https://ctocraft.com/blog/what-about-tech-leadership-makes-burnout-more-likely/

CTO Tenure and Turnover Statistics

“Age and Tenure in the C-Suite: Korn Ferry Study Reveals Trends by Title and Industry.” Business Wire, January 21, 2020. https://www.businesswire.com/news/home/20200121005146/en/

“Chief Technology Officer Demographics and Statistics [2025].” Zippia, January 8, 2025. https://www.zippia.com/chief-technology-officer-jobs/demographics/

“CTO roles are the hardest C-suite position to fill—and turnover is high.” Fortune, February 22, 2023. https://fortune.com/2023/02/21/chief-technology-officer-in-demand-retention-job-hop-cto/

“Why is the turnover rate so high for technology leaders?” RetailWire, May 23, 2024. https://retailwire.com/discussion/why-is-the-turnover-rate-so-high-for-technology-leaders/

CTO Failure Patterns and Mistakes

“8 Reasons Why Chief Technology Officers (CTOs) Get Fired [2025].” DigitalDefynd, November 15, 2024. https://digitaldefynd.com/IQ/reasons-why-ctos-get-fired/

“10 Common CTO Mistakes and How to Avoid Them [2025].” DigitalDefynd, November 15, 2024. https://digitaldefynd.com/IQ/mistakes-ctos-must-avoid/

“CTO Failure Stories: How to Learn from the Failed CTOs in Startups.” FasterCapital. https://www.fastercapital.com/content/CTO-Failure-Stories--How-to-Learn-from-the-Failed-CTOs-in-Startups.html

“Dead on Arrival: Today’s CTO & CIO.” LinkedIn article by Marc Moskowitz. https://www.linkedin.com/pulse/dead-arrival-todays-cto-cio-marc-moskowitz

“The Problems of the CTO Role.” HackerNoon, February 10, 2018. https://hackernoon.com/the-problems-of-the-cto-role-c2a143a1cec7

“Why CTOs Fail and What CEOs and CTOs Can Do About It.” AKF Partners. https://akfpartners.com/growth-blog/why-ctos-fail

Read more

My CEO calls me into a conference room on a Tuesday afternoon. My lead engineer is already the…

Read more