I don’t attend many meetings these days, but when I do, I’m reminded of the failure modes of meetings, when group think can take over, leading to poor decisions by the group. But like all human reliable systems, the group can do some simple things to correct the problem before a failure.
Systems commonly trade off performance for reliability. In telecommunications networks, we can trade off latency for assured packet delivery through Forward Error Correction (FEC). Rather than make a hurried left turn into traffic, we can slow down and wait for a lower risk opportunity to make the turn. Group meetings are similar. We can slow down the meeting a bit by checking our assertions with facts and data.
In a group, we can take time to check our assumptions. Often, in the dynamics of a group meeting, people make assertions that may not be true, though widely held. The other day, I met with a large group of reliability experts, some of the best there are on the planet. I made a statement about the importance of a particular field of research, and one of the best experts on reliability, and this specific field as well, questioned that assumption, asking for evidence. That challenge lead to some serious thought. And while another participant offered some support for my statement before I was able to, the question was still provoking. What if my statement had not been well supported? How often do we check our ideas for support? How often does a group make a decisions off of an ssertion that lacks evidence? Fortunately, in our story, someone questioned the evidence, and the evidence was presented. But how often do groups not behave that way? I could assert that it happens most of the time, but I leave it to you to check your own experience. Fortunately, we can commit to taking the role in any group to question the assertions that members make, and take the time to make sure decisions are evidence based.
When we are in charge of inviting attendees to a meeting, how often do we consider the group dynamics, and try to design the right group for a decision? Sometimes we have to invite process owners, peers, interested parties, and others due to organizational requirements. But what if we considered the group to be a system or a network, and tried to design that team for reliability? What if we added redundant components to the group so that the right experts were in the room, the right points of view, and the right support for the decisions that the group needs to make? When the dynamics of a group are not ideal, try to build some redundancy in that group to help it succeed at its mission. If one person must participate, but they tend to disrupt the discussion with their own agenda, offer them a limited amount of time to address their concerns, and invite someone who can address that need so that the meeting can focus on its main goal. Build redundancy into the group system. If one person you must invite always makes claims that you believe are not correct, gather the evidence before the meeting that supports your point, and meet with that person before the meeting to address the disagreement before the meeting, in a form of proactive maintenance.
Not only can we try to structure our teams to be designed for reliability, but we can also use the dynamics of effective teams to create reliable systems. Think about the different roles that group members take, and consider analogies. The team leader usually acts to break ties. A redundant voting system needs an odd number of voting members to break ties in decision processes. It is always good to have one person take notes, but a second is better in case they miss a key point; redundancy is often important in any system. Think about the dynamics of effective teams you have been a member of, and how you can leverage that design in other applications.
Back to the group, checking our assertions is almost always the right thing to do. I encourage everyone to ask for evidence behind any assertion presented in the group that might be important to the decision process for the group. Reliable information enables reliable decisions by the group. Reliable decisions can yield reliable designs, reliable systems, and reliable results.