TL;DR: To do something together, build shared understanding and then everyone can make compatible decisions. The old style of imposing a single person’s mental model on the group doesn’t work in complexity (and also it’s mean).
An example from my kitchen:
Today I opened the cupboard to get a glass, and the glasses and mugs were all interspersed. In my cupboard, glasses belong on the left, mugs on the right with the tall mugs in the back and the smallest mugs stacked together.
”Argh, someone put them away wrong.” -me in the past.
Present me, wiser: ”Hooray, someone other than me put away the dishes.”
It’s one thing to ask people to help put away the dishes. It’s another to ask them to hold in their head my scheme of where everything belongs. Headspace is a lot more expensive than action.
Hold a shared understanding.
Besides, if I want family members to share my understanding of cupboard organization, then they get to contribute to that understanding. I don’t get to impose my construction. Maybe Evelyn wants the tall mugs in the center–she’d be wrong, but I would accept her aesthetic to include her in the shared understanding. Or maybe she has a contribution that is legit better: ”this one is my favorite, so put it in the front.”
This is participatory sense-making. When we want to work on a thing together, and we need a shared understanding to do it right, then everyone gets to participate in constructing that understanding.
To change software together, we need a shared understanding.
In software teams, everyone who is changing the software—or deciding how to change it—needs to contribute to the shared understanding of what it does, how, and for whom. (This principle appears in Domain Driven Design.)
An example of this: the architectural advice process. Here, software teams are required to invite comment from architect-types who maintain an overall view of the organization’s systems. They don’t have to follow their recommendations, but they have to consider the consistencies and larger directions that the architects know about.
This contrasts with older-style architect decrees: ”Here is my model of how the system will work. Implement it!” Or the architecture review board: ”Don’t do anything wrong,” leading to not doing anything.
An example from business:
The other day in the hospital my friend works in, the administration issued a Recommendation for the Use of N95 Masks, in three pages of single-spaced rules and exemptions. Unintelligible. They’re asking hundreds of people to put all this in their heads and make their daily decisions by these rules. This is cognitively expensive and demeaning.
If the administration instead issued a few points to know: We have enough masks to let nurses in contact with patients use a new one each day. Nurses know how to wear an N95 properly; people who don’t have this training won’t benefit. Beards will prevent a proper seal, so an ordinary mask is just as good. Contact with patients or the public calls for an N95, while internal office work does not. There are thousands of possible situations to cover, so let the person in them make an informed decision. Don’t pass down a thousand decisions; pass down the information and people can decide.
Imposing your mental model is an expression of power.
There’s a power dynamic in demanding that other people adopt your mental model. We grew up on the downward side of that: in school, we’re taught a model of the world. Absorb it, learn to think this way, spit back the answers. (It makes sense, when the model is the culmination of thousands of years of work. But this part doesn’t teach us how to think together.)
Then when we grow up the natural progression is to move to the other side of that power dynamic: ”Now I am the one who decrees the correct mental model!”
Software demands better of us. We’ve seen this high-modernist one-vision-to-rule fail over and over.
Changing software demands thousands of decisions in thousands of situations. Decision-making has to be local. We get better not by pushing decisions up, but by passing information around.
Shared understanding doesn’t come from “I share my understanding, and you adopt it.” it comes from “I share my knowledge, you share yours, and we construct a new understanding together.”
We get better decisions by forming a shared (overlapping) understanding. We do that with participation from everyone who changes the software.
My husband has an old saying: “You can tell me what to do or how to do it, not both.” As in: you can ask for my collaboration in actions and decision-making, or you can make all the decisions and I can opt in or out (probably out). “Don’t do it wrong” accepts “Don’t do it.”
We weren’t trained to participate in knowledge-growing, not in school. We did that in play, in games of pretend or hide-and-seek.
Breaking out of the power dynamic of “my way or the highway,” and into inclusivity of growing a shared understanding, is a path to better software and a better life.