Photo by cottonbro from Pexels
Here you are, sitting in your regular 1-2-1 with your boss. You expected it would be a routine check-in with her: “How have you been?”, “What’s the latest status on yesterday’s support bug?”. Then she gets to her update.
Dale, a peer manager, has decided to leave the company.
You will be leading their team of mobile engineers until further notice. You know nothing about building mobile apps - you’ve been a backend engineer your entire career. There are many unknowns. Kotlin, Swift, and their frameworks are foreign to you. You don't know the team, and some of the engineers are older and more experienced than you.
This is a daunting situation for new leaders and managers. An unfamiliar domain, you don’t have any answers to questions, and some of the team are ten years your senior. How do you manage an existing engineering team that works in a different domain?
The first thing is to accept that you don’t know anything about this existing team's domain.
Next, remember what your job is. Your job is to help guide people to make better decisions, learn fast, and achieve goals. Not contribute code.
Pay attention to how the team communicates:
Your first step is to understand how this team works and how the people on it collaborate.
By focusing on how the team collaborates you can work on the problems with the environment. These are the issues that few are paying attention to or don’t know how to address. Solving these problems is where you can contribute most to the team’s success.
Asking questions is a core skill of great leaders.
When someone is talking, stop thinking about how you want to respond. Instead, listen. Look for details in what they are saying that give you a new question.
By focusing on questions, you achieve two things:
After a while, some of these questions will become redundant. What do you do when you have a deep understanding of the situation?
Ask more questions!
I know - it's redundant, but your questions change at this point. Focus more on asking questions that guide the group towards the goal of the conversation. For example, take a meeting that requires a decision is made. Your questions should look to identify the detail that's preventing the decision.
Example questions include:
Building trust with the team is critical to your success. You will need to build this through relationships with everyone on the team. The most important people to focus on are the influential ones.
These are the people everyone listens to. They mentor the rest of the team and help them grow. Decisions change once they raise their concerns. You won't make any progress without them on your side.
How do you go about doing this?
You need to change your mindset of how you expect these relationships to be. Instead of being a coach, look to them as partners. This means you have to give them the space to own decisions in the domains where they are the experts.
The partnership also requires transparency from you. Talk with these people about the problems you are observing on the team and see how they can help.
By agreeing on the problems in the environment, you will have the support needed to solve them.
At the start, you’re going to struggle to keep up with the team's conversations. You must put in the time to learn the jargon and the systems that the team works in. You aren’t expected to become the foremost expert of the team’s codebases. Yet you must understand enough so you can empathize with the team. The goal is understanding since you will be an important advocate for these people.
Again, asking questions will be your quickest path to success. When in 1-2-1's, if a report begins to talk about what they’re working on, dig deeper than normal.
Don't assume too much.
Embrace your naivety.
Examples of questions to ask are:
You’ll also need to do homework on your own to learn what the team works with. Beyond the languages, identify the application’s key frameworks, systems, and libraries. Ask the team for blog posts, design documents, and book recommendations. This information will provide you with the context you need to finally keep up with the team.
You are going to learn a lot from the team - new technologies, jargon, systems, and more. This does not mean your experience is meaningless, though.
There will be times where the team struggles with a problem because they think an imaginary constraint exists. I’ve seen this before - a client-focused team has had a history of problems working with a backend team. Things like adding a new API is assumed to take a high amount of effort.
This is where you can help with your backend experience. You can provide them insight into how the backend systems work.
Remember that your experience here is not about imposing your will. Instead, continue to focus on questions to identify assumptions. Once you discover these, you can start to add real value.
Becoming the manager of a new team is daunting no matter the situation. Particularly when the team works in a domain you have zero experience with. To succeed in this environment, you need to enter it from a place of curiosity.
Ask a lot of questions, learn how the team does its work, and partner with influential team members. By taking these steps, you will discover the problems that are holding the team back.
With these problems in your mind, you can start to support the team in achieving their goals.
How do you gain the trust of an existing team?
I'd love to learn any tips you have to gain the trust of an existing team. The challenge of leading a group with strong relationships is daunting. How have you done it?
Let me know on Twitter or LinkedIn.
If you want to learn more techniques to improve your leadership skills, sign up for my newsletter.
Previously published here.