Why We Jump: Fear

Fear is one reason teams jump from an idea to a solution before they understand the problem. It does not always look like panic. It can look like action that reassures us, a control that is easy to see and count, or a decision that feels safer because someone else made it.

In this solo compilation episode of Quality During Design, Dianna Deeney asks four contributors how fear or uncertainty affects decisions in their areas of work. Their examples show four different versions of the same pattern: a team reaches for something visible, manageable, authoritative, or inactive before it has understood what is actually happening.

This episode is part of Season 7's arc about why teams jump from an idea to a solution. It is also part of the larger Quality During Design work of examining how teams can stay with the problem long enough to create better design inputs.

About the contributors

Martin Griffiths works with Metis Automation and is associated with the Manufacturers Make Strides podcast. His contribution comes from an early-career manufacturing experience in which each new quality issue led to another check and another colored paint dot on the product.

Jake McKee is a Principal Conversation Design Consultant and a previous guest of the Quality During Design podcast. His example comes from work with an online customer community that had low participation. The team was preparing to ask customers which features would bring them back, but conversations revealed a different need.

Yakira Mirabito is a researcher in engineering design and innovation. In an earlier Quality During Design conversation, she discussed the social dynamics that influence whose feedback engineers accept in a design review, including the difference between expertise and status.

Greg Hutchins is a certified enterprise risk manager and founder of CERM Risk Insights. His contribution focuses on fear of uncertainty, failure, and making the wrong decision, and how those fears can leave people stuck.

Subscribe on Apple Podcasts

Subscribe on Spotify

Give us a Rating & Review

Why We Jump: Fear

Dianna: When I mention fear in product design, engineering, and industrial manufacturing, the first thing you probably think of is the problem that keeps you up at night or wakes you up at four AM. It could be the headache issue that just won't go away or the high-profile project that you feel could make or break your career.

But there are other types of fear at play that may not look like fear. Sometimes it makes us grab the most visible control. Sometimes it makes us build something we can put on a chart. Sometimes it makes us accept the answer from the person with the most authority. And sometimes it keeps us from deciding at all.

I reached out to four thought leaders who work in different spaces and asked them how fear is driving decisions in their areas of expertise.

Let's explore more about how fear can be why we jump after this brief introduction.

[00:01:02] Fear: why we jump

Dianna: In this season seven of the Quality during Design podcast, we're exploring reasons that teams jump from an idea to a solution. We've looked at speed and certainty as reasons teams jump. Fear is another reason, but fear doesn't always look like panic.

It can look like action that reassures us or inaction that protects us from being wrong. The jump that I'm talking about isn't simply making a decision. It's when we're committing to an answer before noticing the gap in what we understand.

[00:02:17] Fear jumps to visible control

Dianna: I asked Martin Griffiths from Metis Automation and the Manufacturers Make Strides podcast, can you recall a situation in manufacturing where fear or pressure affected how a team responded to a problem?

What did it look like, and what changed the decision? Here's what he said:

Martin Griffiths: Early in my career, I worked with a manufacturing company where they'd set up a process that after each quality check the operator did, the operator then added a colored paint dot to the product. Every time a new issue arose or was reported, the r- the response was the same. Let's retrain everyone to do another check and then add another different colored paint dot to the product.

Over time, though, this ended up with the product absolutely covered with a rainbow of colored dots. Each dot was a reaction to a fear of an issue slipping through to the customer. It proved someone had looked, but none of them stopped the problem happening in the first place. What changed it was quality audits of the manufacturing process.

The auditors didn't want more inspection at the end. They wanted proactive process with checks built into each step of manufacturing, and that was really the shift for me. I think fear adds you more checks to try to stop things slipping through. Understanding makes you design a process so the mistake can't happen in the first place

Dianna: I love Martin's story. The checks that the operators were making on the part, they weren't careless. They were reassuring in that somebody was looking at it and noticing that something was wrong. It was being tracked. a paint dot proved that someone had looked, but it didn't explain why the problem occurred in the first place.

The first solution was easy to see and count. The missing work was harder, understanding the process well enough to change it in the first place. Fear produced more inspection. Process understanding produced prevention

[00:04:29] Fear jumps to managable features

Dianna: Let's look at a different reason that fear could be causing us to jump. I reached out to Jake McKee, Principal Conversation Design Consultant and previous guest of the Quality During Design podcast. I asked, "Can you think of a time when fear or uncertainty influenced a product team's move toward a solution before it understood the customer's problem? What happened, and what did you notice?"

He wrote back with this story:

" a client company I worked with ran an online community for its customers, but hardly anyone used it. Leadership worried it looked like a waste of money, so the team jumped to fix. They planned to ask members which new features would bring them back. When we talked to customers, the real problem had nothing to do with features.

Many were the only tech person or one of a very few at a small company. They were lonely. They didn't want more tools. They wanted to connect with people who understood their job. It's easy to jump to features because you can plan them, organize them, and put them on a chart. Feelings are harder to document, but they're often far more important to understand first."

In his story, leadership feared that the community looked like wasted money, features were easier to plan, organize, and display than loneliness or isolation, which was the real draw of that community. The product team was about to solve the visible performance problem instead of actually addressing the customer problem

Both Martin and Jake's examples involve a team reaching for something it could show. The danger isn't that the team is inactive, the danger is that visible response becomes a substitute for understanding

[00:06:28] Fear or pressure jumps to authority

Dianna: Fear can also enter through hierarchy. In an earlier Quality during Design conversation, Yakira Mirabito, a researcher in engineering design and innovation, described how engineers can mistake authority for evidence when they evaluate feedback in a design review.

Yakira Mirabito: The other aspect is looking at the, the relationships and social dynamics, um, starting to think about how you and your relationship with those folks kind of within a team, whose voices do you generally listen to and why?

Starting to increase that self-awareness of, okay, I keep listening to, I don't know, I'll say like Josh's feedback, and it's like, okay, why do you always listen to Josh's feedback? Is it you guys really know each other? Maybe you went to school together, right? Kind of these social dynamics, biases that might be impacting it.

or is it, oh, Josh is an expert in this. He's been in the industry for 20 years. Thinking about kind of what's guiding those processes, Sometimes our, like, our intuition is good, right? Josh is an expert. But sometimes is it, oh, just we really like Josh.

Just thinking kind of more critically about whose feedback do we listen to, what kind of dynamics are at play, right? the social dynamics, some of the biases that I talked about, kind of, like, is it expertise that's really guiding it versus, you know, Josh is my boss. So I will continue to listen to whatever Josh says, even if maybe he hasn't done the calculations or been super involved in the project.

So there's all these things to kinda start thinking about, but just increasing our awareness to it.

Dianna: As Yakira describes, a senior person's opinion can feel safer to accept than to question, whereas sometimes the team needs to ask whether the feedback is grounded in expertise, requirements, testing, or user needs, or simply in status. I'm not saying that we shouldn't listen to experts, but it is a reminder to separate the source of feedback from the basis for the decision

Yakira's story highlights how fear can lead us to cede the decision-making to an expert while avoiding really understanding the problem.

[00:08:53] Fear can produce no decision

Dianna: In another story, fear can also produce no decision at all. Greg Hutchins is a certified enterprise risk manager and founder of CERM Risk Insights.

The question I asked him: Can you describe a situation in engineering or quality work where fear or uncertainty shaped a decision? How did you tell whether it was pointing to a real risk or pushing people toward a premature answer?

He wrote back this: "Fear seems all over the place. Fear of uncertainty, fear of failure, fear of making the wrong decision.

The result is that most folks get and stay stuck. No decision becomes a decision. Solution? Don't get stuck in shoulda, coulda, or woulda doom loops. Just start and see where things go."

That's the end of Greg's quote. Fear doesn't always push us into a bad action. It can also keep us circling the decision because choosing feels like accepting responsibility for being wrong. But no decision becomes a decision too. The team stays with the old condition while time, risk, or opportunity continues to move

[00:10:15] What to do before the jump

Dianna: So how do we handle these versions of fear in our product development work? What do we do before we jump to a decision, before we jump from an idea to a solution?

One suggestion I can give you is to just recognize if you're operating from a place of fear

One question to ask yourself: What am I trying to make safer by choosing this? In this case, think about risk. Are you delaying a bigger decision by choosing out of fear?

A second question to ask is, what do I actually understand and what am I assuming?

Stopping to assess what you know versus what you don't is a way to identify if you're operating from a place of fear

the third question you can ask yourself in this pause is, what small action would increase understanding rather than merely reassure me?

And I'll add a word of caution here. Fear can point to a real risk. The answer is not to dismiss it.

The answer is to investigate what it's telling us before we let it choose the solution

[00:11:32] How to apply this thinking on Monday morning

Dianna: What is our Monday morning move? let's put those questions to work on one current decision.

Write down four things about it. What are you afraid will happen? What is the solution you're tempted to choose? What is the evidence you currently have to support that decision? And identify one small step that would increase understanding before commitment

This has been an enjoyable episode for me to put together, in no small part because of the contributors. I wanna especially thank them for taking the time to contribute to the content of this episode

In the show notes and the associated blog post, I will link to Martin, Jake's, Yakira's, and Greg's information. They are thought leaders in their fields and frequently produce a lot of content. So please visit their sites to learn more about them. This has been a production of Deeney Enterprises. Thanks for listening.

What fear can make a team do

Add another visible control

Martin's story begins with a familiar response to a quality issue: retrain people to perform another check and add another colored paint dot. Each dot showed that someone had looked. Over time, the product was covered with a rainbow of dots, but the checks had not prevented the problem from happening.

The response was understandable. A visible check created evidence that the organization was doing something about the risk. But the inspection did not explain why the problem occurred or change the process that allowed it to occur. The shift came when quality audits focused on the manufacturing process and built checks into the work instead of adding more inspection at the end.

Fear had produced more inspection. Understanding produced prevention.

Build manageable features

Jake's example starts with an online community that customers were barely using. Leadership was concerned that the community looked like a waste of money, so the team moved toward a feature question: which new features would bring members back?

Talking with customers changed the problem definition. Many of the customers were the only technology person, or one of very few technology people, at a small company. They were lonely. They wanted to connect with people who understood their work, not more tools.

Features were easier to plan, organize, and put on a chart than loneliness or isolation. That made features an attractive response, but not necessarily the right one. A visible output can become a substitute for understanding a customer's actual need.

Accept authority as evidence

Fear can also enter through hierarchy. In the design-review example Yakira described, an engineer may continue to accept feedback from a senior person because that person is an expert, familiar, well-liked, or the engineer's boss.

The point is not to disregard expertise. The point is to examine the basis for the decision. Is the feedback grounded in calculations, requirements, testing, or user needs? Or is the team accepting it primarily because of the source's status?

A senior person's opinion can feel safer to accept than to question. But the source of feedback and the basis for a decision are not the same thing.

Avoid deciding

Greg's contribution identifies another form of fear. Fear does not always push a team into a premature action. Fear of uncertainty, failure, or making the wrong decision can also keep people stuck.

As Greg put it, "No decision becomes a decision." The team remains with the old condition while time, risk, or opportunity continues to move. The alternative is not reckless action. It is to avoid the "shoulda, coulda, or woulda" loop and take a small step that helps the team learn what to do next.

What to do before the jump

Fear can point to a real risk. The answer is not to dismiss it or treat every concern as an emotional distraction. The useful move is to investigate what the fear is telling you before allowing it to choose the solution.

Before committing, ask:

What am I trying to make safer by choosing this?
What do I actually understand, and what am I assuming?
What small action would increase understanding rather than merely reassure me?

These questions separate a valid risk signal from a response that only makes the team feel temporarily safer. They also keep the team in the problem space long enough to improve the decision inputs.

Key takeaways

A visible response is not necessarily an effective response. Another inspection, feature, or control can show that someone acted without changing the condition that created the problem.
The easiest thing to document may not be the most important thing to understand. Features can be planned and placed on a chart. Customer feelings and unmet needs require more direct investigation.
Expertise still needs a basis. Listen to experts, but distinguish the person's authority from the evidence supporting the decision.
Inaction also has consequences. If the team does not decide, the current condition continues while time, risk, and opportunity change.
Fear should be investigated before it becomes the solution. Ask what the fear is pointing to, then choose a small step that increases understanding.

Your Challenge This Week

Choose one current decision and write down four things:

1. What are you afraid will happen?
2. What solution are you tempted to choose?
3. What evidence do you currently have to support that decision?
4. What small step would increase understanding before commitment?

Do not use the exercise to talk yourself out of a legitimate risk. Use it to determine whether the proposed solution addresses the risk or simply reassures the team that it is doing something.