Facilitating a Decision You Have a Stake In
You have been Scrum Master for this six-person development team for six months. Before that you were its tech lead for two years and wrote much of the code now in production. Tonight's 60-minute session is a decision meeting: the team must choose how to deal with a flaky automated test suite that has blocked three of the last five releases. You have a strong view - you believe roughly 40% of the tests should be deleted outright - and you have already said so in previous conversations with two of the developers. The Engineering Manager, who writes everyone's performance reviews, has just joined "just to listen" and taken a seat at the table. Eight people are in the room. The team needs to leave with a decision it will actually implement on Monday.
1. Do you facilitate this session, and how do you handle your own opinion?
Read the worked answer
Ideally you would not facilitate a decision you have a strong stake in. With a 60-minute window and no alternative facilitator, the workable option is to facilitate while making your bias explicit rather than performing neutrality you do not have. Claimed neutrality that isn't real is worse than declared bias, because people act on the claim and are quietly misled.
Open with a disclosure: “I used to own this code and I do have an opinion - I think a lot of these tests should go. That's a view, not the decision. I'm going to run the process and not make the argument. If I start arguing, call me on it.”
Then protect the process. Give the strongest opposing view first airtime, before you say anything: “who wants to make the case for keeping the suite as it is?” Stay silent during option generation; capture your own position as one written card among many rather than as spoken authority. If the discussion turns on a fact only you know, state it once, briefly, and label it as fact rather than preference. Then let it go.
2. The Engineering Manager who writes performance reviews has joined. How do you handle their presence?
Read the worked answer
Power in the room changes what people say, whether or not the manager speaks, and a decision made under that pressure will not be implemented on Monday. So handle it explicitly rather than hoping.
At the start, thank them and re-contract their role out loud: “You're here to listen. I'll ask you for context if we need it, but the decision is the team's.” Get their agreement in front of the room. Optionally ask the team whether they want the manager present for the whole session or just the framing.
Protect the first round of input by making it written or anonymous, so the first thing the manager hears is the team's aggregate view rather than the most confident person's opening statement.
If the manager starts steering, intervene at the process level: “that's a strong steer - let me capture it as one input and then hear the others.” Afterwards, check in one-to-one with two quieter team members to test whether the decision matches what they actually think. If the presence is demonstrably preventing candour, it is legitimate to ask them to leave and to say why.
3. How do you design the 60 minutes so the team owns the decision, and what do you do if they choose the opposite of what you wanted?
Read the worked answer
Design. Minutes 0-10: frame the question precisely (“what do we do about the flaky suite so it stops blocking releases?”), state the decision rule - consent, not unanimity - and elicit criteria: release confidence, feedback speed, maintenance cost. Minutes 10-25: generate options individually then in pairs (delete, repair, quarantine, rebuild, tier the suite), all written up before any discussion. Minutes 25-40: test the top two or three against the criteria, with a proposer and a designated devil's advocate for each. Minutes 40-55: consent round, and capture what was decided, what was not, and who does what by when. Minutes 55-60: “will this survive contact with Monday?”
If they choose what you argued against: say nothing in the room beyond the process. Afterwards, if you hold a genuine technical concern that went unheard, raise it as a team member with reasoning, not as a veto. A decision the team owns and learns from beats a better decision they resent - and if it fails, that is data for the next retrospective, which is exactly the loop you are trying to strengthen.