blog.eater.org

Being a good engineering team manager.

For the last few years, I’ve been a reasonably successful SRE team manager for Google. From this experience, and others in the past, I’ve developed a relatively basic philosophy:

    • Lead by example.
    • Keep your engineers happy.

That’s all. The language is succinct, but the practice can be tricky.

Leading by example is critical. It’s a way to inspire confidence from your team, and it’s vital for you to understand the technical environment beyond the usual inadequate managerial abstractions.

However, it’s equally important to identify the boundary between “leading by example” and “stepping on toes.” Do write enough code to stay fresh. Do sign up for on-call shifts. Do your homework when you don’t understand something. Do not write code when someone else would be more willing and capable. Do not force your personal opinions during design reviews; suggestions are fine, but remember that your position adds psychological weight to your words, so it’s hard for some to distinguish your personal perspective from a direct order. Communicate with this in mind.

Then, there’s the happiness part. Keeping engineers happy is a function of providing Silicon Valley style perks: 30” monitors, chair massage, and free food, right? Not really. Those things certainly make people happy, but not indefinitely. Google-style perks lose their lustre after a year or two. I stay at Google because I believe in the mission, and I love being surrounded by brilliant people. I learn and grow at Google. I can put my skills to good use at Google.

The foundation of happiness for engineers is the practice of solving interesting problems. Cultivate that passion in your team. The antithesis of this is bureaucracy; this is where the team manager can shine as a force for good. Team managers matter.

When it’s raining craziness from on high, you are the umbrella. When senior leadership is charting the course for next year, you are the lone representative for your team. You owe it to your people to understand their perspectives and accurately represent those perspectives to the upper echelons. You are a champion and a defender for your team. You speak on their behalf, and you protect their foundation of happiness: the ability to continue solving interesting problems.

I’ve spoken with managers who find it hard to keep people happy versus getting projects done. If you can build an environment where engineers are solving interesting problems, your projects will be done well. For the vast majority of situations, it really is that simple. Some managers may gain short term success by prioritizing projects over people, but that behavior, at best, is unsustainable. (At worst, it is unethical.)

Helping to develop the careers of people in your team is an extension of the engineering happiness principle (i.e., “solving interesting problems”.) Careers stall where there is a lack of passion for the work. Passionate people learn, grow, and get promoted.

When it comes to project staffing, your job is matching individuals to problems they find interesting (do you notice the repetition of this point yet?) This is not easy. People are not fungible resources. They are not interchangeable “full-time equivalents”. They are people, with unique backgrounds, motivations, and personal circumstances. You may have to move a person to a different project to find a suitable match. Sometimes you get it wrong once or twice, but the third time can change “missing expectations” into “rock star”. Sometimes this even means encouraging the person to transfer to another team. Always support transfers when it’s good for the person, even (especially) for your top performers.

Keeping engineers happy also means being honest when they’re not doing well. Practice routine candor with each person on your team. If work is stagnant or in decline, consider it your responsibility to discuss it well before serious remedial action is required. You should treat their performance as your performance, and demonstrate an appropriate commitment to improve the situation. This helps you resolve problems before they get bad. It also inspires the sort of trust and confidence you want as a team manager.

When I look back at my own performance and identify things I wish I had handled better, every case was a result of me getting lazy and not following the principles described above. When I look back at the accomplishments I’m most proud of, they were a result of following these principles to the letter.

[Comments.]

  1. noteater posted this