How to Take Over a Team, Part 2 — Time to Execute
The second part on how to take over a pre-existing team and lead them to success.
Read the first part of this article to prepare yourself to take over a new team.
Evaluate the team
We know a thing because it belongs to a class; we see a thing because it belongs to itself. — Chapter 9, The religion of Man, Rabindranath Tagore.
In addition to using those 1:1s to listen and to build confidence with the team, I also used them to map out my evaluation of the team. And by evaluation, I don’t mean a rating system that boxes people, but an organization of my perception of the team.
The best tool I find for these purposes is a mind map. I worked with a pen and paper to prepare my mind maps, but if you prefer a digital tool, I recommend Coggle or Xmind.
This recording of my perception served as a clear guide for my decision making in the coming months. I knew exactly what each person in the team needed.
Here’s how some of my mind maps looked like.
This evaluation will also help you understand what stage of team formation your team is in as per the Tuckman model. My team was in the storming stage.
Once you’ve understood the team and its individuals, you need to work on setting them up for success. To do this, you need to provide for them both at the team and the individual level.
Set the team and the individuals up for success
I am because we are — Ubuntu maxim
Something I hear often from great leaders such as my current manager and mentor, Mr. Chris Lanier who heads engineering at Betterworks is “setting up for success”. Any conversation about any new initiative, process, or organizational change starts with this idea of setting up for success. If you want your tenure with the team you take over to be a success, you need to provide them with the tools and processes that will help them succeed. Your success comes from the team’s success.
Here’s how I did it for my team.
Provide for the individual
Providing at an individual level is achieved by reviewing the map you created and then dividing tasks based on your assessment of the individual needs. For example, if you have a developer who is suffering from a lack of structure and will be motivated by ownership, then, you carve out a clearly defined well-scoped task for them and help them draft a thorough plan of execution. Or if you have a developer who is suffering from boredom and will be motivated by creativity, then, you work with them to identify initiatives that will benefit the business and the team the most and have them draft a plan of execution for implementing the initiative.
In some cases, you might not be able to fulfill the team member’s need by task division and assignment. For example, if you have a developer who feels like they lack a people connection within the team, then you might have to create opportunities to build connections by organizing shared learning or fun sessions.
It is also important to remember that in some cases, you might not be able to fulfill a team member’s need at all. If you can’t fulfill someone’s need, it is important to have an honest conversation about it and work out the next steps.
For example, if a developer feels they lack opportunities for growth in the current team, there is a chance you might not be able to meet them in the near future given the business’ plans. In this case, you have an honest conversation explaining the situation to the team member and check with them to see if they are willing to wait for the business to develop to a stage where it can fulfill their needs. If they are not willing to wait, you should evaluate if it is better for the individual and the team that they part ways.
In all cases, it is important to remember that your responsibility is not to address everyone’s needs but to be accountable for them. If you make a commitment to fulfill someone’s needs, you need to work out a plan that executes the commitment. If you can’t make such a commitment, then you need to communicate that clearly and work out an alternative.
Provide for the team
Providing for the team is a little more structured than providing for the individual. There has been a lot of research into this area and there are existing models of team behaviour and needs that you can rely upon to guide you.
My favourite model is the Tuckman stages of team development. If this is the model you choose, then you can adopt the below strategies depending on the stage your team is at.
Forming teams
Forming teams need success to fuel their growth. Having a clearly defined achievable goal helps the new team members use it as a means of alignment. Making sure the success is achievable will build their confidence which is crucial for sustained growth in the long term.
In my team I made this happen by introducing the Scrum concept of sprint goals. The team was relatively new to both the codebase and the product. This meant that they couldn’t estimate how much work they can get done within a sprint. So while they were gaining the expertise required to get better at estimation, we set up clearly achievable goals for each sprint (E.g., Get a demo ready version of the reports dashboard.) that could be achieved through different routes (E.g., The demo we gave at the end of the sprint was a UI-only version as ur backend was still in progress.). The team’s energy and confidence started increasing once they tasted success over two sprints.
The forming stage is also a good stage to build relationships. You can achieve this by organizing informal sessions. In the post-Covid19 remote work era, we found online Pictionary to be an excellent team-building exercise.
Storming teams
Storming teams can face a plethora of challenges. The worst case is a storming team that has developed many poor communication practices and unresolved conflicts. The best case is a team that doesn’t have a well-defined communication practice.
The key for a team at the storming stage is safety. This is the number one factor for high-performing teams as identified by Google as a result of a two-year research program. To help the team achieve safety, help them by setting ground rules for operation and communication.
For example, in the team that I had to work with, one of the challenges was office presence. Some of the team members preferred remote work, while some wanted to be in the office. Following conversations with both the team and the stakeholders in management, we decided on a system that would allow two days of work from home in a week and would require the team members to coordinate to achieve maximum collaboration on the days they worked from the office.
The key here is not whether the system was right or not, but the fact that a conflict (disagreements about work from home) was turned into an opportunity for communication, and collaboration. Because the decision was made through conversations and not by a mandate from me or the management, everybody had their buy-in and felt accountable to uphold it.
Norming teams
At the norming stage, the team is comfortable with each other and are used to achieving success on a more regular basis. There are many hits and a few misses.
This is the stage at which the team needs to be educated on the value of the process. At this stage, you must identify one or two members who are motivated by defining and executing processes and educate them to do that.
The most important thing to bear in mind when helping the team set processes is to act as their conscience and to ensure continuously that they don’t prioritize process over purpose.
For example, when my team had settled down comfortably in the norming stage, they were able to track and deliver stories consistently. But understanding and improving the quality of these stories and more importantly the code driving these stories was not very well-defined. So the team and I worked out a code review process with a checklist to guide everybody (E.g., commit message format, unit tests, etc).
The exciting thing about this process was that once the discussion about it was started, the team came up with suggestions and methods to make the code review more effective and owned the process once it was defined. It also helped in setting the norm of letting the team own decisions which helps them to get to the performing stage.
Performing teams
This is the dream stage! The team is consistently producing results. They welcome conflict and resolve it amicably. They are able to communicate and coordinate well both within the team and also with external stakeholders. What more can you offer the team at this stage?
This is the stage where you work more as a participative evangelist rather than a manager who directs.
You work on documenting and making the team’s culture explicit and evangelizing it. This will help the team grow as they identify and bring on new team members.
You work on documenting and marketing the team’s achievements to the wider world. This will help the team gain the traction they need to innovate more.
You work on understanding the product and business vision and evangelizing it within the team so that they stay inspired.
Beyond taking over
The exciting thing about engineering teams is that they don’t stay static. So even if you’ve grown your team into the performing stage, there are numerous factors that can change their configuration — an organizational restructuring, departures in the team, a particularly difficult project, and sometimes even simple ennui and complacency.
So, it is crucial to stay aware of and connected with your team. It is important to keep tuning your 1:1s, goal-setting processes, and understanding of the team to ensure they are always set up for success. Always re-evaluate and re-calibrate, especially if you feel certain about where the team is at.
Because…
Certainty is the source of inertia in thought while doubt makes for progress — Introduction to the Principal Upanishads, Dr. Sarvepalli Radakrishnan.
