Successfully taking on a new team

Problem

I started working at Box as an early engineer. My focus was initially on building a backend team, and I continued to scale and grow the team until it had around 60 people. We then had a leadership departure on the webapp team. My manager, the SVP of engineering, asked me to take this new team on.

I agreed to take on this challenge, however, as it was my first time managing a team that I didn't build from the beginning. I wanted to be careful and thoughtful. A lot of my thinking about taking on new teams comes from the book "The first 90 days". This book is one of the only books I've found that talks about transition changes. One of the statistics in the book states that fifty percent of leadership changes struggle. The failure isn't because of the skills of the manager, but because of the inability of the leader to adapt to a new context. This means that adaptability is key.

Actions taken

There were two issues that I considered when thinking about transitioning. Firstly, the engineering teams at Box had become a little bit siloed from one another. This had resulted in less close relationships between the teams. Because of this, I had to be careful to ensure that the two teams retained their sense of identity throughout transitioning. Secondly, I had seen leaders at Box arrive and say to their teams that they had done things in a certain way at their old company, and so they'd try to implement those procedures at Box. While it's good to take learnings from other companies, you need to also think carefully about the context you're applying solutions to.

My first priority was to assess where the team was, and to decide what approach fits the best. For example if you take on a team that's really in pain and struggling, taking a lot of time to learn before you take action is not productive. Instead you should take immediate decisions to course correct and focus on learning later. In this case I found that this was a team that had good dynamics, and that I should help them take things to the next level to achieve excellence.

When I took over the team, my first step was to become an insider. I did this by integrating with the team, so I could drive change from within. This was key, so I spent time with team members, and tried to meet as many team members as possible one-on-one. During these meetings, I had specific questions I would ask, including "What advice do you have for me?". This question took some people by surprise, but it got them thinking about how I could become part of the team, and how they could help me make this successful. I also had events with each sub-team. I would invite them over, and cook them burgers that I'd sourced from a place in Idaho, so that we'd have fun and so I could become more of an insider.

There are three focus areas for becoming an insider – you need to become an insider with the people, with a process, and with the technology. I've discussed how I became an insider with the team members (i.e. people). For process, you need to understand how a team operates (e.g. how do they measure results, how do they ensure accountability, how do they share knowledge, and how do they do post-mortems?). For technology, you need to first understand an overview of the technology, and then you need to pick the areas you want to deep-dive into. I found the first thirty days critical, and my number one priority was learning and looking for quick wins.

One of the quick wins I had was addressing the sensitivity around having engineers disrupted through random tasks. There would be tasks that would flow the organization without high transparency and awareness, and tasks would be randomly assigned to engineers. I addressed this by ensuring that I communicated through the organizational structure when assigning tasks, rather than just randomly assigning a task to an engineer. I changed this straight away, as I felt it was important for the health of the teams.

Finally, I set up an advisory council, with people I trusted, and who I could meet with regularly. Thirty days is not a lot of time, so I was meeting with one group twice a week for thirty minutes, and another group three times a week for thirty minutes. This allowed me to quickly brainstorm about issues, so they could be rapidly addressed.

Lessons learned

By using this approach, I was able to take on a new team in a way that was sustainable, that built trust and that allowed me to rapidly make the changes that I did in a way that allowed the team to grow and get to the next level.

In addition, one of my learnings from my SVP asking me to take on the web app team was about the positive effects of delegating and trusting your team with more responsibility. The more you empower your team, the more that you'll have space to take on new challenges that the business needs from you.