Follow These Tips Before You Move to a CTO Role

If you're a software engineer looking to move to a CTO role, plan yourself before making the move.

These are my tips for anyone moving to a CTO role.

1. Understand What’s in Scope for the Startup CTO Role

Photo by Danial Igdery on Unsplash

Usually, it spreads in 3 different directions:

Technology
People
Processes

But the weight of each of those directions massively changes depending on the stage, team, and type of company it is.

At such an early stage, there isn't much to manage in terms of people or processes.

So, the core function of the CTO is building technology, which isn't much different from a Software Engineering role, at core.

The transition should be smooth in regard to that core function.

2. Where’s the Feature Spec?

Photo by ThisisEngineering RAEng on Unsplash

Yes, at such an early stage, there's no well-defined product specification.

In fact, the startup is pre-product-market-fit, which means you're still finding the ideal product proposition that will land sales, and iterating towards it.

At such an early-stage startup, you don't have a feature spec to implement.

In fact, as the CTO, you'll be expected to:

Create the MVP spec (along with the co-founder and team)
Build the tech to fulfill that MVP spec
All while you validate the proposition with clients

As Engineers, we over-scope by default. We love to build that extra feature. Or implement that background worker properly.

All of that adds another day and another week here and there.

While it's very common, it's often a cause of frustration and ultimately failure.

3. Optimising for Short Term vs Long Term

Photo by Christina @ wocintechchat.com on Unsplash

This is the biggest mindset shift from Software Engineer to Startup CTO.

At most tech companies, especially the most sophisticated ones, technology development follows a set of processes that optimize for the long term.

Such long term focused processes measure things like:

Absence of bugs -> This means thorough testing
Robustness -> This means redundancy to avoid downtimes
Scalability -> This means service-oriented architectures that allow heavier loads

These things are mostly irrelevant for an early stage startup. As such, you need to strip off this "quality-first" mindset that you had as a Software Engineer.

On the contrary, in a startup, you need to adopt a "speed-first" mindset.

This means optimizing for the lowest possible time to market.

A few things you need to be comfortable doing are:

Build features using off-the-shelf tools
Do close to zero tests
Have no dev or staging environments

If you struggle with de-scoping ruthlessly in the early days, please read some reference materials on the topic, and seek mentorship from more experienced CTOs who've gone through it.

For me, a key reading was the essays by @paulg.

4. What’s Your Personal Runway?

Photo by Dzmitry Dudov on Unsplash

Startups take time.

The first paying client will take longer than you expect
Fundraising will take longer than you expect
All this causes your first salary to be much further away into the future than you expect right now

This was the biggest source of anxiety for me, in my first startup.

My advice: Plan for it!

Do the math for your personal runway (as in number of months you can sustain your life without a salary)

If you don't have 12+ months of runway, consider getting a freelance gig that you can do in 5-10 hours a week.

It doesn't hinder your startup work, but grants you liquidity and peace of mind.

Could be a game-changer.

Follow us for more knowledge about remote work

We'll be publishing new articles every week, and new social media content every day. If you enjoyed this article, follow us on Twitter or Linkedin, and stay in the loop. Share our content and drop us a comment there. Let's help more people learn about remote work.