cto at 24

Graduated from Shiv Nadar University in 2023, moved from India to the Netherlands, became CTO of a funded startup with 10+ engineers. I’m 24. No transition period, no “associate CTO” phase, no senior engineer mentoring me into the role. Just: here’s the codebase, here’s the team, here are the customers, go.

Some things I’ve figured out. Most of them the hard way.

you haven’t had time to fail safely

The biggest gap isn’t technical. I went straight from undergrad to a leadership role in a foreign country without the intermediate step where you fuck up in low-stakes environments and learn from senior people. Every mistake I make is in production, with real customers, real team members, real consequences.

I learn fast but expensively. A senior engineer who spent five years at a larger company before becoming a tech lead has a library of patterns for handling team conflicts, scope creep, and technical debt. I’m building that library in real-time.

coordination costs are invisible until they crush you

Nobody warns you about the coordination overhead. When you’re a good engineer and also the CTO, you end up being the routing layer for every decision. Engineers need your technical context. The CEO needs your technical opinion on product decisions. Customers need you for support escalations. Every person on the team has a legitimate claim on your time.

In our August-September sprint, I was doing code reviews, architecture decisions, customer calls, sprint planning, debugging production issues, and ISO27001 compliance work. All simultaneously. The output was impressive. The personal cost was chest pains and chronic exhaustion.

The fix isn’t “work smarter.” It’s recognizing that coordination work is real work that needs to be accounted for, delegated, or eliminated. Not just absorbed by the person with the most context.

give people bounded problems, then trust them

I used to review every PR in detail, sit in on every technical discussion, and re-verify completed work. This doesn’t scale past 3 engineers, and it communicates a lack of trust even when it’s not intended.

What works better: define the problem clearly, set the constraints, let the person solve it. Check in at milestones, not continuously. When an engineer has 20 hours a week (like some of our part-time team members), giving them a clear bounded problem to own is infinitely more productive than managing them daily.

the sprint update problem

We had a team agreement: in sprint check-ins, only share updates if there’s a significant change. One engineer kept going into detail on minor items anyway. The instinct was to correct this in front of the team. But public correction creates defensiveness and doesn’t fix the underlying issue.

What works: 1-on-1 after the meeting. “Hey, we agreed to only share significant changes. What happened there?” Then listen. Maybe they forgot. Maybe they thought their change was significant. Maybe they felt pressure to justify their work. Each needs a different response.

Public: reinforce agreements. Private: explore violations. This pattern applies to almost every team dynamics issue.

communication is a skill, not a talent

I started reading about communication deliberately. Not business books (I generally don’t trust those), but material about how people actually navigate conversations, negotiations, and relational dynamics. The technical skills got me here. The communication skills will determine whether I can stay.

When you’re 24 and managing people who are older and more experienced in some dimensions, you can’t rely on authority. You need to be genuinely good at explaining your reasoning, listening to dissent, and making people feel heard even when you disagree. Learnable, but takes intentional practice.

the peer network gap

I have almost no peer network in the Netherlands. Moved to Eindhoven at 22, immediately went into intense startup hours. The Indian diaspora connections, the university friends in Europe, the professional network that most people build in their 20s. I skipped all of that for work.

This matters more than I initially thought. Without peers who understand your situation, you lose the ability to calibrate. Is what I’m experiencing normal? Is this level of stress standard for this stage? Am I being unreasonable, or is the situation actually unreasonable? Without peers, every data point is n=1.

Working on fixing this. Slow process when your immediate priority is always the next sprint.