Chapter 5. Managing a Team

It’s a short step from managing a person or two to managing a whole team, but managing a team is more than just doing the job of managing the individuals. At this point, your job has changed. In fact, at every step beyond this level you will probably experience a totally different set of requirements and challenges. The hardest thing to prepare for as you advance in your career is the idea that you’re going to start doing totally different things. As much as you may want to believe that management is a natural progression of the skills you develop as a senior engineer, it’s really a whole new set of skills and challenges.

Here is the job description that I used for the role of managing a team, which I called “engineering lead”:

The engineering lead will spend less time writing code, but they still engage in small technical deliverables, such as bug fixes and small features, without blocking or slowing down the progress of their team. More than writing code, they hold responsibility for identifying bottlenecks in the process and roadblocks to success for their team and clearing these roadblocks.

The person who fills this role is expected to have a large impact on the success of [the organization] as a whole. In particular, leaders in this role are capable of identifying the most high-value projects and keeping their team focused on these projects. As part of keeping the team focused, the engineering lead will partner closely with the product lead to manage project scope and ensure the technical deliverables are met. In addition to focusing the team, they are capable of identifying headcount needs for the team and planning and recruiting to fill these needs.

The engineering lead is an independent manager. They are comfortable managing team members with different skill sets from their own. They communicate expectations clearly to all team members, and solicit and deliver individual feedback frequently (not just in the scope of review periods). In addition to strong management skills, the engineering lead acts as a leader for the technical roadmap for their product group (pillar). They clearly communicate the timeline, scope, and risks to their pillar partners, and lead the delivery of major initiatives on clear timelines. Additionally, they identify areas of strategic technical debt, do the cost/benefit analysis for resolving this debt, and communicate suggested timelines for prioritizing this to the management team.

We’ve covered the basics of managing individuals, but now let’s talk about what it takes to lead a whole team, all while still being technical.

The theme of this chapter is a focus on the job beyond the people management. Because it’s easy for new managers to get overly focused on the people-related tasks, I want to draw your attention back to the more technical, strategic, and leadership areas of managing a team.

Becoming a People Manager

I started out as an informal team lead in a company that had resisted traditional managers. After I played that role for a while, it came time for me to become an official people manager. Managers as a role were new to the company, and the entire organization met the changes with some trepidation. When dividing engineering among managers, we weighed who would chafe at the new structure. Not everyone was comfortable working for their former peers, but I was pretty lucky. Most of the people I now managed had worked with me long enough to be OK with the idea that I was now their manager. Their support helped tons. It wasn’t perfect, but the pushback I received wasn’t significant.

In this new role, I found myself managing a few people who were far more senior, tech-wise, than I was. It was the first time that I couldn’t rely on having the most knowledge as my main leadership tool. This wasn’t simple impostor syndrome. I knew I was out of my league. They knew I was out of my league! Of course, both of the most senior engineers I was now managing realized that this was awkward. We talked about how everyone had a job to do, and mine was to help them succeed however I could.

One engineer continued to help me along the way with ongoing feedback. I worked hard to learn what was important to this person and what they needed to succeed. The other engineer had trouble adjusting to me being his manager. He transferred to another team — at first. Months later, a bit contrite, he returned to our team and agreed to work with me. It turns out, being a good manager isn’t about having the most technical knowledge. The work of supporting people was far more important to management success.

bethanye Blount