Important but Not Urgent
Maintaining standards of excellence
I’ve been thinking lately on how to ensure the execution of work that is important but not urgent. Because this work is not urgent, it will always get de-prioritized in favor of more urgent, pressing needs. However, because this work is important, if no one does it, then standards of excellence slip a bit. And in my experience with software development, when this type of work is consistently put off, the system as a whole suffers, engineers slowly adapt to their worsening conditions, and it becomes harder to execute on any type of work at all.
Suppose you've dedicated 20% of your resources to doing the work that is important but not urgent. But if you are constantly being bombarded with urgent and important requests (this is great— this means you are highly valued!), then that 20% is going to disappear pretty quickly.
So then, how can we make sure that we do the stuff that is important but not urgent?My answer is we must make it as easy as possible.
This means:
(1) Clear instructions for how to execute this work: When people are finished fighting the latest fire or are taking a breather, it should not take a lot of effort for them to context-switch into this new task. Engineers should be able to glide right into coding, if that’s what they want.
(2) Legibility into the system: Work that is important but not urgent is going to be executed in a start and stop manner— fewer resources dedicated during hard times and more during easy times. And so it is important to always know the status of the work to track progress.
To achieve these two goals, you will likely have to regularly spend time and attention pursuing them. And so while the people executing this work may come and go, my conclusion is that we need to have someone or something constantly watching and monitoring the system.
