Other People's Problems

Apropos of nothing, this post came up in my Mastodon feed and odd enough, it reminded me of a topic I’ve kept in my bag of unfinished thoughts.

Here’s a longer quote from the 2016 Politico article:

“It’s called OPM. I do that all the time in business. It’s called other people’s money. There’s nothing like doing things with other people’s money,” Trump said. “Because it takes, the risk, you get a good chunk of it and it takes the risk. We’re going to do this, in this case, from a humanitarian standpoint.

“OPM: other people’s money.”

– Politico, “Trump: ‘There’s nothing like doing things with other people’s money’” (09/20/2016)

Other than acknowledging the above quote, I will leave that behind. Unlike “Other People’s Money”, rules around “Other People’s Problems” (OPP) go the other way: you are taking on risk through managing other people’s problems. It happens all the time.

What’s Interesting About OPP?

First, an article on ‘bullet journaling’ titled “Why You Need a WTF Notebook”:

There’s always stuff that makes me go “wtf” on a new team. The team talks for an hour in retro about a serious problem, and then leaves without making any action items. The tests don’t run locally and no one seems to notice. Big chunks of the build board are always red. Only one person can do some critical, time-sensitive thing. The team is spending a bunch of time on some feature, but when I ask around no one can seems to know why it’s important or how it’ll help a customer.

In the article, Nat goes on to list the ways he categorizes these things (i.e. “other people’s problems”) and how he systematically tackles them.

On the management side, Camille Fournier wrote a post named, directly enough, “OPP (Other People’s Problems)” describing ways to understand problems you were meant to fix and how to decide ways to tackle them. The steps here are helpful, but I want to focus on a different aspect of this topic.

What Is Even Going On?

Early in my career, solving problems I cared about seemed to inextricably coincide with solving other people’s problems. Later, I noticed a few cases where my problems and other people’s problems were not aligned. “Why is this important?” I would wonder. “For who is this problem important to solve? Does the outcome mean the same to me as it does to them?”

Other people’s problems come in two flavors: your company’s problems, and your manager’s problems.

Your Manager’s Problems

Your manager’s problems may be a subset of the company’s problems (cf. meeting the goals for this quarter versus delivering on a long-term strategic vision), or they may reflect your manager’s personal concerns. In the latter case, managers may see their teams (and you as well) as an extension of their career prospects – the vehicle through which they might meet a metric to be measured. That metric may be quantitative (e.g. “increase customer retention”) or qualitative (e.g. “maintain a good relationship with other departments”).

Your Company’s Problems

You may find it unjust to invest time in solving your manager’s problems when they don’t coincide with a company objective, yet I wouldn’t dismiss the importance of these problems out of hand. Let’s take a hypothetical, yet not unrealistic, case:

Your manager asks you to take a few days to debug an issue you are certain is unrelated to your code. You surface this to your manager and they understand it might be a waste of time, but they mention some other team feels frustrated by this bug and is certain your code is the cause. Your manager asks you to stop doing current work and look into this anyway. While this isn’t a company priority, you tell yourself, your manager seems particularly set on you spending your time looking into it.

Reading the tea leaves, it’s possible your manager feels the optics of spending time looking into this issue will make some other teams feel better. Maybe another team has been complaining the loudest and this exercise is meant to show that your manager takes issues like this seriously. Maybe everyone else is at an impasse. It’s hard to know, especially if your manager is reticent and is shielding you from the politics of the situation.

Seeking clarity from your manager is always a good idea in this circumstance. But if you don’t get the clarity you seek, thinking of this as an OPP situation can help you triangulate what the actual problem is you are there to solve and how it can relate to your actual problems. Does the way you approach OPP build credibility with stakeholders you do care about? Is there a missing operational component (e.g. monitoring, tracing, information gathering) you can add to the mix that solves a problem you care about while also addressing your manager’s problem?

The ideal is for every company problem to be your manager’s problem, and similar to your problems and your manager’s problems. But it’s not always the case. Going back to the blog posts above, there are good strategies for tackling these.

By any other name…

At the face of it, “managing up” involves understanding your manager’s needs, guiding them to make good choices, and building a good relationship with people up the org chart. Because many people can ship the right thing at the right time, but mess up on, say, messaging, and get lost in the shuffle. So you manage up. It’s a thing.

But managing up is also a form of OPP. How your manager operates and their particular set of problems is often idiosyncratic, and worth understanding. Maybe your manager is insecure about their position and requires a constant flow of status reports to feel that work is being done. Maybe they are mostly hands-off and need space to digest things in advance.

Regardless, to be effective at what you do and being good at problem-solving, some of these problems may be presented as your problems. You can ignore, delegate, or solve them, but regardless, they are a form of OPP.