For the past couple of years, I’ve split my time between managing individual contributors and technical managers. This is my first time doing the latter, and while I can’t claim deep experience, I’ve learned a lot, and thought I’d put down my personal, highly idiosyncratic, in-no-way universal take on the subject. Think of it as a journeyman piece, naive and idealistic – you know, something I’ll look back on and laugh (or cringe) at in a couple of years. I have the feeling my leadership guru brother is laughing already. :)

First, a Brief Note

Names have been omitted, but that in no way changes the fact that I work with some awesome frickin’ people who’ve made my job (and life) a lot easier than I deserve. Thanks, everyone!

Onboarding

When I first joined TripAdvisor, I started as a senior software engineer, learned the code base, processes, and people, and only started managing a team when I’d built up some cred within the organization. This is a pattern that has been very successful for us – instead of hiring managers directly into the organization, we typically transition an individual contributor into a leadership role gradually, adding different responsibilities one at a time until all that’s lacking is the title. In one case, I had a new hire rotate through several different teams in order to get him up to speed on a broad cross-section of the code base, and also to get other managers familiar with him quickly.

The down side to this approach is that it’s hard to find new hires who already have management experience, as they frequently view an onboarding stint as an individual contributor as a step backwards. Finding great candidates is hard, and finding candidates who are on the cusp of making the transition to management is doubly hard. I’m sure we miss out on a lot of great hires, not to mention the experiences and new perspectives they would bring to the organization. On the other hand, hiring (or promoting) the wrong person into a management role can have an incredible cost, potentially to the extent of destroying a team (as the saying goes, people don’t quit companies, they quit bosses). By doing it this way we have a chance to work with a new manager before handing over the reins, to learn her strengths and weaknesses, and figure out if it’s truly a good fit.

On Being a Team Player

Remember that new hire I had rotate through a couple of different teams? Well, as he went from team to team, it turns out that one of those teams needed a manager more than mine, and he ended up stopping there and not coming back. Of course, this was a disappointment – I’d found him, recruited him, and was planning for him to fill a specific hole on my team. However, the other team needed help more urgently, he was excited by the challenge, and having him take over there was the right thing for the company as a whole (where he’s doing great, by the way).

When you’re a line manager, you have very specific functional- or project-related goals, and it can be hard to see how making a sacrifice for the larger organization’s success will benefit you and your specific KPIs. And, to be fair, in some companies it won’t. But the more senior you get, the more you need to be thinking about the broader context. You’re no longer responsible for one team, one functional area, one project – your job is to start thinking more strategically about the needs of the organization, and sometimes that means hitting a sacrifice bunt to get a runner on third.

Development

Everyone comes to the job with a different background, a unique world view, and a fragmentary set of skills. We’re trained to be engineers, then step into a new world with little or no preparation, and often few positive role models. Some things come easy, others will have to be learned through painful mistakes. You can’t just change a line of code and recompile.

The are four main areas I tend to focus on when working with a new or potential manager.

• General Communication

You need to know what’s going on on your teams. You don’t need the same level of detail as your managers themselves, but you do need to know both the high level details and the gossip. What projects are in flight, what’s coming up, what are the risks, what’s on time, what isn’t. Who’s doing well, who’s underperforming, who needs some encouragement, or is likely to be looking for another job. You may not be close enough to the day-to-day operation of the team to know what questions to ask, so helping your manager to communicate issues proactively is a top goal.

Every week there are a set of standard reports that need to go out. None of these should typically take a lot of time or organizational skill, but they do need to get done. These are the first and easiest things to hand over to someone new, precisely because the difficulty and stakes are low – all that’s required is a little bit of responsibility. Once they’re doing these stock reports consistently, you can start pushing them to communicate on other issues more proactively.

• Project Management

Some companies have formal methodologies (scrum, agile, XP, etc.), others are much less structured. Some have multi-year projects with dozens of team members, others have lots of quick-hit short-term one person projects. The situation can change dramatically from company to company, but there are some commonalities, no matter what the context. Gathering requirements, vetting projects for technical and schedule risk, organizing tasks, change management, working with stakeholders throughout the project to create as well-defined, organized, regular, and flexible a process as possible.

From a practical perspective, it doesn’t make sense to go to the extremes of either throwing the manager into the deep end immediately, or micromanaging. The best way I’ve found to bring someone up to speed is to involve her when it’s still your project, then gradually ask her to take over more and more of the tasks. In the beginning, you have to explicitly assign tasks, and give reminders to handle different things. After a while she’s doing almost everything on her own, at which point it’s easy to slowly disappear, stop going to meetings, and let her take over completely.

• Crisis Management

A surprising amount of crisis management boils down to knowing when, how, and to whom to report a fast-moving crisis. I find that a lot of my mentoring is done very much in the moment, asking one of my managers to write a detailed email to describe a problem. Though it’s natural for them to want to communicate a problem in person, putting that information into an email solves a number of problems. It forces them to organize their thoughts, and helps to clarify the issue; it demonstrates that they’re on top of things; it provides a document that can be circulated as appropriate; it prevents the various stakeholders from coming away with different memories of what was said; and it provides date- and time-stamped proof that they were communicating the issue contemporaneously.

In general, it’s much better to have the managers writing these and circulating them than to do it yourself. First, this kind of crisis communication is an essential part of their job, and this is training them on when and how to do it. Second, they’re the ones who most need to demonstrate that they’re on top of the situation. Lastly, you’re successful when your managers are successful, and you should always be giving them opportunities to demonstrate leadership or initiative. In the beginning, you may be prompting them much of the time, but eventually they should be mostly doing it on their own.

• People Management

Everyone is different, and everyone is going to relate to their teams differently. My model for interpersonal interaction isn’t going to work for you, any more than yours would work for me. People can smell phony a mile away. Even so, there are more and less effective methods of working with people, and these need to be part of an ongoing conversation.

The first is basic HR hygiene. No matter how innocently, you can’t ask an interviewee about national origin. You can’t make an evaluatory comment about an employee that references race, gender, religion, etc. If someone comes up to you with a complaint about sexual harassment, you need to go to HR immediately. And so on. This is basic 21st century common sense, but in a way that’s the point – the manager’s job is to be the adult in the room.

Next, there are some basics, so basic that I hesitate even to put them down, and yet… Like getting bagels, donuts, muffins, pizza, etc., for the team every so often. If the team is working over the weekend, you need to be there too. Always give the team credit, never take it for yourself. Never yell at people. Constantly look for reasons to tell people they’re doing a great job, and be concrete and specific. None of this is rocket science, but it’s also not necessarily obvious to everyone.

Most of us have rough edges that could use sanding down. I try to help my managers work through their less effective approaches, and develop better ones, mostly through readings. I also put in a lot of effort to listen when they’re trying to sand down one of my rough edges. Getting promoted doesn’t mean that you’re suddenly mature, funny, socially adept, and devilishly handsome.

People management is a huge topic, and I’m not going to be able to do it justice in a couple paragraphs in which the major concrete point is to buy donuts occasionally. Everyone’s mentoring needs are different (mine included), and the best I can say (trite though it may sound) is that you have to take each person individually, and figure out where she or he can improve.

Free Agents

It’s helpful to have one or two individual contributors who report directly to you, and whom you can pull every so often when there’s an emergency that needs taking care of. Sure, you can start directly allocating your managers’ resources, but that kind of sucks for all involved. Think about how you’d feel if your boss started bypassing you and telling your teams what to do.

Being Technical

The farther you move up the ladder, the harder it is to find time or reasons to code. Which raises the question of whether it’s really necessary for you to be technical at all, or whether a pure “people manager” could do the job as well (or better). Management, after all, is a completely different métier, and engineers aren’t exactly celebrated for their social skills (though to be honest, this seems to have changed significantly since I was in school).

Hmm… At this point, I was getting ready to write a fairly balanced set of pros and cons, walking through all of the reasons why both approaches had merit… But when I thought about my typical day, I realized that I use my technical knowledge all the time. I may not code that often, but I do lots of technical interviews; I write scripts to automate reports; I write database queries to look into issues; I discuss technical issues with my leads, and do code reviews; one of my peers moonlights as a release engineer; another is a key technical resource for the whole engineering organization. You simply could not do the whole job without a technical background. There’s a place for non-technical leaders in relation to engineers and technical managers, but I believe that place is via a dotted, not a solid line.

A Final Word, and an Invitation (or Two)

In some ways, I realize that I’m like a skier on the bunny slope talking with authority about the black diamond trails. I’ve been fortunate to have a tremendous amount of support from my manager, and extremely capable managers and leads to work with. If there are points I’ve missed, haven’t covered sufficiently, or gotten completely wrong, I’d encourage you to let me know. There’s plenty to learn, and I’m just getting started.

Also, I’m looking for a senior engineer who wants to make the leap – If you’ve made it this far and any of this sounds interesting, let me know! I can be reached at dblumenthal at, well, you know.