Back to portfolio

Operating Note · 2026

Make the Close Condition Visible

Work moves faster when the team knows what finished actually means.

A lot of process work gets stuck because the team agrees on the task but not the finish line. Everyone knows the invoice needs to be checked, the item record needs to be cleaned, the support issue needs to be resolved, or the handoff needs to happen. The ambiguity is in what counts as done.

That ambiguity is expensive. Without a visible close condition, work keeps returning in different forms. A vendor mismatch gets marked as reviewed, but nobody knows whether the price was corrected, escalated, accepted, or deferred. An inventory exception gets discussed, but the record still does not match the floor. A support fix gets delivered, but the user has not confirmed that the real workflow is back.

The close condition is the small rule that protects the system from pretending. It says what evidence has to exist before the loop is closed. Not a perfect document, and not a meeting summary. Just enough proof that the next person does not have to reopen the same question to understand where the work stands.

I learned to care about this in messy operating environments because the visible task is rarely the whole task. Reconciling a supplier transaction is not finished when the row is highlighted. It is finished when the discrepancy has an owner, the source of truth is updated or clearly disputed, and leadership can see what decision still needs judgment. Troubleshooting a cafe system is not finished when the device turns on. It is finished when the people who depend on it can use it under normal conditions.

Good close conditions are specific enough to remove debate. They name the expected state, the evidence, and the owner. "Check inventory" is a task. "NetSuite quantity matches the physical count, or the variance is logged with an owner and next action before ordering" is a close condition. The second version gives the team something to trust.

This is also where automation gets better. A script can move work, send reminders, or surface exceptions, but it needs a clean definition of closed. Otherwise it just changes the status label while the underlying uncertainty survives. When the close condition is explicit, automation can protect the loop instead of decorating it.

The standard is simple: before work starts moving, decide what evidence will let the team stop carrying it. A good system does not just create tasks. It knows how tasks leave.