What Do Technical Managers Do, Anyway? « Dan Dreams of Coding

So what does your boss do, anyway? It can’t all be lying on a divan eating bonbons and watching other people do the work, can it? I mean, OK, sure, there might be a lot of that – but when she isn’t eating bonbons, what then?

It’s natural for this to be a source of mystery for individual contributors – indeed, managers typically try to shield their teams from everything that goes on behind the scrim. But when interviewing manager candidates, I’ve found that even they tend to have an extremely limited view of their roles, usually centering on project management and some vague handwaving around “mentoring.”

It’s important for people to understand what managers do for a couple of reasons. First, if you’re thinking of becoming a manager one day, it would be nice to know what’s actually involved. Second, you should know what your manager’s responsibilities are, and what you should expect from her. And third, if you’re already managing people, you need to know what you’re supposed to be doing.

With this in mind, I present the following thoughts on what it is that technical managers are actually supposed to be doing with their time. The balance may differ from company to company and person to person, but the overall list should remain fairly consistent.

Build a High-Functioning Team

Without a doubt, the most important task for anyone in a management position is to build a great team. Nothing else comes remotely close. You can’t do all the work yourself, and your ability to control how the team actually does its work is limited – so your goal has to be to create a highly motivated, highly skilled team with aligned incentives and similar values. That sounds like a lot of manager-speak (and I guess it is), but in a healthy culture, all it means is that you should assemble a bunch of strong contributors, and create an environment in which they’re rewarded for acting in ways that help the company.

Some of the people on your team are going to end up there through chance – either they were there when you took over, or got assigned to your team (for good or ill) through any of a number of channels. However, there’s a lot you can do to influence the team’s composition after the fact.

Companies live and die based on the quality of their staff and their ability to work together. A great team gets things done faster, better, with less need for direction or support. There’s more trust, less process, more getting stuff done – which, of course, makes everything easier, and everyone happier. None of this happens on its own. Someone has to find, recruit, and hire these awesome people. Helping to build a top engineering organization through hiring is both a key management responsibility, and one of the best-defined ways to provide outsized value to the company.

Not everyone is going to work out, either on your team or at the company. They frequently leave on their own, but sometimes there’s no way around it and they have to be fired. At this point, it’s the manager’s responsibility to the company, the team, and the person involved to grow a pair and just do it. You might have to put the person on a performance plan first. You might have to jump through HR hoops. But it doesn’t do anyone any good to let the situation fester, and painful though it may be, the sooner everyone can move along with their lives, the better.

Whether it’s an underperforming engineer or a star, it’s the manager’s job to figure out ways to help/push her team members to grow. I’ve written another post exclusively on this topic, so instead of repeating myself I’ll let you follow the link for ideas on how to go about this.

The other critical piece is to maintain a high level of engagement, intrinsic motivation, and morale. Every team culture is different, and depends on a variety of factors including the industry culture, the larger corporate culture, and (most importantly) the personalities of the people on the team. To some extent, it’s the manager’s responsibility to evangelize the corporate culture, but ultimately, either the team’s going to create its own identity, or none at all.

Books are devoted to team culture, motivation, and cohesion (I particularly recommend Peopleware), and there’s no way I’m going to be able to do it justice in a paragraph or two. But suffice it to say that doing this right is both difficult and critically important.

Clearing the Way

There’s a lot of random stuff that seems to come up, all the time. Someone needs a new piece of hardware. HR’s dragging their feet on reimbursing an expense report. There’s a personality conflict between two team members that’s negatively impacting team morale and productivity. There’s an annoying bug that’s going to take time to fix, but everyone’s fully booked on higher priorities. The team’s working through lunch, and the local Greek place doesn’t deliver. The CEO is hanging out near the team area, looking anxious. The technical lead and the product manager aren’t communicating.

The manager is the team’s soccer mom, fixer, cheerleader, defensive lineback, janitor, and mechanic. Her job is to fix any problem, and remove any obstacle that stands in the way of her team’s objectives, or that threatens to become a distraction. She’s the adult in the room, and has to be able to take care of any inappropriate behavior, protect the team against unreasonable demands, and navigate the larger organization to help her team succeed, all without losing her cool. Sometimes she has to fight. Sometimes she has to deliver bad news. Doormats need not apply.

Project Management

Whether the team is working together on a big project, or everyone’s doing their own thing, the technical manager typically does some amount of project management on the team. Sometimes this role is split with a business owner, but the tech manager is usually responsible for the following:

Alice is good at X, and Bob is good at Y, but Carol is new and needs an easy task to come up to speed on, so she should take Y while Bob gets the chance to learn Z. Meanwhile, Alice is getting bored of X, but it’s high priority so she’ll have to deal for now – maybe she can get the next “cool” task in W… Though nominally straightforward, task allocation frequently turns into a complicated logic puzzle in which skills, interests, development opportunities, vacation schedules, business priorities and history all interact.

Risk management sounds more complicated than it actually is. In its simplest form, you keep a bullet-point list of things that could go wrong. Each should have a mitigation strategy – usually a one line description of what you’re going to do to avoid the problem, or react to it if it happens. Review and update every week.

Much of the effectiveness of the exercise is that in thinking through all the possible problems, and what you would do to avoid/fix them, you put yourself on guard against them. A less obvious piece is that communicating the risk management plan to other stakeholders will give them confidence that you’re proactively planning for contingencies.

In the absence of information, people make stuff up. -Noah Blumenthal

Bad news can’t wait. -Clinton Keith

Providing regular status reports, communicating risk (technical, schedule, personnel, etc.) and doing deep dives into various areas of concern is a way to make sure that upper management understands what’s going on, and (just as importantly) knows that the manager understands what’s going on. The farther up the chain you go, the more teams a manager/director/VP has responsibility for, and the less attention she’s able to devote to any one. Demonstrating a firm grasp of status and presenting a coherent set of plans builds trust, allowing more senior management to focus their attention elsewhere.

Keeping the team up-to-date on relevant information, making sure that they’re communicating, and providing feedback (both positive and negative), is critically important to maintaining morale on the team. People like to know where they stand, and people will misinterpret any interaction – or non-interaction – in the most bizarre ways. Lack of subtlety is the key to success.

Every team, and every project, is going to have multiple stakeholders. Keeping them informed of status, risks, and major events will increase trust and decrease long-term friction.

In some ways, the manager is the person on the team with the least power over the final deliverable. All of her end product (or most, if she still codes) will be the result of work done by other people, with their own motivations, skill sets, personal lives, hobbies, vacation plans, etc. It’s hard to build intrinsic motivation in others, and it’s hard to keep people focused while not micro-managing. But just assigning tasks and hoping that things get done isn’t an effective strategy either.

Whether it’s Scrum, Agile, XP, Kanban, or some home-grown methodology, there needs to be a reasonably well-defined way of getting certain (not necessarily all) tasks done. Maybe these are rules around merging your project’s branch with the master branch, getting code reviews, or specifying how people can get permission to make risky changes to the codebase. Maybe it’s about having a daily standup, or the decision to use a particular piece of bug tracking software. The manager may or may not decide the specific strategy, but it’s her job to figure out where problems are most likely to occur, and work with the team to create processes to mitigate risk.

Performance Management

There are lots of reasons to do regular one-on-ones with direct reports. It gives them a chance to air grievances. It gives you a chance to discuss performance concerns. Or compliment them on an accomplishment. Or discuss personal development goals. Or develop rapport. And because it’s a regularly scheduled meeting, neither of you has to feel uncomfortable about calling it in the first place.

As much as you may hate doing your self-review, pity the poor manager who also has to do reviews for everyone on her team. This includes keeping notes throughout the year, providing regular feedback, and completing the yearly HR-mandated performance evaluation. It also involves creating lists of personalized goals for each engineer.

Raises, bonuses, and promotions don’t just happen. The manager is responsible for championing her people, fighting to get them the recognition they deserve. This shouldn’t just be during the annual review process, but every time something notable happens. Frequently talking up a great employee will help during the sell when you have to justify a promotion or outsized bonus.

Let’s face it – giving feedback (positive and negative) is one of a manager’s key responsibilities, and also one of the most common areas for her to fall down. Negative feedback is hard to give, but many managers are also uncomfortable giving praise – it’s not something we’re used to doing in everyday life, and people can worry that it sounds fake. The former results in a surprisingly bad year-end performance review for someone who doesn’t know what’s coming. The latter creates employees who are constantly on edge, never knowing if they’re doing well. Obviously, negative feedback has to be delivered appropriately, but giving lots of positive feedback for objective, concrete accomplishments builds trust and demonstrates respect – which makes it easier to give negative feedback later.

Train a Replacement

That’s right. One of the manager’s key tasks is to train a replacement. If the manager gets hit by a car (or, in a happier scenario, wins the lottery), the team needs to be able to continue without her. More importantly, it’s very hard for her to be promoted unless there’s someone on the team ready to take her place. There’s a natural fear that training someone to do your job will make you expendable, but in a healthy organization, it’s a requirement for moving up the ladder.

Coding

Depending on seniority, and the size of the organization, some technical managers still write code. Sometimes this is part of the job description, sometimes it’s a way to get a management task done (e.g., setting up a cron job to generate a report), sometimes it’s a way to clear the way for the team, and sometimes it’s just a way to blow off steam.

Everything Else

A junior developer can be successful just by doing well at the tasks assigned. The more senior you get, especially as a manager, the less well-defined your job becomes. You can do everything described above and still not be doing a great job – at some point, you’re the one who has to figure out what needs to get done. In addition to the interrupt-driven nature of the job, this is one of the reasons it’s so hard to have a role split between management responsibilities and coding. To be an effective programmer, you have to be able to shut everything out and focus completely on the coding task. To be an effective manager, you have to be constantly thinking about what else you could be doing, should be doing – and, of course, be doing it. It’s hard to manage and code without one or both suffering.

Valve

And then, there’s Valve. It would be a fascinating experience to work in a place where none of this applied. Or applied to everyone? Vive la différence!

A Penultimate Word

I’m not going to be able to speak for all managers or organizations, and as I read over what I’ve written I don’t imagine that I’ve written a definitive list of everything technical managers do. But I hope it’s a good start, and would love to hear your stories of favorite technical managers, and what they did that made them great.

Further Reading

The following are some books – some explicitly on management, some not – which I’ve found helpful in thinking about how to do the job.