Starting as a CTO
Episode 1 of a series-to-be: onboarding and meeting the team
Two weeks ago, I started a new job. Nothing worth writing about so far, just one more work experience for one more person, except this time, I am a CTO, the head of technology in the company.
A good onboarding experience
After two weeks, I am still in the energy of onboarding. I can ask as many silly questions as I like and not feel judged. Yet. I know this day will come when I’ll be too afraid to ask.
The purpose of onboarding
This is what I gathered from my 5 different experiences.
In the first hours, the goal is to make the person feel welcome, expected, show them how happy/relieved/excited you are as a company that they are finally here.
In the first days, the goal is to make the person feel part of a team: I met every team member personally, informally, to understand who they are and what they are struggling with
In the first weeks, the goal is to make the person feel part of a company: learning the jargon and the context specific to that company.
On week 3, I am learning new words and acronyms every day, along with the names of clients, partners, investors, what the clients need, what we can do for them, what the users like, what the product does and what it needs to do soon, the tools we use, who does what, who used to do what but should be doing something else, the list is long. It takes a lot of energy to build this mental model, but my job is complex software, this is not so different.
My first days were very well prepared: I had an email address and laptop ready, access to many (if not all) of the standard tools. On my very first day, I was welcomed with breakfast, kindness, a tour of the office, a place to sit, and a calendar of short meetings with my entire team. Not end-to-end meetings: it gave me the time to breathe and recover between them.
It is a great experience that I can easily compare with onboarding as a developer in my previous companies. I could tell about bad onboarding, it makes fun stories afterwards, but it’s beyond the scope of this episode.
The first informal chats
As I said, my calendar was filled up with 30-minute informal chats with all the team members (roughly 10 in tech, 35 in total).
Standard questions when meeting a colleague
Here is the list of questions I asked systematically:
- Who are you, what do you do?
This gives me the opportunity to see how the person sees themselves, what is important for them and of course it helps me put roles to names and faces. Some will elaborate on their entire CV, others will describe their day-to-day work, showcase how often they save the day or explain why they are struggling. Some people understand the question as professional only, while others will tell about their hobbies and family. - If you had 3 wishes, what would you magically change?
This one identifies the pain points, but also gives me an idea of how high-level a person is thinking. Compare “Make our interfaces smaller so that we can mock them”, a one-person problem, vs. “Spread the knowledge so that anyone can fix bugs and it’s not always the same people”, a concern that shows a team-level conscience, or “help get this one answer on my current dev” (showing a one-week vision), “make the deployment a one-button action” (you want tools that work for everyone), “finish this migration that was started months ago” (the weight of legacy). - What do you expect from my role?
This question doesn’t always lead to extraordinary findings, but it shows that I am not coming with my own preconceived ideas, and I will do what people need from me.
Another rule: I never interrupt the person opposite, except for a question about what they are saying. The key to this kind of meeting is to listen. I’m not here to show how good I am, this will come with actions later (also I’m not that good). I always let people finish, which sometimes means that I spend the 30 minutes saying nothing at all while the other person babbles on, and it’s perfectly fine.
First task
Even before I decided to join, during my interviews, I had hints of why the team needed a new CTO. People were starting to feel a general lack of vision and organisation with everyone doing most everything and these two competet saviours spending their time extinguishing fires. Things were already looking brighter since a new CEO joined a handful of months before.
Between the moment I signed and the day I joined, I participated from afar in the definition of a new team structure. My first public speaking opportunity was to confirm that splitting the two teams by domain was a good thing (see below some reading recommendations to back this up).
I made a 10-minute presentation reminding why and how it worked, who was supposed to do what with summarised job descriptions, and the next steps. After the presentation, I felt that a first tiny milestone was behind me and I needed to determine the next. Take a deep breath and look for the next target.
In the next episodes: defining a career framework, and how to identify what slows the team down and makes them unhappy. Will the role still correspond to what I expected, will I be able to keep coding? Stay tuned for how it turns out.
As a side point, I am happy to report that my very first contribution on the first day was to make the wording of an automatic email from our product more inclusive.
Reading recommandations for team restructuration:
- Team topologies, by Matthew Skelton and Manuel Pais
- The Phoenix Project, by Gene Kim, Kevin Behr and George Spafford
