Teamwork shares a lot of good practices with parenting. This lesson was no exception …. I realised fairly early on in my time as a parent that I had a tendency to fail, bigtime, by blasting my kids for something they hadn’t done. The pattern became evident: I see something, I conclude they are rogues and bad actors, I give them both barrels, then after the tears are mopped up it becomes clear that I didn’t see what I thought I saw, or they were actually doing the right thing when they did it.
The defence to this is pretty obvious: I learned to notice when I concluded that someone was a moron, and worked on asking instead of blasting. “It looks like you ___ … is that really what happened?” or “I see ___. I’m afraid that ___. What were your reasons for doing it?” or even simply “Are you ___ ?” The question gives them a chance to explain their actions before the gunfire starts.
This is even deeper than simply process, though. If you shoot first, you presume that you’re the only person in the room who has a brain. If you shoot first, you presume that your perceptions and deductions are flawless: that you know everything and infer motivation with 100% accuracy. The act of asking is an act of humility: “I don’t know everything, you’re the only one who knows what you saw and what your motivation is … tell me what you saw and thought that made this a good thing to do.” It’s an act of respect: “you have a brain and you make good decisions. Help me see why this was a good decision.” It’s an act of good faith.
John Allspaw, spiritual godfather of the Devops movement in technnology, often talks about the lessons we can learn from plane crash investigators. It does no good for something to be labelled “pilot error” … in no way does it help the next pilot avoid that error. Every pilot does the best they can with the knowledge, data, systems, and tools they have at their disposal. If their decision contributed to (or could have avoided) catastrophe, then the real point of the investigation is to learn what knowledge, data, systems, or tools were lacking but could have avoided catastrophe. The heart of the process is acknowledging the pilot did the best they could, so the next pilot can do better. The “blameless postmortem” is a valuable tool for organisations who seek to improve themselves (vs punish wrongdoers).
In business, and especially in startups, it’s easy to leap to conclusions about other people’s motivations because there’s such a lot at stake (when you’re small and trying to grow fast, every decision is an important one) and because time is so critical. We had one stressful meeting where the senior engineer’s choice of technology and architecture was criticised in no uncertain terms by someone who hadn’t been involved in the architecture. The choice of technology and architecture, it later transpired, were fine. The person doing the criticism didn’t know the design goals of the system. How easy it would have been to start with “wow, it looks like this has a lot of moving parts and untried technology. Help me understand why these are the right technology choices for our business” … it a wasted opportunity not just to learn more, but to show the senior engineer that you respect their experience and ability.
Visual designers know this only too well: don’t ask for feedback. Give the design criteria and then ask for feedback on how well the design you made delivers on those criteria. With the criteria, way you get useful feedback, and eliminate a whole lot of “well, I don’t like blue” and “it needs to POP more!” nonsense. (Though good luck getting rid of all of those ungrounded emotional responses!)
Respecting the other person by asking instead of blasting works with your manager, works with your direct reports, works with your peers, works with your spouse, and works with your kids. It works for visual design, it works for architecture, it works for chores, it works for everything. Presume good intentions and calmly question to learn what they were, and you’ll find everyone is happier and more open—yourself included.