Taking Over a New Team When Unfamiliar With the Domain
16 April, 2021
Years ago, when one of the engineering leads left the company, I was chosen to take over their umbrella team. The umbrella team consisted of a team focused on a product that I was originally leading and another team focused on the ML infrastructure. As an engineering lead, I became responsible for managing both of these teams.
The problem was that I didn’t know much about the ML infrastructure, nor I ever worked in the domain. Still had to establish goals for the team, be accountable for the team’s output, and build trust with them. Many people were -- justifiably -- uneasy because of my lack of domain expertise, but as it turned out, I proved them wrong.
Learning about the context and establishing trust
For starters, I identified a couple of tech leads on the team who could provide me with sufficient context. Though we didn’t use a “senior engineer” title, some of the people were already acting in technical leadership roles. I met with them, and in a lengthy and engaging conversation, expressed my interest to learn about the team and what they were working on. Occasionally they would refer to technical things I was unfamiliar with, but I didn’t try to deep-dive and grasp all the different pieces. What I was trying to do instead was to learn the vocabulary. When someone talked about “feature engineering” or “model serving,” I wanted to understand what they were referring to.
My efforts were met with appreciation by senior leaders, which helped me strengthen trust. Once I established trust with them, it percolated down to the team and spared me from trying to establish trust with ten or more people.
Talking to individual engineers
I would spend a lot of time talking to individual engineers on the team. I would be listening to them carefully, as I was in no rush to change things as many managers tend to do. Many managers would walk in and flip everything over, causing frustration among team members. I wanted to avoid that and was rather intentional about listening to different people with different opinions. I was genuinely interested to learn about the team, the broader context, team culture, and the main challenges.
Talking to people who worked with the team laterally
When people are taking over a team, they often overlook the lateral people who interact with the team and typically focus on people up and down the hierarchy. I instead went and chatted with a manager and tech leads of another ML team seeking their feedback on what our team was doing well and what it could be done differently. What I heard from them was quite different from what was coming from within the team, which I took as a great opportunity for improvement.
In general, it is vital to understand how other people are perceiving your team. That is a judgment I could not make for my team, but I had to rely on other people and use their lens to assess how my team was doing.
- It is possible to manage a team without having specific domain knowledge. It could even be an advantage; it was impossible for me to get bogged down with all technical details and low-level tactical decision-making. Sometimes, managers allow themselves to get immersed in irrelevant details and thus fail to make higher-level decisions. Even if you can understand technical details, don’t bother with it since it’s not a high-leverage use of time. You can always delegate those decisions to tech leads or senior engineers.
- Don’t get trapped in your team’s bubble. There is often a big disconnect between what the team believes is happening and what other teams perceive from the outside. When I took over the team, the internal perception was that they were doing great, but after talking with other teams I learned about things we were failing to deliver. If you rely only on the internal perception, you can easily find yourself trapped in the team’s bubble.
- Don’t try to do everything all at once. Instead, seek advice from veterans on the team whom you can trust. In the ideal world, you will be able to trust everyone, but in reality, you will have to choose smartly whom you can trust. Identifying those people and leaning on them to help you out with lower-level tasks is critical. Without having at least one or two people on a team of 12-15 people to help you out, you will not be able to implement changes.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.
Engineering Manager - Patient Experience at Curative
Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.
Engineering Manager - Patient Experience at Curative
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Senior EPM/TPM at Apple Inc.
Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.
Head of Product at ROI Hunter
Neha Saha, Manager, Software Development Engineering at Workday, illustrates the challenges of obtaining a position in management with no prior experience and the confidence it takes in order to succeed.
Manager, Software Development Engineering at Workday
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.