Managers love frameworks to help think through problems and I’m no different. While trying to think of a way to reason through our engineering work I started grouping it into three major categories:
Should have been done yesterday. Self explanatory but these are the items that as soon as you discover them you wish they had already been done. Critical bugs and issues fall into this but also product oversights that you wish you caught earlier.
Has a deadline. Deadlines are an interesting topic and they only exist as much as you want them to. There are true deadlines - imagine wanting to release something in time for the Superbowl or South by Southwest - but more often they are self imposed in order to hit a specific date. A weak reason is to motivate a team but a better reason is to hit a launch date. In that case customers, partners, and other departments are involved and a delay would cause ripple effects across everyone involved.
Important but can slip. This is the work that’s important but not urgent. A delay of a week here or there will not determine the success of this project and will not have significant ripple effects. These are often infrastructure related with the goal of investing in the foundation for future work.
It’s useful to look at the work your team is doing and grouping it into those categories. If you have too much of the first it’s likely your team is either understaffed or not planning effectively. If you have too much in the middle bucket you’re likely not investing enough in the future and accruing unhandled tech debt. Too much in the last one and you may not be focused on customer facing products.
There is no correct distribution since it will vary from company to company and industry to industry but it is useful to track and understand the work. Companies that are more service oriented and have many enterprise contracts may have a higher proportion of deadline driven work. Companies that are more consumer focused may have most of their work in the important but not urgent bucket.
What is valuable is to see if you can shift work from one bucket to another. If a project has deadlines due to the multi-team effort involved is it possible to reorganize the teams so that it can be done by fewer teams? If you’re constantly discovering work that should have been done yesterday is there a way to identify the pattern in these interruptions and build a product to make them go away? It may not be possible but having a framework gives you a tool to at least think through options and may engender some valuable thoughts.