Scrum Masters Should Rock the Boat. Is your org letting them?

I once worked with a really good Scrum Master who made my views on the importance of the role do a complete 180. Most people I encounteredd in the role didn't do much more then share their screen during the daily, schedule the scrum ceremonies or remind the team to stay in a meeting's timebox.

Scrum Master is the role in which the least damage can be done if it is occupied by an ineffective member, but it is also the one which can make the biggest impact on a team if overseen by a rockstar.

Teams don't stumble into greatness

Most developers I discuss this with see the Scrum Master as a stability role, a therapist-esque role who makes sure the peace is kept inside the team and to ensure no one is blocking anyone else. This interpretation undersells the role completely.

A great Scrum Master is a coach who pushes the team to confront what it would rather avoid. They need to be the annoying coach who is constantly in the team's ear. They need to proactively rock the boat constantly, confront and push the team to always improve. They are a leader in the team and have the responsibility to keep raising the bar. A good Scrum Master will proactively push the team out of their comfort zone. It is a red flag if the Scrum Master is only a passive listener and an organizer, only getting messaged by the PO to set up or cancel meetings.

It is said that it is the objective of an Scrum Master to make him- or herself obsolete. That the team has internalized agile values to such a degree that they no longer require the Scrum Master's services. I think this is a picturesque and quaint vision to draw for the role, but it has little place in reality. There are teams who have a larger necessity for a Scrum Master than more mature, well-functioning teams. But the pitfalls team fall into, face and fix are not a binary switch which gets flipped from negative to positive once and stays there. It is a constant dogfight of not letting old habits seep back into the team. New people join with different assumptions. The external pressures on a team shift constantly. A good Scrum Master doesn't become redundant, but become the reason the team keeps raising its own bar. A good Scrum Master will never become obsolete.

Scrum Masters utilized as a "shared service"

Most organizations are set up in a way that makes genuine Scrum Mastery nearly impossible. I have watched genuinely talented Scrum Masters become ineffective not because they changed, but because the structure around them did.

The pattern is consistent. A Scrum Master proves their value embedded in one team. Leadership notices and decides to "share" them across two, three, or four teams to better utilize the resource and get a high performer influencing into more teams. On paper this is efficient. In practice, it eliminates the thing that made them effective.

You cannot coach a team you do not have deep context in. The difficult retro conversations, the slow build of psychological safety, knowing which
team dynamics are dysfunctional and why. All of it requires accumulated understanding of the specific people, history, and patterns of a single team. Spread across multiple teams, the SM attends enough ceremonies to have surface-level awareness but never enough to go deep. They are not choosing to be shallow, but they simply never have the context to be anything else. And they are often plagued by pressure to try and be available for everyone.

This is not a Scrum Master problem. It is what matrix organizations routinely do to specialist roles. A UX designer embedded in one team builds genuine user knowledge over a long period. Spread across four teams, they are making Figma screens without understanding the users and use cases those screens are for. The output looks like the work. It just lacks the foundation that makes the work any
as excellent as when they were embedded strategically into a single squad.

The economic logic is understandable. The human cost is a specialist who was genuinely effective, gradually hollowed out by an org structure that confused presence with impact.