How to become a great engineering manager

You may be a fantastic developer, but when you take on a management position in software engineering, you acquire countless new responsibilities that go far beyond coding.

Think about it—suddenly, you’re responsible for leading your team members, and they’ll all require support from you at some point.

They’ll turn to you when there’s trouble, look to you for guidance, and count on you to successfully coordinate and complete projects.

You’ll become their first point of contact and their biggest champion.

That’s why we’ve written this article—to bring you the best tips for becoming a great engineering manager.

Learn to make tough decisions

Although software engineers make decisions daily, those are usually limited to their own coding. These are decisions about how to structure their workload, variable names, and similar.

When graduating to an engineering manager position, the scope of these questions expands.

Suddenly you have to decide which technology to add to your stack, what backlog items to prioritize, what feature to work on first, and more—all difficult decisions that can significantly impact the product and your stakeholders’ profit.

You become responsible for making the right call.

When making these difficult decisions, it’s essential to do so within a rational framework.

In other words, don’t just rely on a gut feeling. Instead, follow the advice of Lightspark’s co-founder:

It’s critical to develop a process for decision-making and stick to these guidelines whenever you’re required to make a tough call. Otherwise, you’ll struggle to make up your mind.

For example, a popular decision-making framework is OODA. The visual depicts the basic principles:

The tactic is an iterative process repeated continuously as new data arrives.

The initial step is concerned with gaining a complete understanding of the problem and gathering as much information as possible.

Afterward, you should reflect on the findings and decide on the steps that follow. You can do this by creating mental models, such as a mind map or a decision flowchart.

The third step is pinning down the most viable decision, followed by finally acting on it.

If you stick to this four-step routine, making tough decisions will become much easier, as you’ll have set guidelines to follow for every challenge.

However, it’s possible to break the OODA framework down even further. Initially developed by a military strategist, the OODA framework is helpful, but it’s versatile enough to be applied in multiple situations.

Below is a more detailed decision-making framework, adapted for a specific business context:

The first three steps encompass the observe aspect—focusing on what’s important, realizing you can expand your choices, and understanding your restraints.

The following two steps assist with the orient part—contextualizing the expected outcome and getting other opinions.

With these guidelines, you’ll find it much easier to observe and orient yourself and, consequently, make tough decisions and then act on them.

However, step five has one crucial caveat: don’t ask too many people for input.

Decision-making is best reserved for smaller groups of people, as too many voices tend to pollute the waters and make it harder to decide.

In fact, the authors of Decide & Deliver revealed the following:

Considering how the decision-making effectiveness goes down the more you include others, it’s best to consult only a few individuals when making tough decisions you’re unsure about.

These frameworks are a great guide for your tough decision-making process. Following them will certainly put you on the right path to becoming an excellent engineering manager.

Advocate for your team

As an engineering manager, your priority is your team. It’s your responsibility to pave the way for their work and provide the best possible environment.

In other words, you need to advocate for your team.

As part of this, you’ll often need to act as the buffer between your engineers and the stakeholders or upper management.

It’s natural to hear status updates about a project, but third parties won’t always choose the most appropriate time.

Furthermore, if they’re non-technical, they might not fully understand the setbacks your team is facing.

Warren Spector illustrated this situation well:

In these scenarios, it’s your job to explain the delays. Shield your team from any negativity, and meet with these individuals privately.

Illustrate how hard your team is working on the project, and clarify the reasons for the wait.

If they insist on previews or demos, you can host these yourself. Don’t bother your engineers with it—protect your team, and give them more time to focus.

Whatever happens, don’t overwork your team because of an unreasonable deadline.

Overtime is seldom a viable option and will often result in decreased morale, a lack of focus, and building resentment.

Just look at this engineer’s testimony:

In that atmosphere of never-ending hours and ongoing fatigue, this engineer felt the worst part was their seniors’ inactivity.

Instead of standing up for their team and pushing back against overtime, this team lead enabled the practice.

Don’t allow this, as your engineers will likely lose respect for you. Instead, advocate for your team, and refuse forced overtime. Push back against unrealistic deadlines.

Tanya X. Short, the co-founder of Kitfox Games, outlined the alternatives to overtime:

Instead of forcing overtime, explain that these are the two options, and through no fault of your engineers. Anything longer than a 40-hour workweek is simply out of the question.

Furthermore, another frequent reason for project lag is the number of meetings. Do your best to reduce meeting time for your engineers—they will appreciate it.

Coding is immersive, individual work that requires long periods of concentration. Your engineers are what Paul Graham calls makers. To make something, you need to enter a state of flow.

Introduce meetings into that rhythm, and according to Paul Graham, the following will happen:

Meetings can be hugely disruptive, interrupting your engineers and cutting off all the momentum they’ve built.

As a result, shield your team from unnecessary meetings, and reduce their number as much as possible.

Only invite them to meetings when absolutely essential, and free up as much time for coding as you can. Your engineers are sure to thank you for it.

Allow room for autonomy

Even though your job description as an engineering manager is to, well, manage your engineers, you can manage too much.

While you should provide direction, contextualize the workload, and coordinate collaboration, you shouldn’t micromanage.

When it comes to each individual task, there’s not much need for supervision.

If you tell your engineer to write the API documentation, you shouldn’t hover over their shoulder and explain how. Instead, take a step back, and trust them to do their job.

After all, that’s what they were hired to do.

Steve Jobs articulated the notion well:

You recruited your engineers for a reason, meaning they’re most likely talented individuals. Give them the benefit of the doubt, and believe in their abilities to complete their tasks.

With this approach, you might sometimes find yourself disagreeing with your engineers.

However, being in a senior position doesn’t automatically make you correct.

In fact, you would likely benefit from a change of perspective, as your engineer might have insights you hadn’t thought of.

If you and your engineer have contrasting views, don’t immediately shut their idea down. Instead, follow Margeaux Feldman’s advice:

Simply ask questions. Give your engineer a chance to explain their logic. It might turn out that their solution is superior to your own.

On the other hand, while asking them these questions, you might realize that they’re missing parts of information or that they’ve misunderstood something.

In those situations, you’ll need to step in and provide guidance.

However, this should be the exception and not the rule. You should only intervene occasionally, as your engineers should be nearly-independent when working on their tasks.

Christopher J. Pendleton, HPR’s Director of Engineering, described his role as follows:

Although your engineers should have their autonomy, it’s important to recognize when you need to get involved.

An excellent method for achieving this balancing act is to keep an overview of their tasks with a project management tool such as Jira. Take a look at the image below:

As you can see, each task is clearly displayed and assigned to an engineer. When first distributing the workload, it should be a quick process.

Simply delegate accordingly, and you can move on with your day.

However, you’ll have to step in if certain tasks are lagging.

For example, if a card has been stuck in the in-progress tab over the agreed time, you’d do well to ask if that engineer needs assistance.

If it’s only been a day or two, it shouldn’t be too much of an issue, but with a delay of over three days, they might benefit from your input.

Support individual growth

You’ll never find two engineers who are exactly alike. Each of your employees has their own ambitions, motivations, strengths, and weaknesses.

As their manager, it’s your responsibility to guide them to projects that are a good fit and therefore support their individual growth.

After all, your engineers will be much more productive if they are involved in tasks they are particularly adept at. As Nobel laureate economist Friedrich Hayek has argued:

Identify your employees’ unique information and place them in a context where they can utilize it best. Your engineer’s productivity (and happiness) will skyrocket.

Who wouldn’t enjoy working on a project where they can use their strengths?

However, you might not realize what your engineers’ strong points are. In fact, even your engineers might not know.

In such situations, a tool like Waydev can be a huge asset. An analytics and engineer management tool, Waydev delivers data on each of your engineers’ contributions.

For example, here’s a sample employee report:

You can see that this engineer is mainly focused on new work and isn’t too productive with legacy refactoring. Furthermore, their code churn is unusually high.

With these insights, you’d realize that this team member enjoys building new codebases, and you would re-shuffle their tasks to encompass only new projects, removing them from any legacy code.

You could then assign a more enthusiastic engineer to the legacy tasks, and they would likely have better results.

However, what to do about the poor code churn metrics?

Supporting individual growth also includes helping your engineers cover weaknesses and improve in areas they’re less proficient in.

One of the easiest ways to accomplish this is by investing in an online course. Udemy offers countless lectures on all sorts of software engineering topics.

Take a look at this example:

This course focuses on writing clean code, but there are many other programs to increase any skill set. By investing in such lectures, your engineers will slowly grow their expertise.

It’s also important that these courses—or any other professional development investments—should occur during working hours.

They should be an integral part of your engineer’s workday.

Google is an excellent example of this practice. The tech giant reserves 20% of its employees’ free time for unstructured learning on side projects unrelated to their primary tasks.

This is how the company’s founders explained the method:

Google encourages its employees to explore additional learning that is unrelated to their current projects.

They hope to foster creativity and innovation and inspire their employees’ continued education.

It wouldn’t be a bad idea to incorporate this model among your team—it’s a sure way to support your engineers’ individual growth.

Create a strong work culture

Unfortunately, it’s not uncommon for companies to see engineers as a means to an end.

These are businesses obsessed with increasing production speed, focusing purely on the final product and ignoring the process. However, this shouldn’t be your goal.

Instead, you should strive to create a strong work culture.

With a defined set of values and behaviors in place, your engineers will collaborate much more efficiently, and their productivity will increase.

Furthermore, a strong culture will be a huge help whenever you run into unforeseen problems.

Engineers who have embraced their work culture are much more likely to navigate their way through tricky situations.

Peter Drucker explained this concept best:

With a strong culture, your engineers can solve any issue.

In the same vein, no matter how polished your strategy is, it’s nowhere near as effective as a fully developed and widely accepted culture.

For example, if there’s a major bug, a strong culture will likely remind you not to hide the mistakes but to communicate them transparently.

That way, you and your engineers can solve the issue together.

When creating your culture, your first step is to pin down the values your team respects and embodies.

To streamline this process, Mark43’s Director Of Engineering recommends the following:

Don’t throw your net too broad—for a start, pinpoint three values. For example, if you believe in open communication, you may select transparency as a core value.

If learning is important to your team, continuous professional development could be part of your culture.

However, once you’ve decided on your three values, verifying that they’re a good fit for your company is essential.

To do so, ask yourself these two questions: does this value contribute to the company’s vision, and can the company act according to these values?

These questions are crucial to ask, as per Jeremy Wight’s recommendation:

The values you decide on should be relevant and attainable.

In other words, ensure they are in line with the company’s mission statement and that you can implement them in your day-to-day work.

Once you’ve established these three elements, the final step is simple—write it down. The aim is to create a record you can reference in the future.

For inspiration, take a look at the Valve company handbook:

Valve has put in print practices that support their chosen culture, leaving no room for ambiguity. 

As a result, there’s no chance of anyone being fired just for making a mistake—a creed in line with their culture.

Follow Valve’s example, and document your company’s chosen culture.

That way, when in doubt, you and your team members will always have a text that holds you accountable for your decisions and can guide you in the right direction.

Conclusion

Becoming an engineering manager can seem intimidating, especially if you’ve spent a while in a software engineering role.

However, you don’t have to worry all that much—as long as you recognize the most important principles, you’ll do a fantastic job.

For starters, don’t shy away from tough decisions and support your team members’ individual growth while allowing them plenty of room for autonomy.

Finally, do your best to create a strong work culture, one you can be proud of, and advocate for your team.

Follow these guidelines, and you’ll become a great engineering manager your team will be proud of.