The Mechanics of Delegation
Have you ever been on the receiving end of a terrible handover? You get a forward of a sprawling email chain, a few vague sentences saying, "Hey, can you take care of this?"
Whether you are delegating a complex project to a new hire or trying to document a messy daily workflow, clear execution comes down to structure. In todays article lets look into the mechnics of what makes a good instruction.
The Architecture of Intent
Good instructions are not meant to be entertaining or deeply explanatory. They are deterministic state machines: their entire purpose is to translate the intent in your head into physical or digital execution. This is not always possible, but we should keep in mind that this is the optimal structure for an instruction. Defined inputs, defined outcomes.
If you look at fields where execution is a matter of life and death, like aviation or aerospace engineering, you will notice that they rely heavily on concrete checklists. Early research into aviation human factors proved that checklists succeed precisely because they don't explain why a system works. A pilot's pre-flight checklist doesn't contain a lesson on aerodynamics; it simply provides unambiguous, sequential state transitions (e.g., "Flaps – Set to 15 degrees").
The goal isn't to educate the executor on the entire theory of the operation; the goal is to get the job done reliably.
Task-Oriented vs. Tool-Oriented Construction
Another trap we fall into is writing "tool-oriented" instructions instead of "task-oriented" ones.
John Carroll, a cognitive scientist, coined the concept of Minimalist Instruction. He found that users learn and execute much faster when we stop giving them tours of a system. A tool-oriented instruction reads like: "The 'Export' button is located in the top right corner and allows the system to generate a CSV file."
Nobody cares.
A task-oriented instruction simply says: "To back up your data, click 'Export' (top right) and save the CSV." Anchor your instructions to what the person is trying to achieve, not what the software is capable of doing.
The Executor-Centric Perspective
Instructions are meant to be easily understandable without much room for interpretation. Therefore softing up your language does not help the executor. You have to use active, imperative grammar (e.g., "Extract the dataset"). When you use the passive voice ("The dataset should be extracted"), you are forcing the reader to mentally translate who is supposed to act and when.
Where do we go with this?
There is a lot more to what makes a good instruction and I will explore this more in the future. After all the goals of workflows can be wildly different and sometimes the goal isn't even clear from the start of a workflow. Feel free to join me on this blog in my exploration.
