Don’t bring me problems, bring me solutions

Or a fence you may not have heard of

TL;DR

If you’re on the receiving end of “don’t bring me problems, bring me solutions”, reframe “bring solutions” as “engage with problems before communicating”. 

If you’re a manager, stop yourself from spreading management-speak memes. Unpack them for yourself and your team so that folks are clear on what’s expected and why. If you want your team to bring you solutions, help them engage with the problems.

A red fence in a field (source)

---

It’s 2023 and managers are still telling their reports to bring them solutions, not problems. This week someone in RLS shared their confusion and frustration at receiving this “feedback” and it sparked me to explore this often heard and just as often maligned management speak.

If you google for the phrase, you’ll find a pile of posts advising managers not to use this as an operating principle with their directs. This post by Sabina Nawaz published on HBR in 2017 covers four negative consequences of the approach:

1. Important problems may require a pool of talented people to solve.

2. Promotes advocacy culture instead of inquiry/curiosity culture (come into meetings to argue that your way is right vs come together to find the best way forward)

3. Shuts people down. Puts fear into the environment.

4. Hides problems

Before throwing this solutions-not-problems idea onto the management-speak trash pile (it’s a pretty big pile) it’s worth exploring why it came to be.

And that brings us to a short diversion. A few days ago I was listening to an episode of Adam Gordon Bell’s podcast CoRecursive about why 80 columns is the standard limit for code width. In the episode, he introduces Chesterton’s fence. Here’s Chesterton:

The more modern type of reformer goes up to the fence and says, I don’t see the use of this fence. Let’s clear it away. To which I reply, if you don’t see the use of it, I certainly won’t let you clear it away. Go away and think, and then when you come back, tell me what you do see the use of it, and I may allow you to destroy it.

I had not encountered Chesterton’s fence before, but the model resonates with me. I like the nudge towards curiosity and understanding. For this topic of solutions not problems, Chesterton’s fence even suggests an alternative: bring understanding of problems, not just solutions.

So what’s the case for solutions-not-problems? This post by Jim Schleckser published on Inc argues that as a leader it is important not to jump straight to solving problems for your team. While solving problems is something that most leaders are good at and enjoy, taking this approach will train your team to be lazy thinkers. You’ll miss the opportunity to level up your team by having them come up with at least one option. If you push your team to bring solution options, you’re giving them opportunities to learn and you’re creating an environment that will scale. If you solve your team’s problems straight away, over time your list of problems will only grow.

While a bit overly centered on the needs of the leader, the intention of building capability, independence, and helping your team solve their problems (vs being the solution source) is worthy of support. We want teams of problem solvers, not a funnel of problem collectors going to a single point solution person.

Do not find fault, find a solution. -- Henry Ford

I couldn’t find any authoritative source for the solutions-not-problems principle. Could it have originated from Henry Ford and that era of management thinking? It feels aligned to the spirit of the time, but quotes taken without context are easy to assign meaning to. Here’s another example from my rabbit hole. This one more modern and less charitable. I have no idea who this person is or how I ended up at this forum website.

screenshot (source)

Hampshire’s perspective is one in which managers have to learn their employees out of their lazy ways. And while the earlier arguments from Jim Schleckser above have a genuine positive aspect, they also tie back to an underlying view of “boss has the answers” and employees will be lazy unless you push them otherwise. Ironically, Schleckser wrote a book called Great CEOs are Lazy, but I was too lazy to read it. 

The lazy employee scenario is not one I’ve ever experienced in my career and I’m not sure it’s real. I prefer to believe that people generally want to do good work. L. David Marquet’s Turn the Ship Around is a good counterpoint to the “people are lazy” perspective -- it’s a great read if you haven’t encountered it.

What can you do if you find yourself in a situation where you’re receiving a “bring me solutions, not problems” message from your boss? Are you concerned about being perceived as “brings problems” and not “brings solutions” even if your boss isn’t sending this message directly? Here are a few things you can do when you identify a new problem.

Rewrite “bring solutions” as “engage with the problem”. Invest in understanding the why of the problem (Chesterton’s fence) and then explore and record possible solutions. Engaging with the problem means thinking through how the situation arose in the system and considering its overall impact. It can help you to choose your battles, refine your perspective on who should own the problem, and who is impacted. And it will build empathy for your boss or whoever you might end up asking for help or giving the problem to. 

Spend some time exploring and recording possible solutions. Even if you believe the problem is not yours to solve, there’s value in working through how you might go about solving it. If you’re in the position of recognizing a problem that others haven’t, your unique perspective may be a part of the solution. You might be convinced that all of the options you generate are dead ends. Keep track of them anyway. And flesh some of them out anyway. Sometimes a seemingly terrible idea “just might work”. The goal isn’t to have a solution, but to engage with the problem in an active way. When you’ve done this, it will show through when you go to communicate the problem to your boss or whoever you think should own this problem.

If you’re in a leadership role and find yourself wishing your team would “bring solutions, not problems”, refocus your energy on figuring out how you can support each individual team member to engage with the problems at hand based on the context and their level of experience.  Don’t be lazy in how you communicate. You are responsible for fostering an environment in which your team can do their best work. It’s up to you to ensure that purpose, expectations, and constraints are clear. Before repeating management-speak, especially something that has mutated into an easy to repeat meme, stop and unpack what you have in mind. Find a way to share a more detailed picture that reflects your unique perspective and context with your team.

I’ll end with an example of sharing such a detailed view of a management concept – and one that presents an alternate formulation of “solutions, not problems”. In his post on Completed Staff Work, Jade Rubik adapts and clarifies how a doctrine of completed staff work that originated in a military command context applies to a technology organization. I love how he’s constructed an iterative version of Completed Staff Work that encourages collaboration and makes it safe to not have the solution right away as well as placed Completed Staff Work into a larger model of delegation. Perhaps all of this will help inspire you to explore the next management meme you encounter and make it useful by making it your own.

Thanks for reading!