Three years ago I was shipping features alone at midnight, proud of every line I wrote. Today I lead an engineering team at The Localstreet and haven’t written production code in three months. The strangest part? I’ve never had more impact.
The transition from developer to CTO is one of the least documented career moves in tech. There are thousands of books on engineering, hundreds on management — but almost nothing on the specific shift from doing the work to enabling others to do better work than you could alone.
This is what I actually learned.
Your Identity Has to Change First
The hardest part of becoming a technical leader is not learning management. It’s unlearning your identity as an individual contributor.
For years, my self-worth was tied to my output. PRs merged. Features shipped. Bugs squashed. The day I became CTO, that feedback loop broke. Now a good week might look like: one-on-ones with five engineers, a product roadmap review, a hiring interview, and an architectural decision doc. Zero code.
Early on I kept sneaking back into the codebase. Reviewing PRs in detail. Rewriting code in reviews. It felt productive. It wasn’t. It was me avoiding the discomfort of a new kind of work.
The shift happened when I realised: a developer’s job is to be the best engineer they can be. A CTO’s job is to make every engineer on the team better than they would be otherwise.
If I write the code, I’ve removed a learning opportunity from someone who needs it more than I do.
Technical Depth Still Matters — But Differently
People will tell you “once you’re in leadership, you don’t need to stay technical.” That’s wrong. But the nature of the technical work changes.
As an IC, I needed deep expertise in the implementation. As CTO, I need deep expertise in consequences. What does it mean to choose MongoDB over PostgreSQL for this use case — not just for today, but for the team’s velocity in 18 months, the operational overhead, the backup story, the hiring pool?
The questions change:
- Not “how do I implement this?” but “what are the failure modes of each approach?”
- Not “what’s the best algorithm?” but “what’s the tradeoff between build vs. buy vs. open source?”
- Not “how do I fix this bug?” but “why did our system allow this bug to reach production?”
I spend about 4 hours a week reading: release notes, architecture blogs, post-mortems from companies at our scale. This keeps my mental model of the landscape current without requiring me to maintain deep implementation expertise in everything.
Hiring Is Your Most Leveraged Skill
I used to think hiring was admin work. I was catastrophically wrong.
A single bad hire in a small team can destroy morale, slow delivery, and cost you 6-12 months to resolve. A single exceptional hire can multiply the output of everyone around them.
What I’ve learned about hiring senior engineers:
Don’t hire for what you need today. By the time someone starts, ramps up, and is fully productive, your needs will have changed. Hire for trajectory and learning velocity.
The best engineers ask great questions in interviews. They want to understand the system, the constraints, the team. A candidate who only talks about their own achievements without genuine curiosity about your problems is a yellow flag.
Reference calls are underrated. I ask: “What’s the hardest feedback you gave them? How did they respond?” The answer tells me more than the entire interview.
Culture fit vs. culture add. I stopped hiring people who fit our existing culture perfectly. I hire people who share our values but bring perspectives we don’t have. Homogenous teams have homogenous blind spots.
Making Decisions With Incomplete Information
As a developer, you wait until you understand a problem before solving it. As a CTO, you often have to decide before the picture is clear — because waiting for clarity has its own cost.
The framework I use:
-
What’s the reversibility? Reversible decisions (feature flags, architecture experiments, process changes) should be made fast with less information. Irreversible decisions (key hires, major infrastructure migrations, data architecture) warrant more time.
-
What’s the cost of being wrong? A wrong decision that surfaces in a week and can be corrected is much better than a “right” decision made three months later.
-
Who’s closest to the problem? The best person to make technical decisions is usually the engineer who lives with that code daily, not me. My job is to set the context, not make every call.
The worst thing you can do as a technical leader is become the bottleneck for every decision. Give your team the context to make good decisions, and get out of the way.
The Loneliness Nobody Talks About
This is the part that surprised me most.
When you’re an engineer, you have peers. People who understand exactly what you’re working on. You can complain about a frustrating bug and they’ll commiserate. You can share a clever solution and they’ll appreciate the craft.
When you’re a CTO at a startup, you’re often the only person who holds all the context — the technical constraints, the business pressures, the team dynamics, the investor expectations. The problems you’re wrestling with often can’t be shared widely.
What helped me: finding a peer network of other CTOs and technical founders. Not for advice specifically, but for the relief of talking to someone who understands the weight of the role. Twitter/X, Slack communities, local startup events — these communities exist and they’re genuinely valuable.
What I’d Tell Myself Three Years Ago
-
Your first 90 days are about listening, not doing. Resist the urge to change everything. Learn the system — technical and human — before you redesign it.
-
Write things down obsessively. Architecture decisions, hiring principles, what you’re optimising for this quarter. Writing forces clarity and creates a record that outlasts any individual.
-
Protect your engineers from organisational noise. Product pivots, investor questions, company stress — your job is to keep your team in a state where they can do great work. Shield them from what they can’t control.
-
You will make mistakes that affect real people. That’s different from shipping a buggy feature. Sit with that responsibility. It makes you more careful and more human.
-
The best technical leaders are great communicators. Not just with their team — with the board, with customers, with non-technical stakeholders. The ability to translate technical complexity into business language is the highest-leverage skill you can develop.
The transition is hard. It’s supposed to be. The difficulty is proportional to how much the role matters.