The voice: "I can't afford to trust the unit-level leaders to run it my way."

The operator owns more than one building. Unit 1 runs at 4c. Unit 2 exists or is being built. The operator is no longer in any single building daily. The constraint changed shape entirely — not the affordability of bodies. The affordability of trust at distance.

[Money] runs as deployment capital across multiple P&Ls. The first unit funds the second. The second has to stand on its own within a defined window or it bleeds the first.

[Time] is divided across units that do not share a roof. The drive between buildings is not free. The cognitive switching cost is not free. [Time] at this rung has to be spent on the system that runs the units, not on the units themselves.

[Trust] is the bandwidth this rung lives or dies on. "Do I trust this lead to run their domain" becomes "do I trust this leader to run an entire unit the way the system says, when I am not watching?" That is a different muscle than any earlier rung built.

[Systems] is the operator's primary lever. The unit does not run because the operator visits. It runs because the system holds.

The Trust-At-Distance Problem. Three failure modes: the operator runs the second unit through the first unit's leadership team — Unit 2 never becomes its own operation, it becomes a satellite; the operator runs the second unit by visiting it — Unit 2's leader never gets to actually lead, Unit 1 starts to drift; the operator runs by exception only — the leader optimizes for not getting called, not for running the operation.

The Replication Problem. Replication is not copy-paste. It is the operator confronting which parts of Unit 1's success were the system and which parts were the operator. The parts that were the operator do not replicate. Those have to be rebuilt as system before Unit 2 has a chance. The operator who skips this confrontation builds Unit 2 as a clone of Unit 1 — and discovers six months in that what made Unit 1 work was something the operator was doing personally that no one ever named or systematized.

The unit-level leader is the role this rung lives or dies on. They run their unit at 4c posture. The multi-unit operator's job is to develop unit-level leaders, not to run units. Three failure modes: the leader runs it the operator's way out of fear — looks like alignment, is actually dependency; the leader runs it their own way out of ego — looks like leadership, is actually drift; the operator hires the leader and does not develop them — the leader stalls at their own Rung 3 or 4 with no one developing them through it.

The unit-level leader is the rung's product. Build them right and Rung 5 works. Build them wrong and Rung 5 collapses Unit 2 back into Unit 1.

The operator's verb at this rung: building unit-level leaders and the system they run. If the calendar shows shifts on the floor at any unit, the verb is wrong. If it shows leadership development sessions, system architecture work, and growth work — the verb is right.

The [Future State] question at this rung: what will success look like when I am running a portfolio of units and the system runs the units rather than me running the unit-level leaders?

Honest read: "I can't afford to trust the unit-level leaders to run it my way" reduces to one of three things. The system is not actually built — "my way" is half in the operator's head and was never extracted. The operator has not built the [Trust] muscle at distance. Or "my way" is a control mechanism — the standard is actually the operator's shifting preference and no leader can run to a moving target. "I can't afford to trust" is almost always "I have not built the system that makes trust possible — and that is the next development piece, on me."