When starting a new role as a tech executive, it is common to feel slightly disoriented at first. That’s because, in most startups, you’re not going through a ready-made orientation process. More often than not, you have to carve your own path forward without a lot of guidance.
Having aided many CTOs and VPs of Engineering during their onboarding, I have thoughts about this. Your personal onboarding can feel overwhelming, especially when you are taking over an organization that is already up and running. However, once you acknowledge that you are supposed to take charge and organize this for yourself, you should already be better off. Remember, you have agency here.
Now, what should you do with it? Let us cover the things you should keep in mind over your first 100 days on the job.
In my book The Tech Executive Operating System, I lay out a framework for designing your onboarding over your first 100 days. Why 100? It might seem an arbitrary number, but the truth is that there are sundry reasons for it.
First, it has become the general grace period one is given in new roles. Like it or not, the CEO is probably looking to see improvement within that time frame; there’s no way around it.
Further, the first few months are one of the precious windows of malleability that we are granted. A window of malleability is when people are more susceptible to change and fresh perspective. This is a scenario where you have a two-sided window. The first side is yours: you still obtain a beginner’s mind and can use that fresh perspective to ask questions that you wouldn’t voice later—you’ll get used to things being the way they are.
The opposite side is the organization’s: people expect things to change when management changes and are less likely to begrudge significant change in the beginning. However, if you wait too long, you might miss the boat and find that kicking off change initiatives is a lot harder. Understanding this, there are two main objectives for your first 100 days: research and taking the initiative.
When a new startup is formed, the team spends hours in customer research, learning the lay of the land, and talking to potential users. You should treat the initial phase of your role similarly. This is a period where you should conduct a lot of research and establish rapport with your reports and peers.
I recommend having a lot of one-on-ones where you hear what people are thinking, what they think should be changed, which areas are considered the organization’s current strengths, and similar. Maybe the team itself is pleased, but other departments feel neglected? Perhaps it is the opposite, where the team is delivering, but ICs will report burnout and high stress? Without establishing relationships with people throughout the ranks of your organization and the rest of the company, you’ll be operating with a dense fog of war.
The other aspect of your research should be to create a personal crash course where you acquire Product Mastery. That is, you must become proficient in the company’s product, business, and environment. What problem is the product solving, and how? Who are your users? What kind of competition is out there? Looking forward, what’s the strategy? What are people writing about your product on Facebook? As we all know, context is king. Without understanding the environment you’re in, you are not likely to make the right long-term decisions and weigh in the crucial aspects when deciding on different trade-offs.
In chess, taking the initiative often means moving from defense to offense. During your onboarding period, knowing that it is a precious window of malleability, you should aim to do the same. Don’t be mistaken; I’m not encouraging you to rush into things or come up with a reorg for reorg’s sake.
Nevertheless, working with my clients, it is often clear within the first couple of months what are the important and urgent issues at hand. Once you’ve gathered enough information and have a reasonable level of product mastery, it is time to set your next steps. For example, you don’t have to declare what process changes are required if there are quality or efficiency issues. You can start by declaring improving those metrics as your goals and kicking off the effort of forming a plan to address it.
It might feel premature, but hitting the ground running and starting to improve things quickly is necessary to gain traction. Frequently, it also does wonders to your own self-esteem: by starting to operate and taking charge, you will shed the impostor syndrome that makes a common appearance during these times. Go get ‘em.
Look, I know we talk about it a lot but we love our developer discord community. With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>