Software companies, even successful software companies, often have trouble hiring and retaining good engineering managers. Software engineering management isn’t a career you generally study in school, or that you get specific training for at work. Thus, there isn’t a pipeline of new engineering managers being created in the way university computer science programs are creating programmers. Beyond problems of supply, many of the managers that are hired and retained by software firms are often regarded as not being very credible or effective by the teams that work for them. For many programmers, the reaction they have to managers is a wish that they didn’t have one.
I got into engineering management as a result of this gap. When my boss Vic asked me to take over management of the team I was leading, I initially wasn’t wild about it. I loved my job as an engineer, and I loved my team, and I was hesitant to change that relationship. At the time, though, I already realized that this gap between the demand for managers and good candidates existed, and I didn’t feel great about what manager my team might get if I didn’t take the reins. So I dove into the role, and I started learning on the job.
Since then, I’ve learned a few things that I believe help separate good engineering management from the sort of management that you wish, maybe, just wouldn’t come into the office today. These are the three guiding principles that have worked for me as a manager.
Do the Work
The members of your team need to feel like you (as a manager) can do the work they are doing as well, or almost as well, as they can. That’s a tough thing to do, and I know a lot of people in a management role might feel like this objective is out of their reach. But I think it’s perhaps the single most important trait of a good manager.
You can’t lead a group of engineers if you haven’t worked intimately, for months, on the same codebase that your engineers have. Period.
Until you’ve done the job of the people on your team, and done it well, it is very hard for the people working for you to respect you. Why should they? If they think you don’t really know the system or the area they are working in, they’re probably right. If you haven’t tried to earn your team’s respect, by showing them that you have done their job and know how they feel, you’re always going to have the bozo bit set when talking to your team. They may listen to you, and they may well do what you say, but they’ll always perceive you as someone who doesn’t understand, someone from the outside— someone who’s architecting from the bench.
When you’ve worked in your team’s codebase, and you know for your specific team why various individual engineers are respected more or less because of what they’ve done, you can hope to interact with your team on engineering topics from common ground— and hopefully with a deep reservation of shifting decisions from the smart guys on your team, because you respect what they do. You’ve done it, too.
Getting to know your team’s code, and working in their codebase, doesn’t need to feel like an insurmountable goal. It’s important to remember that when diving in to the code of the project, you don’t need to become the best engineer on your team. In fact, you don’t need to become a mediocre engineer on your team. Your goal is just to learn enough to have a meaningful involvement with the project, and your team. Move slow. Take on a small bug or feature first. It’s OK to need a lot of help, and to have to do a lot of reading. Your team will be impressed that you’re humble enough to learn from them.
For managers that have never worked on the code that your team works on, I know this task will seem hard to do. You might nod, acknowledge the benefit, but not get around to it. You’re too busy right now, you’ve got a a full schedule every week, maybe 6 months from now.
But just do it. It’ll be the best 3 months you ever spent.
Be a Shit Umbrella
You’ve probably heard this expression applied to managers by now: “You can either be a shit funnel, or a shit umbrella.” If you haven’t, here’s a quick explanation: Umbrellas see their primary role as shielding those under them, protecting them from the problems that come down. Funnels see their role as directing the problems they receive down to the people who work below them.
The dichotomy between umbrella and funnel is first off a matter of attitude— a matter of whether you as a manager consider your primary purpose to be looking good in front of your own boss or being a good boss to the people who report to you.
Being a shit umbrella for your team (pardon my French) is a critically important part of being a good manager. Being the umbrella will be the most unappreciated, and unnoticed, thing that you’ll do as a manager. When you’re doing it right, your employees don’t notice anything at all— they just notice that they enjoy their jobs more. Over time, they may talk to their peers at other teams or companies, and realize that they’re in a pretty good situation— no pointless meetings, no unnecessary interruptions, no random changes of course, no new problems from on high dumped in their lap each month.
But they may never notice. You don’t become a shit umbrella so that anyone will notice. You do it because it’s probably the single most important thing you can do to make your team effective and happy. But more importantly, you do it because engineers will get more done under an umbrella— and getting more done ultimately makes you more effective at your own job.
Although the difference between an umbrella and a funnel is a matter of attitude, in practice being a shit umbrella is an instinctive response. Say your manager hands you a problem with a new set of requirements, ones that you don’t believe in and that were unexpected. As he describes this new request to you, immediately your stomach churns and your anxiety levels rise. What’s your first response? If your first thought is to dodge, question the problem, drag out the conversation, try to broker a solution with him, cajole and use any trick to get out of it you can think of, then you might be a shit umbrella.
If your first response is to nod politely, and say you’ll handle it, and then to immediately schedule a meeting with the best member of your team— well, then you might want to take a harder look at what you just dropped.
Every Day, Earn Their Loyalty
As a manager, having a team that is loyal to you is priceless. Every manager knows that getting, and then keeping, the right people on your team is your most important task. Everything else you do is just a means to that end: building and holding together a great team.
When trying to keep a great team together, loyalty is a more important factor than many managers realize. It’s also easier to cultivate than you think.
A team that feels loyal to you as a manager is a team that stands by you in hard times, sticks with you longer, and recruits their friends to join them. But a team’s loyalty is not automatic. Any engineer that’s been around for a while knows that important-sounding positions and titles aren’t worth the card stock they’re printed on. Your team’s first reaction to you is likely to be wary and skeptical.
In my experience, the primary motivators of professional loyalty among engineers are personal admiration and self-interest. The first factor is irrational, but the second factor makes sense: you stick with those that you believe will continue to work in your interest.
The missing link, then, is finding a way for you to demonstrate to your team that you are the best game around for their self-interest: a compromise between your needs as manager and a leader, and your employees’ expectations of reward and fairness.
The way you achieve this goal as a manager is by being completely, obsessively fair, in every little thing you do.
When you are a manager, or a team lead, you’re in a position of incredible of power. It might not seem so: after all, we’re only talking about the little details of daily work, and most of the decisions a manager makes each day are small.
But each one of those decisions is not small to the people working for you. In engineering, and in our modern culture, a tremendous amount of self-worth and identity comes from the workplace. Which project your team members get to work on, what specific words you use when providing them feedback, who gets a 4% raise and who gets 5%: each one of these little decisions matters the world to your team. And because those decisions are usually made in private, by you, your team is trusting you to be fair. They have to.
Being worthy of your team’s trust every minute, of every day, is what earns you your team’s loyalty.
Because you have so many little decisions to make, so many tradeoffs to make, it’s very easy as a manager to lose sight of how much these decisions matter. And the worst part is that you know that most of the time, your team will never know if you don’t give each of these little decisions the attention they deserve. So what if you phone it in, and just re-use your performance ratings from last quarter? They’re pretty close, and nobody will know.
But you’re wrong. Over time, your team will know. It’s a slow, very slow thing, because it’s the sum of a million little decisions and a million little reactions that your team only hears echoes of. But it’s the sense of confidence that comes from hearing the correct echoes over time that creates trust. People become loyal to you because they find that they can trust you to represent them fairly over time.
So there’s only one way to earn your team’s loyalty. You have to always be completely, entirely, 100% fair, in everything you do for and between your employees, no matter how tedious it gets and how much paperwork piles up. This may be hard to do, but you will never know which detail is going to be the one that comes back to bite you. If word of an unfair decision gets out, taking just one shortcut, performing just one lazy injustice, puts you at risk of losing you all the trust you’ve earned with your team members. So don’t let up. Be worthy of your team’s trust every minute of the day. Doing this is something your employees can’t detect in the first 3 months, or in the first 6 months. But around the first year of working with you, when everything they’ve heard in the hallways sounds right, and they’ve seen the right people get rewarded and the wrong people left behind, the members of your team may start to feel confidence in you.
And as time goes on, it’s that confidence that inspires their loyalty.
This management gap isn’t going away. The rate at which students are enrolling in computer science programs, and that we are creating programmers, is increasing rapidly. But the rate at which we’re training and educating managers isn’t. That said, no matter how good or bad a manager is, the most important thing about any engineering team will always remain the engineers themselves. A great team will usually survive a bad manager, but a great manager can’t turn a bad team into gold.
However, for a good engineering team, a good manager can make a dramatic difference in how effective that team is— how happy the team members are, how effectively they work, and how long they stick together. These three suggestions represent the principles that have worked for me as an engineering manager.
