The CTO Who Didn't Code

The Snobbery of the IC

As a Senior Engineer, I was an elitist. I believed that if a manager couldn't open Vim and fix a race condition, they had no business leading me.

"How can they make decisions if they don't understand the code?" I sneered.

Then I met Sarah. Sarah was our new CTO. Her background was in Product and Operations. She hadn't written production code in 10 years. I prepared my resignation letter.

Two years later, I consider Sarah the best technical leader I have ever worked for.

The Job of the CTO

I misunderstood the job. I thought the CTO was the "Best Coder."

But the CTO's job isn't to write code. The CTO's job is to:

1. Align Engineering with Business: Sarah stopped us from spending 6 months rewriting the frontend in a new framework because "it's cool." She forced us to explain how it would increase user retention. We couldn't. We saved 6 months.
2. Protect the Team: When the CEO demanded a feature by Friday, Sarah didn't ask us to crunch. She sat down with the CEO, explained the "Iron Triangle" of project management (Fast, Good, Cheap - pick two), and negotiated a smaller scope. She absorbed the pressure so we could focus.
3. Build the Machine: Sarah didn't build software; she built the team that built the software. She fixed our hiring pipeline. She instituted clear career ladders. She fought for our budget.

The Trap of the "Coding CTO"

I've also worked for the opposite: The Founder/CTO who is a genius hacker.

It was a disaster.

He would parachute into the codebase at 2 AM, rewrite core libraries without telling anyone, and break everyone's build. He critiqued variable names in PRs but ignored the fact that half the team was quitting due to burnout. He was a great coder, but a terrible leader.

He was playing "Hero," not building a system.

Technical Empathy > Technical Skill

Sarah didn't code, but she had Technical Empathy.

She understood the concepts. She understood technical debt. She understood that "refactoring" wasn't just "wasting time." She trusted us to make the implementation decisions, but she held us accountable for the business outcomes.

She knew enough to ask the right questions: "What is the tradeoff here?" "What happens if this service goes down?" "Are we locking ourselves into a vendor?"

Those are the questions that matter at the executive level. Not "did you use a map or a reduce?"

Conclusion

If you are an engineer looking at leadership, stop worrying about whether your coding skills will atrophy. They will. And that's okay.

Your new code is the organization. Your new bugs are misaligned incentives. Your new refactoring is organizational design.

Respect the non-coding leader. They are doing the work that lets you do yours.