Scrum Masters who are technically doing the role, running the ceremonies, tracking the board, and Scrum Masters who are genuinely effective in it are often doing visibly similar day-to-day work. The difference shows up less in what's on the calendar and more in six specific habits.
1. They protect the team's focus, not just its calendar. It's easy to confuse "the team's schedule is protected" with "the team's focus is protected." A Scrum Master who keeps meetings off the calendar but lets Slack interruptions, ad-hoc requests, and scope creep flow freely into the sprint hasn't actually protected anything that matters. The habit that separates effective Scrum Masters is treating focus itself as the thing being defended, which sometimes means having an uncomfortable conversation about an interruption that looks small in isolation but is one of a dozen such interruptions undermining the sprint.
2. They ask questions they already suspect the answer to. The instinct to solve a problem the moment it's raised is strong, especially for Scrum Masters with deep technical or process backgrounds. Effective Scrum Masters resist it more often than not, asking "what do you think is happening here?" even when they have a good guess, because the team arriving at its own diagnosis builds capability that a quick answer doesn't.
3. They read the room, not just the board. The sprint board shows what state the work is in. It says nothing about whether the team is energized or exhausted, whether a disagreement in yesterday's stand-up got resolved or just went quiet, whether someone's "I'm fine" actually means they're fine. Effective Scrum Masters treat this human information as data worth acting on, not as a distraction from the "real" job of tracking tickets.
4. They escalate sparingly, and specifically. A Scrum Master who escalates every obstacle trains the organization to see them as unable to solve problems independently, and trains the team to stop bringing them small issues. One who never escalates anything lets structural obstacles fester because no one with the authority to fix them ever hears about them. The skill is a genuinely selective threshold: solve what's solvable at the team level, escalate what genuinely requires organizational-level authority, and be precise about which is which.
5. They measure their own success by what they're no longer needed for. A useful, if uncomfortable, test: is this team more capable of solving its own process problems than it was six months ago, or is it just as dependent on the Scrum Master as ever? The goal of the coaching relationship is to work toward not being needed for a given problem anymore, not to remain indispensable.
6. They keep learning what "good" looks like beyond their own team. Scrum Masters who only ever see their own team's dynamics tend to mistake local normal for universal normal. Talking to Scrum Masters on other teams, in other organizations, reading outside the immediate literature: this keeps the reference point for "how well is this actually going" calibrated against something wider than one team's history.
None of these six are dramatic. They're closer to habits of attention than techniques, which is exactly why they're harder to teach in a two-day certification course than the mechanics of running a retrospective, and exactly why they're what actually separates Scrum Masters who move the needle from ones who keep the process running.