2 min read

What They Call You When You Do Everything: On Startup Titles and What They Actually Mean

The gap between writing code and leading technical direction is wider than it looks.

I'm a few weeks into being called the CTO of Trendoline. The title is new but the work isn't entirely: I've been building the product for months. In an early-stage startup you don't get a title because someone decided you earned it. You get a title because someone needs to put something on the business card, and you're the person doing that thing.

What actually changed is the framing. There's a difference between being the engineer who makes technical decisions and being the person accountable for the technical direction of the company.

I'm learning what that difference is in real time.

What I was wrong about

I assumed the hard part would be technical. It isn't. The hard part is everything adjacent to the technical work: communicating tradeoffs to non-technical people, deciding what not to build, knowing when good enough is actually good enough, and being confident in decisions when you can't be certain.

Being a good programmer helps. It's not sufficient.

The decision-making problem

When you're an engineer on a team, most decisions have a feedback loop. You write the code, you see what happens, you adjust. As a CTO, some of the decisions you make today won't show their consequences for months. Architecture choices, technology bets, how you structure the team. By the time you know if you were right, the context has changed.

I don't have a solution to this. I'm trying to make reversible decisions where possible and be explicit with myself about which decisions are hard to undo.

What nobody told me

Technical debt is a people problem before it's a code problem. It accumulates because of pressure, because of incomplete information, because the right choice was unclear at the time. Managing it requires understanding why it happened, not just fixing the code.

Also: being right about the technical answer is not the same as making good decisions. A technically correct choice that the team doesn't understand or doesn't believe in will cause problems that a slightly worse choice, well understood and well executed, wouldn't.

Where I am now

Building fast, learning faster. The product is taking shape and I'm starting to see which early decisions are going to need revisiting. That's a healthy sign, I think.

More to write about this once I've had time to process it properly.

With gusto, Fatih.