Fear paraylzes, which destroys action

When we are afraid of making a mistake, we're really afraid of humiliation.

A few weeks back, I drafted a product announcement email. Like my customer-facing content, sending such an email involves multiple rounds of reviews from various people. Each reviewer might make a suggestion, add a grammar edit, or ask a question.

At some point during the review process, it was obvious to me we were reaching diminishing marginal benefit. While each person was “doing their job” as a reviewer, feedback started to overlap. When the lawyer was giving grammar critiques to the copywriter, I asked myself, was this a good or bad process? How did we get to this type of outcome?

If two brains are better than one, are four brains better than two?

No, but with four people, you could appoint one person to complete 90% of the work, while the other three give feedback. My smartass comment aside, I reflected back on the review process and identified several problems, some with solutions and some without.

1. The burden of inter-communication (no permanent solution)

When we create something, whether a chair, working software, or a product launch email, we go through a transformation: from idea to output. We start with the idea, which is a mental construct in our brain. Then, execute making the chair, coding the software, or writing the copy.

Having completed execution, you ask someone to review the output (e.g., email). The communication burden starts.

*Does the reviewer understand the idea? If not, how complicated is it to explain?
*Does the reviewer understand the constraints experienced during execution? Are those constraints something the reviewer can help remove?

Understanding both depends on the idea, the output, and the number of reviewers. More people working together compounds the communication burden because feedback from one reviewer could impact another reviewer. That’s why sometimes you get into a review loop that doesn’t seem to end

This burden of communication cannot be avoided and the burden increases as you involve more people. There have been techniques/attempts to reduce the burden of communication. People often use the assembly line analogy, by “industrializing a process”. But I believe this is the wrong approach because:

A. Tasks can’t be partitioned among participants.

Not all tasks can be partitioned and sometimes partitioning tasks incorrectly causes more problems. Imagine partitioning the task of writing an email to a friend among four people. Do you partition by subject line, salutation, body, and closing? Or perhaps you should partition by research, drafting copy, and creating visuals? Even if you decide on a particular partition, is this the same for every email you write?

B. When partitioned, there’s no mechanism for addressing accountable

Let’s imagine in the email review, you have two reviewers because tasks have been partitioned: legal review by a lawyer and grammar review by a copy editor. Assuming during the legal review, the lawyer identifies a grammar issue. How does the lawyer hold the copy editor accountable for the output of a sub-process?

In an assembly line, inputs from one part can be rejected before use in another process. Can the lawyer reject it? If the lawyer can, will people do this when the rejection can be fixed?

The analogy breaks down quickly in practice. I’m aware of no permanent technique to lessen the communication burden when you increase the number of people working. This is why smaller teams that communicate effectively work better (with higher output) than larger teams or small teams that don’t communicate well.

2. Can you engineer a process that prevents errors from occurring? (partial solution)

In writing an email, you shouldn’t have any spelling errors in Gmail if you enable spelling and grammar correction. In other words, can you design a process that prevents errors from ever occurring, which reduces the need for reviewers?

In theory, yes. For example, in sailing, there are one-way cam cleats that open in one direction, making it easy to feed rope in a specific manner.

However, we need to be very careful in making these idiot-proof design choices. Specifically, we must be 100% certain we are preventing an error, and that the error is worth the cost of limiting user freedom. Wrong assumptions can be costly.

For example, recently I observed a feature that prevented a user from deleting new data entry records in an application. The idea behind preventing deletion was to preserve the record. Thus, if the user makes a mistake, the user should just create a new record from scratch, and ignore the prior record. You might imagine what happened in practice. Suddenly, there was an accumulation of erroneous entry records, all in various draft forms. There was more erroneous draft than correct records, and an enhancement had to be developed to archive “errors”.

Because for every situation you might think about stopping the user, you have to think about if there’s a legitimate use case. This is why typically, these idiot-proof designs are more often used only to prevent the worst outcomes, such as human death.

3. Don’t be afraid of errors, but be afraid of repetitive errors. (partial solution)

There’s the unspoken assumption that a mistake is deadly. You might be reprimanded, humiliated, or fired because of your mistake. But very few errors result in the anxiety-driven risks we assign them in our minds.

I am not arguing we should perform no reviews or risk assessments. I agree that two brains are better than one, so a buddy system is often a great approach (i.e., have one other person review your work). After that, press send and move on.

Instead, when you do make an error, log it and look for repetitive patterns over time. For example, for me, I have a tendency to type “not”, when I mean “now”. I don’t know why, but I’ve made this mistake in slack messages (which does not have a grammar check, if I could make it error-proof). Nowadays, I’m extra sensitive in reading paragraphs where I write not or now in slack because I’ve made repetitive errors.

4. Ask yourself how you might respond if the error you’re trying to prevent occurs. (partial, long-term solution)

One common reason people add reviews and overlay processes to prevent errors is that they are afraid of the humiliation when others see their imperfections.

I sometimes have this feeling when writing because my written posts are a record of my product management beliefs and thoughts. The internet never forgets and I’m certain, some of my thoughts are wrong or outdated. That’s humiliating for me because it lowers my personal self-identity and standing.

But, I’ve asked myself and over time, became more comfortable with admitting I’m not certain or I don’t know. As odd as it might sound, I believe experiencing humiliation and learning how to react to the negative feeling of humiliation, is a way to build resiliency.

Thus, instead of trying to avoid the feeling, which is what I frequently notice when someone points out an error that I’ve made or immediately deflect, I try to now to acknowledge the feeling, respond, and listen. Now, I’m not arguing you shouldn’t be defensive (with is often an automatic response). Instead, can you listen, acknowledge the error, and present your reasoning without being defensive? Can you learn to act and make good decisions while feeling embarrassed or humiliated?

---

Additional Reading

• Psychotherapy as Correction of Faulty Social Values (read the part of mistakes)

• How The Fear Of Humiliation Can Ruin Your Life (read the part about Ben’s story)