So now you're an engineering manager. How do you know if you're doing a good job?
This was an important question for me about thirteen years ago, when I moved from a code-every-day software engineer into my first management job. In the decade-plus I've been an engineering manager (up until recently) I've relied on three measures for myself and engineering managers under me. It's the title of this post.
The problem is that managers enable their people to produce. An engineer's contribution is measurable, more or less. Even when the scale and units are slippery (is that 95% or 50% done?) at least you can see forward progress: releases, bugs closed, API users. But an engineering manager? At best it feels squishy; at worst it feels like overhead, and nobody wants to be overhead.
The question of "am I doing a good job?" came up when I was a first-time engineering manager at Akamai Technologies. This was 1999 and Akamai was still small-ish (30 engineers). Us first-time managers were learning on the job. That's when I distilled down my three rules. They are:
A good engineering manager's team should be
- working hard,
- working on the right stuff, and
- doing it the right way.
The key insight here is that you don't measure the manager herself, since management done well just enables the creative work of the team. Judge the team and you judge the manager.
Working Hard
Of course a high-performing team is inherently good. But it's also the best indicator if the manager is doing their job right. A productive team is a motivated team. In my experience, teams don't work hard unless they have all the wonderful qualities that we want in a team: empowerment, alignment with company goals, feeling of camaraderie, trust in management. They should be equipped to do their work and know why they're doing it. A manager should try to give their teams these things, or at least not get in the way.
Let's consider the alternative. If your engineers are demotivated or bored then long before they quit (and they will) they will check out.
One caution: working hard is often confused with long hours and face time. It's not. And there are few things more demotivating to a team than a manager demanding more hours. (Some places are really productive and only work four days a week.)
Hiring and firing figures into this too. An under-staffed team can't do what it needs to do or can get burnt out. Worse, lowering the bar to hire someone beneath the team, or not firing the low performer, is hugely demotivating.
Working On The Right Stuff
This is where the manager can have a more direct and immediate impact. You have to set up a few good processes (not too many) and enforce them. Your goal is maximize useful work. One way is to prevent work on stuff that will be wasted. Another is to reduce thrashing by finishing one thing before starting another. This is where delivery comes in: it's one thing to be busy, but how much makes it into real customers' hands?
Some of this sounds like product management, especially prioritization and product definition. But it doesn't happen well without the engineering manager communicating well, working closely with those product managers, pushing back constructively when needed. So actually read that spec!
Much of my career has been in backend systems. Infrastructure projects to enable features are the exceptions. Most aim to improve reliability by doing things like removing bottlenecks (scaling) or bulletproofing systems. Unfortunately I think the only way to judge these projects qualitatively. Measuring how often it would have broken is so hard. Just make sure you get a techie who you trust to evaluate projects impersonally and critically. And be careful of pet projects.
Doing It The Right Way
For many years I only had the first two measures. But I've come to value this one more over time.
This criteria captures quality and culture. Are the manager's engineers working well together? Best judge of this is if other engineers want to be in this group. Do the engineers have a culture of quality? They should speak with pride of their work. If they feel their products are slipshod, through lack of care or lack of room to do the job right, then it will show.
It also means that they aren't leaving scorched earth behind them. Their systems are maintainable and usable by others; the ops guys don't hate them because of missing tools or crappy logs; they've done code reviews and actually listened to the feedback.
Anti-Patterns
There are a couple of other things that I haven't mentioned as being important. They're probably on others' lists, but not on mine.
- "Leadership." To some people this means that you know how to tell people what to do. To others it means just doing a lot of the things above well, like communication. I'm not disagreeing that it's not important, I just don't know how to define or measure it. It feels like one of those "you know it when you see it" things.
- Well-triaged bug lists; great status reports; well-run team meetings. If any of these things help you accomplish the three things above, then do them, if not then they're paperwork.
For example, when I managed a large team at VMware I spent a lot of time triaging bugs. That's the VMware's engineering culture, but it's also what you need for a large, distributed team delivering enterprise software. By contrast, at Ning I spent very little time in the bug database. That team was much smaller (6 vs 100), and our releases were less complicated and less scary. And that was the right way to manage that team.
Finally, I want to credit some of those early managers in those Akamai days that I learned with/from:
- Experienced managers like George Conrades, Danny Lewin, Tom Leighton and Ross Seider
- Fellow newcomers like Joel Wein, Ravi Sundaram, Harald Prokop, Marty Kagan, Jay Parikh, Julia Austin, and Bobby Blumofe
- Thoughtful techies like Danner Stodolsky, Bill Weihl, Erik Nygren, and Chris Joerg.
A web app could be something as simple as embedding a little flash player. I've done this for the 
