How to take over a team?
A few months ago I changed business area I work in at Intercom from Messenger and Platform to our Messages product. I started to manage one brand new and one existing and old team. Taking over such team is always a challenge. The cogs are spinning, everyone has formed opinions about you, you don’t have context about anything and usually there is no time to slow down. Let me share some thoughts on what’s important when starting to manage an existing team.
The code will be fine, think about people.
Code, infrastructure or tests will be fine. Your fresh look a week after former manager won’t have any meaningful impact and probably will eat weeks of your time to build a better context than engineers in the team. Think about people and their anxiety and stress. People worry that they will need to rebuild their position, career or lose the rapport they had with the previous manager. Do your best to ease it. A genuinely successful transition means that everyone is excited about the change and no one leaves the team, or even worse - the company.
Align on goals and plans.
When taking over a team, there are already existing plans and goals for this quarter or, in Intercom case, six weeks. Make sure that everyone in the team, stakeholders and your manager understands the goals and plans the same way. Re-align with engineers on what’s feasible and are they happy about that. Lower the bar a little bit if you think that they are too ambitious. The success of the transition will be shaped by your first quarter and how green your goals are - consciously or not. Put a lot of pressure on planning.
Have strong opinions, extremely weakly held.
You bring new experiences and opinions to the team. Share them and ask for feedback whenever you see the chance. Sharing your thoughts makes you more accessible, but only if you hold them extremely weakly and proactively ask for counter opinions or feedback. Talk and don’t get silent.
Evolution of processes over revolution.
There are processes left by your predecessor that you might not fully enjoy or understand. But acknowledge that they were created with a reason and in most of the cases, they actually improved something and brought value. Make sure that you understand the why for each process and before doing changes, understand the second and third order consequences of changing it. Evolve the team slowly instead of turning things upside down.
What is the data?
Learn what data the team measures and why. You can’t improve what you don’t measure, and on the other hand, usually, we unconsciously make better things we measure. You may think that the team should measure more thing to get better insight into what to improve. Add metrics as you want, but don’t immediately settle the goals. Let the team understand the goal of new measurement and over time, build alignment on what the success looks like.
There is another side of data and monitoring - operational health of your product. Make sure that you feel confident with monitoring and alarming of your new area of ownership. Get this confidence from most tenured members of the team and if you lack it, prioritise work in this space. You can’t ship confidently and build a performant team without robust monitoring.
Be deeply curious and ask questions.
Not only about technology, as it’s common for former engineers to get excited and start diving deep into technology. Ask about what they think about things that are crucial for high performing team. Gather insights about your shared understanding of everything you do as a team. Ask how they trust each other. Understand what they think about their velocity. Ask these things on 1:1s or surveys, but not in a group. Let the quiet voices speak louder this time.
Summary
If there is only one thing you could focus on in your first six weeks in a new team, make it the people. People in your team are a most important asset and building a strong, healthy and successful relationship with them should always be your top priority. Acknowledge that they know the product and the business area better than you and instead of pushing your ideas, guide and nurture your team to solve problems, deliver goals and improve the team and product.
