Do I think we should fix every problem that someone on my team points out? No.
Do I think I should always be the one to consider the tradeoffs and make the decision? Also no.
I’ve seen a huge amount of wasted talent and human energy that I could connect to someone asking ‘how can we fix this?’ and repeatedly hearing ‘we don’t have time for that right now’.
Every time that happens, the problem stays the same and the people get a tiny bit worse. A little more accepting of the status quo, a little less likely to speak up.
(You’re probably thinking that I’m talking about Giant Enterprise companies. Yes, and – also fast-growing smaller companies, where the urgent repeatedly crowds out the important.)
As a manager, I’ve got a limited number of “no, there’s nothing you can do about that today” cards to play before I demoralize folks. I’d prefer to save them for when it’s really necessary.
Instead, I prefer to suggest one or more of these five tactics that an individual contributor can use to attack the problem. Any of these can be time-boxed to less than a day.
The 5 problem approaches
They give someone a way to thoughtfully consider “Do I still want to fix this?” If yes, they have more information with which to take a next step. All without me having to suggest solutions!
Know the problem
Have you ever complained about something without even realizing why it annoyed you? (Yes, you have. Humans do this all the time.)
The first thing you should do is ask yourself: “why is this situation/process a problem?”
- Is it slow, so you feel like you’re wasting time?
- Is it error-prone, so you’re spending additional time fixing bugs?
- Does it feel error-prone, so even though it rarely breaks, you’re stressed while you’re using it?
- Does it increase ambiguity, so people have a hard time aligning on a goal?
- Is it unpredictable, so you aren’t sure how to allocate time/energy to it?
I am often surprised by how frequently naming the problem goes a long ways towards solving it.
Get the history
Why does it work this way? What decisions led to this situation? Start with some ‘verbal padding’ (“I’m curious, you’ve been here longer than I have…”) and then ask.
Sometimes there is a good reason behind a process that makes you say “ohhh, now I get it, this makes more sense to me now”.
Sometimes you’re doomed to work within constraints from a terrible decision made in the past by people who no longer work here. Well, at least knowing that information keeps you from blaming your coworkers.
I separate ‘context’ from ‘history’ because it’s possible to know the latter without the former.
How does this process fit into our overall workflow? How much headspace does anyone devote to it? What other pieces/people does it touch?
If you’re going to change something, it’s high risk (though maybe high reward) to change something that is central to a workflow or touches a lot of people. Knowing that tradeoff may lead you to shrug and decide you can live with it. It may be easier to fix a problem that no one else is devoting mental energy to – though you’re unlikely to get any credit for that.
List your assumptions
The best way to get through “I don’t know where to start” is to force yourself to write down what you do know. List out your assumptions. Think up some questions. Write out relevant facts.
Once you have something written down (a “something to react to”), then you can share it with peers. Nine times out of ten, your coworkers will have answers to some of your questions and have comments of their own. You’ll turn “I thought I was the only one who hated this” into “hey, maybe we can hack something better together real quick…”
Brute force it
A surprising lot of problems have a one-time high friction cost. It may seem overwhelming and awful to manually de-dupe three hundred email addresses, and also, you can probably do it in Excel in less time than you’d spend complaining.
Another class of problems is not solvable through brute force, but going through a certain amount of repeat effort teaches you about the boundaries of the problem. With that additional knowledge, you can then more easily reason through potential solutions.
But what about focus?
Focus is what you work on. That’s different from how you work.
I’d rather someone spend a couple hours on any of these versus flat-out telling them “no, we don’t have time for this”. It doesn’t matter if the problem is small; it’s an inexpensive investment in problem-solving and a way to prevent learned helplessness.