Every day we have to determine how to spend our attention, one of our most valuable and finite resources. I like to make sure I’m spending my attention effectively so I try to attend to the highest-value work whenever possible. One way to determine which work meets this bar is determining whether it’s a trend or just an event.

As a development team, there are probably more issues that require your attention than you have time for in a given day. To stay focused and productive you usually have to undergo some sort of prioritization of what to work on at any given time. Prioritization implies intentionally ignoring something in favor of another. If your to-do list is self-contained and just for you, consider yourself lucky, picking one thing over another is likely easy and frictionless. However, most of us don’t work in a vacuum, we work on a team, potentially with other teams, all within a company. Working with others means that our prioritization list can be driven by requests, questions, and needs that originate from outside us.

I try to maintain some consistency of responsiveness, especially for others who rely on me. I also attempt to focus on one thing at a time as much as possible and so I have to make tradeoffs. Making these tradeoffs means some asks are deprioritized more than their requestor would prefer. I’m always trying to be effective with my time so to avoid working on the task with the loudest champion, or the job that looks the most fun I use a loose set of heuristics to help me prioritize.

One of the ideas that I use when determining what I should work on is what I call “Trends not events”.

Everything that we do and everything we experience is an event…something happened. We experience them every moment of our day. Sometimes those events pull you in because they are around an interesting problem. Other times it’s a most vocal customer. Whatever the source, they are hard to ignore especially if they’re right in your face. Sometimes you have to respond, to a software outage or a high-value customer about to churn, but most of the time an individual event should not upend everything you are doing. Instead, look for events that are part of broader trends like “Are the same customer concerns recurring or even growing across our entire user base?” or “Is this pain point in the developer experience costing the team hours per week?”.

To accurately answer these questions, you need to be tracking this information before it becomes a problem. Not every trend is created equal. That’s why we measure. If you’re tracking important trends before there is an issue you can see how much of a problem it is and how it compares to other priorities. Now you have a historical record backed by data to help inform your decision and respond appropriately. Without this, decisions can be driven by any of mixture of gut, emotion, fear, greed, and more.

Save yourself from this kind of decision-making. Pay attention to trends and wait for events to become one before abruptly changing course prematurely.