“We have Scrum Masters, but I’m not sure what they actually do all day besides setting up meetings and asking people what they did yesterday?”
I hear this often during due diligence or organizational assessments. I have also caught myself asking this question during my own time as CTO. CEOs and investors look at the payroll, see a role that doesn’t write code and doesn’t define the product, and wonder: Is this just expensive overhead?
In many organizations, the answer is sadly yes.
But that is not because the role is useless. It is because the organization has filled it with “Feel-Good Managers” or “Team Assistants” rather than Engineering Leaders.
The Problem with “Floating”
The most effective Scrum Masters I have worked with usually have one thing in common: They have done the work.
They don’t have to be star developers. I have seen excellent Scrum Masters come from QA or UX backgrounds. But they need to have “been in the trenches.” They need a deep understanding of how software engineering actually works.
Why? Because without that context, a Scrum Master tends to “float” on top of the team.
A “floating” Scrum Master focuses on what they can understand: Is the Jira ticket in the right column? Is the meeting room booked? Did everyone speak in the Daily?
Meanwhile, the real blockers—flaky automated tests, a convoluted deployment pipeline, or crippling technical debt—go unnoticed by them because they lack the technical depth to identify them as solvable impediments. They focus on solving superficial problems while the team drowns in the structural ones.
The Real Job Description: The Big Three
The official Scrum Guide lists a long array of accountabilities for Scrum Masters. They can be overwhelming.
From a business perspective (and based on my experience scaling teams at Webfleet), I boil the role down to three non-negotiable responsibilities. If your Scrum Masters aren’t doing these, you aren’t getting your money’s worth.
1. Make sure to remove impediments. This is the classic definition. But as mentioned above, this requires the ability to distinguish between a minor annoyance and a critical blocker.
2. Make sure the team improves. This is the core purpose of the Retrospective. It is not a complaining session; it should be a constant drive for increased effectiveness. If the team faces the same problems in June that they faced in January, your Scrum Master is failing at this responsibility.
3. Make sure the team delivers. This is the one that surprises people. Really, try it yourself. Ask your Scrum Master: ‘When the team missed that last timeline, or when that customer left due to a production bug—did you feel personally responsible?’ Their answer will tell you everything.
Many organizations treat the Scrum Master as a neutral facilitator who is detached from the outcome. This is wrong.
If a team consistently misses its Sprint Goals, it is the Scrum Master’s job to fix it. Are the stories too big? Is the estimation process broken? Is there too much context switching? External dependencies holding the team back? Code reviews done late or poorly preventing the team from finishing on time?
There are a thousand reasons why things can go wrong. There are also a thousand ways to go ahead – but if nobody speaks up and dares to ask the simple, but hard question “what can we do as a team to still reach our goals?“, you don’t need to be surprised that your team is not performing.
“Delivery” is not just the problem of the developers. It is a leadership problem. A great Scrum Master takes ownership of the team’s predictability – and makes sure they deliver.
This is a Leadership Role
We need to stop viewing the Scrum Master as a “servant” in the sense of a helper, and start viewing them as a Leader.
In a healthy Agile team, leadership is a triad:
- The Engineering Manager: Responsible for the People (hiring, careers, skills) – and also the overall outcome.
- The Product Owner: Responsible for the Value (what we build).
- The Scrum Master: Responsible for the Process and Delivery (how we build it reliably).
If you treat the Scrum Master as a junior administrative role, you break this triad. You end up with a team that is well-staffed (EM) and has good ideas (PO), but cannot execute predictably because no one is taking the wheel and steering the process.
The CEO Takeaway
Review your roster. Do you have “Team Assistants” who schedule meetings, or do you have “Delivery Leaders” who understand the engineering reality?
If your Scrum Masters are “floating” above the real problems, it is time to anchor them in reality—or find leaders who can do the job in the way it was intended.
