Many tech leaders will start a new senior position whether as a promotion or a new job at a new company. I know how daunting it is to take a new position. You can do as much research as you like, but there will always be surprises. On the bright side, you do have those first 90 days. During that time, there are seven key areas that you must focus on.
Why 90 days or three months?
It’s a honeymoon phase during which you can still blame it on your predecessor (unless he’s your boss).
In my experience, these are the seven areas you should pay attention to.
The subject of an optimal strategy when joining a new company is covered in detail throughout our Digital MBA for Technology Leaders. Drawing from those lectures, you must first understand the company’s objectives and business plan.
In other words, the vision is the why, the target is the who, the mission is the what and the strategy is the how.
Now, if the business strategy is not yet formalised, you’ll have to work out what each of these four is through implication. Furthermore, it would be best if you suggested to the CEO and SLT that a session be held to discuss and agree on all the points.
The main thing here is to align the strategy with tech. And here are two vivid examples of misalignment.
One of our lecturers took over a CTO position in a company only to find out that the plans weren’t aligned. The business plan was assuming the legacy of on-prem licensing whilst the tech team was still building a SaaS platform. In another example, a CTO approached the COO asking for the business plan. However, there wasn’t one except the vague goal to make more money.
What do you do in such a situation as a newly appointed Chief Technology Officer?
You must prioritise the requirements of alignment and work out the action plan.
The first thing you should do in this matter is to get to know your colleagues. In other words, make an effort to understand their individual priorities and comprehension of the business strategy. The latter is quite important because, as you’ll learn, each of them will give you a different answer. This, in turn, will give you a good overview of how well they are coordinated.
If discrepancies indicate a complete lack of alignment, initiate a quiet chat with the CEO because, one way or another, you must improve C-level communication. Why? It’s the only way to truly understand their perception of tech and subsequent priorities.
You may also find yourself in a situation where your SLT colleagues voice where your priorities should be. Feel free to disagree, but, at the same time, use that to build a better picture of what is required to support the business.
The first step is finding the organisational chart of your department. Create one if necessary simply to work out the composition of the teams.
Often, the team structure is based on historical circumstances which may no longer be relevant to the work in progress and plans in general. So get to know your direct reports and team members. Learn their strengths and weaknesses to better understand the areas they need support with. Once you feel comfortable enough, take that org chart and confirm/update roles and responsibilities.
Whilst you are learning your team, contemplate the following few questions:
Is the output meeting your expectations? What is your gut feeling telling you? Are you getting a return on your investments? Is there something you must improve right away?
Do processes exist, are they correct, and are they being followed?
One of my friends joined a large company a few years ago and inherited a fairly large team. They were sending one release to the testing team every couple of days. He thought the cadence was far too slow so he decided to get his hands dirty just to understand what was happening within the CI/CD. It turned out that it was a terrible implementation, but no one had bothered to fix it as the expectations had been set. He immediately changed things around and they were building tens of releases every day for testing.
The bottom line is that if the processes aren’t working for you, you’ll need to fix them. However, that won’t come without pushback. So you’ll need your team leads to not only drive but also own the change.
There are two types of communication I’m referring to here: within the tech team and to the wider company.
You see, there might be some false beliefs caused by bad communication. This is commonly caused by teams who are using Slack private channels to discuss tickets which, consequently, makes it difficult for others to understand the decision-making process.
The only way you’re going to solve this is to move discussions to tickets directly – without exception. It is something that I mandate on all my projects.
Additionally, analyse Slack plugins and remove unnecessary ones because they produce a lot of messages that quickly turn into noise and distraction. For example, I have ten workspaces in my Slack and I’m simply forced to mute a lot of channels just to focus on work in hand.
What I’m trying to say here is that Slack is a great tool, but do mind the correct usage of any tool at your disposal.
Budget can often be foisted upon you with minimal input from you and your team. If this is the case, figure out the flexibility and calculate whether or not you are within, over or under the budget at the precise point.
Here’s a wild story from the public sector that vividly depicts such a problem. A friend of mine joined the team and found out that the budget was significantly underspent. However, if she did not spend it all, the following year’s budget would be cut and she would therefore have significant problems going forward. So she decided to spend the existing budget by buying a new computer for everyone involved in the project. This simple solution solved her budget problem and she quickly gained respect across the organisation.
Therefore, if you find issues that require expenditure, to fix them, you need to understand the budget.
The question you need to ask yourself is: Are these (inevitable) skeletons relevant?
One of our Global CTO Community members quickly realised that he was taking the CTO role in a company that was, effectively, an understaffed and disorganised mess. He spent a lot of time with the CEO trying to work out how they were going to get out of that mess. The problem was that the CEO was open and honest, but not technical and the skeletons in this case were the code repositories. Long story short, someone put more than one product into the same repository. Naturally, everyone assumed there were only two, but it turned out there were three. The skeleton that was serious and relevant was that for one of their products. They did not have ownership of the repository. The real owner, an ex-employee, kept saying he would hand it over, but it dragged on and on and caused a significant problem for the company.
If something doesn’t make sense, then dig. You need to listen and watch for changes in body language, voice tone or vagueness. It is the latter that I use the most often. If something is vague, they either don’t understand it or they’re trying to cover something up.
Ask questions such as: ‘What does that mean?’ or ‘Why is that process in place?’.
By pre-qualifying, you are disarming them. Ultimately, you are going to create a plan and a roadmap, which you may keep to yourself, but should be made up of immediate medium- and long-term recommendations.
Immediate recommendations are a high priority. And those that are severe, you should have already actioned.
Once you have a plan, then you can implement solutions using all the relevant skills and tools (explained elsewhere in the course). However, if after 90 days, you’re still struggling to understand the business processes or people, then maybe this is not the right fit for you.
To sum up, having a concrete plan within these first 90 days gives you a good foundation to become a successful tech leader in your organisation. Remember: business plan and objectives, SLT relationships, team and resources, efficiency and processes, communication, budgets and skeletons. These are your immediate focus areas.
90 Things You Need To Know To Become an Effective CTO
