Everyone shows their wins. Here are my losses. The mistakes I made, the lessons I learned, and what I'd do differently.
"Experience is what you get when you didn't get what you wanted." — Randy Pausch
When scaling from 15 to 89 people, I prioritized speed over fit. We had open positions and pressure to fill them. I lowered the bar on some hires because we "needed bodies." Then when it was clear someone wasn't working out, I waited too long to act, hoping things would improve.
Team morale suffered. High performers got frustrated covering for underperformers. Projects slipped. By the time I acted, the damage was done. Some of my best people had already mentally checked out.
I built a microservices architecture for a product that had 100 users. I was so focused on "doing it right" and "building for scale" that I created complexity we didn't need. Service mesh, event sourcing, CQRS — the whole enterprise playbook for a startup.
Development slowed to a crawl. Simple features took weeks. Debugging across services was a nightmare. New developers took months to onboard. We spent more time maintaining infrastructure than building product.
For years, I thought being a great engineer was enough. I built amazing products and waited for people to discover them. I saw sales as manipulative, something for "business people." I was too proud to ask for what I wanted.
Good products died in obscurity. I missed opportunities because I didn't advocate for myself. Colleagues who were worse engineers but better communicators advanced faster. I stayed in my comfort zone while the world moved on.
I wore 80-hour weeks like a badge of honor. Sleep was for the weak. I missed family events, ignored my health, and convinced myself it was temporary. "Just until we ship this feature." "Just until we close this round." The goalposts kept moving.
My health suffered. Relationships strained. My decision-making got worse the more tired I got, which created more problems, which required more hours. I was running on a hamster wheel, getting nowhere fast.
As CTO, my job was to lead, not code. But I kept diving into PRs, rewriting things "the right way," and becoming a bottleneck. I didn't trust my team to make decisions. Every major change had to go through me.
I became a single point of failure. My team stopped taking initiative because they knew I'd change it anyway. I was exhausted from doing two jobs poorly instead of one job well. The team didn't grow because I wouldn't let them.
Every Hacker News post about a new technology sent me down a rabbit hole. New database? Let's try it. New frontend framework? Rewrite everything. New deployment tool? Migrate immediately. I was so focused on tools that I forgot about outcomes.
Projects never finished because I was always starting over with "better" tech. Teams got frustrated learning new stacks every quarter. We accumulated more tech debt from migrations than from actual development.
I tend to rush when I should slow down. Hiring, architecture, decisions.
Letting go is hard. Trusting others is harder. But necessary.
I'd rather build than sell. But building alone doesn't create impact.
I'm still making mistakes. The goal isn't perfection — it's to make new mistakes instead of repeating old ones.
If any of these resonate, I'd love to hear your story.
I share these not because I've figured it all out, but because I haven't. The best conversations come from shared vulnerability.