Back to resources

Taking Over a New Team When Unfamiliar With the Domain

Internal Communication
Team Reaction
New Manager

16 April, 2021

Tommy MacWilliam
Tommy MacWilliam

CEO at Serenade

Tommy MacWilliam, CEO at Serenade, recalls his early days of taking over a team and being responsible for a technical domain he knew little about.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

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.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Managing Remotely: Balancing Team Cohesion and Focus Time

26 May

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.

Remote
Micromanagement
Meetings
Internal Communication
Productivity
Psychological Safety
Performance
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

The Challenges of Becoming a New Manager Among Old Peers

22 April

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.

Leadership
New Manager
Neha Saha

Neha Saha

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.