Five years as a startup CTO: How, why, and was it worth it? (2024)

You're a startup when you're testing a new business model. If you realise that it works, then you're a business.

I helped found a startup[0] and have been around a number of them, in slacks and on email lists[1].

I think that domain knowledge is so so important for startup success. Even more important than technical expertise.

Why? Because the main problems for 0->1 startups are business problems, not technical ones:

* where do possible customers hang out

* what problems will they pay you to solve

So in that case, a good CEO who knows the domain is critical. They'll have good answers to these questions, which will help guide the technical decisions. Or they'll know who to talk to in order to find the answers. There's no shortcut to that knowledge; you have to spend years to get experience in the domain. Learning and reading about the domain can help, but you still have to spend the time.

The main exception, and it's a big one, is if you are building something in the devtools space, where you can be your own customer.

0: https://www.thefoodcorridor.com/ (I left after a few years, but they are still going strong!)

1: https://ctolunches.com/ (free email list for engineering leaders, so many good discussions happen there)

They all failed at sales, scaling, retention, and generally running the business.

I did work for one very successful company that was founded by an engineer. However, he was focused almost exclusively on non-engineering business functions from the start.

If you want to be a CTO and do engineering things, don’t assume founding your own company is the best way to get there.

A startup is a kind of ponzi scheme benefitting the founders (and VCs).

Successful founders will happily tell everyone and their dog how being a founder was so much work, how they didn't go on holiday for a few years, how they worked long hours, etc. And mostly why they deserve to be rich now while none of their employees is. None of them will talk about how being one of the first employees was also so much work, usually with a pretty bad salary and order of magnitudes fewer options than the founder.

I always wonder how the founders can genuinely believe that they are actually worth thousands of me. I am pretty damn sure that with a thousand me, we produce more than the founders alone.

I kind of enjoy working with partners, especially when everyone "knows their lanes" and agreements are properly defined. It just tends to blow up at some point it seems like... :)

The main goal is to keep a pulse on finances.

In any case, "start my own" is still on my todo, it's just... not that easy to pull of :))

I know more technically inclined than not that can easily identity this situation. At least my CEOs have a tendency toward thinking we should pursue any path that likely leads to some income stream...

At the moment our engineering is ahead of our sales - which gave me some capacity to lift my head up and test my skills relevance against the market on the fractional/advisory capacity potentially turning into revenue stream with more control from my side.

You know how it works for us with engineering minds - you always consider worst case scenarios and try to mitigate them before they become real problems.

Based on my experience it typically works in cycles, where you need some sort of fresh blood every five or so years to re-kindle the spark and keep going.

It's been great five years for me and my family, exactly what I was looking for before the transition from stable corporate world.

I guess it depends a lot of personality and the type of work you enjoy. I thrive at early stages, where most things a built on common sense and you have enough power to shape things into something meaningful.

These days I try to appreciate "the process" (day-to-day) over "results" (exits).

You don't really have too much control of how things unfold in your life really, be blessed you are alive and kicking.

Do I say money is not important? Of course not - it's very important, but in a challenging times you have to test your limits and re-assess your priorities (whether you like it or not...)

It's easy to look at things in hindsight - the question is what is the alternative? 5 years of what?

- Jira Epics (describe the why from the business standpoint)

- HQ meets two times a week to re-asses priority (drag up Epics up or down, or change priority) and monitor status

- Two week sprints where engineering leads along go through epics

- New sub-tickets created by engineering (including design) and assigned to specific people.

- Once thing are getting done, they are move to QA test status. After testing it either goes back to engineering or to Release Approved status.

- Engineer initiates and monitors the the release via CI/CD Jenkins pipeline.

That's pretty much it on the high level, unless I'm forgetting something.

One important note here - some time ago we made a decision to ignore "good ideas"/backog. We don't keep them in Jira until business is sure that we really need this particular functionality and ready to start building it right now.

That was somewhat radical and took some time to get used to, but it allowed everyone to focus on what's important now vs nice to haves to keep people busy with things noone really needs.

Overall there is no "generic" advice, everything is very org and stage specific. Common sense is the main guiding principle.

Even more questions to the business / CEO ( Why this, why now )

"why", "how", "can we", "who can"?

Just try to be humble in the world where nobody knows anything (including yourself)... :)

Then, in a group, probing together for 12 factor app or AWS well architected type principles as well as something like BSA security principles, gets you a very long way.

The framework doesn't matter, just something to cause a beat of design, ops, and threat modeling and "rugged manifesto" thinking.

https://ruggedsoftware.org

At the end of the day someone needs to answer a simple question - "Is the product functional right now / after the last release?".

If you don't have QA team you either rely on your product person to "give it a spin" or your engineering who are generally not very excited about clicking through the product multiple times (more often than not, they'll just leave it at the unit test phase and move on).

In small orgs that product person could be your CEO or CTO, meaning this will give them an easy false-escape into "micro-management" mode (aka feeling productive by doing low priority tasks) vs forcing them to make strategic decisions or worse, they'll just block the entire pipeline.

QA creates a natural quality gate looking at the product from the user's perspective, putting pressure at the engineering to deliver quality work and gathering leadership feedback at critical points only.

Aside from writing end-to-end test automation, the best SDETs add value in many other ways. They triage bugs, use their deep product understanding (frequently the best on the team) to refine requirements and build test plans, coordinate bug-bashes and large scale releases, measure and report on quality metrics, and much more. All of this takes considerable load off other members of the team (SWEs, PMs, EMs, etc), allows the whole group to ship with much higher confidence, and increases the number of defects caught before making it to production.

If you have an organization where end-to-end tests are easy to write and very quick to execute, then I think the need for QA folks is greatly reduced. In my experience, once there's enough complexity and scale to a product, it's basically impossible to have a rapid TDD loop with enough end-to-end coverage that allows devs to ship features with perfect confidence. Combine that with all the other "hats" QA folks wear, and I think it's is a role that pays dividends in product quality and the efficiency of others across the org.