A candid look at the technical and leadership mistakes I made leading engineering at my first startup, and what I'd do differently.
I took my first CTO role younger than I should have. The startup was small, the founders were friends, and the title sounded like a graduation. Two years later I had learned more about what I did wrong than what I did right. This is a list of those mistakes, in roughly the order I made them.
I write this not as a confession, but because I see other first-time technical leaders walking into the same patterns. If you are about to be a startup CTO, or you just became one, this is the post I wish someone had handed me.
Mistake 1: Building too much, too early
The first thing I did was design the system for the company we wanted to be in three years, not the company we were that month. Microservices we did not need. A queue we did not need. A staging environment more elaborate than our production traffic justified.
The cost was not the architecture. The cost was the months we spent maintaining it instead of shipping. Every founder will tell you this in retrospect. Almost none of us listen the first time.
The fix is unglamorous: build the smallest thing that could plausibly work, ship it, and only add complexity when something is actually broken. I wrote more about this in Complexity Is the Enemy.
Mistake 2: Hiring for the company I wanted, not the company I had
I hired senior engineers from larger companies because I wanted "real engineers." Most of them did not want to be at a five person startup. Two left within six months. One of them was actively unhappy the whole time and made the team worse while they were there.
In my experience, the best early startup hires are not the most senior. They are the people who are slightly under-leveled for their skills, hungry for ownership, and who get genuinely excited about messy ambiguity. You learn to spot them. I did not, the first time.
Mistake 3: Confusing speed with progress
We shipped fast. We measured PRs and deploys per week. We put up a dashboard. The chart went up. The product did not get better in any way the customers cared about.
This is the velocity trap. Speed is a means, not an end. From teams I have worked with, the founders who do this best are obsessive about what they ship, not how much. One thoughtful release a week can beat five reactive ones.
Mistake 4: Not firing fast enough
I had two engineers I should have let go in the first three months. I waited eight. The cost was not just their salary. It was the team's trust in my judgment, the culture they were shaping by example, and the opportunity cost of the people I could not hire because the budget was occupied.
This is the single hardest part of the job. There is no version of this that feels good. I now believe the kindest thing you can do for a struggling employee at a small startup is be honest with them quickly, so they can find a place where they will succeed.
Mistake 5: Treating the cofounder relationship like a friendship
My CEO was a friend before they were a CEO. I did not draw enough boundaries early. We avoided hard conversations because they felt like fights. The company suffered for the year it took us to admit that.
If you are co-founding with friends, the most useful thing you can do is schedule explicit, regular hard conversations. Make them a meeting on the calendar. Make them awkward on purpose. The ones you do not schedule will find you at the worst possible time.
Mistake 6: Building, not selling
I told myself my job was the technology. I let the CEO own all the customer conversations. As a result, I made a hundred small product decisions without ever hearing a customer's voice in my head.
The CTOs I respect most spend at least a quarter of their time talking to customers, even at very early stages. Not as salespeople, but as listeners. The product decisions get sharper. The team gets clearer. The founder gets less lonely. Every signal points the same direction.
Mistake 7: Not writing things down
For the first year, the company's architecture lived in my head. The decision history lived in my head. The production runbook lived in my head. When I went on a two week trip, two outages happened that nobody could fix without paging me.
The fix is the cheapest thing in this whole list and I still see new CTOs avoid it. Write down the why of every non-obvious decision. Write the runbook. Write the onboarding doc. The act of writing is itself how you discover what you do not actually know yet.
What I would do differently
If I had to compress all of this into one sentence: I would do less, in fewer places, with more honesty. Less code. Fewer hires. Fewer meetings. More direct conversations. More writing. More time spent with customers.
The job of an early CTO is not to build the most sophisticated system. It is to keep the company alive long enough for the system to be needed. Almost every mistake on this list was a version of forgetting that.
If you are stepping into this role now and want a second pair of eyes on architecture, hiring, or the cofounder dynamic, /start-project is one place to reach me. I would rather catch a few of these for you than watch another team learn them the way I did.
References
Tagged
Sri Vardhan
Independent technology studio of one. I help founders and small teams ship serious software without the consultancy overhead. More about me.