---
title: "Why Good Processes Fail: The Human Side Leaders Overlook"
description: A process can be logical, documented, producing results, and still stop working. Here’s the human side leaders overlook, and how to account for it.
image: https://methodorum.com/hubfs/The%20elephant%20in%20the%20workflow.png
---

[![Methodorum](https://methodorum.com/hs-fs/hubfs/Methodorum%20color%20logo.png?width=172&height=38&name=Methodorum%20color%20logo.png)](https://methodorum.com/)

- [How I Work](https://methodorum.com/how-i-work)
- [Services](https://methodorum.com/services)
- [About](https://methodorum.com/about)
- [Blog](https://methodorum.com/blog)
- [Resources](https://methodorum.com/resources)
- [Book a free call →](https://calendly.com/nadaelkady/intro-call)

[How I Work](https://methodorum.com/how-i-work) [Services](https://methodorum.com/services) [About](https://methodorum.com/about) [Blog](https://methodorum.com/blog) [Resources](https://methodorum.com/resources) [Book a free call →](https://calendly.com/nadaelkady/intro-call)

![why good processes fail](https://methodorum.com/hubfs/The%20elephant%20in%20the%20workflow.png)

leadership

# Your Process Can Be Impeccable and Still Fail

![Nada Elkady](https://methodorum.com/hubfs/Nada%20Elkady%20-2.png)

Nada Elkady  October 16, 2026 · 13 min read

Listen to this post Read by Nada

Share

1×

15

0:00 / 0:00

Nearly ten years ago, I gave a [keynote at Stack Overflow](https://www.youtube.com/watch?v=06u2iw_cc28) about how my team learned to solve big problems.

I opened with the concept of vectors.

A vector has both magnitude and direction. So if every person on a team is a vector, you can have a group of incredibly intelligent, skilled, experienced, powerful people, each operating with enormous magnitude.

But if they’re all pointing in different directions, the team still won’t reach its destination.

For a long time, I believed I knew how to solve that.

Clarify why the team exists. Define the destination. Identify the goals and KPIs. Create SMART objectives. Evaluate the possible initiatives. Prioritize them. Build the roadmap. Measure what happens. Optimize and iterate.

It was detailed. It was logical. It was methodical. And it worked - we produced extraordinary results.

Until growth stalled, and problems I couldn’t explain started showing up everywhere.

The process hadn't changed. The context holding it up did.

Because I was looking at each person’s magnitude as though it consisted only of their intelligence, skills, experience, and ability to get things done.

It doesn’t.

People also bring their fears, ambitions, habits, histories, loyalties, expectations, emotions, incentives, and need for safety into the system.

And I hadn’t accounted for enough of that.

Sometimes a process stops working because the company [outgrew it](https://methodorum.com/blog/why-what-worked-at-20-people-breaks-at-100). But one of the most overlooked reasons is that the process was designed for the work and not for the people doing it. Their fears, incentives, histories, and expectations shape how they follow it, work around it, or quietly resist it.

## I thought the process should be enough

I could see what we were trying to build and how all the pieces needed to fit together.

Here’s the outcome. Here’s the framework. Here are the goals. Here’s how we’ll prioritize the work. Here’s the roadmap. Ultimate clarity.

Let’s go, let’s go, let’s go!

When people resisted the process, questioned it, stepped around it, or failed to move at the speed I expected, I became frustrated. Why couldn’t everyone see what I saw? Why couldn’t they just put their big-girl pants on and get moving?

People around me tried to point out what I was missing. One leader told me to use my empathy. Another told me I was trying to solve a problem through logic that couldn’t be solved through logic alone.

Naturally, I resisted that too.

I am empathetic.

That was how I saw myself, so I struggled to receive information suggesting that my behavior might be producing something else.

I was so focused on getting everyone to see what I saw that I failed to see what they saw.

And that was the problem.

There wasn’t one moment that changed it. It was a process (lol, yes I see the irony). One manager told me something. A colleague told me something else. The elephant in the room kept getting heavier. I started asking my direct reports for feedback one-on-one and asking peers for their input. And because I was genuinely trying to understand, the information that kept coming in finally started landing differently. [My lens changed](https://methodorum.com/blog/how-to-become-more-self-aware), and I began to see what I was contributing to the context.

## A process changes more than the work

From the person designing it, a process may look like a sensible series of actions, decisions, handoffs, and measurements that will help everyone operate more effectively.

To someone else, that same process may feel like surveillance, a loss of authority, criticism of how they’ve worked until now, or an attempt by another team to control them.

A clarified role may look like focus to one person and diminished status to another. A shared roadmap may look like alignment to you and interference to someone who’s used to working independently. A new system may improve planning for one team while another experiences it as a barrier between them and the help they need.

That doesn’t mean the process is wrong or that every emotional response should determine how the company operates.

It means the response is part of what’s happening.

If you ignore it, the thoughts and feelings don’t disappear. They move underground and begin influencing how people interact with the process and one another. Those unspoken, hidden thoughts and feelings become the elephant in the room. You can’t see it, but everyone can feel it, and it takes up so much space that no process can survive in its presence.

People work around the system.

They protect their turf. Cliques emerge. Information gets withheld. Teams complete work in silos because coordinating no longer feels worthwhile or safe. [The official process exists in documentation](https://methodorum.com/blog/the-system-is-working.-thats-the-problem) while an entirely different process develops through people’s behavior.

And it doesn’t always show up right away. Early wins and momentum can carry a process for a long time, masking what’s building underneath. The cracks tend to appear when the pressure rises - the team grows, the stakes go up, or the people that the process depended on start to change.

Then [leadership concludes that people are resistant to change](https://methodorum.com/blog/people-problem-or-process-problem) or unwilling to follow the process.

Maybe.

Or maybe the organization designed a logical process without understanding the human operating system it was entering, or how that system has changed since.

## You’re never only implementing a documented process

Any process you introduce enters a broader system that is already operating. Some of it is visible, some of it, invisible.

People may have existing responsibilities, relationships, incentives, frustrations, habits, and ways of getting work done. They have histories with one another and perhaps also memories of what happened the last time leadership introduced a change, and assumptions about why this process is being created and what it might mean for them.

Some of that will be communicated. A lot of it won’t.

In moments like these, you’re rarely only talking about what you think you’re talking about.

While you’re walking through a workflow, someone in the room may be thinking, *So my role matters less now.* Someone else may be thinking, *This is just another way to monitor us*. Another is wondering who gets the final say now, or bracing to be [held accountable for something they can’t control](https://methodorum.com/blog/unempowered-accountability-the-silent-killer-of-tech-startups). One team suspects another is taking over work that used to be theirs. While someone else hears, *Leadership thinks we’ve been doing a bad job*. A manager is already counting the extra work coming their way with no extra resources. And someone else is quietly thinking, *Why bother? The last three processes disappeared too.*

The process documented on the screen isn’t the only thing being processed.

## How do you get people to see what you see?

Well, you have to see what they see first. That was the hardest lesson for me to learn.

I believed that if I explained the logic clearly enough, everyone would understand why the process made sense. And once they understood it, they’d align around it.

But people don’t receive information outside of context. They process it through what they’ve experienced, what they know, what they value, what they’re responsible for, and what they believe may happen next.

I don’t have to agree with every interpretation, fear, or objection. But I needed to understand enough of what people were experiencing to see the system I was actually trying to change.

That required me to listen differently, not only for agreement, answers and useful information, but also for hesitation, defensiveness, silence, and what people were struggling to say directly.

It required me to ask questions without preparing my rebuttal while they answered. To accept that my good intentions weren’t the only relevant information. To examine what my behavior was producing even when it conflicted with how I saw myself.

Only then could I begin seeing the process from somewhere other than my own position inside it.

## Seeing people doesn’t mean surrendering the outcome

Accounting for the people inside a process doesn’t mean avoiding structure, lowering expectations, or waiting until everyone feels completely comfortable before anything changes.

People may still disagree and a decision may still have to be made. Roles may need to change, work may need to stop, and someone may not get the outcome they wanted.

You can still move forward.

But you’ll move forward with a clearer understanding of the human system your process lives in, whether you’re introducing it or trying to keep it working.

In other words, the process and the people were never two separate things to choose between. You keep doing the things that make a process work - revisiting it with the team as the work evolves, creating clarity about who owns what, and keeping expectations, responsibilities, and handoffs explicit. Because the people are part of the process, tuning into them is part of that work too, so that what people are quietly struggling with doesn’t become the next elephant in the room.

And because your original design is still only a hypothesis about how the work should happen, you can observe what the process produces and change it accordingly.

You’re not abandoning the process.

You’re designing one people can actually use, and that produces the results you want to see.

## Acknowledge, then align

When a process that used to work starts to stall, it’s tempting to treat the dip as a failure, or to push harder on the process. But some of those dips are growing pains, and they’re inevitable. Teams evolve, priorities shift, and people bring more of themselves into the work than any plan accounts for. Resisting that won’t serve you. How you handle it helps determine whether the dip becomes growth or decline.

For the mechanics of designing the process itself, like outcomes, ownership, handoffs, and testing, check out my other blog post, [Before You Implement a New Process, Look at the One You Already Have.](https://methodorum.com/blog/how-to-implement-a-new-process) 

Here’s what made the difference for us, and what I’ve seen work on [high-performing teams](https://methodorum.com/blog/actionable-habits-of-high-performing-teams):

- Hold up the mirror. I thought I was a very self-aware person. So why was I so surprised? I had to challenge my own beliefs to see more clearly. Look at what you may be contributing to the current context.
- Listen for what isn’t being said. It lives in the in-betweens: the hesitation, the silence, the conversations that happen after the meeting, the moments when what people say doesn’t quite line up with what they do.
- Make feedback go both ways. Ask for it and give it with enough trust and connection that people can actually hear it. [Separate the observation from what you’re making it mean.](https://methodorum.com/blog/observation-vs-interpretation)
- Name the elephant. Call it out - out loud. Unspoken tensions don’t fade. If you’re feeling something in the space that’s creating uneasiness or tension, chances are others are feeling it too. Name it. Something like, “I’m sensing that there are some objections that aren’t being vocalized,” or “We seem to be arguing about KPIs but my guess is that this isn’t really what we’re really upset about,” or “I’m guessing you’re wondering why we’re hiring for this role.” You’d be surprised at how much relief is created simply by naming it alone. And once you do, you open the door for folks to share more of what they're thinking.
- Create role clarity. We were all smart capable people who could do everything, so we all tried to. But imagine a basketball team where everyone plays center, or a football team where everyone tries to be the quarterback. It doesn’t work. Role clarity is both a process fix and a people fix, which is exactly why you can’t separate the two.

Then align. Once people feel seen and heard, they’re far more willing to see what you see, and shared goals start to feel genuinely shared instead of something simply jotted down on a piece of paper. There is no magic formula for alignment, but these practices make room for it.

## The people are not outside the system

Looking back, I wasn’t wrong about the need for clear outcomes, objectives, priorities, roadmaps, roles, and measures. Our team needed all of those things, and they did produce extraordinary results, until the part I hadn’t accounted for caught up with us.

What I initially failed to understand was that aligning the work wasn’t enough.

We also had to make room for the people doing it, because the people and the work are part of the same operating system.

Once we did, even conflict got better. And the results didn’t just recover, they grew. We could finally argue about the things we were actually arguing about, instead of the elephants nobody had named.

And I had to recognize that I was one of those people. My urgency, expectations, frustration, fear, habits, and way of communicating were influencing the system too. I wasn’t standing outside of it, objectively installing a better process.

I was part of the process I was trying to implement and enforce.

That lesson became the foundation of Methodorum. People are the force multiplier, and nothing they do happens in a vacuum. There are layers of operating systems already in motion - personal, team, and organizational - and if we don’t keep trying to see them, whether we’re introducing a process or pushing for change, growth gets a lot harder.

Your process can be logical, meticulously documented, and operationally impeccable. But if it ignores what the people inside the system see, feel, fear, need, and do in response, the process on paper will never be the process that actually operates.

No one will see what you see until you see what they see.

![Preview of Results Gap Diagnostic results](https://methodorum.com/hubfs/resources-thumb-results-gap.png)

Free diagnostic

### Is it you, your team, or the system?

If your team is working hard but the results aren't following, this diagnostic shows whether your biggest lever is in how you lead, how your team works, or how your organization operates.

- About 5 minutes
- Scores across three layers
- Shows your biggest lever
- Results sent to your inbox

[Take the free diagnostic →](https://methodorum.com/results-gap-diagnostic)

 

#### Get new posts by email

Practical ideas on leading yourself and your team. Unsubscribe anytime.

In this post

#### Get new posts by email

Practical ideas on leading yourself and your team. Unsubscribe anytime.

Keep reading

[![how to survive a toxic workplace](https://methodorum.com/hubfs/Orange%20Core%20Amid%20Indigo%20Pressure.png) personal development Don't Let A Dysfunctional Workplace Decide Who You Become 12 min read](https://methodorum.com/blog/how-to-survive-a-toxic-workplace) [![how to implement a process your team will actually follow](https://methodorum.com/hubfs/From%20observation%20to%20scale.png) leadership Before You Implement a New Process, Look at the One You Already Have 13 min read](https://methodorum.com/blog/how-to-implement-a-new-process) [![what to do when everything goes wrong](https://methodorum.com/hubfs/One%20clear%20step%20through%20the%20tangle.png) personal development When Everything Goes Wrong, Find Your Next Move 17 min read](https://methodorum.com/blog/what-to-do-when-everything-goes-wrong)

[Methodorum](https://methodorum.com/)

Sustainable growth from the inside out.

<https://linkedin.com/in/nadaelkady> <https://nadaelkady.medium.com> <https://youtube.com/@nadaelkady>

#### Methodorum

- [How I Work](https://methodorum.com/how-i-work)
- [Services](https://methodorum.com/services)
- [About](https://methodorum.com/about)
- [Contact](https://methodorum.com/contact-me)
- [Book a Free Call](https://calendly.com/nadaelkady/intro-call)

#### Resources

- [Blog](https://methodorum.com/blog)
- [Resources](https://methodorum.com/resources)
- [Customer Stories](https://methodorum.com/nada-elkady-testimonials)
- [Take the Results Gap Diagnostic →](https://methodorum.com/results-gap-diagnostic)

Copyright © 2026, Methodorum [Privacy Policy](https://methodorum.com/privacy-policy)

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Nada Elkady",
    "url" : "https://methodorum.com/blog/author/nada-elkady"
  },
  "dateModified" : "2026-10-16T14:11:49.013Z",
  "datePublished" : "2026-10-16T14:11:49.000Z",
  "headline" : "Why Good Processes Fail: The Human Side Leaders Overlook",
  "image" : [ "https://methodorum.com/hubfs/The%20elephant%20in%20the%20workflow.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://methodorum.com/blog/why-good-processes-fail",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://methodorum.com/hubfs/Methodorum_Logo_Color.png"
    },
    "name" : "Methodorum"
  }
}
```