I once worked with a team that made a call which shaped both what the solution actually did and how much technical debt it left behind. In the conversation that followed, two communication gaps came into focus: one between the team and the business partners, the other between the team and the technical owners. Trying to make sure it did not happen again, I asked a question that felt fair to me at the time: whose responsibility was it to make sure that communication happened? I was not trying to place blame on anyone. That is not how it landed.
That question came from a role clarity instinct, the same instinct a Team Assessment is built to check: who owns what, and is everyone clear on their lane. It is a reasonable question to ask after a decision goes wrong. But asking whose responsibility it was, right after a visible failure, is exactly the kind of question that can shut down the honest conversation you actually need next time. The real gap was not who owned the responsibility to communicate. It was whether anyone felt safe enough to say, before the decision was locked in, that they had not checked with the business or technical side yet. That is a psychological safety problem, and it does not show up on an org chart.
A Decision With Two Blind Spots
On its own, the decision the team made was not unreasonable. It solved a real problem the team could see clearly in front of them. What it missed was the functional impact the business partners could have flagged, and the debt the technical owners could have flagged, if either had been pulled into the conversation before the decision was final.
The Scaled Agile Framework’s own guidance on decentralized decision-making lays out five questions a decision maker should ask before taking a call: do I have the information, the authority, the competence, the clarity of intent, and a clear read on the impact. This team had the authority. What it did not have, and did not go looking for, was the information and the impact. Those two blind spots are exactly where this kind of decision goes sideways, quietly, until someone downstream inherits the cost.
The Question That Sounded Fair and Landed as Blame
Once the gap surfaced, my instinct was to fix the process so it would not happen again. Whose responsibility was it to loop in the business partners, and whose responsibility was it to loop in the technical owners? Those questions were meant to clarify responsibility going forward, not to assign fault for what had already happened.
That distinction did not survive contact with the team. What I heard as a process question, they heard as an accusation. Google’s own research on team effectiveness, described in its Project Aristotle findings, found that psychological safety is the strongest predictor of how a team performs, ahead of skill, seniority, or personality. Teams with low psychological safety stop raising concerns early, because the cost of being wrong, or being seen as the one who missed something, outweighs the benefit of speaking up. Asking whose responsibility it was, right after a visible miss, sent exactly that signal, whether or not I meant it to.
Realizing that felt terrible. I had not set out to make anyone feel blamed, and knowing that I had anyway stayed with me well after that conversation ended. That discomfort is what pushed me to look hard at how I show up as a leader in moments like that one, and to work deliberately at not making the same mistake again.
Why the Real Gap Was Psychological Safety, Not Roles
Role clarity would have told this team who was supposed to loop in the business partners. It would not have told anyone whether it felt safe to raise a hand mid-sprint and say, “I have not talked to the business side about this yet, can someone help me get thirty minutes with them.” That second question is exactly what an Empathy Assessment is built to surface: not who owns what, but whether pain points and gaps get raised while there is still time to act on them.
A team can have perfectly clear roles and still miss this, because clear roles answer who decides, not who feels safe saying “I am stuck” before a decision ships.
What Actually Changed
The fix was not a better RACI chart. It was changing the question. Instead of asking whose responsibility it was after the fact, I started asking, earlier and more often, “what got in the way of checking with the business or technical side this time?” That question invites an honest answer instead of a defensive one, and it surfaces the same information without anyone needing to feel blamed for it.
This is the same principle we bring into team performance engagements at Stephens Insight Group. Role clarity and psychological safety are not the same problem, and a well-intentioned question about ownership can quietly damage the second one while trying to fix the first. We look at both before recommending where a team should start.
None of this means the original question was a bad instinct. Wanting clear ownership after a miss is a normal, reasonable response, and role clarity genuinely matters. But it answers a different question than the one that actually caused the problem. Confusing the two is an easy mistake to make, especially when you are the one trying to fix it.
Understanding why the question had landed the way it did changed how I approached the team after that, more than any process fix did. People were more willing to surface a gap early once raising it stopped feeling like it would turn into a blame conversation later. I still catch myself reaching for the ownership question first when something goes wrong. The difference now is I notice it before it lands.
If a well-meant question about ownership has ever landed as blame on one of your teams, the gap probably was not in the roles either. Where would your team land if you assessed both?
If this sounds like where your team is stuck, this is exactly the kind of work we do at Stephens Insight Group. Talk to us about your team’s performance.
Sources
Decentralize Decision-Making (Scaled Agile Framework)
Understand Team Effectiveness (Google re:Work)