Off your plate ≠ Done
Here's an all-too-common failure mode when optimizing a workflow: optimizing for the time it takes to get something off your plate as soon as possible:
How fast can you reply to an email in your inbox and put the ball in the other party's court?
How quickly can you submit the code for a feature you’re working on, so that someone else has to review it?
How fast can you perform the first pass on a document review before handing it off to the next stage?
For the email example, writer Cal Newport goes into great detail: If work unfolds haphazardly via back-and-forth messages, knowledge workers drown in a flood of messages. Their instinct is to do the minimum amount of work required to punt that message, like a hot potato, to the next person to deal with.
The problem is that this is rarely the way that optimizes for the overall time it takes for an item to actually be completed. You trade temporary relief from the full inbox for even more work, rework, and back-and-forth messaging later down the road:
The vague email that was lacking context and ended with “Thoughts…?” will produce countless more emails asking for clarification.
The rushed code will cause the reviewer to waste time pointing out all the issues and will force you to work on the same feature again.
Errors in the first stage of a review process will slow down or outright jeopardize all future steps.
I’m reminded of the saying, Slow is Smooth and Smooth is Fast. Other relevant pieces of wisdom:
Measure twice, cut once
If you’ve got an hour to chop down a tree, spend 50 minutes sharpening the axe
Don’t just do something. Stand there. (As in, observe the situation and come up with a good plan first)
I was especially reminded of these ideas when talking about certain software development best practices where a lot of folks say, "Oh I don't have time to write tests." I challenge that and say, "No, you don't have time not to." By skipping these crucial things you're optimizing to get the thing off your plate as soon as possible but chances are it will create more work for the reviewers and more work for quality assurance and it will certainly create regressions when someone else starts working on that part of the codebase because they need it for their future.
So don't do the laziest quickest thing in the moment. Do the thing that lets you be efficient in the long run.
