What is an Engineering Manager?

The role of an Engineering Manager (aka Development Manager) will vary from company to company, but this post covers what, in my humble opinion, the core expectations, duties and deliverables of an EM are.

It is intended primarily as a guide to engineers who are starting down the path of Engineering Management.

At its essence, the role of an EM is about:

Building, leading and retaining high performance teams that regularly ship software to meet business requirements.

 

Let’s break that down into 5 key areas…

People first

TLDR; Your team, and the people on it, are now your primary focus. Keep your technical skills sharp, but never at the expense of the people on your team.

Switching from an Individual Contributor (IC) to a manager is a big career change (not a promotion!) and people now become your primary focus. While you have previously obsessed over code, architecture and technology in general, your team and the individuals in it become your focus. The role (as the “Engineering Manager” title implies) is a split of engineering and management, and as I wrote about in So you want to be a manager, it may even be as much as a 50-50 split in smaller teams, but that ratio will inevitably skew heavily towards people . 

As a manager, you likely have strong engineers on your team who can pick up any technical work. You likely do not have someone else who can pick up the people work. That is your role, and should be your focus.

That is not to say that technical skills aren’t valuable. They are in fact invaluable and undoubtedly worth keeping sharp. A hands-on understanding of technology is enormously useful in your day to job and part of the EM role is to provide technical input and guidance. This can be in the form of estimates, design and code reviews and documentation.

Can you still code too? Sure, but my suggestion there is to not take on coding tasks that are on the critical path. Remember that people are your primary focus and if a key team member needs your time, you should be available, rather than in a corner with headphones on coding to a deadline. Taking non-critical bugs that perhaps other team members don’t want to work on can be a great way to still contribute code. Pair programming is even better.

See also Kathleen Vignos‘s presentation and related github repo on how to keep up your technical skills as a manager.

 

Building a team

TLDR; Always be recruiting from a variety of sources. Team sizes of 6-8 seem to work well. Smaller can be too fragile, and larger means not enough time for 1-1 coaching.

Building a team is a key responsibility. Whether you are building from scratch, backfilling attrition, filling in skills gaps, or responding to growth, recruitment is key.

Always be recruiting

While internal recruiters are a great resource if available, don’t be lazy and rely on them exclusively. Utilize your own existing network, and seek out potential recruits at any tech events you may be at too (meetups, conferences etc). Internal transfers are also a great option. It is infinitely better to have someone move teams than move to another company. My own guidelines there are that it is fine (and indeed very healthy) to have coffees with people outside your team regularly, but if a conversation about someone moving to your team become a little more serious, loop in their manager early. You might also get feedback affecting your appetite for the move. 

Team size

How big is an ideal team size? 6-8 engineers is common, as the Amazon 2 pizza rule would would suggest. Will Larson in his book An Elegant Puzzle also suggests a similar team size, and that “Teams with fewer than four individuals are a sufficiently leaky abstraction that they function indistinguishably from individuals. They are also fragile, with one departure drastically changing things.” I don’t feel super strongly on smaller team sizes not working, but I can say from personal experience that when managing teams of larger than 8 engineers (or, at the next level, 6 managers), it is increasingly difficult to give each team member them time, coaching and feedback that they deserve.

 

Coaching

TLDR; Provide candid feedback and encouragement to your team. Don’t hold off on either difficult conversations, or longer term career coaching.

You have hired (hopefully) great people. How do you retain them, keep them motivated, and indeed have them keep improving?

A key element is having regular check in with your team members, including 1-1s and performance reviews (I previously posted on Preparing for 1-1s as a manager). Provide candid feedback, encouragement, coaching and mentoring. Focus on strengths and achievements. The “sandwich approach” has been widely debunked, and a ratio of 2 pieces of positive feedback to one suggested improvement is way too low, no matter how it is delivered. Studies suggest a ration of 5 or 6 to 1 is more appropriate.

On giving candid feedback, I recommend both No Rules Rules from the folks at Netflix, and Radical Candor by Kim Scott. If feedback doesn’t seem to be working and someone continues to underperform, have the difficult conversation sooner rather than later. I previously posted on Giving difficult feedback.

And how much feedback should you give? I like this quote:

“The real skill of an EM is in identifying which members of the team work best with minimal interaction and which require much more structure”

Finally, day to day coaching and feedback is important, but don’t forget about collaborating on a long term career path with your team members too. Team members shouldn’t have to change companies to take the next big step.

As a manager, you succeed by your team succeeding, rather than through individual heroics. So, do everything you can to lift the team up.

 

Represent the team

TLDR; Represent the team to others, both in terms of knowing external expectations, and making sure that your teams needs and goals are well represented.

As the EM, you are probably going to be the single most visible member of the team. That means representing the team to your senior leaders, other engineering managers, architects, product managers and recruiters. It is important to know what is expected of the team from others and be be able to communicate status up and out.

My own personal experience has been that Product Management is a particular important group to interact with. While direct customer interaction is always good, Product Managers are often the proxy, so you should have open, frank and frequent communication with them. In addition to hearing customer needs, you also need to communicate your team’s needs too. Ensure that Non-Functional Requirements (NFRs) are considered at planning and roadmap discussions. This may include technical debt, testability, architectural, security, reliability, performance and maintainability considerations. 

At this level, you probably won’t be expected to represent engineering to other departments (such as sales, marketing, legal etc), but this may depend on the size of your company, and it is always good to be aware of your surroundings anyway.

 

Provide cover and context to the team

TLDR; Filter and route communications to the team to ensure that they have the ideal mix of having the information they need while not being constantly distracted. Emotional safety is important too.

As well as being the focal point and representing your team to folks elsewhere in the org, you obviously also need to be there for your members, being an umbrella while providing the right contextual information.

As an umbrella, you need to be the first point of contact, shielding the team from any easily answered questions, and filtering out noise.

But some context is key so you need to provide that context and direction, communicating overall org goals as well as individual sprint objectives to ensure the correct business goals are being reached.

This may mean for example, that engineers should know that marketing are are trying to increase sales this quarter and how their work can help with that, but they do not need someone from marketing stopping by 10 times a day about that.

Instead, with context set and goals clear, engineers need space to concentrate and write code. There has been much written about how context switching is a productivity killer, not to mention the fact that most engineers hate to be interrupted while they are in a flow state (there is a reason so many wear noise cancelling headphones), so do everything you can to provide space to work. In addition to being an umbrella, this may include things like focus hours, meeting free days, core collaboration hours, quiet spaces or flexibility to work from home.

And still in the context of providing cover for the team, is the topic of emotional safety. Slack and Intercom have both written good posts on this, but the essence is to innovate and share bad news; Failures should lead to questions, not blame; Messengers of bad news are not punished.

 

Finally, measure success

With a team built, regularly coaching and direction setting, and the team focussed on shipping software, how do you know if it’s all working? I think there are 3 things to watch out for:

1. Measure Software Delivery Performance

The State of DevOps report describes 5 key measures that are useful guides on team performance and delivery success. The Accelerate book elaborates on this. I wrote about some of this in Development and delivery practices for team success

2. Measure what’s important

Measure if the new features you are shipping are being used. Measure downloads and customer engagement. Measure whatever you can to gain insights into the effectiveness and usefulness of your solution. And, at the most obvious and macro level, is the software being created increasing revenue? 

3. Get feedback

Get feedback from your team, customers, stakeholders, product managers and senior leaders. Often people are telling you how things are going everyday anyway. Listen.

 

Sources and References

• An Elegant Puzzle (amazon.com)
• Radical Candor (amazon.com) 
• No Rules Rules (amazon.com) 
• Accelerate: The Science of Lean Software and DevOps (amazon.com)
• State of Devops report (google.com)
• The Ideal Praise-to-Criticism Ratio (hbr.org)
• The “Sandwich Approach” Undermines Your Feedback (hbr.org)
• Please stop using the feedback sandwich (forbes.com) 
• Being an Engineering Manager (medium.com)
• Psychological safety first (slack.com)
• Psychological safety (intercom.com)
• The Managers Handbook (themanagershandbook.com)

And finally,

• Why great managers are rare (gallup.com) which suggests that the important traits for a manager are being able to motivate, be assertive, create a culture of accountability, build relationships and make decisions.

Tags: engineeringmanager, leadership, management, newmanager