This is the first in a many-part series about the growth path of engineering management. For most people, the Engineering Manager role is the first foray into this track. I intend to write about how one may (and whether one should) transition into a management role, but I wanted to start by exploring what approach a new Engineering Manager should take. This order may seem backward, but it is deliberate: a lot of new managers find that engineering management happened to them vs being something they have carefully planned and executed.

For example, you were likely a highly performing individual contributor in a rapidly scaling startup and the company’s leaders needed to anoint someone as a manager to deal with the growth. Or the CTO wanted to reward you for your effort, believing that a management track is the best (or the only) path to grow. Perhaps you did this to yourself, believing firmly that to be successful, you have to be a manager. Many engineers become managers against their wishes or despite how they best can add value, especially in companies that haven’t thought about the different dimensions of growth.

That said, if you want to be a good manager and believe yourself to have what it takes, hopefully this can help you get oriented.

The transition to management is conceptually difficult. Even though it’s still part of Engineering, often it feels like an entirely different function. To understand why, and what this implies about your strategy, let’s start by identifying what it means to be a valuable individual contributor. These are likely the traits you have been rewarded for so far, and these are the sources of biases that likely accompany you.

• You wrote high quality code: it had few defects, was thoroughly tested, maintainable (someone else could have picked it up), and scalable and future-proof
• You came up with good technical design, able to solve problems in front of us, as well as tomorrow’s problems
• You were a good collaborator: you reviewed code and helped junior engineers
• You had a deep understanding of the problems to be solved
• Perhaps you were a key developer on projects that included multiple developers
• You may also have architected solutions beyond the specific projects that you worked on It’s pretty clear to you what success looks like for each. While the specific answer (e.g. the technical solution) isn’t always easy to arrive at, the path is often straightforward, and there are incremental steps to take to get there. Many activities involve code – reading it, writing it, thinking of it. And you get feedback quickly from your peers, customers and your manager.

Now let’s look at your responsibilities as a manager:

• Make the team effective, both as individuals, and as a collective
• Help individuals grow in their careers
• Hire!
• Deal with people issues, have difficult conversations, be the steward of feedback
• Scale beyond yourself
• Own the team morale and be the cultural beacon

As a manager, your job is now fundamentally different in that what used to be standard indicators of excellence no longer apply, and in some cases may actually be holding you back. What it means to “add value” is a lot more vague and uncertain; there seem to be fewer “right” and “wrong” answers. What does it mean to successfully help individuals grow in their careers? Or scale yourself for that matter? How can you be evaluated on others’ ability to write code or their happiness? People issues feel squishy and they never feel that they are resolved. As for hiring, it takes much longer for you to figure out if you’re doing a good job. So much more of your job involves talking instead of doing.

In short, “adding value” now looks distinctly different in ways that can be really frustrating.

Let’s unpack that a little: what are the characteristics of your new role?

• Work is much less linear. The yield is much lower – you could be working on something for months and very little comes out of it.
• A lot of the impact you can have is invisible, or takes the form of second order effects. It is hard to trace outcomes to what you specifically have done. It’s hard to post-mortem outcomes because there are a lot more factors involved, over a longer time period. Worse, you may not even know if the outcome was successful.
• As a manager, you are expected to have an impact that is many times more than any single person’s capacity for impact. In part, of course, that is because you come with a team. But you can greatly affect the “multiplier” involved in translating the impact of each individual into the overall team’s impact
• You solving a problem is often hurting the team rather than helping, because you’re depriving your team of opportunities to grow, get better at something, and take on responsibility
• There are fewer excuses. As an IC, you could be working on something and if it never sees the light of day, it’s often not your “fault”. As a manager of a team that delivered this work, you would likely have been expected to avoid such an outcome. Even if you’re in no more control over the outcome than someone on your team, by the virtue of your responsibility, it is on you
• Soft skills are very suddenly, greatly more important. That includes communicating nuance, reading between the lines, inspiring people who “don’t feel it”, selling others on the opportunity, getting people to do things even though you have no authority over them
• Some things you’re expected to do are really uncomfortable, such as having hard conversations or firing someone
• The broader your purview (a full team, and later many teams), the more your job happens outside of your team – dealing with other teams, with the stakeholders or the customers
• You need to plan a lot more than you used to, even if there isn’t a clear answer
• You have to takes the perspective of others, e.g. when communicating or making staffing decisions

To make matters worse, you now will likely get less 1:1 time with your manager than when you were an IC (even if it is the same manager!), and overall you will get less feedback – in part, because of your new position of authority over others, but also because people have less visiblity into what you do. To add insult to injury, you may still be expected to play a non-management role, being a “hybrid” between a tech lead and a manager, as a transition to management is never a clean, binary one.

It’s easy to imagine what could go wrong with each of the above. As a new manager, I would encourage you to actually imagine what could go wrong. Play out the different scenarios and look deep inside yourself to understand what biases or wrong assumptions you may be prone to. A few common failure modes include:

• Not shaping your role to address the biggest gaps (or opportunities) on the team, for example, staying a “hybrid” tech lead-manager just because of inertia while in actuality, what the team really needs is a solid manager
• Not seeking feedback. I’ll talk about feedback later, as I think this is probably the most fundamental building block of good management
• Not finding the right balance between doing administrative work (e.g. reporting, performance reviews, going over comp, etc.) and providing support to your team (e.g. helping junior engineers, growing engineers into tech leads, etc.)
• Avoid difficult things (e.g. having a tough conversation) because you don’t know how to approach them or because they could cause conflict

What to do?

With that (somewhat depressing) context as backdrop, now what? Don’t give up yet. Below is a simple framework that might help you get started. Adapt it to your needs, but – since a lot of your role now requires planning – it’s better to have a plan for yourself than just to be “winging it”.

1. Identify key skills that you know you lack that you have to pick up as soon as possible

This could be things like good time management, ability to prioritize between disparate items, ability to act on multiple threads simultaneously, or simply follow-through. It is okay to have these gaps. We all have them even if it’s hard for us to admit it to ourselves. It is much better, though, to be honest with yourself now while it’s possible to course correct, than to do nothing and let bad outcomes happen because of these gaps.

The good news is that these key skills are usually easily learnable. Build a rapport with your new peers and ask them for their techniques, and support yourself with tooling (e.g. Asana for follow-through, calendar blocks for time management).

2. Ability to communicate is one of the skills you will continually have to be getting better at

Read back what you’ve communicated out. Identify the best communicators in the company and study the ways in which they communicate. And ask for feedback, often just after you’ve communicated. If people on your team find it hard to give you candid feedback, ask them to rank the different ways you communicate instead. The good news is that you will end up communcating a ton, so you have plenty of opportunities to get better.

3. Speaking of feedback – seek feedback, early and often

The best managers have created a finely tuned feedback machine on their teams, not just for themselves, but for everyone on their team. They have buy-in from their teams that feedback is valuable and is the most effective mechanism for the team to improve. They know that they need to use different channels for feedback, between 1:1s, surveys (anonymous and not), and conversations with their peers, stakeholders and reports, as well as their manager. They crave feedback.

4. Build early mechanisms for anything you dread

Most people aren’t looking forward to a review period. This is true, sadly, of many managers. Unfortunately, performance reviews are one of the few concentrated “tests” for managers, where it becomes clear who has done a good job managing their team and who hasn’t. If you find yourself sludging through the reviews, finding it hard to remember what each person did, build a mechanism to help you throughout the year. Write down data points as they happen, or force yourself to write down a sentence about everyone on your team every week or two, just for your own records. You can come up with similar mechanisms for other activities you’ll own as a manager.

5. You have a dual mandate

Your role has a big open-ended component: make the team successful. However, there are also likely specific fires you have to put out or parts of the mandate that are relatively clear. Align with your manager on them, and write them down. Score yourself on them periodically as a way to course correct.

6. Spend a lot of time with your team, in different forums

The most common criticism I hear of managers who are hired into companies from the outside is that they don’t spend enough time with their new teams to understand what they need, what they struggle with, and how they can help. I would argue that the same is true even for engineers-turned-managers who have been a part of the team. That is because the context you acquire as a team member is different than the context you need to acquire as the team’s leader. You need to understand where each person is more deeply, and you need to understand the interactions and points of interface more. Consequently, you need to ask different questions. Also important is ensuring a diversity of forums – not just 1:1s or team all-hands. That way you can help surface information that may not naturally come up. My favorite forum is a 2-or-3 on 1s: the manager gathering a very small group where one person may say something that helps trigger a useful response in others.

7. Ask your manager for help, being specific

Just like you, as a manager, would probably like your reports to tell you exactly what they need help with, you can help your manager help you by giving him a specific set of things you need help with. Don’t only focus on what you think your manager can help you with themselves. They should be able to figure out how to help you even if it’s not their time or expertise – for example, they can put you in touch with the right person, or raise the issue up. The more specificity you provide, the more effective help you are likely to get. Of course, if your need isn’t well-defined, don’t invent something. But at least for some aspects of your job, you probably have a good sense of what you need.

8. Identify areas of leverage

The most effective managers are able to build leverage for themselves. Identifying areas where you can get leverage is one of those activities you will always find yourself doing – as you get more leverage, higher level problems with greater scope open up, which require you in turn to get more leverage. As an IC you probably haven’t had a lot of opportunities to see what doing this well looks like. A good first-order approximation is to look at all the activities that you are currently spending your time on, and ordering them by importance. For anything that’s in the bottom half of the list, it should either be dropped or you should find a way to get leverage doing them.

**

Management roles come with a good deal of responsibility. They carry the potential of superlinear impact and often the cost of failure is high. If you have the right mindset and tools in your toolkit, management could be a very fulfilling career move, but it will come many areas where you will need to stretch yourself and places where you have to check your bias. While you should be open to a possibility that management is not a role where you can add the most value, I do believe that most companies don’t achieve an efficient frontier of management; that is, many people in management roles haven’t fulfilled their potential and others could be good managers but don’t know it (or aren’t given a chance). If you are up for it, hopefully the above is a good start.