Operating Patterns

Six patterns we’d expect to find. None of them are client work.

We’re early, so we don’t have client case studies yet. We’d rather say that than dress up a pattern as proof. What’s below are operating patterns we’d expect to find in founder-led agencies, D2C brands, and tech-enabled teams, each grounded in outside research, not in our own client data. If you want to see exactly what we’d hand you, the real thing is a sample Teardown report — see it here.

Every pattern below follows the same template: what we’d expect to see, why it happens, and how we’d approach it. Every card runs on the same three engines: Technology, Processes, and People.

[Hypothetical pattern]Illustrative, not a client engagement.

The Coordination Tax

What we’d expect to see

Your team spends more time coordinating work than doing it — status updates, chasing handoffs, redoing work because nobody agreed who owned the last step.

Where it shows up

Common in service teams as headcount grows without workflow structure. Coordination overhead climbs even though the volume of real output hasn’t.

Why it happens

Nobody wrote the handoffs down, so each one gets renegotiated live. Nobody can see the state of the work without asking, so status meetings fill the gap. Ownership of cross-functional steps stays implicit, so the same step gets redone by two people or dropped by both.

How we’d approach it

Map the workflow and turn each handoff into a defined step, with an input, an owner, and an exit condition. Put work state in a shared board everyone can see, Notion or ClickUp, whichever already anchors your team, your stack, not ours, so status is read, not asked. Assign one accountable owner to every step that crosses a function.

What would change

Fewer status meetings, less time re-explaining where something stands, and hours back on work that actually bills.

Engines

ProcessesTechnologyPeople

Grounded in

Asana — Anatomy of Work Index

[Hypothetical pattern]Illustrative, not a client engagement.

The Founder Queue

What we’d expect to see

Decisions stall because they all funnel through the founder: approvals, sign-offs, “can you just check this” pings.

Where it shows up

Past a certain headcount, the queue at the founder’s desk grows faster than the founder can clear it, and it doesn’t self-correct as the team grows.

Why it happens

No one has defined which decisions a role can make on its own versus which need the founder. There’s no threshold that routes a decision automatically, so everything defaults up.

How we’d approach it

Build a decision-rights map — which role owns which class of decision, and up to what limit. Set escalation thresholds (deal size, contract type, exception category) so only the decisions that actually need the founder reach the founder.

What would change

Faster routine decisions, a founder’s calendar with fewer approval queues on it, and an operation that keeps moving on a day the founder is unreachable.

Engines

PeopleProcesses

Grounded in

Harvard Business Review — Why Entrepreneurs Don’t Scale

[Hypothetical pattern]Illustrative, not a client engagement.

Three Versions of the Same Number

What we’d expect to see

Two dashboards, two numbers, one meeting spent arguing about which is right before anyone gets to the actual decision.

Where it shows up

Common wherever a CRM (Zoho, HubSpot), a project tool (ClickUp, Notion), and a finance system run separately with nothing reconciling them, whichever number loads last becomes “the” number.

Why it happens

There’s no single layer where the systems agree with each other, and no one owns deciding which system is the source of truth for a given metric.

How we’d approach it

Build a pipeline that reconciles those systems, your stack, not ours, into one Notion or Google Sheets layer on a defined refresh schedule. Name one owner and one source system for each metric that matters.

What would change

One number in the leadership meeting instead of three, and less time spent debating whose spreadsheet is right before anyone gets to a decision.

Engines

TechnologyProcesses

Grounded in

IBM Institute for Business Value — Chief Data Officer Study

[Hypothetical pattern]Illustrative, not a client engagement.

The Operating Model That Didn’t Grow Up

What we’d expect to see

The way the business is structured hasn’t caught up with how big it’s actually gotten. Roles, procedures, and reporting still fit an earlier, smaller version of the company.

Where it shows up

Growth-stage firms in particular — the operating model from an earlier phase stays in place well after the conditions that made it work have changed, and margins compress as headcount grows faster than output.

Why it happens

Structure was never revisited against current work volume. Procedures built for a smaller team were never rewritten, or never enforced, at the new one. And the signals that would show the drift lag behind it.

How we’d approach it

Redesign structure against current and projected volume — role envelopes, capacity bands. Document procedures fit for the current scale as controlled, followed artifacts. Put leading indicators in place that surface drift before it shows up in the numbers.

What would change

A structure that matches how the business actually runs today, procedures the team can point to instead of improvise, and drift caught before it costs a quarter of margin.

Engines

PeopleProcessesTechnology

Grounded in

McKinsey — The State of Organizations 2023

[Hypothetical pattern]Illustrative, not a client engagement.

Capacity You Can’t See Coming

What we’d expect to see

Capacity problems get discovered the hard way, through a missed deadline or a burned-out senior person quitting, instead of being seen coming.

Where it shows up

Common in professional services, where nobody has a live read on who’s actually at capacity until delivery has already slipped.

Why it happens

Utilization isn’t tracked in anything close to real time. No role has a defined capacity band, so “overloaded” has no threshold to trip. And nothing gates new commitments against what capacity is actually available.

How we’d approach it

Define capacity bands per role, with real thresholds. Instrument utilization across active work on a cadence that matches delivery cycles. Gate new intake against the live capacity signal, not a gut check.

What would change

Capacity problems visible weeks before they hit delivery, intake decisions backed by an actual number, and fewer people leaving because nobody saw the overload coming.

Engines

PeopleTechnologyProcesses

Grounded in

McKinsey — Mastering the Challenge of Capacity Management

[Hypothetical pattern]Illustrative, not a client engagement.

Where Strategy Goes to Die

What we’d expect to see

A decision gets made at the leadership level and, by the time it reaches the floor, barely resembles what was approved.

Where it shows up

At any scale, strategic plans approved at the top consistently lose fidelity by the time they reach day-to-day procedure.

Why it happens

There’s no standard way to turn a decision into an actual operating procedure. No one is assigned to own execution at the moment the decision is made. And nothing tracks whether execution still matches the original decision.

How we’d approach it

Every approved decision generates a procedure — owner, timeline, exit criteria. Execution ownership gets assigned the moment the decision is made, not weeks later. Track execution against the original decision so drift shows up early.

What would change

Strategy that survives contact with the floor, a visible owner and timeline for every approved decision, and stalled execution caught early instead of discovered in a quarterly review.

Engines

ProcessesPeopleTechnology

Grounded in

McKinsey — How to Improve Strategic Planning

If patterns aren’t enough

These are patterns. The Teardown is real.

Everything above is illustrative, grounded in outside research and not in our own client work, because we don’t have any yet. If you want to see exactly what we’d hand you, skip the patterns and look at a real, redacted sample Teardown report: the same format and structure we’d deliver for your operation.

See the sample Teardown report

Read the research

Where these patterns came from.

Each pattern above is grounded in outside research, not our own client data. Insights is where we write more about the sources and the thinking behind them.

Read Insights