The boundary under real-week pressure

In Own-2 you met the line as an idea — you decide what and why, the builder decides how, shipping needs both.

This is the same line under the pressure of a real week.

You own the outcome because you live in the work: you feel the friction, you know who it serves, you carry the priority against everything else.

The builder owns the how because building is a craft with its own trade-offs — pre-decide those and the builder inherits a constraint instead of a problem, and the best answer may already be ruled out.

The first tell: you've started naming the mechanism

The moment your request describes the fix instead of the problem, you’ve slipped past the outcome and started designing.

Catch it and restate the outcome.

About to say: "Build something that blocks the email until I approve it."

Say instead: "Client emails are going out before I see them.

I need to review every one before it sends — solve that."

Now the builder chooses the how, and may reach a cleaner shape than the one you’d have spelled out.

The second tell: you've started saying where the work should live

This one slips past more quietly.

You haven’t named a mechanism — you’ve named a location.

That’s a placement call, and placement is the builder’s: which step a change hangs off, whether it belongs in a domain’s knowledge or a skill, what else it touches.

The builder weighs that; you don’t have to.

Crossing: "Add a line to the morning brief that pulls overdue items first."

Say instead: "The morning brief buries overdue items.

They should lead, because that’s what I act on first."

The discipline here isn’t vagueness.

Be as concrete as you can about the problem, who hits it, and what good looks like — and silent on the mechanism and the location.

A clean hand-off carries three things and stops

The problem, who it hurts, and what success looks like.

No design, no placement.

The builder takes those three and comes back with a shape — sometimes the obvious one, often a better one you’d never have reached.

A complete hand-off: "Our proposal turnaround is too slow — clients wait three days for a first draft, and that’s real renewal risk when we look slow to them.

Success is a same-day draft they can react to.

This matters more than the dashboard work this week."

That names the problem, the person, the success state, and the priority — and stops.

The builder now owns the most interesting part of the job, which is exactly where their judgment earns its keep.

Your standing job is bigger than the hand-off

Owning the domain is a governance job with four standing parts.

You set the method — the framing and the standard for how the work in your domain gets done.

You ratify the decisions the domain makes, so the record reflects what you actually agreed to.

You curate the knowledge — and when the hand-off is about how the method itself should change, there’s a deeper way to build it out: Operate-5, build your own expert.

You drain the feedback on a beat — every friction signal your team captures lands in your domain’s feedback inbox, and weekly you read it, diagnose it, and decide what becomes a fix.

Left undrained, the signal piles up and the domain stops learning.

The line runs both ways

The builder can cross too, and that half is yours to pull back.

If the builder starts deciding what success looks like, or quietly reorders your queue toward what’s fun to build, name it: *"That’s a priority call, and priority is mine.

Here’s the order I need; build against that."*

It’s rarely a turf fight — the builder usually crosses trying to be helpful, filling a gap you left open.

So fill the gap: state the outcome and the priority clearly enough that there’s nothing left to infer.

When you wear both hats at once, say the seam aloud: "as owner, the priority is the proposal turnaround," then "as builder, the cleanest place for this is the proposal step plus a knowledge update."

What makes a wrong hand-off cheap to undo

You can hand off boldly because a bad build inside the domain isn’t permanent.

Every change I make to the workspace is recorded in a logbook — so when a build goes the wrong way, "undo that" puts it back.

That’s what lets you state the outcome, let the builder run, and correct the shape after you see it, instead of over-specifying up front to avoid a mistake you can reverse.

The one thing that stays one-way is outbound — a sent email, an updated the CRM record, a published document.

Those I always hand to you.

The one thing to remember

Under real-week pressure the line slips two ways: you name the mechanism, or you name the location.

Catch either one, restate the outcome and the priority, and stop — the builder owns the how and the where, the logbook makes a wrong build cheap to reverse, and a hand-off that carries the problem, the person, and the success state leaves the builder the part you most want them on.

Next: the development plan