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 :)
Top comments (4)
One of the questions I had Rich was how do you know if your team are giving you truthful feedback? Or perhaps a better question is how do you provide the right environment or setting to achieve truthful feedback?
Hi Adam, I don’t think that’s necessarily easy to do. If people don’t feel safe telling the truth then it’s likely they won’t. To overcome this you have to demonstrate it’s ok to be honest and tell the truth and the best way to do that is to demonstrate that yourself. It’s probably a good idea when you introduce yourself to show some of that honesty - for example, I don’t have a background in development so I’m not going to be an expert in the best way to write code so I’m going to be looking for support on that area.
Likewise it might be helpful to describe some of the mistakes you’ve made in the past. The bottom line is you have to be honest yourself if you want to foster a culture of honesty and show it’s ok to make mistakes. Psychological safety is vital for building effective teams. The boundary of that safety is the boundary of the team.
"Week 1 - Establish my place in the company" -> this is one of the biggest parts that I see impacting other CTOs I socialise with - they are solid on tech, solid on building a team, solid on product... what they don't foresee about being a CTO is that they now have to work in the context of the company leadership - depending on the size of the organisation, this could become political.
I often read CTOs where the other execs just don't understand tech etc - don't understand tech debt, don't understand XYZ - it's your responsibility to explain it to them and put your arguments across as to why it matters.
I think that's the sentence I struggled with the most - it was never meant to be "Make an impact, make my mark" it's really intended as "learn what my place is" or perhaps; start to create my butt groove in the sofa..
You're so right about that second part "I don't understand this tech thing, that's your job" - after 2 years as CTO at Wealth Wizards, I'm still trying to explain exactly these things..