Last week Aaron Snyder (@aesny) talked a bit about our process for hiring engineers. This week he shares some thoughts about how to prioritize the problems you need to solve.
As an engineer and team lead, my day is spent solving problems. For me the problems range from cache invalidation schemes to motivating clients to work differently. At times it can be difficult to decide which problems are worth solving and which aren't. But here’s a thing I’ve learned: save your energy and don't act until you see a pattern.
Solving every single problem is expensive. Try solving only the problems that occur twice or more in close proximity and then prioritize the most recurring problems. This method should completely eliminate “solving” mistakes, and concentrate efforts where they matter most.
This approach works well both in managing a team, and managing a codebase.
When managing a codebase, one of the hardest endeavors is expressing the value of refactoring code to non-technical clients. I get it. It just doesn't make a lot of business sense to spend money fixing something that works when it could be spent on new features. For this reason I find an elevated importance in choosing the right features to fight for refactoring. Which features do I focus on? The features that have the highest occurrence of technical debt relative to their importance.
People problems are arguably more sensitive to "choosing your battles." Solving people problems often comes at the cost of ruffling feathers.
Do we really need a to chew a teammate out for being late once in a while? What do we actually gain from taking every opportunity to point out "that's not agile" before we even let the other person finish?
I know I have been guilty of both. What really happened was I paid the price of social friction, lost respect and really didn't solve any problem of importance. That's not to say that being late or abandoning agile methodology aren't problems worth correcting. It just means that there's nothing lost by waiting for a pattern to emerge.
The easy math behind prioritizing any problem is:
Priority ~= Importance * Frequency / Cost to Fix
This formula focuses your efforts and bubbles important, frequent, cheap problems to the top, while less important, infrequent and high cost problems sink to the bottom. Have a ton of problems that are a mix of those attributes? This formula helps to find your way through the fog.
Give it a try. Prioritize the most problematic patterns and see if it makes work a bit easier.