Nobody likes to be in debt, but money and time are scarce when you're getting started, and whether it's student loans or technical debt most of us have a hole to climb out of. You can ignore it but debt is a beast which feeds on inattention. The challenge for a start-up is that even when you're paying attention it's hard to know how to prioritize the debts you're facing. When a client's team was struggling for yet another week to determine which tickets on the backlog were the most important I was determined to help them find a way through.
Conversationally the problem seemed simple. Pick the tasks that provided the most value. But in practice it is much more challenging. What is value? Value to who? How to define it? How do you explain it? What's valuable to engineering may not be valuable to the business. We needed a simple definition that we could all agree on.
One difficulty is that engineers struggle to prioritize technically interesting problems over tasks that provide business-facing value. It’s natural. Don’t deny it. When I'm wearing my developer hat I do it too. The other challenge is that when you care about code every refactor feels important. So how do you decide?
Time for some soul searching. I had recently read First Fire All the Managers, a piece on flat management and intrinsic motivators. It argued that the way to get the best out of your people was to make them all managers. While chewing on that it occurred to me. Take it one step further. What if everyone was an owner or investor? Typical investors won't even talk about something unless the return is at least 3x the intial investment, so why should we? What are we investing? Time.
The currency in engineering is time but devs don’t usually consider ROI on time concretely when prioritizing. So I took this back to the client, "Don't do anything that doesn't have at least a 3x return. Prioritize what remains by what provides the greatest return in time or dollars for that time." In our next meeting I suggested each engineer put on an investor hat and to prioritize tasks accordingly. I was optimistic but even I was surprised by how well this was received. The payoff was immediate. Priorities ceased to be arbitrary. Many tasks ceased to be relevant at all. It changed the context of everything we were doing, from the way we approached what to refactor, to whether we wrote tests at all. Discussions of refactors with the business became much more productive and challenges we had in defending to the business what technical debt we needed to pay off and when fell away. Having a concrete threshold made all the difference.
This spread quickly from a way to deal with technical debt to how we approached looking at everything they did as an engineering team. The irony is that despite having introduced the rule myself it was easy to forget. Joe, one of the lead developers, took it up as his banner and became its consistent champion. Time and time again it cut debates short about what to do next, and saved them on many occasions from sinking effort in to tasks without sufficient value. It's become a permanent tool in my belt and I have Joe to thank for that. Here's to you Joe.