.png)
2 hours ago
2
Story time. I used to live in a rented townhouse across the street from a mansion. One night, its inhabitants hosted a flamboyant outdoor pool party / rave with many guests, a professional DJ, and no regard for how their actions might be impacting others. In the wee hours of the morning, our walls and floors were still reverberating from the music, loud screams were heard, and guests were seen climbing onto the roof of a car.
Knowing that my next door neighbours had just come home from the hospital with a newborn, and wanting to get some sleep myself, I called the police; in my jurisdiction, amplified music is illegal after 8pm. What do you think happened next?
Nothing was done, of course, and the reason why is worth considering. It was a Friday night. All kinds of violent and/or petty crimes were being committed, and the police were doing their best to prioritise. In the grand scheme of things, a noise complaint seems rather quaint when compared to an armed robbery. Effectively, their strategy was one of "greedily" allocating capacity to the highest priority items. What could possibly be wrong with that? The problem is that by choosing not to act on the "lower priority" noise complaint, they effectively repealed a law they had a mandate to uphold. I am not here to judge the people who attended the party (I'm sure many of them had a great time!) nor the police (I guess they allocated their scarce resources to the most pressing concerns). But this story does illustrates how a prioritisation decision that seems completely reasonable in isolation can result in unintended consequences -- in this case, a failure to prevent and/or punish antisocial behaviour with downstream impacts on the health and happiness of others.
Bringing it back to building software, many of us have been confronted with a similar challenge: how do we decide what to work on? If we strictly work on the most urgent task, then less urgent (but still important) items such as bugs, technical debt, etc. will never get fixed, just like noise laws never get enforced, rendering them effectively non-existent. And just like in the real world, this can have unintended consequences -- development velocity stalls as engineers get stuck in a quagmire of unresolved technical debt, customers get fed up with all the bugs and churn.
What can be done to prevent this? We have two options: accept it and live with the consequences, or adopt a portfolio strategy that focuses most of our resources on the most valuable problem to be solved, while reserving some capacity for important, but lower priority, items.
Here are some approaches I've seen in the wild:
Time allocation: reserve 1 day per week for non-urgent but important work (example: Technical Debt Fridays)
Human allocation: dedicate 1 person to a particular kind of task for a week (example: Datadog's practice of having on-call engineers work on operational improvements rather than features)
Team allocation: create a dedicated team to handle a particular kind of task (example: Gergely Orosz's writeup on platform teams)
Zero tolerance: prioritise important work over urgent work to prevent it from building up in the backlog (example: Linear's zero-bugs policy).
On my team, we simply bring in at least one technical debt or operational excellence ticket every single week; any engineer can propose one, and depending on capacity, we may decide to pick up more than one. This has been working well for us so far, in that we've managed to consistently ship new capabilities while simultaneously keeping technical debt at bay and improving our standards of operational excellence over time. While there's still room for improvement, I'm proud that we've been able to significantly reduce the amount of time spent on toilsome manual tasks and reduced the on-call burden to the point where even early-career engineers on our team felt comfortable joining the rotation.
What about your, dear reader? Have you grappled with prioritisation challenges of your own? How did you balance the urgent versus the important? Let me know on Twitter or on LinkedIn.
