Read · Craft · Scale: the Deepgrain method

Three movements. They are sequential, not parallel. They are also asymmetric in time: most of the work is in the reading.

Most People Ops work skips straight to the middle movement. Someone in leadership decides the org needs "an AI strategy" or "better onboarding" or "a new performance process", and a team gets assembled to build it. Nobody spent proper time establishing what's actually true about how the organisation runs today. The build starts from an assumption, not a diagnosis. That's how you end up with a beautifully designed intervention that nobody uses, because it was never built for the organisation that has to run it.

Read, Craft, Scale is the discipline against that. It is a sequence you enforce, hardest exactly when the pressure is on to skip to the middle.

Read: establish what's true before you touch anything

Read is the diagnostic phase. You're not designing yet. You're not fixing yet. You're finding out how the organisation actually operates, as distinct from how the org chart, the handbook, and the leadership team's mental model say it operates. Those three things are rarely the same document.

In practice this means structured interviews across levels, not just with the people who commissioned the work. It means watching a process run rather than asking someone to describe it from memory. It means reading the Slack threads and the ticket backlogs, not just the strategy deck. A U-shaped audit exists because the people at the top of the org and the people doing the work at the bottom see completely different organisations, and the gap between those two views is where every failed initiative lives.

The temptation to cut Read short is constant, and it gets worse the more senior the sponsor. Executives want to see progress, and progress looks like artefacts: a new process document, a pilot, a slide with a timeline on it. Sitting in interviews for three weeks doesn't look like progress. It looks like stalling. This is exactly the moment to hold the line, because everything built on a shallow read has to be rebuilt once the real picture surfaces, usually at the worst possible time, usually in front of the same executive who pushed you to hurry.

A carpenter doesn't argue with wood. They read it first. Every intervention that ignores the grain of an organisation gets the same result a woodworker gets when they cut against it: it splits.

Craft: small interventions that fit what you found

Craft is where the diagnosis becomes a design. This is the part everyone assumes is the real work, and it is real work, but it's supposed to be small. If Read was done properly, the intervention should feel almost obvious, almost underwhelming, because it's built to fit a shape you already understand rather than to impress anyone.

Big interventions are how teams break the grain they just learned to read. A leadership team that spends six weeks diagnosing a fragmented onboarding process and then responds with a twelve-module enterprise LMS rollout has thrown away everything Read taught them. The diagnosis said "three specific breakpoints in week one." The craft should fix three specific breakpoints in week one. It should not become a platform migration.

Small, in this context, means: the narrowest change that resolves the diagnosed problem, built with the tools and the people already in the building, tested against the actual grain rather than against a best-practice template pulled from a different company's org chart. It means resisting the instinct to bundle in three adjacent problems while you're in there, because bundling is how a two-week fix becomes a six-month programme that never ships.

This is also where AI tooling earns its place or doesn't. The craft question isn't "where can we use AI", it's "what specific, diagnosed breakpoint does this close, and would a human process fix it just as well." If the answer to the second half is yes, use the human process. Tooling should follow the diagnosis, never lead it.

Scale: pace it to what the organisation can absorb

Scale is not a rollout plan. Rollout plans are about coverage, getting the intervention in front of everyone as fast as possible. Scale is about absorption, making sure the organisation can actually take on the change at the rate it's arriving without rejecting it.

The constraint here is pace, not distribution. An intervention that worked beautifully in one team of twelve can fail completely when pushed to four hundred people in six weeks, not because the design was wrong but because the absorption rate was wrong. Organisations have a metabolic limit on change, the same way a person does. Push past it and you don't get faster adoption, you get exhaustion, workaround culture, and a quiet reversion to the old way as soon as attention moves elsewhere.

Scaling well means watching for the signals that absorption is lagging behind rollout speed: managers starting to skip steps, questions repeating that should have died out after week two, the intervention becoming something people comply with rather than something they use. Those signals mean slow down, not push harder. The habit compounds when it's given room to become normal before the next wave arrives.

This is also where the work either compounds or evaporates. An intervention that gets scaled at the right pace becomes infrastructure: the next thing gets built on top of it. An intervention that gets forced through too fast gets tolerated for a quarter and then quietly abandoned, and the next initiative has to start from zero, sometimes from below zero, because the organisation now has a scar tissue memory of "that thing we tried that didn't work."

Why the order is non-negotiable

Read, Craft, Scale only works in that order. Craft before Read produces solutions to problems nobody diagnosed. Scale before Craft produces rollout of something unfinished. And skipping Read entirely, which is the most common failure, produces theatre: activity that looks like progress and changes nothing about how the organisation actually runs.

The asymmetry matters as much as the sequence. Most of the time budget should sit in Read, not because diagnosis is glamorous but because everything downstream is only as good as the diagnosis it's built on. Spend the uncomfortable amount of time there. Then craft small. Then scale at the pace the organisation can actually keep.