Stop Building Blanket Processes: The Nonnegotiable and Split Method

Trying to enforce one blanket process across an entire scaling company is a guaranteed way to slow your team down. The Nonnegotiable and Split method gives you a cleaner alternative: lock in the core, fork only where reality demands it, and stop bargaining with people who just want their preferences accommodated.

The Problem With One-Size-Fits-All Processes

When you scale, you eventually hit the same wall everyone else hits. Do you build one process with a bunch of weird nuances, or two entirely different processes? Too many processes are a nightmare to govern, especially if your company hasn't actually defined what a Process Owner does all day.

But forcing a single, blanket process across the entire board rarely works either. The natural instinct is to lock everyone in a room, find the overlapping steps, and stitch together a compromised process from whatever everyone agrees on. A weird middle-ground where nobody is happy.

Doing this blinds you to your actual goals. If you're constantly tweaking the rules to keep everyone comfortable, you don't have a standard process anymore.

You just have nicely documented organised chaos.

Step 1: Define the Core With Must and Always

The Nonnegotiable and Split method starts by isolating what is genuinely fixed. Frame your non-negotiables as absolute statements:

• A person Must and Always do this first.
• This action Must and Always be completed by this specific role.

If you can't honestly use absolute words like "Must" and "Always," it's not a core non-negotiable. Drop it. Build your baseline process out of the steps that pass this test. Nobody deviates.

Step 2: Add Splits for Real-World Exceptions

Reality happens. Sometimes a specific department genuinely cannot comply with the core step, and pretending otherwise is just wishful documentation. When that happens, you don't water down the core process. You create a split.

This introduces the UNLESS: It Must and Always be X, unless Scenario A happens, then it Must and Always be Y.

The split protects the integrity of the main process while acknowledging that real-world operations are messy. You get a clear fork in the road instead of a fuzzy "use your judgment" instruction.

Step 3: Know When to Stop Splitting

You can extend the design to a third path if an edge case genuinely demands it. But know your threshold. If a single workflow requires five different splits just to accommodate everyone's preferences, the work has diverged too far.

When to Build a Separate SOP Instead

At that point, it's no longer a shared process. Build an entirely separate SOP. Trying to keep five splits inside one document protects nobody — it just punishes the people who actually follow the rules.

Anchor the core, manage the splits, and ignore the noise. That's the whole method.