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 Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.
Engineering Manager at AlleyCorp Nord
Congratulations, you have just been promoted to an engineering management role. Once you are done celebrating the promotion you have worked hard to earn you might start to ask yourself, now what do I do?
AJ St. Aubin
Director Software Engineering at The RepTrak Company
A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.
CTO at REAL Engagement & Loyalty
Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.
Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
Muhammad Hamada, Engineering Manager at HelloFresh, addresses the uncertainties brought on by the pandemic, how these have affected our work environments, and how we can adapt.
Engineering Manager at HelloFresh