There’s a rule out there, circulated widely as conventional wisdom, that you should never bring up a problem in the workplace unless you have a proposed solution.
For example, consider the following excerpt from this Inc. Magazine article, Eight Things Great Bosses Demand from Employees:
Rule 6: Provide Solutions, Not Complaints. Complainers are the bane of your boss’s existence. Nothing is more irritating or more boring than listening to somebody kvetch about things that they’re not willing to change. So never bring up a problem unless you’ve got a solution to propose–or are willing to take the advice the boss gives you.
The argument goes that if you just bring up problems, then you’ll be seen as a whiner, as a complainer who drones on endlessly about problems that can’t be solved or that no one knows how to solve.
The question: is this a good rule?
Let’s take an old example from my career. It’s 1990, you work at Ingres which is $250M division of ASK, and you compete in the relational database market against Oracle, who is about $1B. You are getting your ass kicked up and down by Oracle in the RDBMS market. Management is silently executing a retreat strategy into the application development tools market and worse yet, your parent company, ASK, is betting all-in on a new version of Ingres 4GL that only works on the Ingres DBMS for their next-generation ERP system.
Here are some darn good problems:
- Oracle is killing us in the DBMS market.
- We are moving into tools when “runtimes” are increasingly free and there is no money to be made
- We are double-downing on a proprietary, unstable application development environment instead of using standard tools
- ASK is suffering from a serious escalation of commitment problem and should not double down on a dying database business.
If you followed the “don’t bring up a problem without a solution” rule then you could never talk about any of these problems. And they are only the most important problems facing the company (and that would ultimately lead to its undoing). What if, for example, you ran sales and had no idea what application development tools the company should be using, but simply knew which it should not? Should you make up a bad solution just so you can talk about the problem?
I can take more recent examples of similar no-easy-solution problems:
- What do we do about the Internet? (At Business Objects in 1996, when we were 100% Windows client applications.)
- What do we do about NoSQL? (At MarkLogic in 2009 when we were a closed-source non-relational DBMS into a strong open-source trend.)
- What do we do about Zendesk? (At Salesforce in 2012 after acquiring Assit.ly and mistakenly seeking synergy vs. trying to use it in a major blunting initiative.)
Let’s look beyond the business environment and see some problems that we couldn’t talk about if we followed the rule:
- Mid-East peace
- Cancer
- Global warming
“Sorry Jimmy, if you don’t know the solution to global warming then you shouldn’t bring it up because you’ll just be whining.”
Obviously, I think it’s a stupid rule.
The correct rule is: don’t whine.
It turns out the hardest problems, the most important problems, often have no obvious solution. So if you prohibit discussing them, you cripple our organization and limit discussion only to easier, more tactical matters, akin to re-arranging the deck chairs on the Titanic.
Problems are the price of progress. Don’t bring me anything but trouble. Good news weakens me.
– Charles Kettering
Great quote
Dave — good post and good examples. I still think the expression has a lot of life left. In professional services, you just can’t point out weakness or brainstorm without having good suggested solutions. Sadly, the vast majority of clients are not Charles Kettering.
Couldn’t agree with you more. Ben Horowitz does too in his raw new book “The Hard Thing about Hard Things”. Many employees in an organization don’t either have the knowledge or experience to make recommendations but they can sure see problems which we want to surface not suppress due to a lack of a quick fix. The implications of the “solution” to a problem of the scale you describe are too big for a simple problem/solution model.
I’ve always felt the point of the quote was to remind us to be active participants in finding solutions to the problems we face collectively, rather than place all responsibility onto others. To your examples, an appropriate response (per the quote) might be something like “Hey guys, there’s a big problem we need to tackle, let’s break down the problem into its constituent parts and come up with a strategy” vs “None of this is working and we’re headed for disaster, someone better do something.”
Pingback: June 2018 Newsletter - The Renegade Coder