Defending “Never raise a problem without a solution”

I want to offer a soft rebuttal to the article The Problem with Saying “Don’t Bring Me Problems, Bring Me Solutions. By “soft” I mean to say that I do not disagree with the thesis, only some of the implied assertions. Bear in mind that critiquing “Implied assertions” can be deeply unfair in a work that is intended to be taken literally. 

The substance of the article covers a particular phenomenon typical of poor leadership that should indeed be stopped, but begins with the lede of: “It’s time to retire the saying ‘Don’t bring me problems, bring me solutions.'” Writing good ledes is hard, but sometimes the goal of creating a punchy opening sentence can frame the article’s thesis in a way the author may not have intended. As it stands, I am forced to interpret the rest of the material as attempting to defend this opening statement, though I know it was most likely only meant to grab the reader’s attention. Furthermore, the article was written for a general audience, but I am framing it through the lens of a software developer, which may exacerbate the unfairness of a rebuttal.

Taken out of the context of the article’s critique, “Don’t bring me problems, bring me solutions,” can be a very reasonable request. If you are a software developer commenting on just about any aspect of developing software, it is a firm requirement. I have echoed this sentiment countless times when observing code reviews. For example, “This code is bad,” will not help your reputation, but “This class deals with two concerns, and needs to be broken apart to increase expressiveness and cohesion,” will win the respect of everyone in earshot. 

A software developers’ job is to solve problems, and if your only value is to identify problems, it is hard to take seriously a claim that you are good at your job. In fact, there is a name for people on software projects who bring up problems without solutions: Testers. If you are not a tester, it is implied that when you find problems, you either fix them or have a good suggestion for how to fix them.

There is a variation of this phrase that sounds the same, but to my ear has different implications: “Never raise a problem without a solution.” With the former phrasing of “Don’t bring me problems, bring me solutions,” it implies a weak leader shut off from reality who wants all of the hard work to be done by someone else. In the latter, there is someone who cares enough about the problem to at least try to think of a solution on their own before bringing it to someone else. That demonstrates ownership of the problem and a willingness to take accountability for the solution. Even if your framing of the problem and suggested solution are rejected, you showed initiative and a positive attitude. 

The article goes on to advocate making “Problem statements” over “Complaints,” but I believe it’s difficult to fully understand a problem without giving potential solutions a fair amount of consideration. This is not to say you have the best possible solution, but you at least tried to think of one as you were formulating the problem. 

When you bring the “Problem statement” to the group, and you’re asked, “So what do you think we should do,” the article – from my perspective – appears to make two assertions that I do not believe are universally valid: 

  1. An individual cannot think of a better solution than a group, and therefore should feel disempowered to propose a solution.
  2. The individual who thought of the solution is necessarily the wrong person to execute on the solution, and so should wait for a selection of “the right person/people” and should only take action if they are selected.

It can be argued ad nauseam as to if these are actual claims, but in my reading, these are at least implied. You are free to reach your own conclusion after reading the article. At the risk of rebutting claims the author might argue were never made, I will proceed as if the author intended these assertions.

The first claim effectively neutralizes the role of a sole expert in a group, which, from my perspective, perpetuates the current trend of anti-intellectualism, sweeping corporate culture in favor of groupthink. This trend is most visible in the emphasis on group brainstorming over individual research and cognitive diligence. 

The second claim trends to being false as the number of people in the group decreases. The smaller the group that frames the problem, the potential solutions, and then executes on solving the problem, the more likely it will be only one person filling all three roles. Furthermore, in many cases, the person who can best define the problem is the person who is in the best position to solve it

Ultimately, I think the article is a must-read for leaders but should be taken with a grain of salt for software developers who are professional problem solvers – which is to say all software developers. Taken too literally, it takes away the accountability of the person paid to solve problems from thinking of solutions.

2 thoughts on “Defending “Never raise a problem without a solution”

  1. I’m not sure I entirely agree with your claim that the article implies the person doing the problem identification shouldn’t be also the problem solver. I think it, more precisely, leaves the role of assignment of tasks to the team lead or project manager to prevent freelancing on issues as that tends to cause increased risk and lowers efficiency. As to who is the best to think of solutions, it seems to argue that this would depend of problem complexity. For example, a problem that involves both the database and the front end is identified by a person with strong skills in the project front end but very limited experience with the database. Although they identified the problem, the knowledge of what they should do about it probably shouldn’t be left to them since they may lack the experience to come up with a complete solution. They may be involved though due to their strong experience on the front end.

    • Your perspective seems perfectly valid to me, and I may very-well be misinterpreting the author’s intended meaning.

      It’s difficult to figure out what the implications of an article are when the author doesn’t make a clear assertive claim to which I can either agree or disagree. Indeed, attempting to refute what I perceive to be an implication could earn me the title of being overly-sensitive – which may in fact be true. I considered not writing this post for that reason: it felt unfair to take up an opposing position to that which the original author did not claim to make.

      In the end, I felt that it would be useful to explore the implications of the article as it might spark a conversation around the high-level idea of “Never raise a problem without a solution.” I like the concept of taking accountability for a problem rather than saying, “The group will handle it,” but as you point out the complexity of the specific problem has to be taken into account.

Add your thoughts