4 Valuable Tips for Moving From a Senior Engineer Role to CTO

"I'm pitching myself to move from Senior Engineer to CTO.

Do you have any tips to prepare my mindset?"

An engineer asked me in the comments section of a recent tweet.

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

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?

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

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?

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 me for more knowledge about remote work

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