The Problem With Problems

We've all been there. It's crunchtime and you're too busy getting things done to worry about the little things. Your job is to make sure the big things get done, and there are a lot of big things at the moment. When the mist clears, the product is shipped and the powers-that-be are happy, but you're not. You've been left with a flock of little problems that are still flapping about in the back of your head, and now you just can't be bothered. Rinse and repeat until you realise that now, the little things have grown into a big problem.

What Happened?

The problem with this vicious cycle is that, as a manager, you become callused to problems. You deal with dozens a day and you triage with the best of them, so you learn not to sweat the small stuff. This is good, it's a virtue to be unflappable in the face of a challenge, but it does present a complication. When are you dealing with the issues that matter, and when are you just avoiding the issues?

Like so many things, this becomes a balancing act we all have to learn for ourselves. There are a million frameworks for attacking these problems as well, like the Eisenhower Grid (it's not a matrix, I will die on this hill!) but the problem with frameworks is that I have to answer two questions about the problem before I can make a decision. With that amount of investment, I'd rather just do the thing! After thinking about it, I think I've managed to find a couple of heuristics and processes that at least help make a decision quickly and with minimal fallout.

Processes, Processes, Processes

Generally, the little things are the necessary things we must repeatedly do to get the job done. It is the form signing, email managing, question answering tasks that are a lethal combination of trivial and can be done later, but are ultimately still crucial. My benchmark is simply do the thing. Write the email, answer the question, sign the form. This seems an overly simplified solution, but it only works given one caveat.

You must have a framework for the thing.

The Idea of Frameworks

For the most part, frameworks predominantly account for resource allocation. For example, for email I ensure I have several dedicated mailboxes for certain things such as sales, operations and marketing, and I use a throwaway email address for anything that doesn't fit into those categories. This means that outside of certain dedicated mailboxes, I can ignore most of the unimportant mails we all receive regularly.

For answering questions, I have dedicated channels for questions that need urgent attention. If these channels are abused, I remove the people who do so from the channel. This seems fairly militant, but without boundaries, it's too easy to get sucked into a never-ending stream other people's work.

Ensuring that only the necessary distractions make it through to you takes time, but it pays dividends in the long run as you can focus on the things that actually move the needle.

The last thing is a very simple heuristic that requires just a little forethought. For any given project or phase, is there an ultimate goal? If not, describe one. Write something down that illustrates your core function in the project. Once you've done that (and it's actually quite shocking how simple our roles turn out to be when we tune out the distractions) you answer a simple question each time a small problem comes up. Is this thing necessary to the goal? If this thing has made it through every framework, it's usually easy to decide, and you purge it if it's not.

Dealing with problems is what managers do, but making sure they're the right problems is what separates great managers from the rest.