Engineering Manager vs Scrum Master

People often ask me, “What is the difference between an Engineering Manager and a Scrum Master?” and “Do you need both an Engineering Manager and Scrum Master?” This article will highlight the differences between the two and what I observe across different organisations.

What is an Engineering Manager (EM)?

If you have read my article on the 5 Engineering Manager Archetypes, you will notice a broad range of EMs. For this article, I might offer a more general description that is true for all archetypes and describe an EM as a role that is: 

1. Responsible for managing people; and
2. Accountable for the outcomes of one or more software teams.

What might this look like in reality? To improve the outcomes of a team, a Tech Lead EM might share their technical skills/expertise and help teams make better design and architecture decisions. They might work with their Product Manager (PM) to prioritise the right technical debt to continue supporting business change over time. A Team Lead EM, often paired with a Staff Engineer or Tech Lead, might be able to focus more on the people and team aspects. A Team Lead EM might focus more on coaching and growing individuals, so the team is capable of reaching even more exceptional outcomes. A Delivery EM might focus on improving team processes or work with higher-level managers to optimise broader organisational bureaucracy to help work flow better through the team. The Product EM will act as a strong PM, working with customers and internal stakeholders to ensure the team works on the most impactful outcomes. Finally, a Lead of Leads EM will work with their leaders across several teams to support each team and ensure they work together to achieve more complex outcomes.

What is a Scrum Master (SM)? 

According to the latest (2020) Scrum Guide, the Scrum Master (SM) is accountable for two things:

1. Establishing Scrum as defined by the Scrum Guide
2. Is accountable for the Scrum Team’s effectiveness

According to the guide, SMs, “do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organisation,” and “by enabling the Scrum Team to improve its practices, within the Scrum framework.“

In the updated 2020 guide, Scrum shifted away from roles to accountabilities. Although I agree with the intent, I find their new terminology (accountabilities instead of roles) unnatural. This shift in language was to de-emphasis role descriptions because organisations see one role as one job, resulting in people with job titles called “Scrum Master.” A more appropriate approach is to clarify who in the team is acting as the SM or who currently has the SM accountabilities. 

What Are Major Differences?

EMs have line management duties; SMs do not

Unlike the Tech Lead role, most EMs (90+%) are responsible for line management duties. Examples of line management duties include running 1-1s, providing feedback, career planning and running performance reviews. 

The Scrum Guide does not address how line management intersects with Scrum, although it generally encourages a team to self-manage (i.e. the team decides who works on what). The Scrum Guide does not include line management duties as part of the SM accountabilities. Additionally, in this community post on Scrum.org, the consensus seems that SMs should not have line management responsibilities because it creates a conflict of interest. 

SMs should be experts in Scrum; EMs may not be

The first part of the SM accountabilities is “Establishing Scrum as defined by the Scrum Guide.” To establish Scrum, this statement implies that the SM should have an excellent understanding of Scrum.
Let’s look at an example. Imagine a company that has been around for 20 years. They have a very old-fashioned approach to planning software (think waterfall) and are looking to adopt a more agile way of working. This organisation might adopt Scrum and hire a SM to enable a successful transition. This organisation will already have EMs, but their EMs may not have a good awareness of agile or Scrum-specific knowledge. Think of the SM a lot like an agile coach, a role that needs to train, coach and help people learn new ways of working.

EMs have a broader and more defined set of responsibilities than SMs

Look at any EM job description, and you’ll find a detailed list of responsibilities. For example, a Tech Lead EM’s set of responsibilities might look like the following:

• Recruit, lead and motivate a team of dedicated cross-discipline engineers. 
• Design and lead the construction and evolution of software systems for the team
• Advocate and advance modern development practices in your team
• Champion high technical and architectural standards and drive sound technical decisions
• Actively foster a healthy team
• Coach, mentor and provide hands-on career development

If you compare this set of responsibilities to the SM’s, this EM’s set is more expansive and specific. The second SM accountability (“Is accountable for the Scrum Team’s effectiveness”) is probably the most confusing because it is so general. You can imagine a SM justifying all sorts of activities because it “improves the Scrum Team’s effectiveness.” Since this SM accountability is so broad, it is easy for people to define what they like, leading to different expectations.

What Are Some Common Challenges?

A team with a full-time EM and a full-time SM

Teams with both a full-time EM and SM sometimes conflict because they both expect to be accountable for a team’s effectiveness and have not agreed on how they should work together. Suppose both roles assume they take care of the same activity (e.g. facilitating a team retrospective). In that case, it’s natural that each person might feel upset or threatened when the other jumps in without involving the other person. The key to resolving this conflict is having a productive discussion around roles and specific responsibilities, such as running a RACI exercise. 

I have seen this specific configuration work quite well if the team is adopting agile ways of working and the SM focuses on training/teaching new approaches while the EM focuses on their typical responsibilities. These differences do not matter as long as the EM and SM form a healthy partnership (similar to how I’ve seen agile coaches support teams).

SMs who want more (EM) responsibility

Some organisations hire SMs for full-time roles. If they are doing their job well, they have introduced a team to Scrum and helped a team achieve extraordinary effectiveness. Their team self-organises, draws on agile principles and practices, and regularly delivers value with excellent technical quality. The SM has fulfiled their role expectations.

I see excellent SMs act like great agile coaches in a healthy situation. They’ve built a self-sufficient team, so their role is now redundant. The SM now has time to help a new team in the same organisation. But if the SM views their role as a full-time job on that team, what might happen? The SM seeks justification for their role, so they take on additional responsibilities and often want management responsibilities, leading to conflict with EMs.

Organisations can best avoid this situation by establishing expectations the SM should be a timeboxed role. For example, a SM works full-time with a team to introduce Scrum (e.g. six months). After coaching and training a team, this SM transitions to a different team or the person adopts a new full-time role in the team (e.g. as an individual contributor).

Does This Matter?

Ultimately, no. Companies that “use Scrum” have the most confusion about the scope of EMs and SMs. If you’re in one of these organisations, remember that:

• Scrum is a starting point – Any agile methodology (like Scrum, XP, Kanban, etc) provides a valuable starting point with rituals and processes. But, if your organisation has adopted the agile mindset using practices like retrospectives and inspecting and adapting, then any company and team would not operate the same way a year later.
• People can play multiple roles – Many confuse roles with jobs (i.e. one role = one job = one person). In reality, people play multiple roles at the same time. For example, a person might fulfil several roles such as “Team Member”, “Developer”, and “Support Contact Person.” Once a team has adopted Scrum, I often see the SM role rotate across team members.
• The SM is a Scrum construct – Many companies operate well without Scrum and SMs but still have EMs. These companies might use agile practices and approaches and still operate well without SMs. Although the Scrum Guide defines the SM role doesn’t mean it is necessary.

Although there are definite differences between the EM and SM roles, in the end, it’s up to you and your team to establish and build shared expectations on what provides the most value in your context.

---

• Enjoy this article? Sign up for Level Up, a free curated newsletter for leaders in tech.
• Want to level up as an Engineering Manager? Join the online Engineering Manager Essentials course or sign up for self-paced courses at http://techlead.academy