The Manager’s Manifesto

Adopt the right mindset as you transition into engineering management

One of the most important career decisions for an engineer is whether or not to go into management. On one hand, it can seem like the only natural growth path. It could also be that you find you have an affinity for leading people and teams. On the other hand, it could take you away from what made you a great engineer in the first place, which is the technology and the code that you write every day.

So how should you think about this choice?

In this series of posts, I’ll talk about what it really means to “move into management” and how that is balanced against the fact that you are an engineer at heart, and also what an alternative path looks like. And I’ll offer some caution about trying to “have your cake and eat it too” and follow a hybrid path.

Let me start with an opinionated stance:

1. Software engineering is a different job than engineering management.
2. Just because you are great at the first, doesn’t mean you’ll be good at the second.
3. However, you’ll only be great at the second if you were good at the first.
4. Companies that recognize this and provide dual career tracks are more effective than those that don’t.

I won’t enumerate all of the responsibilities of an engineering manager here; it’s a long list, and given the open-ended nature of “people problems”, it’s hard to codify. (I recommend this blog post that covers the role in great detail).

The key insight is that it’s a fundamentally different job. While you are ultimately still working with technology and software, you are focusing on accomplishing your work through people: Aligning, organizing, motivating, inspiring, supporting, coaching … the list goes on.

Since your work is very different, your entire mode of operation is very different (check out this classic Paul Graham post on the manager schedule vs. the maker schedule). This is one of the key reasons why it is incredibly difficult to be a great manager and engineer at the same time.

Furthermore, by continuing to do your old job (engineer) while also doing your new job (engineering manager), you will inhibit your own growth and effectiveness in your new job, and you probably inhibit the growth of those on your team as well. Does this mean you need to go “cold turkey” and stop coding overnight? No, not at all. But you need to adopt a clear mindset change when becoming a manager.

And that is why I wrote the Engineering Manager Manifesto, to provide a very clear statement about the job of an engineering manager and the mindset that is required to be truly great at it.

Let’s unpack each of these points.

Managers first, engineers second

A manager needs to be technical to properly help and advise the team when needed, but it’s no longer the most important attribute of their job … their acumen regarding people is the most important.

Put another way, given the choice, where should you focus your time? 1) Gaining more hands-on expertise to drive a certain technical decision, or 2) ensuring that someone on your team has this expertise and can drive the right decision for the team? You will need to do both, but a manager should spend more time on 2).

A fundamental point is you still need to be technical to do 2). How else will you know that the team is making the right decision? The key consideration is at what level of technical detail do you need to also understand the topic, to ensure the right decision. Do you really need to get into the code or is a more conceptual level sufficient? Can you harness the expertise of others outside your team to help you?

If you’re successful at this second option where you leverage your team, you scale your impact, because someone else is doing what you would otherwise have done. And it gives you more time to do other aspects of the job!

But it means less time, and eventually, no time, in the code. If you’re not ready for that, don’t take this path.

Accountable for everything that their team does

Managers share the credit for successes, and shoulder the blame for failures, whether they were directly involved or not. This point couldn’t be more important to understanding the “all-in” nature of the job.

Let’s say that someone on your team introduces a bad bug, bypasses code review and ships directly to production, and causes a business-impacting outage. It all happened on one fine evening, without your knowledge. Are you accountable?

Most definitely! This person is on your team. Maybe you hired them, maybe you didn’t. Maybe the person is a high performer, and this was a rare accident or a process gap. Maybe the person is a low performer, maybe you’re already aware and working with them. Maybe someone else should’ve jumped in and helped. None of this changes the fact that you’re ultimately accountable for what this team does. You need to take ownership and decide how to improve the situation going forward.

Meanwhile, the opposite is also true. If someone on your team does something great, even if it’s not on your personal radar, that positive success does attribute to you as the manager! This doesn’t mean you should take credit for your team’s work; a great manager will give their team credit for wins while stepping up to take blame for failures. But rest assured that ultimately you will be measured by your team’s accomplishments, for better or for worse.

So remember, even if various people on your team are responsible for certain tasks, you’re accountable. No matter what. If this type of “all-in” ownership for a team motivates you, you’re on the right track.

Leaders

Much has been written about the difference between leadership and management. Some say that leadership is about vision and the future (“what” and “why”) and that management is about execution and the present (“how” and “when”). Others say that leadership is about driving change, while management is about keeping things running smoothly.

The reality is that great engineering managers need to also be good leaders. They need to ensure that their team is aligned with company goals and strategy, but also be able to have their team innovate and come up with new ways of doing things that can positively impact the business. They need to know when their team needs inspiration or space vs. operational improvements or concrete plans.

And as leaders and managers, they need to develop leaders in their own teams. These future leaders could be up-and-coming engineering managers, or they could be budding senior engineers on the IC track (which we’ll cover in a separate post).

Make sense so far? Now let’s talk about what great engineering managers are not:

The “smartest people in the room”

A great engineering manager must be able to hire, develop and retain people on their team that are better engineers than they are. This is both to keep increasing the level of talent and capability of the team, as well as to accommodate the fact that the manager doesn’t have the time to stay a great engineer and their hands-on skills will degrade over time.

Great engineers want a manager that they respect, including for their technical experience and direction, but they also want a manager that knows their limitations and when to defer to their team to make the right decision.

Order-givers

There is a big difference between providing strong leadership, including a clear vision and priorities, and autocratically directing your team’s activities. Great engineers don’t respond well to being ordered around; instead they need to be put in positions where they understand the goals and have the support needed to truly shine.

I’m a big believer in the work of Dan Pink, author of Drive, where he shows that the main ways in which individuals are motivated and do their best work is by ensuring that they can find Autonomy, Mastery, and Purpose. The most fundamental aspect of those three is Autonomy; the best people need space to achieve their maximum potential.

Another way to think about this approach is, “tell your team why, and work with them on what, and leave how up to them.” And if one of the things you look forward to in being a manager is “calling the shots”, you should strongly reconsider. You’ll need to do this from time to time, but it shouldn’t be why you chose this career path.

Technical leads or architects

Just like engineering management, senior technical leadership is a job unto its own right, and to do it well, you need to focus on it. So, while an engineering manager, having been a capable engineer before, and having a wealth of experience, can “pitch in” and fill these needs from time to time, they must be very careful to minimize this situation.

Instead, they should look to develop their team and also to partner with others in the organization (like staff or principal engineers who might be peers) to ensure that the right technical decisions are being made.

I was once told by a mentor, “Be careful not to play the architect. It will be really tempting at times, but even if you have a very strong conviction about something, you won’t have the time to research it deeply enough or to follow it through. Instead, bring your leads together and ensure they think deeply about the problem and arrive at a good decision. And always be evaluating whether you have the right people in the room.”

But wait, I don’t want to just be a people manager!

If you’ve read this far, hopefully you can tell that I’m not a fan of what some would call “pure people management”. There is a misconception in the industry that some types of managers can be successful solely by having 1–1s with their direct reports, looking out for their career development and happiness, and allocating them to projects led by others. I do not subscribe to this view.

Instead, I find that great engineering managers maintain a strong level of technical competence, even if they no longer code day to day or at all. They understand the domain in which their teams work, and lead critical projects and initiatives to successful completion. They have skin in the game for product velocity, health of the codebase, and operational excellence, not just team morale and retention.

However, if you don’t embrace the mindset that, as a manager, your job is fundamentally different from your previous job as engineer, you will be less effective in both roles. Keep the Manager Manifesto in mind!

What Else?

In future posts, we’ll explore a few related topics:

1. The staff engineer career path, and how a dual career ladder is a critical ingredient of engineering culture
2. The best way to divide up your organization into multiple teams, and how engineering managers and staff engineers work together
3. The stages of evolution of an engineering manager, from a newly promoted engineer to someone ready to take the leap to a director or VP level role.