Skip to content
The state should change with the work
|2 min read|By Shawn Pennington

The state should change with the work

A lot of workflow friction starts in a small gap that teams get used to. The work is done, but the system still looks unchanged. A task is complete, but the board still says it is open. A file is updated, but the visible record still points to the old version. The answer was already sent, but the next person cannot tell that from the state in front of them.

That gap creates its own kind of labor. Someone sends a follow-up message. Someone leaves a manual note. Someone pings the next person to make sure the change is seen. None of those moves feel dramatic on their own, which is why the pattern survives for so long.

But the cost adds up fast. Teams start treating manual confirmation as part of normal execution. People learn that finishing the work is not enough. They also have to carry the state update, translate what changed, and make sure the rest of the system catches up after the fact.

That is usually not a people problem. It is a workflow design problem. The process is separating the action from the state that should reflect it. When that happens, the system cannot be trusted on its own, so people build a layer of reminders and patches around it.

Good workflow should close that gap. When the work changes, the record people depend on should change too. The board should reflect the new state. The status should move. The next person should not need a side message to understand what already happened.

Simple work gets cleaner when the system keeps up with reality. The state should change with the work.