Field note
Operational drag is usually a design problem
The slow parts of work often hide in unclear ownership, duplicate capture, and systems that were never designed as a whole.
Note
Operational drag rarely announces itself as a design problem. It tends to show up as small delays: a decision waiting in a message thread, a duplicated update, a status report that has to be rebuilt from memory.
Those moments can look like individual habits, but they usually point to a system that has grown in pieces. Tools were added at different moments, ownership shifted, and the shape of the work changed faster than the operating layer around it.
The useful move is to map where the drag gathers before choosing what to automate or rebuild. When the source of truth, handoff points, and decision moments are made visible, the fix is often simpler than the symptoms suggest.
More notes