How to Ramp up as a Newly Hired CTO
Let’s say you’ve accepted a job as a CTO of an early-stage startup.
How should you ramp up? I suggest doing it in three phases:
Phase 0: Before joining
Before you join, make sure that you’ve understood the outcomes you’ll be working towards. Outcomes can be:
more features
better UX
support for more platforms
scalability
reliability
improving engineering culture and satisfaction
When you ask what outcomes to work towards, you may get answers that are not outcomes, like “increasing productivity”. You should counter that by asking, “How will we use the extra productivity?” If the founder answers “Improve UX”, then that’s the real outcome, not increasing productivity1. If you don’t challenge these non-answers to your question, you won’t have clarity on what your actual outcomes are.
Phase 1: Planning
In this phase, act as an observer: attend all the meetings, join all Slack channels, and so on. The purpose is to see the status quo is with your own eyes. This is critical — what the founders told you is only one view into the company from one vantage point, not the whole picture.
Ask the company to conduct 360-degree performance reviews of everyone in the product team (eng, UX, product) and everyone they interact with. If Shruti from the marketing team often interacts with engineers, she should be included. Which means all the engineers she interacts with review her and vice-versa. This will give you valuable information into the company that would otherwise take you a quarter or longer to uncover.
Build personal connections beyond work: meet people at a park or lake, have regular dinners, and so on. When push comes to shove, our personal connections make all the difference. When we’re in the honeymoon phase, we may forget this, but by the time we need it, it’s too late. A strong network will also help you in your subsequent gigs.
In addition to being an observer, be an advisor: feel free to offer any suggestions, but tell your predecessor — let’s call him Venkatesh — that he’s still running the show, and he should continue executing as he has been before your arrival. Announce on Slack that you’re currently acting as an advisor, and people are absolutely free to take or ignore your advice as they see fit, all the more so if it contradicts what their manager or Venkatesh tells them. Venkatesh has full freedom to make whatever decisions he wants, and he is held accountable, not you.
In this planning phase, you identify a list of changes, and put them in writing. These should cover all aspects of your job like architecture, engineering processes like code review and launch process, project management processes like sprints, hiring, engineering culture, changing how the non-technical stakeholders interact with the product team, and so on. You prioritise these changes. You also solicit inputs from various stakeholders on the plan, identify what you’re missing, and ask them what they would do if they were in your shoes, to identify gaps in the plan.
Planning will result in better results than just rushing into it:
You may find that one change B obviates the need for another A, in which case you remove A from the list. If you didn’t do the planning exercise, you might implement A and then B, which is inefficient.
You may find that B will reduce the time A takes, in which case you’ll swap the order to B followed by A rather than A followed by B.
You may find that one change is critical, and so do that earlier. When I worked as a CTO, I identified a few focus areas to work on in the first quarter, and mobile was not part of them. But only later did I realize that the mobile app was broken, so I had to backpedal on my plan, which created more uncertainty and discomfort for everyone.
You may find that a change you proposed requires a lot more effort or has far less benefit than you anticipated, so you delete it from the list and put it in a separate Later list. You don’t want too many changes at once — it will create a chaotic work environment, like Elon’s takeover of Twitter.
You may find that a change you proposed doesn’t make sense at all. You want to learn this before implementing the change.
Planning helps you work backward from the outcomes the company desires (strategic / top-down). If you don’t plan, you might end up lost in the day to day noise (tactical / bottom-up). For example, you may lose sight of the need to hire more people.
For all these reasons, you want to plan and then implement, not directly implement.
The planning phase should last a quarter or two. If the founders pressure you to start making changes immediately, tell them that that will compromise the result, and that rushing and doing a bad job won’t benefit anyone. If they’re driven by emotions like worry and panic, remind them that our emotions sometimes drive us to make poor decisions. In fact, tell them that the planning phase will take a quarter or two before you accept the offer, so that there’s no surprise later.
Thanks to my friend and CTO Priyaank Choubey for suggesting the planning phase.
Phase 2: Implement
In this phase, you start implementing changes. It won’t feel as chaotic as it otherwise would, since you validated the changes beforehand. This phase constitutes the regular work of a CTO, and since this blog post is about onboarding, I won’t cover it further here.
If you onboarded as a CTO, please share what you did and what worked for you.
Of course you’ll increase productivity — that goes without saying