How to coach a team that knows more than you do

You can't out-know a senior team, and you were never supposed to. Domain authority is their job. Process authority is yours.

Your first sprint planning is Tuesday. The team you're supposed to coach has a principal engineer who was shipping production systems while you were still writing practice user stories, two seniors who built the platform the whole company runs on, and a staff engineer who says maybe ten words a day, all of them load-bearing.

You've shipped nothing they'd respect. You know it. And somewhere under your carefully prepared facilitation plan sits the fear every new Scrum Master carries into a senior room and nobody says out loud: one day someone will ask me a technical question, I'll fumble it, and they'll all know I have no business standing at this board.

Here's the part nobody tells you. They already know. They read your profile before you showed up. They know you can't review a pull request or weigh in on the database choice. That question was settled before your first standup, and they care about it far less than you think.

Because the question they're actually asking isn't “does this person know more than us?” Nobody expects that, and nobody hired you for it. Their real question is sharper: is this person going to waste our time, or make us faster?

That one you can win.

Two kinds of authority walk into the room

The fear runs on a bad assumption: that authority is one thing, and they have more of it. It's two things, and they're not in competition.

Domain authority is the craft. The architecture, the tradeoffs, what falls over under load, which shortcut quietly becomes next year's rewrite. Your team has it, deep. You will not catch up, and chasing it part-time against people who live in it full-time is a race you should refuse to enter.

Process authority is a different job. It's ownership of how work moves: where it queues, whether decisions stick, how many things are in flight at once, and what happens at the seams where your team touches every other team. And the useful part: on most senior teams, that job is sitting empty. Experts optimize inside their own lane. Almost nobody owns the space between the lanes.

So split the field and stop competing on the wrong half. They own the craft. You own the system around it:

• Flow: where work sits and waits. A senior team can write brilliant code that then ages three days in review. They see the code. You see the queue.

• Focus: how much is half-done at once, and who's interrupting the team six times a week with quick asks that are never quick.

• Decisions: whether hallway agreements stick and get written down, or come back as the same argument every second Tuesday.

• Interfaces: the platform team dependency, the stakeholder who changes scope over chat, the Product Owner nobody can find on Thursdays. Experts optimize inside the boundary. You own the boundary.

You will never out-know this team. You can absolutely out-notice it.

The bluff costs more than the silence

Under pressure, most new Scrum Masters reach for the worst available move: pretending to more domain than they have.

Picture the design discussion. The team is debating whether to cut a corner on the migration. You've been quiet for twenty minutes and the silence is eating you, so you grab the one technical thing you half-remember:

“Couldn't we just cache that? I've read Redis handles this kind of thing well.”

Nobody argues. The principal says “sort of,” kindly, and the conversation routes around you like water around a rock. What got decided in that moment is this: the team moved you from not technical to not honest about it. The first is completely fine. The second is expensive. A team will forgive you for not knowing the craft. It will not forgive you for faking it.

The bluff has a quieter cousin: quiz facilitation. Asking questions you already think you know the answer to, in a coach voice. “What do we think about testing?” Experts smell a quiz from across the building, and they grade it. Never ask an expert a question to check their answer against yours. Ask because nobody in the room has said the answer out loud yet.

Same meeting, different move. You ask:

“Say we take the shortcut. What has to be true for it to still look like the right call in March?”

The room stops. The principal starts answering, pauses in the middle of his own sentence, and says “actually, hang on.” That pause is your entire job compressed into four seconds. Notice what the question required of you: nothing technical. You don't need to know Redis from a bus route. You asked about consequences over time. That's a system question, and the system is your lane.

Their thinking, made visible

Here's the principle underneath that question, and it's the whole post in one line: coaching experts means making their thinking visible, not adding yours.

Coaching a junior is mostly addition. You supply context they don't have yet. Coaching an expert runs the other way. They hold depth you can't audit, so the job is getting it out of their heads and into the room, where the team can use it.

Which brings us to the sentence every Scrum Master eventually hears from a senior engineer: “This is fine, trust me.”

Translate it. That sentence doesn't mean he's arrogant. It usually means the risk assessment happened privately, in his head, and nobody has asked to see it in years. Most of the time it really is fine, which is exactly what makes it dangerous. An expert who's right in private is one bad Tuesday from being wrong in private, with nobody positioned to catch it.

So your move isn't doubt. You'd lose, and you'd deserve to. Your move is: “I believe you. Walk me through what would make it not fine.” You're not checking his answer. You're publishing his reasoning. The two mid-level engineers hear a hazard map they'd never have gotten otherwise, and the quiet staff engineer finally has something concrete to push against.

Four questions do most of this work. None of them require you to pretend anything.

“What would make this risky?” beats “is this risky?”, which invites a shrug and a no. You're asking the expert to draw the hazard map they already carry. They always carry one.

“What are we trading away?” puts the hidden no on the table. Every technical yes is quietly a no to something else: resilience for speed, clarity for cleverness, this quarter for next year. Experts price these tradeoffs silently and then carry them alone. Say the tradeoff out loud and the whole team gets a vote.

“Who disagrees with this?” fetches the dissent that seniority suppresses. The staff engineer who went quiet twenty minutes ago went quiet for a reason. Go get it.

“What would change your mind?” is the calibration test. An expert with a crisp answer, like “if latency crosses 400 milliseconds, I'm wrong,” is safe to bet on. An expert whose answer is “nothing” has just told you where the next incident lives.

One more thing about these questions, and it's your hidden edge: you're the only person in the room who can ask them cheaply. Everyone else has technical status to protect. Asking the obvious question costs a senior engineer something. It costs you nothing, which makes you the one person who can always afford to ask it. That's not a weakness in the role. That is the role.

The interview already contains this question

Now the payoff beyond Tuesday. “Tell me about coaching someone more senior than you” is a real interview question, and it shows up exactly when the job is worth having: senior Scrum Master roles, delivery lead roles, any team worth inheriting.

Most candidates flinch, then reach for a story where they secretly knew better than the expert. Wrong shape. The interviewer isn't checking whether you once outsmarted an engineer. They're checking whether you know what job you're in.

You now have the answer shape:

• Name the split. “I don't carry domain authority on a senior team, and I don't pretend to. I carry process authority: flow, focus, decisions, interfaces.”

• Give the moment. “A principal told me a risky change was fine, trust him. I did believe him. I still asked what would make it not fine, and halfway through the whiteboard answer he found the edge case himself.”

• Show the system change. “That question became a standing part of our design reviews. I didn't add technical knowledge to the team. I changed what happens to the knowledge it already had.”

That's not a survival story. That's the seat, described by someone who has sat in it.

Back to Tuesday

You'll never be the best engineer in that room, and the room doesn't need another engineer. It needs someone watching the queue, naming the tradeoff, fetching the disagreement, and asking the question that makes a principal stop mid-sentence.

A conductor doesn't play a note all evening. Nobody in the hall thinks the orchestra would sound better without one.

They own the sound. You own whether it lands together. Go run Tuesday like that's the job, because it is.