The Hardest Refactor You'll Ever Do
I had a conversation with Adam Horner recently that took me back to one of the most painful moments of my career. In 2008, My co-founder pulled me aside and said, "You know you have to stop coding, right?"

I had a conversation with Adam Horner recently that took me back to one of the most painful moments of my career. In 2008, My co-founder pulled me aside and said, "You know you have to stop coding, right?"
I thought he was insane.
I'd built my entire identity on being able to pull out MVPs in 24-hour sprints that blew everyone's minds. I could see patterns others missed. I could architect solutions in my sleep. And now he was telling me my code was the problem?
Turns out my developers had gone to the CEO asking him to please, please make me stop submitting PRs.
That hurt.
When Being Right Is Dead Wrong
Here's what nobody tells you about becoming a CTO: you're probably right about the technology. You really are. After coaching thousands of CTOs, I've seen this pattern over and over. When CTOs argue about technology strategy, question the market, or cry about C-suite competency—in most cases, they're actually correct.
We're prediction machines. We can observe inputs, calculate complexity, and forecast outcomes with scary accuracy. That's our superpower.
But it's also our kryptonite.
Because what we absolutely suck at is being wrong about the stuff we're terrible at. Like reading the room. Understanding that the CEO's question about hiring 50 engineers yesterday isn't actually about the hiring funnel—it's about a vote of no confidence they just received.
I learned this the hard way through ontological coaching. A CTO came to me asking for hiring advice. My old self would've rattled off LinkedIn strategies and referral programs. Instead, I listened to his language. Within 40 minutes, he was weeping. The real problem wasn't hiring—it was that he needed to solve the problem himself, not delegate it.
The Four Things That Actually Matter
After a decade of running 7CTOs and coaching hundreds of leaders, I've distilled the CTO's responsibility down to four sentinels. Not technologies. Not methodologies. Four fundamental responsibilities that don't change whether you're working with containers or quantum computers:
Speed - You're never getting an out on delivery. I don't care how charismatic or businessy you are. If you're not shipping, you're not even meeting the baseline.
Stretch - Can you look at your organization and articulate the gaps? Not "I'll figure it out" or "I'll build it myself." Can you tell your company what it costs and attract the people needed to build what the company needs? Stretch isn't fun. Nobody likes stretching. But you have to do it.
Shield - From vulnerability scanning to threat modeling to protecting IP. But here's what most CTOs miss: can you go to your C-suite and say, "Hey, I built something that could open new revenue streams"? Slack started building one thing and the CTO built something else. They bet on it. That's shield.
Sales - Show me a CTO loved by their sales team, and I'll show you someone who gets it. Find out what success looks like for your other C-suite members and enable it. That's how you build advocates for when things get tough.
The Math That Changes Everything
Want to know the real game changer? Learn CORE: Cost of goods sold, Operating expenses, Revenue, Earnings.
Walk into a board meeting fluent in these numbers and you become irresistible. You stop being "the technical person" and become a business leader who happens to understand technology better than anyone else in the room.
I put this at ctocore.org because I'm that passionate about it. If you can speak the language of the executive team—which is essentially finance plus domain-specific context—you can probably double your salary. I'm not exaggerating.
From Boiling to Liquid
This thinking is what led to my new book "Liquid" with Kathy Keating and Scott Graves. We follow two founders building a startup through the invisible systems causing chaos. Organizations exist in states: boiling (everything's on fire, no rules, constant bugs) or frozen (so many rules nothing moves).
The art of leadership is staying liquid—that constant rebalancing act as complexity grows exponentially with every new person, feature, customer, and system you add.
What Got You Here Won't Get You There
The transition from builder to leader is the hardest refactor you'll ever do. And here's the thing—you can't debug humans like code.
My advice to every new CTO? Learn the business. Understand the product. Learn the business.
Not the technology. You already know that. Learn what makes money, what loses money, what the growth engine looks like, and how your technology fuels it.
Because the CTOs who succeed aren't the best coders. They're the ones who learned to lead humans, not just systems.
And yeah, that means letting go of the code. Even when it feels like losing part of yourself.
Trust me, what you gain is worth it.
Etienne de Bruin is the founder of 7CTOs and co-author of "Liquid." He helps CTOs transition from technical excellence to human leadership. Find him at etiennex.com or connect on LinkedIn.