Taking Over a New Team When Unfamiliar With the Domain

Problem

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.

Actions taken

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.

Lessons learned

• 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.

"It is possible to manage a team without having specific domain knowledge."

"Don’t get trapped in your team’s bubble."