Why do you want to be an engineering manager?

  Why do you want to be an engineering manager?

 

 

I constantly run into folks [1] who want to become engineering managers - by that I mean managers within an engineering organization (vs. managers of engineering teams) [2]. I usually ask them "why do you want to be an engineering manager?" and that leads to (a series of) conversations along the axes I'm going to outline below. Rarely do I cross paths with someone who has already thought things through and has a good answer as to why they want to lead and why they are qualified to lead. 

Moreover, I run into many *current* engineering managers who've never had this conversation (with themselves, with their team, or with their manager). I had this chat with someone recently who asked me a very valid follow-up question: "so how do I get better at it?". In order to talk through how to evolve as an engineering manager, let's first walk through the different dimensions that make up the role.

 

1. People Management: This is the most obvious but also the most misinterpreted - yes, you have a set of direct reports, and you're responsible for them and accountable to them, but you're not there to tell them what to do every minute of every day (if you're doing that you're in for a surprise the first time you take a day off). Your job is to let them do their job, and that means creating an environment that not only allows them to do it, but excel at it. 
2. Communication Management: There are 2 elements to this - active listening and crisp delivery. For the first, you need to pay attention every time one of your team members speaks to you (during a 1:1, in the hall, dropping by your desk) - beyond that, ask clarifying questions, write down follow-up action items, and leave them with the (hopefully accurate) impression that you heard them loud and clear. Do not play with your phone while they tell you about some problem they're dealing with. Do not keep one eye on your laptop while they try to connect with you. Do not daydream about about lunch when they tell you they're getting burned out and need some time off. The second angle to this is making sure every communication to your team and about your team is crystal clear. You have to plan it, craft it, review it, rewrite it, and socialize it. Your team should never feel more ambiguity after you communicate to them - it should reinforce the same principles you've been repeating forever. And when you communicate outward about your team, it has to be the same message anyone would get if they stopped by to chat with one of your team members. 
3. Relationship Management: Once you understand that you essentially work for your team (vs. the other way around) and have done what's necessary to establish robust lines of communication, you can start focusing on relationships. You know relationships - long-lived with ups and downs, brimming with potential that's sometimes unfulfilled. You and the individuals on your team are in it for the long haul - think and plan accordingly. Going one step further, start to behave as one unit that builds relationships with other teams - these could be users, customers, dependencies, partners, overlords, etc - the success of your team is tied largely to intra-team and inter-team relationships. 
4. Opportunity Management: Part of setting up your team, and each individual on that team, for excellence is figuring out the "right" opportunities. Once relationships are in place, the opportunities will start to flow. Understanding which ones to tackle and which ones to pass on is more art than science - it comes do a combination of skillset, bandwidth, and alignment. You want to keep solving newer and more interesting problems, but that implies a certain mastery of yesterday's problems. And, even if all those ingredients are available, the relationship aspect still plays a big part.
5. Backlog Management: Once you have a good sense of the types of opportunities your team is willing and able to tackle, you can start to create a backlog of items you'll deliver. Again, more art than science - signing up for everything ever is a good way to overwhelm your team. You need to have enough things in the pipeline that folks are stretched to new limits without reaching their breaking point. You also need to be cognizant of actually delivering what you say you will to the people who need it; the todo list for the team constantly has to be reviewed, analyzed, pruned, and communicated (within and beyond). For a team that is truly humming, the backlog just becomes a simple priority queue and anyone with available time takes on the next thing. 
6. Results Management: Even with the world's most beautiful backlog, the only measuring stick for a team is results. In fact, the only reason to put management structure in place is a hypothesis that it will drastically (or at least marginally) improve the output of the team. Engineering Manager + Individuals = More than Sum of Parts. So, if you're accountable for results, but you're not really doing the heavy lifting (drafting specs, writing code, reviewing tickets, chasing bugs, making schedules), then you'd better make sure the people who are doing that are completely focused on the task at hand (note that task management is *not* on this list - trust people to do their jobs). This equates to building bridges, chasing dependencies, providing air cover, communicating progress, translating risks, identifying gaps, and being a management chameleon who can morph into whatever the teams needs to finish the job.
7. Metrics Management: The best way to quantify results for the team (internal understanding) and the broader org (external understanding) is metrics. Your job is to make sure they are defined, measured, optimized, and refined over time - again, it's your job to make sure that happens, not necessarily to do it all yourself. Your energy is best spent figuring out what measures actually represent success for your team, making sure everyone else understands and agrees, and then holding everyone accountable for them. And part of managing metrics it to make sure you're not falling into the trap of gaming metrics (where you try to make a graph or chart look good vs. using it to supplement a story about things that got done). 
8. Project Management: The act of weaving together a cohesive story around a set of deliverables your team gets out the door from time to time is project management. This is status reports and slide decks. This is Gantt charts and task tracking tools. This is reports that make you look good and bad. This is the broad email and the executive review. This is the nuts and bolts of running an org, and you need to automate and simplify it as much as you can. Make it as routine as possible so that it doesn't become the focus over actual results.
9. Priority Management: So, you know what to do, the team knows what to do, you're getting the opportunity to do it, and you're focused on getting it done and measuring it too. What could go wrong? Priorities. The thing that pushes most teams off course is a shift in priorities. Either externally (they shuffle and you don't absorb it) or internally (you start doing something other than your prioritized backlog without being aware of it), this happens constantly. You have to be ruthless. You have to apply them to your backlog. You have to constantly ensure they are what you think they are. You have to repeatedly communicate them to yourselves and others to ensure there are no gaps in understanding. A team that masters priority management will deliver results, and can then build from there to increase the output and velocity of those results.
10. Resource Management: Making sure you're working on the right things is step #1, but making sure the right people are working on the right things is the clincher. Through a combination of people / communication / relationship management, you have to develop an understanding of who is capable of what, who needs to be pushed, who needs some space, who needs a break, etc. The engineer who's built, scaled, and operated n Tier 1 services in a row might be ready for something new. The program manager who doesn't have a user bias probably isn't right for the customer-facing product launch. If everyone could do everything equally well, your job could be automated. If there weren't unique individuals to interact with and plethora of personalities to contend with, it would get pretty boring. But, as it turns out, your stew is unlike any other stew, and only you know when and how to season it. To top it off, you'll have to deal with "launches that cannot slip" and "projects that have gone on too long" and "people I can't work with" and "partners who don't know what they want."
11. alent Management: But how do you make sure you have the "right people"? This is where managing talent comes in. This starts with recruiting - you have to be clear about the needs of your team and then go out and do everything necessary to fill those needs (write job descriptions, socialize the postings, show up at career fairs, review resumes, conduct interviews, debrief on candidates, make sell calls, etc). And getting folks in the door is just the start. You have to onboard them carefully and completely, get them the perfect starter gig, and manage their growth carefully for 30, 60, 90 days and beyond. Growing talent from that point comes down to relationship / resource management. There is feedback to be synthesized and delivered. There are career ladders to climb. There is training to be provided. There are rewards and recognition. There are tough (very tough) conversations to be had. And it's a cycle that always has folks entering and exiting.
12. Operations Management: If you're doing all of the things above, you're running an org that has many different needs. Planning needs. Support needs. Logistical needs. Proactive and reactive needs. Just an all-around execution framework - in simple terms, the (documented or not) process by which work happens. This is beyond the day-to-day project management mentioned above - this weaves together things like key metrics and vision statements and delivery roadmaps and headcount asks. You'll get asked about this from time to time both from your team (who want to understand where things are going) and from your leadership team (who want to understand how fast things will get to where they need to go). 
13. Roadmap Management: We talked about a backlog earlier, but the other side of that coin is looking ahead, being proactive, and anticipating what will be needed or what bets to make. A good engineering manager can articulate (to anyone) where things are projected to be weeks out, quarters out, year outs, etc. This comes down to having a vision (there is no right or wrong vision). More than just having a vision, you have to decompose it into digest-able chunks and socialize it in a way that sets up your team to execute.
14. Knowledge Management: If your team routinely hits all of the above, it obviously has some tricks up its sleeve and is rapidly developing more - the difference between good and great managers is the ability to tap into that tribal knowledge. This could be documentation or talks or pairings, but you have to move beyond individual points of failure towards a high-performing whole that taps into the strongest abilities of each other almost at a subconscious level. And then extrapolate beyond your team to the groups that work with your team so that they can reap the benefits too without having to understand the minutae of your operating framework. 
15. Leadership Management: You keep up all this for long enough, and leaders start to emerge. What was painful yesterday becomes routine today, thanks to the contributions of folks who are ready for more responsibility. And it's your responsibility to find them more responsibility. Otherwise, they stagnate and leave (slowly or abruptly, doesn't matter, it robs the team of a chance at an evolutionary leap). The things you have to do are delegate, coach, and trust - that is fundamentally not easy for someone being held accountable as the manager of the team. In fact, it's almost counter-intuitive.
16. Intuition Management: Trust your gut. If you know your team, if you can communicate with your team, if you have strong / flexible relationships within the team, leverage all that. When you have ideas, explore them. When you see opportunities, jump on them. When you see risks, surface them. When you see problems, talk through them. When you've reached the point of no return, act decisively. Someone trusted you to shepherd a group of individuals towards a larger goal, so trust in yourself. 
17. Scope Management: If your team is successful in all of the above, more enduring opportunities start to materialize. You own A and B and were asked to help with C. Maybe now you're asked to just own C outright. And how about D too? Again, you know your team. You know what they can (and can't) absorb. You know if you have the leaders in place to tackle new, big things. You know how C and D fit (or don't) with your roadmap. You know how applicable your knowledge around A and B is to C and D. You know if C and D fit with your ruthless prioritization scheme. You know if talent that excels at A and B would do so at C and D. You know what relationships can be built (or destroyed) by taking on C and D. And, on some level, you have an intuition about it.
18. Decision Management: One of the biggest mistakes individual contributors make when transitiong to management roles is thinking that's their ticket to "making decisions". I got news for you - you make very few. You influence and facilitate a ton. But you only decide occasionally. If you're doing it frequently, you're not allowing your team room to grow. The real trick here is developing an understanding of what decisions can be handed off or made by committee vs. those that need a swift path forward from a singular voice. I won't spoil it (which ones to make) for you; what I've found is it's actually a function of the make-up of the team and even then it evolves a lot over time. Oh, and decider or not, you're accountable for all of it. 
19. Transition Management: People will leave the team. On good terms or bad. For the right reasons or not. For failed opportunities and new ones. It's the nature of the team - it's fluid. If you're doing the right things, you take it in stride. No one individual makes or breaks the team. Therefore, the departure of any one person doesn't cripple the team. Including you. Especially you. The day you take the job is the day you start preparing everyone for the day you leave the job. If you do this job well, there's a tougher job waiting for you. Every day, ask yourself what happens to the team if you get hit by a bus [3], and keep working on making yourself expendable bit by bit.
20. People Management: This one is so important I'll mention it twice. I've oversimplified to this point and made it seem like the team is you and a set of 1:1 connections radiating out from you. That's not true. There are a ton of inter-dynamics within the team. You not only need to be in tune with every one person as an individual, but every possible combination as well. You need to understand what can be tag-teamed and by whom. You need to understand who can back up whom. You need to understand who can teach and who can learn. You need to understand how each team member sees you, each other, and themselves. 
21. Time / Expense / Travel Management: Think of this as a bonus / warning - you'll have to track this in the most unfriendly-UX way possible using tools that were built by a team that probably didn't have a good engineering manager (if one at all).

I ask myself 3 questions every day to make sure I'm doing right by the team:

1. Am I prioritizing our work ruthlessly?     
2. Am I setting the team up for success?     
3. Am I working myself out of this job? 

But those are the things I ask myself because I've recognized by now that they help us move forward in the right direction at the right pace. You might need to ask yourself a slightly different set of questions in order to be successful. Nobody starts out an expert on any of the areas laid out above - it takes time and effort. And it takes a level of self-awareness; you need to recognize your strengths and build on them while being cognizant of areas for improvement and finding people / process / tools to help you out.

 

Now that you have a sense of what it means and what it takes, I'll ask again - why do you want to be an engineering manager?  

[1] this is not just via my day job, but also a pretty common theme in networking circles, job interviews, tech talks, etc  

[2] an engineering manager could be responsible for any subset of folks with the following titles: software engineer, hardware engineer, capacity planner, support engineer, partner engineer, program manager, quality engineer, product manager, reliability engineer, engineering manager  

[3] I had a manager that constantly asked me this - it really made me think ahead (it also made me look both ways while crossing the street) 

The Author: Ibrahim Bashir

 

                                     

About: 

Cross-functional leader in the technology sphere with extensive general management experience building user-focused, delivery-oriented product and engineering orgs