Alongside leading the platform, I've taken on the Scrum Master role for the data team, and it's taught me something that the certification and the tidy job description rather miss. On paper, a Scrum Master runs the ceremonies, guards the process, removes impediments — a facilitator of a framework. In practice, on a data team specifically, I've found the role is mostly something the process language doesn't name: I'm a translator. The actual job is standing in the gaps between people who don't speak each other's language and making each one understood by the others.

The gaps a data team lives inside

Data work sits at an unusually busy intersection of people who genuinely don't understand each other, and I don't mean that unkindly — I mean they have different vocabularies, different mental models, different definitions of "done" and "urgent" and even "revenue." A data team is perpetually surrounded by:

  • The business stakeholders, who know what they want to achieve but often can't express it in terms the team can build from — who ask for "a report on customer health" meaning six different things they haven't disambiguated even for themselves.
  • The engineers on the team, who think precisely in the terms of the systems and the data, and can find the ambiguity and shifting requirements of the business world genuinely bewildering and frustrating.
  • The other technical teams upstream and downstream, each with their own priorities, their own systems, their own sense of what matters.

Every one of these speaks a different language, and left alone they routinely fail to understand each other — the stakeholder feels unheard, the engineer feels jerked around by vague and changing asks, and the work suffers in the misunderstanding between them. The Scrum ceremonies are a venue for these people to meet. They are not, on their own, a translation between them. And translation is what's actually needed.

What translating actually looks like

So the real content of my Scrum Master days, underneath the standups and the retros, is a constant back-and-forth interpretation:

  • Turning business wants into buildable requirements. Taking "we need better visibility into customer health" and working — with real questions, patience, and a refusal to accept the first vague version — until it becomes something specific enough that an engineer can actually build it, and correct enough that it's the right thing. That's not note-taking; it's interrogating a fuzzy human desire until it becomes a precise, agreed definition.
  • Turning technical reality into terms the business can weigh. Taking "this is hard because the source system's data model doesn't support that join cleanly" and translating it into the trade-off the stakeholder actually needs to understand — the cost, the time, the "you can have it fast or you can have it right." So they can make an informed decision instead of just hearing "no" or "later" as an obstruction.
  • Protecting the team's focus by absorbing the ambiguity. A lot of translating is shielding — taking the shifting, contradictory, half-formed stream of stakeholder input and resolving it into something stable before it reaches the engineers, so they can do deep technical work without being whiplashed by every change of mind upstream. I absorb the chaos so they don't have to.

None of that is in the Scrum Master certification, and all of it is the job. The framework gives me the meetings. What makes the meetings work is the translation happening inside them.

Why data teams need this more than most

I think data work needs the translator role more acutely than a lot of software work, for a specific reason: the gap between "what the business means" and "what the data can support" is unusually wide and unusually treacherous. In much of software, the requirement and the build are closer to the same language. In data, the business asks in the language of outcomes and meaning — "are our customers healthy?" — and the team has to answer in the language of what the data actually is and can honestly say, and those two are often further apart than anyone realises until a beautifully-built report answers a subtly different question than the one that was asked.

Bridging that specific gap — between what people mean and what the data can honestly support — is the defining challenge of the whole field, and on a data team it lands squarely on whoever's standing between the stakeholders and the engineers. That's the Scrum Master, whether the job description says so or not.

The Scrum Master certification teaches you to run the ceremonies. On a data team, the ceremonies are just the room. The job is the translation that has to happen inside it — between people who want outcomes and people who build with data, and who will not understand each other unless someone makes them.

Where this leaves me

I keep arriving, from every role I take, at the same conclusion: that the scarce and central skill in data work is communication — the translation between the humans who need something and the humans (and systems) that can provide it. I came into this field from communication, took a long detour through the deep technical, and every rung up keeps depositing me back at the translating. The Scrum Master role is just the latest place it's happened, and the most explicit.

So if you're a Scrum Master on a data team and the certification's ceremony-and-process framing feels like it's describing a different job than the one you're actually doing — it is. The one you're actually doing is translator, mediator, and interpreter between worlds that don't speak each other's language. Get good at that, and the ceremonies mostly take care of themselves. Get good only at the ceremonies, and you'll run flawless meetings in which people continue, politely, to misunderstand each other.