Disclaimer: It's another post I haven't planned. It was inspired by various discussions and situations I've encountered within the last few months. I have the pleasure and privilege to work with many startups representing different industries, countries of origin, sizes, and levels of organizational maturity. I connect primarily with CTOs or other top technical leaders within org. Such a unique position provides me with a fascinating perspective - I can compare the challenges they face and find common denominators and differences between their roles. And with all of that, assemble some general conclusions out of repeated observations.


So I was trying to capture the essence of what being the startup CTO really means (e.g., in comparison to tech executives in other types of organizations). And I came up with a controversial (?) conclusion:

Being a startup CTO is primarily about continuously outgrowing your yesterday self by making quick decisions with a short "shelf life", frequently against (!) good engineering practices.
It also requires incredible levels of awareness, as today's most pressing issues (that you need to recognize and identify first) may have been irrelevant (or downright non-existent) yesterday.

Startup is not a "small company"

To clarify the reasoning behind this statement, I need to start with dispelling a common myth - popular especially among people who've never worked in startups. A startup is NOT a "normal organization, but miniaturized (scaled down) to the level where you can fit it within a garage".

No, that's not how it works:

  • a startup rarely copies the org. structure / org. model of "normal" / "standard" organization; people on board just do whatever is needed at the moment, the only roles present are the ones who are absolutely essential at this point
  • if "normal" organization could be depicted as a Boeing 737 plane, a startup would not be a small aircraft (like Cessna), but the minimal set of pieces one could possibly make flying (short distance ...): some sort of an engine, tiny fuel tank, half of the wing; no seats, no safety belts, no brakes, etc.
  • startup as an organization can grow several times faster than the individual - it's completely opposite to what we know from bigger (more traditional) orgs (where an organization may have no visible growth at all, while one's career progresses due to gaining experience, skills, and knowledge)
  • as an organization grows rapidly, some roles change with equal speed (the verb 'evolve' doesn't reflect the actual velocity) - even if the high-level role overlook can be phrased in exactly the same way ("CTO is personally accountable for all technology-related aspects of what organization's doing"), in practice, it means completely different everyday concerns and new modus operandi

Enters the CTO

Cool. Let's get back to the CTO role then. But let's skim through the more-or-less obvious stuff:

  • yes, the first CTO is probably a builder and may have initially zero experience in technical leadership/management
  • yes, the CTO role is susceptible to the "marines-soldiers-gendarmes" growth pattern described by Reid Hoffman in "Blitzscaling" (my synopsis of this pattern can be found here)
  • yes, as startups are product-oriented organizations, CTO always has to keep the product in mind while making/prioritizing decisions

Brilliant. But what about those "short shell-life decisions" and going "against good practices"?

The level of uncertainty startup is facing is tremendous. And its velocity and low inertia have a multiplying effect on that. So, in fact, a time horizon that is relatively short for any other kind of org (a quarter, half a year) appears like an eternity (for startup). Within such period of time:

  • product vision may be turned completely upside down (few times ...)
  • so could the monetization strategy or event target segment choice
  • not mentioning the architecture/code that backs all of that up
  • and ... well, it's also entirely possible the business will no longer be there anymore ...

That forces CTOs to optimize the decision-making for a really short-term ahead. Why invest in scalability, resilience, or even security if there's a big chance no one ever will use/pay for your service? Just focus on the product's essential features (and distinguishing factors) and ensure that most decisions you have to make are like revolving, two-way doors (not permanent and can be adjusted/revoked - if needed - in the future).

Examples?

  1. why spend 4 hrs on automating credentials/secrets rolling if you don't know whether you'll need them in a year (when they expire)
  2. why set up rate-limiting for your API if your traffic could be handled manually by a one-armed monkey
  3. why automate seeding test data if it takes 30 seconds to click them through within the app's UI

The primary currency in nearly every startup is not money but focus. Do not underestimate its role in the company's success. But as your resources are probably very scarce, it means you need to make painful, compromise decisions every single day. Very frequently against your (academic) engineering judgment (which can make you feel like you're failing as an engineer somehow) - it's the purely economic calculation that has to win here.

The good architectural/technological foundation for the early stage doesn't have to be described with adjectives like "perfect" or even "long-term optimal". It has better to be "sufficient", "easy to modify", and "loosely-coupled" (a change in one piece doesn't force rewriting half of the platform).

But all this "debt" you've postponed, can't be omitted forever. And this is a very important aspect of CTO's role.

Knowing what you don't know

The problem happens when CTO has a low awareness (and/or insufficient experience) and fails to realize that the conditions have changed (and so did the rules of the game). E.g.:

  • company is now big/popular enough to attract malicious actors (hackers, scammers, etc.)
  • manual activities have gradually become too expensive (overly time consuming) and now are the operational obstacle that slows everything down
  • some activities that could have been ad-hoc executed by literally anyone have now evolved into something that screams for a dedicated, specialized full-time role
  • decisions that could have been made intuitively now require objective data that is not available in the organization
  • the skunkworks, temporal solution for a given problem didn't stand the test of time - it's now the sunk cost, so it's time to forget your sentiments and replace it with something better suited for the job
  • or in more general words - something (not necessarily a piece of code: a mechanism, procedure, routine) that has perfectly worked yesterday, has stopped to do so; and you have no clue why (welcome to the world of scaling ...)

In other words - it's about CTO being open-minded enough to critically assess all the aspects of both the engineering organization and the solution continuously. And about being able to identify (and not ignore) what you don't know (and have never encountered in the past) - problems that may haven't even had names in your company's taxonomy at all. That is very demanding, and you nearly never know how well you do.

Let me rephrase it bluntly: if nothing surprises you, if everything appears familiar and obvious, you're either super-experienced serial technical entrepreneur or plainly delusional :)

Realizing uncertainty on-the-go is one thing, but dealing with it is another one. The truth is, many do struggle with that. Isn't CTO's role to KNOW stuff beforehand? To be certain about the direction you set? To beam the clarity and confidence, so others see you're in full control?

It's damn lonely at the top

It's some sort of a trap situation - on the one hand, you're not comfortable with revealing openly something you consider your weak spot; on the other hand, it's you who's in charge - there's probably no one more experienced to reach out and confide to (within the organization).

What can be done about that?

Well, that's one of the reasons why I find networking so crucial in the technical entrepreneurs' community. Yes, each startup is unique and faces its specific set of problems, but once you start talking to others (who fulfill similar roles), you'll quickly realize that there definitely are some common concerns and challenges. Sharing your learnings, asking questions, or even simply going through some others' war stories may trigger an interesting discussion that could inspire you and set your thinking on completely new tracks you didn't even realize possible before.

Another thing that helps is maintaing a professional curiosity. Which means investing time and energy in observing and digesting what's going on around. What are the hot topics, who has recently done anything interesting, how the various technical/business/organization trends develop out there. Having broad horizons will help you understand the basic mechanisms behind the dynamics of your environment and even predict (to some degree) what's going to happen next. As a CTO you're probably a helluva busy person, but this is the kind of investment that really pays off.

And the last advice is about mentorship. Networking is one thing, but having someone you trust, who has followed a similar path ("been there, done that") before and who you are not afraid to discuss the tiniest details with is an incredible boon. Of course it's another relationship you need to build and cultivate, sometimes the first steps (reaching out) are the most challenging and discomforting ones. But again - it pays off, in many various ways.