Nobody writes a five-year plan that says “accidentally become a CTO.” I certainly didn’t.
My career started the way most engineering careers do: heads down, compiler errors, the satisfying green of passing tests. I was good at building things. That was enough, or so I thought.
The first time someone called me “lead” it felt like a typo on an org chart. I was still writing production code, still reviewing pull requests, still arguing about tabs versus spaces in standup. The title changed. The work didn’t.
The transition nobody prepares you for
Here’s what nobody tells you about the engineer-to-leader jump: you don’t stop being an engineer. You just start carrying a second job that nobody trains you for.
At Wells Fargo, I was running a team before I had the vocabulary to describe what “running a team” actually meant. I knew how to debug a distributed system. I did not know how to debug a struggling direct report who was burned out and hadn’t told anyone yet.
The technical skills that got you the title are necessary but insufficient. The real work is learning to operate in ambiguity, to make decisions with incomplete information, and to absorb uncertainty so your team doesn’t have to.
The servant leader isn’t a metaphor
I’ve since come to believe that “servant leadership” isn’t a management style. It’s the only style that scales.
At Hive42, we built a system that automates work around the clock. The technology works because of the team behind it, and the team works because of clarity of mission and psychological safety.
Servant leadership means your job is to make everyone else’s job easier. Not softer. Easier. Remove blockers. Clarify priorities. Shield the team from organizational noise. Make it possible for smart people to do their best work without spending energy on things that don’t matter.
What I’d tell my younger self
If I could go back to that first “lead” title and give myself advice:
First, trust your instincts. You probably already know what the right call is; you’re just scared of the consequences. Make the call anyway.
Second, read more broadly. Technical depth matters, but the leaders who compound their impact are the ones who understand business context, organizational dynamics, and human motivation alongside systems architecture.
Third, say “I don’t know” more often. It signals you’re learning, and it gives everyone permission to be honest about what they don’t know either.
The best leaders I’ve worked with never had all the answers. They asked the right questions and then got out of the way.