Silence Means ... Agreement?
Have you ever used this approach for decision making in group settings? "OK, that's the question. Let's decide. Yes or no? Silence means agreement. 3 ... 2 ... 1 ... thank you, we have a decision, it's a yes."
Some months ago, I had spoken with a product manager in the org of which I lead the engineering side, and expressed some discontent with some not-so-nice UX that had ended up in production. The PM and I then mused a bit about how more attention to detail could be instilled so that rather obvious UX glitches don't end up in customers' faces. I like to refer to this as taking pride in one's work, and having a sense of honour as craftspeople. We ended up discussing about how to have shorter feedback loops, by pulling up the "latest version" of the experience at all possible occasions and collecting quick feedback.
Since, I'd thought about this some more, and would like to share one thing that happened a while back in a meeting with one of my teams. There, the discussion was whether to assume responsibility for a piece of functionality that's currently stewarded by another team but that would make much more sense in this team. The question came up, some people expressed agreement, and then - silence.
The usual pattern is to assume silence means agreement. That's easy, right? I turned it around, because taking responsibility for a piece of functionality means some more work, and potentially interruptions if something is really off. So I made clear in the meeting that "silence means disagreement, so please speak up with a clear YES now or raise your concerns" - and lo and behold, some concerns were raised. These were subsequently settled, and the story could continue.
So much for the excursus. The idea, abstracted from the example scenario, is to pull in active consent rather than consent by silence, and thereby to encourage dissent.
Applied to the UX-glitches-in-production issue, if anyone feels that the experience we're about to release to the users is not good enough, they should speak up. If the entire team expresses active buy-in, they're also collectively accountable.
It's also a pretty egalitarian exercise: no matter who speaks up and mentions concerns, these concerns will be important to address. Whoever raises their voice, they're not speaking from a position of power, but from one of empowerment. Everybody in the team is empowered to deliver good UX.
This should not be misused as a tool to enforce consensus. Some concerns may be valid but not urgent. They can be addressed later. But it is important to identify concerns that should block a rollout and address these. It's also necessary to have a foundation of trust, because otherwise expressing active buy-in can be abused to weasel out of necessary and healthy conflict. We don't want yes-people, we want people who are proud of their work.
Try it next time. It can have a surprising effect.
Tags: work