Write the interface before the org chart

The standard way to add capacity is to define a role, hire a person, and let the actual job emerge from what that person turns out to be good at.

It works, in the sense that the work gets done. It also manufactures situations — undefined steps held together by one person's judgment — at exactly the rate you're hiring. Two years of that and you have a company whose processes cannot be described, only staffed.

The alternative takes an hour and inverts the order: define the segment, then hire the person who fits it.

What "define the segment" means

Before you write a job description, write these four lines:

In — what arrives, from where, in what state
Out — what leaves, to whom, in what state
Gauge — the number that says this segment is healthy
Rate — how much throughput it needs to handle

That's the interface. Notice it says nothing about seniority, background, or which tools get used. Those are implementation. The interface is the contract.

If you can't write those four lines, you don't have a role yet. You have a feeling that things are busy, and hiring against a feeling is how you end up with a person who is undeniably working hard on something nobody can quite describe.

What it changes

The job description writes itself, and it's honest. "Own the seam between closed-won and first successful import. Target: median under three days, P90 under seven. Currently at 4.1 and 9." A candidate reads that and knows exactly what they'd be accountable for. The ones who don't want that job select out, which is the entire purpose of a job description and something most of them fail to do.

You find out whether you needed a person. Roughly a third of the time, writing the interface reveals that the segment is well-defined enough to automate, or that it's really two segments and only one is overloaded. Those are cheaper answers than a hire, and you only get to them by making the work explicit first.

Onboarding gets short. A new hire with a defined In, Out, and gauge is productive in days, because the ambiguity that normally eats the first two months has been resolved before they arrived. The expensive part of onboarding isn't learning the tools. It's discovering what the job actually is, which the interface hands over on day one.

The role survives the person. When someone leaves a defined segment, you replace a segment. When someone leaves a situation, you lose a capability and spend a quarter reconstructing it from artifacts and other people's memories.

The objection

"Our work is too fluid to define like that."

Sometimes true. Early-stage companies genuinely have work that changes shape monthly, and premature definition would be a cost with no benefit.

But it's true much less often than it's claimed. The usual meaning of "too fluid to define" is "we haven't looked closely enough to describe it," and the tell is that the same work has been happening for eighteen months. Fluid work changes. Undescribed work just hasn't been examined.

The honest test: pick the role you'd call the most fluid, and try to write the four lines. If you can't, ask the person doing the job to write them. In my experience they can, usually in ten minutes, and frequently with visible relief — because being accountable for an undefined job is worse for the person in it than for anyone else.

The connection to the law

Pipes connect because segments have fittings. An org chart tells you who reports to whom, which is a fact about authority and not about flow. A pipe diagram tells you how work moves.

Hiring against the org chart adds a person to a box. Hiring against the interface adds a segment to a pipe — with a defined inlet, a defined outlet, and a gauge on the joint.

One of those compounds. The other one accumulates.