The Animal That Doesn't Belong
Imagine a horse farm. Thirty horses in a pasture. Fences, troughs, a barn with stalls built for horses. The whole operation is designed around what horses need and how horses behave. It works.
Now put a zebra in the pasture.
It has four legs. It eats the same grass. It runs in the same field. From a distance, to someone who isn't paying close attention, it looks like a horse. A little different, maybe—something about the markings—but it's in the pasture, it's doing horse things, and nobody questions it.
But a zebra isn't a horse. It doesn't respond to the same training. It can't be saddled the same way. It has different instincts under stress—a horse that's been trained can be led calmly out of a burning barn; a zebra will kick through the wall. The infrastructure that was designed for horses doesn't account for the zebra's fundamentally different nature. And because nobody named it as a zebra, nobody redesigned the infrastructure to accommodate it. They just worked around it. The farmhands know which stall not to approach from the left side. The veterinarian knows to double the sedation. The farrier knows not to bother trying. Over time, the workarounds become the process, and the cost of the zebra disappears into the background noise of "that's just how it is around here."
Every organization has zebras. Processes that look like they belong because they produce output and arrived with authority. To the trained eye, they stick out. To everyone else, they look like horses.
Where Zebras Come From
Zebras don't arrive by accident. They're brought in by competent, experienced people who are solving real problems with real urgency. And that's exactly what makes them so hard to see.
A new VP of Operations joins the company. She's talented—she scaled operations at her last company from $10M to $80M. She looks at the current state and immediately recognizes problems she's solved before. Within her first quarter, she installs the approval workflow that worked at her previous company. She restructures the reporting cadence. She introduces the vendor evaluation framework. She implements the escalation matrix.
Every one of these was a good answer. At her last company. For that company's scale, that company's market, that company's team composition, that company's risk profile, that company's growth velocity. She isn't wrong about the problems she's seeing. She's applying solutions from a different context—and nobody questions it because she's credible, she's decisive, and the solutions come with the weight of prior success.
This is what I call borrowed rigor—process infrastructure imported from another environment and installed in this one without redesigning it for this context. It's not negligence. It's the natural behavior of experienced people under pressure. When you've seen a problem before and you have a solution that worked, the instinct to install that solution is overwhelming. And the pressure to produce results quickly makes it feel irresponsible to start from scratch when you already have something proven.
The trouble is that "proven" means "proven somewhere else." The three-stage approval chain that prevented costly errors at a 500-person regulated enterprise becomes a velocity killer at a 40-person consultancy where the CEO is three desks away. The weekly leadership sync that kept five department heads aligned at a company with 200 employees becomes a performative ritual at a company with 15, where everyone already knows what everyone else is doing. The quarterly business review template that gave a board of directors the oversight they needed becomes a documentation exercise that consumes a week of preparation for an audience of three people who could get the same information in a 20-minute conversation.
Each of these processes works. It produces output. The approval gets approved. The meeting happens. The report gets filed. And because output exists, nobody asks whether the process itself belongs here. The zebra eats the same grass.
The Friction That Hides in Plain Sight
Borrowed rigor doesn't announce itself. It doesn't create a crisis. It creates friction—distributed, chronic, low-grade friction that accumulates so gradually that it becomes the baseline. People don't complain about it because they assume it's necessary. They don't question it because the person who installed it was more experienced than they are. And they don't measure it because nobody tracks the cost of a process that technically works.
But the friction is real, and it compounds. A deal that should close in two weeks takes four because the approval workflow has three stages designed for a regulatory environment this company doesn't operate in. A hire that should take 30 days takes 90 because the interview process was built for a company that needed to filter 500 applicants, not 12. A product decision that should be made in a meeting takes two weeks because the decision framework requires a written proposal, a review cycle, and a sign-off chain imported from a company where the stakes of a wrong decision were measured in millions, not thousands.
None of these processes are broken in the traditional sense. They all produce the intended output. The approval is thorough. The hire is well-vetted. The product decision is well-documented. But the time they consume, the energy they absorb, and the velocity they suppress are wildly disproportionate to the value they add in this context.
The person doing the work feels it. They can tell you that the approval process is slow, that the hiring loop is heavy, that the decision framework is cumbersome. But they frame it as a complaint about bureaucracy, not as a diagnosis of a misfit process. They don't have the language to say: "This process was designed for a different context and it doesn't belong here." They just say: "This takes too long." And leadership hears that as impatience, not as signal.
The most dangerous friction is the kind that everyone feels and nobody names.
The Scale Problem
Borrowed rigor accumulates with scale, and it accumulates faster than most people realize.
At five people, every process is visible. If something creates friction, you feel it in real time. You're sitting next to the person who's waiting for the approval. You can see the queue building. You fix it over lunch because the cost is obvious and the authority to change it is sitting at the same table. At five people, zebras can't hide.
At fifty people, the imports start accumulating. You've hired leaders from different backgrounds. Each one brings their version of how things should work—their tools, their cadences, their review cycles, their templates, their operating rhythms. None of these are wrong in isolation. They're all proven. They all come with stories of prior success. But they were proven in different herds, and the horse farm is quietly filling with zebras.
At a hundred and fifty people, the friction has become structural. The organization is running on dozens of inherited processes from dozens of prior contexts, layered on top of each other. Some contradict. Some overlap. Some have been modified so many times by so many people that nobody can explain why they work the way they do—only that they've always worked this way, which isn't even true. They've worked this way since the person who installed them arrived. Before that, they worked differently. Before that, they didn't exist.
At this stage, the friction is so distributed across the organization that no single person feels enough of it to justify a redesign. The VP of Sales feels the friction in the deal approval process. The VP of Engineering feels it in the technical review cycle. The VP of Finance feels it in the budget approval chain. Each one feels their piece. Nobody feels the whole. And because each piece technically works, the organizational response is to optimize within the existing structure rather than question the structure itself.
This is the paradox of growth: the organization hired experienced people precisely because it needed their expertise to scale. And those experienced people, in good faith, installed the processes that worked at scale in their prior contexts. The zebras arrived in the service of growth. And now the growth is slowing, and nobody can see why, because the cause isn't a single broken process. It's thirty functional-but-misfit processes, each adding a small tax on everything the organization tries to do.
Too Much and Not Enough
The tension at the organizational level isn't rigor versus speed. That's the false trade-off that most companies believe they're navigating. The real tension is between rigor that was designed for this context and rigor that was borrowed from another one.
An organization running on borrowed rigor is simultaneously over-rigorous and under-rigorous. Over-rigorous where the imported processes add controls that don't match the actual risk profile. Under-rigorous where nobody ever designed the processes that this organization actually needs—the ones that would address this company's real risks, at this company's real scale, with this company's real team.
Consider a company with a rigorous, multi-stage vendor evaluation process imported from a prior context where vendor failure could shut down a production line. The process is thorough. It takes six weeks. It requires three departments to sign off. And in its original context, that rigor was proportional to the risk—a bad vendor decision could cost millions in downtime.
But in the current company, the vendors being evaluated are SaaS tools with monthly contracts and 30-day cancellation windows. The maximum downside of a wrong decision is a month of wasted subscription fees and a weekend of migration. The six-week evaluation process hasn't been calibrated to this risk. It's applying the rigor of a mission-critical procurement to a decision that could be safely made in a week with a trial period.
Meanwhile, the same company has no designed process for how customer feedback from the Retention stage of one product reaches the team designing the next version of another product. The cross-product feedback loop—which could directly improve revenue—has never been specified. Nobody imported one, because nobody's prior company had the same product portfolio. And nobody designed one from scratch, because all the organizational energy for process design was consumed by the imported processes.
Too much rigor where it wasn't needed. Not enough rigor where it was. Both caused by the same root: the organization's process infrastructure was assembled from imports rather than designed for context.
The Trained Eye
To the trained eye, a borrowed process sticks out like a zebra at a horse farm.
The tell isn't that the process is bad. It's that the process is disproportionate. The rigor doesn't match the risk. The complexity doesn't match the scale. The formality doesn't match the culture. The cadence doesn't match the velocity. Something about it is off—not wrong, exactly, but misfit. It works in the way that a zebra eats grass: technically functional, fundamentally out of place.
The trained eye also notices the workarounds. Wherever a borrowed process creates friction, people build paths around it. The approval chain has three stages, but the team has learned that if you get the CEO's verbal okay first, stages one and two are formalities—so they always get the CEO's verbal okay first, and the approval chain exists as theater. The weekly status report is required, but everyone knows the real status conversation happens in Slack on Thursday afternoon, so the report is copy-pasted from last week with the numbers updated. The interview process has five rounds, but the hiring manager decided after round two and the remaining three rounds are performed with the outcome predetermined.
Every workaround is a signal. It's telling you that the process doesn't fit and the people inside it have adapted. They haven't removed the zebra—they don't have the authority to do that, or they don't realize it's a zebra. They've just learned which side of the stall to approach from.
The question that the trained eye asks, and that nobody else thinks to ask, is simple: does this process exist because the work requires it, or because someone brought it from somewhere else and nobody questioned it?
If the answer is the latter, you're looking at a zebra.
What Deliberate Culture Actually Is
In Origins, I described two lineages converging: the practice tradition's insight that people develop through designed repetition with feedback, and the systems tradition's insight that consistency is engineered through designed process. Deliberate Work emerged at the intersection—a methodology for designing work so the system produces excellence and the people within it continuously develop.
That methodology operates at the operation map level. Each product or service has its own map—an AAAERRR-governed structure of stages, workflows, and steps that defines how value is created, delivered, and compounded for that offering. The methodology is rigorous at this level. Every step specifies its inputs and outputs. Every zone boundary has a handoff contract. Every execution pattern is declared.
But an organization isn't one operation map. It's a portfolio of them. A consulting firm runs a Customer Experience Design operation map, a Fractional Leadership operation map, and an Assessment operation map. A SaaS company runs a self-serve operation map and an enterprise operation map. Each is governed by AAAERRR. Each has its own Funnel, Flywheel, and Off-Ramp.
And then there's everything that connects them. The shared services—finance, HR, legal, IT—that enable all the operation maps but don't follow AAAERRR because they don't have external customers. The cross-map routing—where one product's Referral output feeds another product's Awareness or Acquisition. The organizational infrastructure—the approval chains, the reporting cadences, the decision frameworks, the planning cycles—that governs how the whole thing operates as a company, not just as a collection of individual operations.
Deliberate Culture is the operating system for that connective layer.
It's not a set of poster values. It's not a mission statement. It's not a list of behaviors that get praised in performance reviews. It's an organizational capability—the ability to look at your own infrastructure and distinguish between what was designed for this context and what was inherited from another one. And then the discipline to redesign what doesn't fit, without waiting for it to cause a crisis, because by the time a misfit process creates a visible crisis it's already been generating invisible friction for years.
Deliberate Culture is what fills the gaps between operation maps. It's what governs how teams interact when the specification runs out. It's what ensures that when a new leader arrives with experience from a different context, the organization has the vocabulary and the framework to evaluate what they're bringing—to take the insight without taking the zebra.
The Principles of a Deliberate Culture
A deliberate culture operates on principles that are testable. Not aspirational statements about who we wish we were, but observable patterns in how the organization actually behaves. Each one answers a question you can ask of any process, any decision, any piece of organizational infrastructure.
Design Over Default
Nothing runs on accidental work. If a process exists but nobody designed it for this context, it's a liability being mistaken for a system.
The test: Can you show someone the specification for how this works—why it exists, what it costs, and what risk it addresses at this company's scale? Or does the answer start with "well, usually what happens is..." or "that's how we did it at my last company"?
Systems Over Heroics
When an employee has to be heroic to deliver a basic outcome, that's not a culture strength—it's a system failure wearing a cape. The organization celebrates the system that makes heroics unnecessary, not the hero who compensates for its absence.
The test: When something goes wrong and someone saves the day, does the organization fix the gap or give the person an award?
Transmission Over Assumption
Every commitment that's made must be transmitted—not assumed. The organization doesn't treat "I told them" as "they received it." Every boundary between teams is a designed transition where context travels with the work.
The test: When a customer interacts with a second team, do they ever have to re-explain what the first team already knows?
Proof Before Payment
Value is delivered, then confirmed, then collected. The sequence is non-negotiable. This applies to customers and to internal operations: don't ask for trust, budget, or commitment before you've demonstrated the value that earns it.
The test: At every point where you ask someone for something—money, time, commitment, a referral—can you point to the value you've already delivered that earns the ask?
Designed Exits
Every relationship ends. The question is whether the ending was designed or accidental. A deliberate culture treats departure—of customers, of employees, of partners—with the same intentionality as arrival.
The test: Is your off-boarding experience as well-designed as your onboarding? When someone leaves—a customer, an employee—is the final impression one you'd choose?
Feedback Over Faith
Every step produces observable output. You know whether it worked because the system tells you, not because you hope it did. Feedback is embedded in the work itself—not deferred to quarterly reviews or post-mortems.
The test: For any step in any workflow, can you tell right now whether it's producing the intended outcome? Or do you have to wait until someone complains?
Baselines, Not Ceilings
Standard work captures today's best known method. It's a foundation for improvement, not a constraint on autonomy. The specification exists so that people can improve upon it—and the improvement is adopted system-wide, not siloed.
The test: When was the last time a front-line employee improved a process, and was the improvement adopted across the organization?
Context Over Import
Experience from elsewhere is insight, not instruction. When a leader brings a process from a prior company, the organization has the vocabulary and the discipline to evaluate it—to take the wisdom without taking the zebra. The question isn't "did this work before?" It's "does this fit here?"
The test: When a new leader proposes a process they used successfully elsewhere, does the organization evaluate its fit for this context? Or does prior success serve as sufficient justification?
These aren't aspirational. They're diagnostic. Each one gives you a question you can ask of any process, any team boundary, any piece of organizational infrastructure. The gap between the answer you get and the answer the principle demands is the size of the zebra.
The Layer Above the Operation Map
In Deliberate Work, the hierarchy inside an operation map is clean: AAAERRR Stage, Workflow, Stage, Step. Each level has rules, specifications, and designed relationships. The Design Layer—the invisible architecture between strategy and execution—governs how AI agents design and evaluate at this level. The methodology is rigorous here.
Above the operation map, there's been a gap. The methodology could tell you how to design a product's customer journey from Awareness through Referral. It couldn't tell you how that product's operation map connects to the three other operation maps running simultaneously, or how the finance function serves all four, or how the organization decides which operation map gets priority when resources are constrained.
Deliberate Culture is how that gap gets filled. Not with another map—though an organizational-level artifact may eventually emerge—but with principles that govern how the pieces interact. When legal takes six weeks to review a contract and that bottleneck constrains every product's Activation stage simultaneously, Design Over Default says that's an undesigned process, not a staffing problem. When a customer completes one product's Off-boarding Path and there's no designed route into another product's Funnel, Transmission Over Assumption says that cross-map routing needs a handoff contract. When HR hires the same way it's always hired regardless of what role or what team, Context Over Import asks: was this process designed for how this organization actually works, or is it a zebra from somewhere else?
The principles don't replace structural design. They govern the space where structural design hasn't reached yet. They're the culture that fills the gaps between the specifications—the operating system that determines what happens when someone encounters a situation the methodology doesn't cover.
Toyota understood this intuitively. The Toyota Production System wasn't just kanban and kaizen and standardized work. It was a culture so embedded that when a line worker encountered something the process didn't specify, they already knew what to do. The values governed the unscripted moments. The system didn't need to specify every edge case because the culture filled the gaps.
That's what Deliberate Culture is for this methodology. The values that govern the unscripted moments. The principles that tell you what to do at the boundaries between operation maps, between value-generating and support functions, between what's been designed and what hasn't been designed yet.
Seeing the Zebras
The first step is the hardest: developing the organizational ability to see what's already there.
Most organizations can't do this because the people best positioned to see the zebras are the ones who brought them. The VP who installed the approval workflow genuinely believes it's the right process because it was the right process in a different context. Asking her to evaluate it objectively is asking her to question her own expertise. That's not a character flaw. It's a structural problem—and it's why Deliberate Culture has to be an organizational capability, not an individual one.
The diagnostic starts with a question applied to every piece of organizational infrastructure: when was this process designed for this company, at this scale, for this context? Not "when was it installed." Not "when was it last updated." When was it designed—from first principles—for the organization as it exists today?
If the answer is "never," you're looking at either a zebra or an accidental process. Both need attention. The difference is that the zebra was designed—just not for here—while the accidental process was never designed at all. The zebra needs to be re-examined for fit. The accidental process needs to be designed for the first time.
The second question is about proportionality: does the rigor of this process match the risk it addresses at this company's actual scale? A six-week vendor evaluation for a $50/month SaaS tool is disproportionate. A verbal handshake for a $500K annual contract is also disproportionate. The rigor should match the stakes. If it doesn't, something was imported without calibration.
The third question is about workarounds: where have people built paths around this process? Every workaround is a signal that the process doesn't fit. The workaround is the organization's immune response to a foreign body. Map the workarounds and you've mapped the zebras.
None of this requires tearing everything down. It requires seeing what's there, naming what doesn't fit, and redesigning with the same intentionality that the operation map methodology brings to the product level. Not more rigor. Not less rigor. The right rigor, designed for this context.
Deliberate, All the Way Up
Deliberate Work started with a question about the work itself: how does the work get better? The methodology answered it at the operation map level—designed stages, specified steps, handoff contracts at every boundary.
Deliberate Culture asks the same question at the organizational level: how does the organization get better? Not through more process, but through the right process. Not through borrowed rigor, but through designed rigor. Not through importing solutions, but through developing the capability to design them for this context, at this scale, at this velocity.
The zebras will always arrive. Experienced people will always bring what worked before. That's not a problem to prevent—it's a reality to design for. A deliberate culture doesn't reject outside experience. It evaluates it. It takes the insight. It leaves the zebra.
Design the work. Develop the people. And design the culture that connects them. Deliberately.
Continue Reading
Origins—the two lineages behind Deliberate Work, from deliberate practice through systems design.
Evolutions—how AI became native to Deliberate Work, and why it changed everything and nothing.
Something Is Breaking in Your Business Right Now—the three symptoms of undesigned operations: tribal knowledge, invisible handoffs, and heroic effort.
Deliberate Build #1: The Car Service Appointment—a first-person teardown of borrowed rigor in action: the brand made a promise the dealer didn't receive.
TL;DR
The most expensive friction in your organization isn't caused by bad processes—it's caused by good processes from somewhere else. Experienced leaders bring solutions that worked at their prior companies without redesigning them for this context. Deliberate Culture is the organizational capability to see these "zebras," name them, and replace borrowed rigor with designed rigor—calibrated to this company's scale, risk profile, and velocity. Eight testable principles govern the connective layer above individual operation maps, filling the gaps between what's been specified and what hasn't been designed yet.
Working at this scale? The Deliberate Company consults directly with leadership teams.