I was on a call with a group of tech leaders in New Zealand recently—Auckland, Wellington, Palmerston North—and I started with this:

For every initiative you introduce, there is an equal and opposing force in your organization.

Think about that. Think about the last big thing you tried to change. The new hire from a fancy company who never shipped a single PR in three weeks. The product team that built a roadmap your engineers ignored. The two teams that somehow shipped conflicting features. Everyone was excited at the kickoff meeting. Three months later? Everything was back to normal.

What the hell happened?

The Numbers Don't Lie (But They Might Be Exaggerated)

You've probably heard the statistic: 60-70% of organizational change initiatives fail. It gets thrown around in boardrooms and business school lectures like gospel.

But when researchers actually traced that number back to its source, they found the evidence was shakier than anyone wanted to admit. One critical review found "the absence of valid and reliable empirical evidence" behind the oft-cited 70% failure rate.

But here's what is empirically validated: Only 38% of employees today are willing to support organizational change—down from 74% in 2016. That's a collapse in change readiness over just six years. And 80% of employees report experiencing "cultural tensions" during change—competing priorities they don't know how to balance.

The failure rate might be debatable. The resistance isn't.

So what's actually happening when your initiative dies three months after launch?

The Machine Fallacy

Here's what I've heard for most of my tech career: we think of our tech organizations as machines. Input goes in, output comes out. Hire better people, get better results. Fix the process, fix the problem.

It's bullshit.

Your organization is a complex adaptive system. And until you understand that, you'll keep treating symptoms while the disease spreads.

This isn't metaphor. It's established organizational theory.

Back in the early eighties, a group of researchers locked themselves away at the Santa Fe Institute and asked a fascinating question: why do things seem to organize themselves without any external force? The immune system. The internet. The way a crowd disperses after a soccer game. John Holland eventually defined what they discovered: complex adaptive systems—systems "composed of elements, called agents, that learn or adapt in response to interactions with other agents."

Since the 1990s, researchers have applied CAS theory directly to organizations. The academic literature is clear: organizations exhibit fundamental CAS principles like self-organization, emergence, interdependence, and co-evolution. Changes in one part of the system ripple unpredictably through the whole. The system learns and adapts whether you want it to or not.

This means you're dealing with interconnected entities that create emergent properties you can't predict or control. It means the reactions to your changes will be non-linear. You can cool water for a long time and nothing happens, then suddenly. Ice! Your organization works the same way.

The Four Sentinels (And the Forces That Destroy Them)

When I built the CTO Levels Framework, I started with a question: what does a healthy technology organization actually look like?

It comes down to four emergent properties and this is what I call the Four Sentinels:

Speed. Your ability to deliver technology quickly.

Stretch. Your ability to adapt and grow into the future.

Shield. Your ability to protect yourself.

Sales. Your orientation toward revenue.

These aren't things you can just turn on like a switch. They emerge from the behavior between interconnected people in your organization. And here's the more ominous part: each one of them carries a hidden force that can destroy you.

When you optimize for Speed, you risk fragility. Manual deployment processes. Triple-checking each other's work. Or worse, no checking at all. Lean security profiles. You move fast and build a house of cards.

When you optimize for Stretch, you risk bureaucracy. Remember when it was two pizzas, some Cokes, and coding at 2am? Then Series A happened. Now someone needs permission from someone who needs to ask someone else. Congratulations on your gloriously baked-in bureaucracy.

When you optimize for Shield, you risk paranoia. Compliance becomes your religion. Every change requires a committee. Innovation dies in the approval queue.

And Sales (this one's my favorite). When you optimize for connecting with the business, you risk being misunderstood. Why do you always say no? Why are you never happy? Why do you want to build your own thing instead of what we asked for? It's a lonely place to be. You were catalytic and forward-thinking with five people. Now with fifty, you're the guy nobody understands, they don't want you pushing to production anymore, and you start having your own issues.

What Great Teams Actually Do

Let's take a closer look.

Dr. Nicole Forsgren, along with Gene Kim and Jez Humble, spent years studying what separates high-performing technology organizations from everyone else. Their research, conducted through DevOps Research and Assessment (DORA) and published in Accelerate, surveyed tens of thousands of professionals across hundreds of organizations.

Their findings are striking: elite performing teams deploy multiple times per day, maintain change failure rates below 1%, and recover from failures in under six hours. These teams show 50% higher market capitalization growth and reach market 2.5 times faster than their competitors.

But here's the insight that changed how I think about tech organizations: there is no tradeoff between speed and quality over the long term. Elite teams don't sacrifice stability for velocity. They achieve both because they've built the right foundations.

This is why Levels 0-1 of the CTO Levels Framework focuses on what might seem basic: automated CI/CD, trunk-based development, infrastructure as code, the ability to deploy multiple times per day. These aren't nice-to-haves. According to DORA's research, they're the difference between elite performance and mediocrity.

If you can't deploy five times a day, you're arguing about monthly release cycles and who's gonna plan them. You're struggling with Level 4 problems when you've got a Level 0 fix sitting right there.

The Real Problem Is Never the Problem

A CTO came to me recently. Seventeen engineers, SaaS company. Their lead engineer quit. Two teams shipped conflicting features. A new hire hadn't merged a single PR in three weeks. The product team built a roadmap that engineering ignored.

Sound familiar?

Conventional wisdom says: better benefits to retain people, set up meetings between product and engineering to duke it out, create more process.

But those are symptoms, not causes.

Let's talk about that new hire for a second. Research shows that 28% of new hires quit before reaching 90 days on the job. Half of senior outside hires fail within 18 months. And here's the kicker: only 12% of employees strongly agree their organization does a great job of onboarding.

When organizations do nail onboarding—with clear values, defined playbooks, structured integration—they see 82% better retention and 70% higher productivity. The difference isn't the talent. It's the foundation.

When we did a Levels assessment on this CTO's organization, we found they were operating as a Level 4 organization (based on team size and budget), but they were stuck at Level 2. The foundation was cracked.

They were trying to build job ladders and team topologies, Level 4 activities, but they'd never defined engineering values or playbooks. How do you build ladders on quicksand?

They wanted better product collaboration, but the team had never truly aligned on the MVP. There was no shared foundation to collaborate around. No wonder the new hire couldn't ship. There was nothing solid to ship into.

How often does your CEO or client come to you with a hot-button issue that you and I both know isn't the real issue? You can cash in on that retainer by quickly addressing the symptom. Or you can do the hard work of going beneath the surface, understanding the complex adaptive system at play, and finding that the solution is actually different.

The Principle That Predates Agile

In 1975, decades before anyone coined "Agile" or "MVP", a pediatrician named John Gall published Systemantics: How Systems Work and Especially How They Fail. He'd spent years observing how complex systems behave, and he articulated something that software engineers would rediscover again and again:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

This became known as Gall's Law, and it's been quoted by systems designers since Ken Orr cited it in 1981 and Grady Booch popularized it in the 1990s.

What strikes me about Gall is that he wasn't a software engineer. He was a doctor. He observed that systems, whether biological, organizational, or technical, fail in predictable ways. The immune system. Hospital bureaucracies. Software architectures. The pattern is the same.

The companies I see struggling most are the ones who skipped steps. They built for Level 4 complexity when they hadn't solved Level 0 problems. They designed the complex system from scratch instead of evolving it from something simple that worked.

The AI Conversation (With Actual Data)

On the New Zealand call, someone asked about AI pressure. Their board wants to see AI everywhere. The CEO thinks they should get 50% productivity gains. Maybe 10x if they really commit.

Here's what the research actually shows.

Microsoft, MIT, Princeton, and Wharton ran randomized controlled trials with over 4,000 developers. The result? Developers using GitHub Copilot achieved a 26% increase in completed pull requests. A separate controlled experiment found developers completed tasks 55.8% faster with AI assistance.

That's significant. But it's not 10x. It's not even 2x in most real-world conditions.

And here's the part your CEO probably doesn't want to hear: experienced developers see less benefit than juniors. The research found that developers above median tenure showed "no statistically significant increase in productivity" from AI tools. Senior engineers are less likely to write better code with Copilot, though it does help them work faster on unfamiliar languages and automate repetitive tasks.

So when your CEO says "I expect 10x productivity from AI," you now have ammunition. The largest randomized controlled trials ever conducted on AI coding assistants found 26-56% improvement, not 1000%. And that improvement skews toward junior developers and routine tasks.

What I told the group in New Zealand: No one on that call, no one reading this, knows what six weeks from now looks like. We're all speculating.

And here's the thing that's changed: the acquisition of knowledge has essentially evaporated. Your CEO can walk into a C-suite meeting having asked an LLM to explain whatever you're about to present. They can take what you said, feed it to Claude, and ask "Is my CTO full of it?" They can take the transcript of your Zoom call and get three bullet points on how to challenge you.

The expert card doesn't work anymore.

So what do you bring instead? Relationships. Curiosity. Trust. The soft skills that LLMs can't replicate yet. When your CEO says "we need AI in our product," your job isn't to argue about whether it's the most significant feature. Your job is to demonstrate that you're open, curious, and exploring together.

What I won't accept? A mandate to fire half my team and replace them with AI. That's not strategy. That's panic dressed up as innovation.

Scaling Is Blocked by Invisible Forces

In the C-suite, we love to blame lack of vision. "We lost our way." "The new CEO doesn't get it."

Some of that might be true. But I'd invite you to consider: scaling is actually blocked by invisible forces. And if you have the patience to be meticulous and curious, to wonder what's happening underneath while everyone argues at the surface level, you might actually fix something.

Remember Gall's Law: any system designed to be complex from the start will fail. But any system that starts simple can eventually succeed as it becomes more complex.

So the question becomes: what does simple look like at Level 0? At Level 1? Have you nailed the code block? Automated CI/CD? Can your developers deploy five times a day, or are you all arguing about monthly release cycles?

The DORA research proves this isn't just philosophy. Elite teams—the ones with 50% higher market cap growth—deploy multiple times daily. They didn't get there by skipping foundations. They evolved from simple systems that worked.

The Real Work

The Levels framework isn't magic. It's a suggestion for how to look beneath the surface. You can do your own assessment. Have you nailed the code block? The values block? Infrastructure as code? Then ask yourself: how might this be causing the strain we're experiencing at the surface?

Because the thing that everyone thinks is the problem? It's rarely the problem.

And the thing that would actually fix it? It's usually something you skipped over, deemed unimportant, or thought you could address "later."

Later is now.

If you want to dig deeper into the Levels Framework, it's all free at ctolevels.com. And if you're a CTO or technical leader who's tired of solving the wrong problems, the 7CTOs community might be worth exploring. We run calls every week across multiple time zones—hundreds of CTOs processing real challenges together.

Because scaling a company means scaling yourself. And you can't do that alone.

References

Complex Adaptive Systems:

• Holland, J. (2014). Complexity: A Very Short Introduction. Oxford University Press.
• Anderson, P. (1999). "Complexity Theory and Organization Science." Organization Science.

Organizational Change:

• Errida, A. & Lotfi, B. (2021). "The determinants of organizational change management success." SAGE Open.
• Hughes, M. (2011). "Do 70 Per Cent of All Organizational Change Initiatives Really Fail?" Journal of Change Management.

DORA Metrics:

• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
• DORA State of DevOps Reports (2014-2024). Google Cloud.

AI & Developer Productivity:

• Peng, S. et al. (2023). "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot." Microsoft Research.
• Ziegler, A. et al. (2022). "Productivity Assessment of Neural Code Completion." GitHub/ACM.

Systems Design:

• Gall, J. (1975). Systemantics: How Systems Work and Especially How They Fail. General Systemantics Press.

Onboarding & Retention:

• Brandon Hall Group (2017). "The Impact of Strategic Onboarding."
• SHRM (2018). "Onboarding New Employees: Maximizing Success."