---
title: How to Implement a New Process Your Team Will Actually Follow
description: Discover why understanding your current processes is crucial before implementing new ones. Learn key questions to ensure effective process redesign.
image: https://methodorum.com/hubfs/From%20observation%20to%20scale.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)

![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

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

Nada Elkady  October 14, 2026 · 13 min read

Listen to this post Read by Nada

Share

1×

15

0:00 / 0:00

When something repeatedly breaks down at work, one of the first things leaders tend to do is try to implement a new process for it.

Customer handoffs keep getting delayed? We need a process.

Projects are being launched without the right people knowing? Create a process.

Everyone is doing the work differently? Alright then, let’s get something documented, put it in Notion, announce it during the next team meeting, and link it to Slack.

Boom. Process implemented.

Except, not really.

Just because you haven’t intentionally designed or documented a process doesn’t mean there isn’t one. A process is how work actually moves from a trigger to an outcome. And right now, the way your work moves between people, decisions, tools, meetings, approvals, delays assumptions, and workarounds *is* the process already happening.

You just may not be able to see it yet.

That’s usually why new processes don’t stick. When you layer an idealized workflow on top of the one already operating, the old one doesn’t disappear. I learned this the hard way. People quietly keep doing what they were doing, because nothing about the conditions that created it has changed.

So before you introduce something new, you have to make the current process visible, figure out what it’s producing, and determine what actually needs to change.

## The current process may be hiding in plain sight

Let’s say customers are waiting an average of eight business days to begin onboarding after signing a contract.

Leadership sees the delay and decides the company needs a better customer handoff process. So, someone documents what should happen, assigns a few responsibilities, builds a checklist, and walks everyone through it during a meeting.

Looks great on paper, right? [Everyone nods in the meeting](https://methodorum.com/blog/how-to-communicate-change-to-your-team), mission accomplished.

But when you examine how the work actually happens, you find out that Sales records customer information in two different places. Customer Success doesn’t know a deal has closed until someone tags them in Slack, and every onboarding plan requires some sort of signoff from a leader who’s too busy and responds several days later.

That’s the existing process. [Nobody intentionally designed it that way](https://methodorum.com/blog/the-system-is-working.-thats-the-problem), but those repeated behaviors, decisions, dependencies and workarounds are producing the eight business-day delay. [Maybe this informal, ad hoc process worked when the organization was smaller](https://methodorum.com/blog/why-what-worked-at-20-people-breaks-at-100). But if the new checklist doesn’t address all the hidden ways things get done to onboard customers, the results probably won’t change.

A process is not the document describing how work is supposed to happen (no matter how much we believe it is). It’s how the work actually moves from that triggering event to the result.

Sure, the document can help make that movement visible and consistent, but writing it down doesn’t make it real.

## First, figure out what actually needs to change

Before designing anything, you have to uncover the current state of affairs and get clear on the result you’re trying to change. You’re gonna have to do some sleuthing.

So start with a few questions: What’s happening now? How often does it happen, and under what conditions? What outcome do you want instead?

Then follow the work as it actually happens. Speak with the people doing it, observe the steps they take, and identify the decisions, handoffs, tools, waiting periods, approvals, and unofficial workarounds involved.

You may find out that the current process is unclear, inconsistent, or unnecessarily complicated and needs to be redesigned.

But you may also discover that the process itself isn’t the problem.

Maybe someone doesn’t have the authority to make a decision they’re responsible for, or the team doesn’t have the capacity to take more on. Maybe one of the tools keeps breaking or isn’t being used properly. Maybe there are conflicting expectations between folks, or someone repeatedly fails to follow through on an existing commitment.

It could be any number of things that have less to do with process and more to do with something else contributing to the unwanted results you’ve been experiencing.

[So how do you tell the difference?](https://methodorum.com/blog/people-problem-or-process-problem) A few quick signs:

- If people are doing different things for the same task, you probably have a process problem. The way the work moves isn’t clear or shared.
- If people know the steps but don’t follow them, the process probably isn't the problem. Something else is getting in the way, like authority, capacity, tools, competing priorities, or [a commitment nobody’s holding anyone to](https://methodorum.com/blog/lack-of-follow-through-company-culture).
- If the work breaks down between particular people, you may have a relationship or communication problem. Misaligned expectations, low trust, or friction between people can stall a process that's perfectly clear on paper.
- **If the work flows fine until it hits the same spot every time,** like an approval, a handoff, or a team that's stretched too thin, [you probably have a bottleneck](https://methodorum.com/blog/how-to-stop-being-the-bottleneck-on-your-team). Fix that dependency before you redesign everything around it.

Not every unwanted result needs another process.

Sometimes you need a decision, clearer ownership, real accountability, more information, additional resources, a functioning tool, or an honest conversation about what someone agreed to do and didn’t follow through on.

So before you prescribe a solution or slap on a new process, you need to first understand what’s actually producing the result.

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

Free diagnostic

### Where is the gap showing up?

If your team is working hard without moving the right results, the Results Gap Diagnostic shows whether the gap is in how you lead, how the team works, or how the 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)

## Five questions to ask before implementing a new process

If a process does need to be created or redesigned, these five questions can help you build one that works within the reality of how your team operates.

The key is to ask each question twice. Once about how the work is supposed to happen, and once about how it actually happens today. The gap between those two answers is exactly where your new process needs to do its work.

### 1. What outcome should this process produce?

Always start with the result you want to see, not the steps. Clarify what should become different because this process exists and how you’ll know whether it’s working.

“Improve customer onboarding” is too ambiguous and opens the door to conflicting interpretations. Be specific, and make it measurable and observable. “Reduce the time between a signed contract and the customer kickoff from eight business days to three” gives everyone a clear outcome to design around and assess.

And be honest about what the current process is producing, too. If you don’t know it’s taking eight business days today, you won’t know whether three is realistic, or whether you ever got there.

Without that clarity, you may create a beautifully documented series of activities without knowing whether any of them improve the result.

### 2. Where does the process begin and end?

Identify the event that triggers the process and the observable output that tells everyone it’s been completed.

Decide, for example, whether customer onboarding begins when the contract is signed, when payment is received, or when the account stage is set to “onboarding” in the CRM. And clarify when it ends, like after the kickoff is scheduled, after it takes place, or when the customer reaches a particular milestone.

Then look at where it actually starts today. In our example, the official trigger might be the signed contract, but the real one is whenever someone remembers to tag Customer Success in Slack. That gap alone could account for a few of those eight business days.

If the boundaries aren’t clear, different people will enter and exit the process at different points while assuming everyone is working from the same understanding.

### 3. Who owns the actions, decisions, and handoffs?

Name who’s responsible for moving each part forward, who contributes information or support, who makes the necessary decisions, and how the work moves from one person or team to another.

Treat each handoff as a verifiable outcome, something observable that signals one part is done and the next can take off. Something like, “the CRM stage changed to onboarding,” not “I assume Sales sent over the notes.”

Then compare that to who actually does those things today. The person who’s supposed to make the call and the person who actually makes it aren’t always the same, and your new process has to account for that.

Make sure the people being held accountable have the authority they need to do what the process asks of them, too. If Customer Success owns the onboarding timeline but still needs an executive to approve every plan, [they don’t fully own the outcome](https://methodorum.com/blog/unempowered-accountability-the-silent-killer-of-tech-startups). The process contains a dependency that must be acknowledged and accounted for.

### 4. Can people realistically follow it?

I’ve spent over 20 years leading teams and building the processes and operations to support their work, and I can tell you this with total confidence: a perfect, impeccable, looks-great-on-paper process designed for imaginary working conditions will immediately produce workarounds.

If the new process doesn’t take into account the people involved, they will almost always find a way to get their work done regardless of any documentation.

This is also where today’s workarounds become your best source of information. They’re not rebellious. Every workaround is telling you something the official process didn’t account for.

So consider the workloads, tools, information, skills, incentives, and time available to the people who will implement the new process. Socialize your ideas with your teams before you finalize anything. Ask them what would make the process difficult to follow and what people are likely to do when something doesn’t go according to plan. Get their ideas on what will work and what they’d need to make it happen.

The people closest to the work can usually show you where the proposed process conflicts with reality, so involve them before everything has already been decided. You also have a better chance of follow-through when they feel like they’ve contributed to the new way of doing things.

### 5. How will you test and revise it?

This isn’t a one-and-done kind of thing. A process is not something you design once, roll out, and assume will keep producing the intended outcome forever.

The first version of a process is still a hypothesis about how the work *should* operate. You’re hypothesizing that if particular people or tools take certain actions, make specific decisions, and move information through a defined series of handoffs, the process will produce the outcome you want.

You won’t know how well it works until people begin using it and you observe what it actually produces. The rollout is an experiment, and every experiment needs to be observed and measured. If you want to turn a documented process into a functioning, scalable system, you can’t skip this step.

Which means you need to decide how you’ll monitor it *before* you launch it.

For the new onboarding process, maybe you create a dashboard that shows when each customer enters the process, how long they stay at each stage, where handoffs get delayed, how often required information is missing, and how long it takes to get from a signed contract to the kickoff.

Then decide who watches it, how often, and what happens when the numbers are off. Maybe an operations leader reviews the dashboard every week, talks with the people involved, identifies where work is getting stuck, and brings recommended changes back to the team.

[The numbers alone won’t tell you everything,](https://methodorum.com/blog/youre-not-data-driven-youre-dashboard-driven) by the way. You also have to notice where people are confused, which steps they skip, what workarounds pop up, where rework piles up, and which conditions the original design failed to account for.

If your process is larger, riskier, or spans several teams, shrink the scope of the first rollout. Test it with one team, customer segment, region, or type of project. Observe and measure, adjust what isn’t working, test it again, then expand to the next group. Test, observe, iterate, expand.

It’s not that you’re moving slowly for the sake of caution. It’s about learning while the impact of being wrong is still contained.

And even after a process is fully implemented, keep an eye on it. The people, volume, tools, customers, risks, and conditions surrounding the work will change, and a process that worked well for a team of twenty may collapse when the company reaches one hundred.

A process becomes scalable not because it’s been standardized, but because the organization can see how it’s performing, learn from what it produces, and evolve it as the surrounding system changes.

The five questions

- What outcome should this process produce?
- Where does it begin and end?
- Who owns the actions, decisions, and handoffs?
- Can people realistically follow it?
- How will you test and revise it?

For each one, compare how it's supposed to work with what's actually happening today.

## A process isn’t implemented because you announced it

You can document a process, introduce it during an all-hands meeting, train everyone involved, and add it to the company wiki. But if the work keeps moving the same way it did before, well, you haven’t changed the process.

You’ve just created a document describing another one.

So before you add another process, don’t begin by asking what steps should be documented or what tools you need to implement it. Find out what’s already happening, what it keeps producing, and what actually needs to change and why.

See the process that’s already running. Sync with the people doing the work. Systematize what actually needs to change. Then scale what you’ve proven, and keep changing it as the work changes.

Because at the end of the day, you can’t sustainably implement or scale a process you can’t observe.

Free 30-minute call

Want help seeing what's really going on?

Book a free discovery call. We'll talk about what you're working on, what's getting in the way, and whether working together makes sense.

[Book a free call →](https://calendly.com/nadaelkady/intro-call)

 

#### 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

[![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) [![how to apologize when you think you're right](https://methodorum.com/hubfs/Layered%20Figures%20Around%20a%20Central%20Tangle.png) leadership An Apology is Not a Surrender 9 min read](https://methodorum.com/blog/how-to-apologize-when-you-think-youre-right) [![self awareness when self reflection alone isn't enough](https://methodorum.com/hubfs/Shared%20vision%20through%20borrowed%20patterns.png) personal development How to Become More Self-Aware When Self-Reflection Isn't Enough 9 min read](https://methodorum.com/blog/how-to-become-more-self-aware)

[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-14T17:15:43.247Z",
  "datePublished" : "2026-10-14T17:15:33.000Z",
  "headline" : "How to Implement a New Process Your Team Will Actually Follow",
  "image" : [ "https://methodorum.com/hubfs/From%20observation%20to%20scale.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://methodorum.com/blog/how-to-implement-a-new-process",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://methodorum.com/hubfs/Methodorum_Logo_Color.png"
    },
    "name" : "Methodorum"
  }
}
```