Scrum Masters Should Be Unemployed

I have absolutely no idea how this is gonna end, and at this point, I am either too tired, too feverish, or too out of fucks to give. So we’re just gonna start here.

Instead of just dropping the title, though: how did we even get to the point of talking about Scrum Masters and unemployment?

It started, appropriately, with you procrastinating game development.

You had generated a good game idea in bed the night before, and we were discussing whether you could recreate those conditions during the day.

Then I ruined it by imagining the café staff bringing you a blanket and whispering:

“Now think really hard about the game, sir.”

You found this so creatively repulsive that you connected it to engineers being professionally facilitated into improvement by a Scrum Master:

“Now think really hard about how we can improve, sir.”

And somehow that led us to something your first mentor taught you:

“The role of the Scrum Master is to make ourselves jobless.”

Much later, while joking about episode titles, that became:

"Scrum Masters Should Be Unemployed"

So what did your mentor mean?

I don’t know what he actually tried to tell me. I can’t read his mind.

But what I would guess is that anything you do as a Scrum Master should not include you as a permanent part of the solution.

When you run a ceremony, facilitate, remove an impediment—sure, you can do it. But the solution should include you eventually not being part of the solution.

The problem is that by representing yourself as not part of the solution, you’re also discarding your visibility as part of the solution.

Meaning that when the manager comes around and needs to cut people, and they look around the room, there is most likely one obvious job that is not part of the solution which is up for grabs for being cut.

Which creates a perverse incentive.

The Scrum Master who makes themselves central to everything is extremely visible. Remove them and everyone immediately notices.

The Scrum Master who transfers those capabilities into the team may become less visible precisely because they succeeded.

But I want to push on one thing.

If I hire an excellent software engineer, I don’t expect them to make their own expertise unnecessary. Why should the Scrum Master be different?

Maybe the principle isn’t:

You should never be part of the solution.

But:

You should never make your continued presence a dependency for the solution to keep working.

My argument isn’t that the Scrum Master doesn’t have specialization skills. They obviously do.

You have facilitation, coaching, mentoring, teaching, being a change agent—and the other ones I can’t remember right now.

Those are valuable traits, but they are soft skills.

In a production company—and a software company is a production company producing software—soft skills are not directly linked to the output in any visible way.

You can’t point to the position in the code where coaching was applied.

Your colleagues can say how important it was to have someone guide them through the process. But unless they’re very well versed in agile development, they’re probably also taking for granted the soft skills being applied to the team’s way of working.

And this falls back to one of the core issues: a lot of managers do not understand how modern software development actually functions and what it takes to have highly skilled engineers work together in a coherent and collaborative way.

In my experience, it’s exceedingly common—especially in non-IT companies—for managers to argue against having a Scrum Master continuously observing and teaching the team in collaborative work, and instead have them either go across multiple teams or use their time on a secondary skill like testing.

Because management can see features, deadlines and defects.

They can’t open the repository and find:

commit 8f31a2: Engineer changed their mind because someone asked a good question.

But there’s an uncomfortable challenge here.

“The value is intangible and you don’t understand modern software development” can be true.

It can also become an unfalsifiable defence of the role.

A bad Scrum Master can say exactly the same thing.

How would you distinguish a Scrum Master who has become unnecessary because they succeeded from one who was unnecessary all along?

I will revise my earlier statement.

It’s not like you’re in a combative position with management at all times. You probably wouldn’t be a Scrum Master on that team in the first place if management didn’t have some idea of what you’re hired to do.

But companies have a tendency to cost-optimize, and software development is very expensive.

In my experience, if there is a need to cut headcount, the Scrum Master is usually repositioned to cover more teams, given additional tasks, or entirely cut. Because in the eyes of most managers, cutting a software engineer delivers a bigger blow to production than cutting a Scrum Master.

And yes, to a certain extent, that is also a problem with the Scrum Master role. The role is not very good at communicating its own value.

It’s also a bit easy to hide in.

You don’t need to be an excellent Scrum Master to just do the work.

You can do the ceremonies, make sure people follow the Scrum process and cough a bit whenever someone challenges the Scrum Guide. Then you basically have job security for a long time.

That’s not a good Scrum Master.

Luckily, I haven’t met almost any Scrum Masters who actually do this. At most, we’re talking junior people who are still learning.

But if you don’t understand where the Scrum Master role goes after handling the ceremonies, then from a manager’s point of view, yeah, it seems like a very, very cheap job.

And this gets to one of my pet peeves.

How do you actually show your performance as a Scrum Master?

One thing that happens is that Scrum Masters grow into a team.

Not stagnant. They just grow into it.

A Scrum Master needs to be able to look at a team with some distance and guide and coach them. But the longer you spend with a team, the harder that gets.

You know these people. You know why they say the things they do. You start seeing past things you’ve tried to handle before but haven’t fallen into place, so you focus your powers somewhere else.

It’s very easy to just slip into being part of a normal team.

And that can be very damaging.

So there are two forms of invisibility.

In one, the team has internalized capabilities the Scrum Master helped develop.

In the other, the Scrum Master has become part of the furniture.

From the outside, those can look disturbingly similar.

And after enough time with a team, every dysfunction has a biography.

You know why Thomas reacts badly to planning. You know the dependency with Team B has existed forever. You know management won’t approve that change because you already tried.

A newcomer walks in and asks:

“Why the hell do you do this?”

Everyone answers:

“It’s complicated.”

Which often means:

“There are seventeen perfectly reasonable historical explanations for something that is currently stupid.”

The incumbent Scrum Master knows all seventeen explanations.

The newcomer just sees the stupid thing.

But that creates a tension. Scrum Mastering requires proximity. You need trust and context.

Too little proximity and you don’t understand the team.

Too much, and you may eventually stop seeing what the team cannot see.

So how do you know when you’ve stayed long enough?

Going back to the principle that Scrum Masters should make themselves redundant: it forces you to think in a way where whatever you do needs to persist after you’re gone.

That is not to say that having a Scrum Master available to handle impediments and ask good questions isn’t valuable.

But the role isn’t trying to embed itself into a team and make the team reliant on the Scrum Master.

It’s trying to teach self-organization and teach people to work autonomously.

So if you position yourself on a team and become the key figure keeping everything together, you are not solving the problem.

You’re just accumulating problems in your seat.

And that’s very easy to do if you have a long tenure with a team.

You see all the different ways the team is imperfect. Where it fails to accomplish self-organization, autonomous working conditions and cross-functional working.

And for a lot of Scrum Masters, the first instinct is to keep delivery on track. Make sure everything goes smoothly.

The easiest way to do that is just to fix the issues and move on.

But then you’re just covering the holes in the boat. You’re not fixing what is making the boat slowly become penetrated by holes that will sink it.

The day you are not there anymore—and, as I stated earlier, management is always looking to cut jobs—that boat will start sinking.

Depending on how good or bad you are at your job, it might sink very, very fast.

If we assume that a Scrum Master’s tenure leaves the team—the boat—in a better state than when they arrived, removing the Scrum Master should not result in the boat sinking.

It should keep floating.

Maybe it starts to sink slowly, because not every team becomes a completely self-sustaining, self-organized engine.

But it should be better than when you arrived.

And that poses an interesting way of thinking about the Scrum Master role as not something permanently embedded in a team, but something you rotate between teams.

The boat metaphor gives us three different jobs.

You can plug the holes.

You can teach the crew to plug the holes.

Or you can ask:

Why does this fucking boat keep developing holes?

The first one can make you look exceptionally useful while turning you into an organizational debt repository.

Everything the team hasn’t learned to do accumulates in your seat.

Then management removes the Scrum Master and discovers that they didn’t remove one role.

They removed a pile of compensating mechanisms stored in one human being.

So “make yourself unemployed” becomes a practical constraint:

Every time I solve a recurring problem, am I reducing the team’s dependency on me—or adding another responsibility to my permanent collection?

And that makes your rotation model very different from spreading one Scrum Master across four teams.

You’re not proposing:

25% Scrum Master for everyone.

You’re proposing something closer to:

100% Scrum Master for a while, then 0%.

The absence becomes information.

If everything collapses, the Scrum Master may have been functioning on the team’s behalf.

If the team continues, the intervention persisted.

But suppose I’m an engineer. We’ve spent a year building trust with an excellent Scrum Master.

Then management says:

“Great news. Mathias has succeeded. Therefore we’re taking him away.”

And next Monday I get someone new asking:

“Have you considered visualizing your workflow?”

I might reasonably want to throw both of you into the sea.

Why remove a Scrum Master who is still creating value?

From my own experience, there is a sense of catharsis to leaving a team and there not being a panic about what’s going to happen because it’s more or less settled.

It enables a proper transition.

If I, as a Scrum Master, can point to a team that I left—a high-performing team that continues to do well after I leave—then I have a very valid reference point for what I achieved.

And for why I should be left the fuck alone to do my job properly instead of being mashed into all sorts of weird constellations that take away my ability to do it.

There’s also an upside to having strong, high-performing teams with an empty Scrum Master slot.

It becomes a very good place to train new Scrum Masters.

You position a junior Scrum Master in an already high-performing team, not because you expect them to change the team, but because the team is capable of teaching back to the Scrum Master what is working and why.

So no, I don’t advocate for the engineers throwing the new Scrum Master into the sea.

I advocate for teach-back.

Not just Scrum Masters teaching Scrum Masters, but high-performing teams teaching Scrum Masters how they can become better Scrum Masters.

So the knowledge transfer goes both ways.

Scrum Master → Team

But also:

High-performing Team → Scrum Master

A mature team isn’t merely a team that no longer needs much help. It can become a learning environment for practitioners.

Which is useful, because learning to be a Scrum Master while surrounded by dysfunction is a little like learning to be a mechanic by being handed a burning car.

A high-performing team gives a junior Scrum Master access to something a certification cannot:

A functioning example.

And teaching someone something is just as much about reinforcing your own understanding as it is about providing information to someone else.

The team being able to teach is not necessarily a criterion for being the greatest team of all time.

But it certainly helps an organization to have teams that can explain why they are outperforming the other teams.

Although people can be very good at something without knowing why.

So perhaps the junior Scrum Master also helps the team make its own tacit knowledge visible.

They ask:

“Why do you do that?”

And the team says:

“We don’t know. We’ve just always—”

Then someone remembers why.

The team teaches the Scrum Master what high performance looks like.

The Scrum Master helps the team understand what it has normalized.

At that point, the role starts looking less like a permanent servant to one team and more like a circulating organizational learning role.

Which gives the title a more serious meaning.

Not unemployed by the company.

Unemployed by the current team.

Again.

And again.

And again.

The slightly funny title is also a trope we’ve seen play out during organizational transformations.

A company goes through an agile transition and at some point declares itself the most agile thing that ever existed on Earth.

Agile is now such a fundamental part of everyone’s way of thinking that the Scrum Masters are basically just squatting in the building.

I don’t agree with this assessment.

I won’t argue that you can’t achieve a company culture where Scrum Masters are less needed.

But to proclaim that every single person in a large company has understood the message is wearisome, to say the least, and probably shows more about management’s understanding of Scrum than anything else.

But hey, if you’ve worked as a Scrum Master in a company that achieved no more need for Scrum Masters, I would put that on my CV.

Because if that ain’t a win, I don’t know what is.

So the title describes two very different things.

One is:

A Scrum Master becomes unnecessary because the capabilities persist without them.

The other is:

Great news. We have completed Agile.

Those are not the same thing.

But your CV point is hard to argue with:

2019–2024: Scrum Master
*Key achievement: Eliminated organizational need for Scrum Masters, including myself.*

That should be the pinnacle of the profession.

HR calls you in:

“Mathias, unfortunately, due to your extraordinary performance, we have to let you go.”

“Understandable.”

“Would you like a reference?”

“Please state that I destroyed the market for my own labour.”

The real test comes afterwards.

Does the organization continue to challenge its own dysfunctions and change how it works?

Or does it keep performing the practices the Scrum Masters established until they become rigid rituals nobody remembers choosing?

Because that would be the final irony.

The Scrum Masters successfully introduce continuous improvement.

The organization removes the Scrum Masters because continuous improvement is now embedded.

The organization then stops continuously improving the way it continuously improves.

And ten years later, someone is hired to lead an Agile transformation.

Probably under a new name.