In a perfect world, your manager would have a series of meetings with you to guide you into your new role. But that’s not always the case. Most of us are thrown in the deep end and expect to perform. So here’s five things I always make sure to do when taking over a team as a lead.
Meet with your team members
The first you should do is talk to your colleagues. These are the people you will work with on a daily basis. Team makes or breaks the lead, so having good relationships within is crucial.
Before you start sending invitations to your Zooms and Google Meets though, make sure you know what you want to communicate. Going in without preparations sure gives this “laid back” vibe, but it also can raise questions of whether you actually know why you’re here.
So, what should you say? Some must-haves are:
- A good introduction with some background. How did you get here, what experience you have under your belt, what makes you the person for the job? Highlight your strengths and try to lean into your interlocutor’s experience to connect with them;
- Brief vision of how you envision working together. What you would like to introduce? What worked in your previous companies and why?
This meeting should also help you to know your new team members. It’s a good place to ask some questions, like:
- What’s their background, past experiences, hobbies;
- What do they think is missing in the team or in the company;
- What works and what not.
Don’t expect five hours conversation though – they will most likely be reserved. Don’t take it against you – it’s completely normal. What’s important is not to push anyone. Some open sooner, some later – but it’s on you to see when they are getting pressured. If you see someone’s getting less comfortable, don’t push any further. Remember, you’re for a long ride together, and pressing people will never work out, it will just alienate everyone.
Okay, if you know what to say and what to ask, send invitations. I make it 30 minutes (with 15-20 minutes to spare in my calendar, just in case), as there’s no point to keep people for too long. I like to write them a heads-up on Slack, something like “Hey, I’ve sent an invitation for an intro call, nothing fancy, just a chat to know each other”. I found out it takes a bit of the edge and costs virtually nothing.
Meet with your stakeholders
The next thing you should do is to meet with the stakeholders. Product owners, marketing and design leads, other team leaders. This shouldn’t be that different from meeting your team, after all this is – again – the intro call. When introducing yourself, try to:
- Highlight your experiences with working with people in a role similar to theirs (for example, how you improved design/development handover or estimations);
- Offer your support, but underline that you’re still onboarding and most likely will require their help.
Also make sure to prepare questions you want to ask, such as:
- What are their expectations towards you?
- What are their expectations towards your team?
- What strong sides they see when working with the team so far?
- What weak sides they see?
After having answers to your questions, you will be able to start formulating a game plan for the team. It’s not a job for now, but something you should keep in your mind.
Go Through the Codebase
Once you talked with the devs, you’ve most likely heard at least something about the code. But nothing beats going through it alone. Clone the repo and read the docs attached. Note all the observations, like:
- Can it be installed easily? Will newcomers have hard time getting it up?
- Does it require any internal knowledge to get it running?
- Does the pipeline looks understandable? Can it be modified by someone who isn’t a senior?
- Which parts are changed often, which are dormant for months or years?
- What are observability options? Which parts of the applications are measured, can you see bottlenecks?
Note these findings and address them with your team. There’s nothing wrong in showing that you don’t know everything. It is certainly better than pretending that you do, and make a laughing stock out of yourself.
Take a Step Back
You’ve analysed all the things your colleagues and co-workers told you. You made some notes, jotted some ideas for what’s to come. You have an idea of what people like and what they don’t in the team. You know how the team is perceived by the other stakeholders. Great, now what?
Now, take a step back. Put these things on the back burner for a few days and just be present in the team. Join meetings, listen how the team works together, just feel the pulse of it. Don’t jump into any conclusions, don’t assume anything. Just listen.
I always try to take at least three days, possibly a week or more, to see how the team really behaves. What people say is very important, but keep in mind that they don’t always perceive things as they are. We are all biased, and you, coming from the outside, have a unique perspective that folks working in the team for months or years lack. During this time, try to note:
- What pain points the team has? Maybe too many or too long meetings? Or too much tasks in the sprint? Too much pressure? Or the other way around – too little to do?
- How is the communication within and outside the team? Are people on the same page? Are things getting agreed on during private conversations and then introduced?
- Who works well with who. Are there are “pairs” that perform well together? How can you utilize this further?
- Who is the natural leader of the pack? Who’s the “go-to” person? Who mentors others?
- Are things reported as problematic during the intro calls happen often? How do they look from the outside?
After having these things out, you will not only know what people think, but also will have your own observations of how the team works. It will help you formulate any and all further steps. But do note that these might change and for sure does not paint the entire picture. Take it with a grain of salt, even if you are certain.
Start Formulating the Game Plan
Armed with all the knowledge you’ve accumulated throughout last weeks, it’s time to be the leader. One of the most important qualities of a team lead is the ability to play the long game.
This step is the hardest one, because it requires analyzing all the findings and condense them into actionable items. You most likely find two types of action points:
Short-term goals, or low-hanging fruits, such as:
- Minor code problems, like flaky unit tests or pipelines;
- Too long and/or numerous meetings.
Things like these can be addressed rather quickly, as they require little actual work. Too many meetings? See which one are the least beneficial or which don’t require every team member. Flaky tests can be at least investigated during one sprint, with a bit of luck, this problem can be taken care of by simply assigning someone on it full-time.
But there will, most likely, be more complex issues that you will need to spread and plan in time, for example:
- Lack of stakeholder communication with the team;
- Constant sprint overloading;
- Internal conflicts.
Such things require your attention the most. You need to dive deep into this and analyze why they occur. For example, lack of stakeholder communication may be caused by chaos in the management, or by ignoring engineers and treating them as tools. It’s your job to build conscious recognition of your team. If sprints are overplanned, that’s an issue with either management, or the team, or both. Who forces these tasks into sprint? Why the team doesn’t fight back, and if they had, why it didn’t work? Are there conflicts? People don’t have to like each other, but they should at least stay professional to be able to work together. Not everybody is capable of that though, and it’s your job to make sure this conflict doesn’t spill on the entire team.
—
Doing these five steps should not only give you ideas of what the team really looks and works like, but also how the company works with the team. From there on out, you should formulate both short- and long-term plans to mitigate the issues and embolden the strengths.
Good luck!
