First 90 days as a new CTO
Tags: leadership, career, technology
Published: 2021-03-12 09:08:33

A few weeks ago there was a question posed in a slack group: "If you could go back to your first day in the role what are the 3 pieces of advice you would tell yourself?"

There were some really helpful responses in there: "Read a lot of books and speak to other CTOs as early as possible"; "Spend more time thinking and less time doing in the first 90 days"; "Believe in yourself - there’s a reason why they asked YOU to be CTO" - that last one was my suggestion, but as an evergreen sufferer of imposter syndrome, I have to keep reminding myself. 

The question got me thinking though. Pithy advice is certainly helpful, but where do you go from there? So beyond the advice, what's my plan to hit the ground running in my next leadership role? This post is partly me sharing my thoughts but is also a request for peer review - I'd love to hear back on what I've missed, what I'm over emphasising - so please feel free to post back and comment. I should share my assumptions here too - the team is somewhere between 10 and 50 people and a new leader is being hired because the company is growing or because they want to trigger change.

Starting a new role is an opportunity to start with a clean sheet, to take all the things you've learned to date and and try and apply them in what feels like a more sensible approach and order. So here's my 90 day plan - what's missing, what's un-necessary? Where am I setting a trap for myself?

* Day 0 - introduce myself
    * Tell the team about who I am, what I believe in and how I like to work. Give the team a chance to mentally prepare themselves for my arrival. Importantly share my intentions with them. 
* Day 1  - (organise to) meet the team, listen. Hear what they have to say. What do they love, what bugs them? What insight can I gain from them?
    * Meet with all of them and make notes - individual notes for each person. 
    * Make sure I have time after each person to write up my notes and digest what they've said
* Week 1 - Establish my place in the company
    * Establish what my peer leadership group needs from me, what expectations do they have - "role descriptions' are rarely well defined at this point. 
    * Form an engineering leadership group, if there isn't one - this will likely be my go-to team as I learn the ropes.
    * Start to lay-out the common working patterns
    * Describe the culture that I'm looking to build
    * Start to establish team principles and purpose
    * Measure, or identify the tools that will allow us to measure
    * Build trust with the team and show them how I plan to work with them in future
* Month 1 - Establish frameworks for how I want to support and grow people
    * Agree principles. Share them, adopt them, refere to them at every point
    * Share any feedback or insights already learned
    * Start to create framework for professional and personal development - there are some great examples out there for re-use. E.g. Basecamp and Gitlab company handbooks. 
    * Check-in with peer leaders. How am I shaping up? What am I missing?
* Quarter 1 - "Standardise" on measurements, learning and feedback
    * Socialising what we're learning from measurements, use this to establish what's working well and what needs improving
    * Forming tactical and strategic plans
    * Team check-ins - how am I doing?

Taking those tips into account too, I don't plan to change things in a hurry, unless I really need to - the first 90 days are about learning and listening.

I've mentioned measurement in there a few times. I'm really interested in knowing how the teams are performing, not so I can make them work harder, but so we can learn to work smarter. I think Accelerate is a fantastic book that goes into the science of high performing teams. Measuring how we're performing as a team is vital in being able to learn and improve. Likewise I'll be looking to resolve specific pain points. Over the past 18 months, Team Topologies has become my "go-to" when trying to understand what's not working well and how we can think about improving it. It's a tool box of patterns to describe and promote people working well together within teams, and how different teams should work together and importantly know how and when not to work together. I also believe strongly in teams being given purpose and empowered to achieve their goals. Distilling company values into more readily consumable principles is an important part of making this possible while ensuring there is still consistency across those teams. I've found Simon Sinek, especially in "The infinite game" and "start with the why" brings purpose and clarity to my thinking and provides a valuable anchor when I need to take a step back and reset. 

Finally, there was another piece of advice which was given, and I still can't decide if I totally agree: "your team is the exec team now, not the development team". If there's one thing I've learned in my current role is that if the exec don't act as a team, then you're not going to be effective as a business, so I agree the exec team is absolutely your team.. and yet I can't help think that the tech team is _also_ my team. If I have the vision, they're the people that make it possible. If I have a problem, they're the people that are likely to solve it. If we're not in it together, working towards out purposes then we're all just "me" or "them" and that's not the path to success either. For me it's got to be "us" all the way, so thank you but I'm in both teams now :)