Title: Lessons Learned from Five Years as a Startup CTO: What I Got Wrong and How I Adjusted
After serving as CTO for two fintech startups in succession, from 2019 to 2024, I took time to write down the missteps and lessons from that period. Both companies were early-stage, under 10 people, and built products where real money moved between businesses and governments. I started documenting the messy realities—the moments when there were three people, no GitHub repository yet, and the team was juggling code, hiring, founder expectations, and setting up laptops.
Where my time actually went
– 40%: Writing code
– 20%: Translating between founder speak and engineer speak
– 15%: Operations and admin (vendor calls, tooling, onboarding)
– 15%: People (hiring, feedback, unblocking)
– 10%: Unclassifiable tasks
I disliked that split and wished it reflected more coding. I had built my identity around being a strong programmer, yet I found myself managing tickets and processes, which felt like a detour from engineering focus.
Key mistakes I made and the hard truths I eventually faced
– Treating every architecture decision as permanent. In a startup with roughly 18 months of runway, nothing is permanent. Ship, learn, adjust. I spent weeks overanalyzing things that were likely to be replaced six months later.
– Underappreciating the operations side because it didn’t feel “real work.” I once spent an entire day organizing the workflow system and hated the lack of immediate gratification. Yet, it was essential to long-term velocity.
– Hiring for technical skill over judgment. An engineer who can make solid calls without constant direction is worth more than three who need hand-holding on every decision. It took two startups to internalize this.
– A moment of humility and realization. An engineer asked the founder what they should work on next, and the founder relayed it to me. I was mortified, felt exposed, and realized that merely writing code and shipping features wouldn’t suffice. Leadership was required.
– Being in every PR, Slack thread, and meeting can feel productive, but it often isn’t. The team could have shipped faster without me in many of those conversations. Stepping back felt like losing control, but it wasn’t; it was part of the job.
– The most painful but transformative lesson: honesty about gaps made me a better CTO. Acknowledging where I fell short—first to myself, then to the team—allowed us to hire for those gaps. It’s counterintuitive, but owning weaknesses can improve overall performance.
Curious to hear from others
Has anyone else navigated a similar path? I’m especially interested in what surprised other first-time CTOs or engineering leads, and how their views on leadership and technical decision-making evolved over time.
