Surprise! You’re an Engineering Manager. What now?

Great software engineers are amazing problem solvers with code and can get a crazy amount done. That’s what they’re paid to do. But if you become very skilled at writing code, you often get promoted. Great news, right? Maybe.

The worst use of an engineering manager’s time is writing code. Be sure you know that before you accept a promotion.

The software industry still (mostly) promotes excellent developers into people-management roles because companies rarely develop advancement paths for non-people managers (AKA Individual Contributors or “people who are not managing other people”). So now you’re the boss, are you prepared to not write any more code? Where is the documentation for this new “manager” job anyhow?

How can you, as an excellent developer, succeed as people-managers; a role for which you may have no experience or training?

Moving from a job for which you have tons of experience and expertise (writing code), to one where you have none at all (people management), is like becoming a baby again: you’ve got a whole lifetime of knowledge to learn and you need to do it yesterday.

It’s a transformative moment in any career to get promoted to a managerial role (it sure was for me). Here’s how you can handle this specific change and come out happy on the other side.

Flat Organizations are Replacing Command-and-Control

After World War II, veterans flooded into the workforce, at all levels. The following years saw huge growth in companies like IBM, General Motors, General Electric, and Westinghouse. As they grew, the ex-military executives used a command-and-control management structure to quickly grow companies.

Tech companies are rapidly deconstructing this management philosophy by flattening control structures. Where one manager may have previously had few direct reports, all of whom took directive orders, a manager now may have dozens of reports and employees are expected to be much more independent. This model scales up much more quickly than the command-and-control way, and also provides autonomy — one of the work qualities employees value more than money.

However, this flatness creates a very tough job for engineering managers: You manage more people, have less room to be directive, and you’re no longer doing the technical work at which you are so amazing. Not to mention you’re doing a lot of touchy-feely things (aka “not writing code”) at which you may not be experienced.

When we promote people diagonally like this, is it any wonder we see so many management issues at technical companies?

How can I be a great engineering manager?

It’s not prior job experience, because generally speaking, there are few jobs which prepare people to manage others. Coding is a focused, solitary activity, so developers are often less prepared to lead others.

Here is what makes a great manager:

• High emotional quotient (EQ)
• Excellent communication skills
• An understanding of the job

The first two are straightforward and I won’t delve into them here. The last should be clearly defined by the organization, but rarely is. Let’s give it a whirl:

Understanding the Job of Engineering Manager

Your job is to

• Set the broad goals of the team
• Propose a plan to achieve the goals
• Track progress against those goals
• Remove obstacles in the way of those goals
• Create alignment through organizational transparency

Seems simple? It’s super hard because each of those things shifts all the time. Let’s look at an example.

Set the Broad Goals of the Team

Let’s say you are a new engineering manager and you’ve been tasked with something like adding a “Teams” feature. Your job as the manager is to clarify what this means and propose a plan to get there.

The goal of the project is “figure out how our individual users can work together in teams”. Maybe you have 3 months and a team of 4 to get it done. This is your goal and you should probably write it on the wall in huge letters. Everyone needs to know right away if this goal changes, even slightly.

Propose a plan to achieve the goals.

Breaking this down, it means you can propose some kind of plan like:

1. Figure out how people are using the application collaboratively now (probably using hacky workarounds). This is the hardest part — figuring out what “working in teams” means specifically.
2. Prototype some ways of making those previously hacky interactions simpler and easier. Do this super cheaply and quickly.
3. Test prototypes with customers by showing them what you sketched up and talking to them.
4. Build the prototype customers loved most.
5. Deploy and get feedback via analytics and talking to customers.

Part of the plan involves group delegation, or figuring out whose strengths match up with the most important team tasks. As the manager, it’s your job to make it happen, but you need to do so with input from the group.

Track progress against those goals

How can you track progress? You can try a few ways and likely, your project or workflow may demand a specific way to know how you’re doing. Maybe the simplest first-draft is to write your plan up on the wall in big letters (see a theme?) and put check boxes next to it. Alongside that, you can also post work artifacts on the wall, like pictures of prototypes, photographs of user-testing, or quotes from customers. Maybe it’s in right-to-left timeline format?

I prefer Trello, but other tools (e.g. Asana) do the job just as well. Avoid things like Pivotal Tracker or Jira, as they’re built to grind out big waterfall software projects, not squishy projects which change constantly.

Remove obstacles in the way of those goals

Now that you’ve got a plan and a way to track progress, step back and do the obstacle-removing. This could means things like:

• Team Design — hiring, recruitment, interviewing, performance evaluations, terminations
• Better processes — using your broad view, spot process/flow issues and see if they’re an issue for others. Allow the people in the process to come up with the solutions.
• Engage in internal politics for the good of your team — Public recognition and kudos for your team, jockeying for more budget, trading favors, etc.
• Check in with employees to see how happy they are — Helping employees achieve autonomy, mastery of craft, projects with purpose, adjusting compensation, ensuring a safe working environment.

Some of these are obvious but you should also figure out what other obstacles lie in the way using this patented phrase:

“What obstacles are in the way of you doing your best work and helping us achieve our team goal?”

Create alignment through organizational transparency

This is an important activity which isn’t exactly related to the project success but is critical to engage in, nevertheless.

To describe this in other words, your goal as a manager is twofold:

1. Keep your team up to date on the activities, priorities, and temperature of the rest of the organization, particularly leadership.
2. Share what your team is doing with people elsewhere in the organization.

By helping to share of work across the organization, managers can help create alignment across all of the teams. This benefits the broader organization by facilitating knowledge sharing (best practices, useful new tool, etc.) and fostering a sense of cohesiveness. In general, sharing tactical project information like this has the effect of making everyone feel aware of the internal current events, which can help prevent feeling blindsided by organizational changes, not to mention feeling like a valued teammate.

What Is Not The Job of Engineering Manager

Your job is not to

• Write Code. You have a team for this.
• Review Code. You are not writing code, so you don’t get to have opinions about code.

I’m a decent coder (I think). At one previous management job, I shared plenty of opinions about code and it was a huge mistake. When I talked too much about how to write code, I noticed communication with me stopped until I backed off of the codebase.

Why? The team wasn’t 100% sure if they should take my advice as an order or disregard it and work in the way they found most efficient. I’m not alone in my experiences: many other managers and executives I’ve talked to have similar stories about muddying the communication waters.

This is a hard lesson to learn for many new engineering managers, because again, usually the reason they were promoted is because they’re great at coding, right?

What If I Still Want to Code?

Since most developers don’t really understand what their managers do, it’s inevitable that some want to be promoted — or already have been promoted — into a job that’s not a good fit.

This is a good realization to have, at any point.

You might be better suited for the role of Lead Developer. The Lead is more of a “first among equals” leader, setting tone for the actual technical work. This person gets to lead the architecture discussions, set code standards, lead developer improvement discussions, streamline deploy processes, and serve as the tiebreaker for bikeshedding arguments.

Lead Developers absolutely should be writing code.

If your organization declines to create a position like this or a parallel advancement path for Individual Contributors, and you really feel you want to follow a dev track, consider moving on. Fortunately, at the present time, there are a lot of other companies who would be happy to hire you.

I Took the Manager Job. How Do I Know If I’m Any Good?

Besides understanding what the job actually is, this is next the hardest thing about managing. You are very unlikely to get good or honest feedback as a manager from your team. It’s just hierarchy and there isn’t much to do about it. Even teammates who are excellent at giving feedback will inherently be averse to speaking up to their “boss”. It’s not their fault.

Here are some questions which might help you figure out how well you’re doing:

• Are you crazy-productive as a group?
• Are people eager to join your team or asking to be transferred elsewhere?
• If you ask, do the people on your team feel like you’re looking out for them?

Conclusion

Mostly, engineering managers struggle because of a lack of support from the organization, lack of definition of the role, or just a mismatch in strengths vs. role.

This doesn’t mean expert developers have no future career path outside of management, it just means you may have to work with your organization to develop a career path for people who don’t want to be future executives.

Acknowledgements

Thanks to Drew Dillon and Michael Ornellas for the original discussion which inspired this article. Thanks Chris Morrison for help in getting this this article started. Thanks to Pavan Trikutam and Gabe Berke-Williams for editing help.

Special thanks to anyone who has ever put up with me as a manager.