There’s a rule out there, undoubtedly made long ago, and circulated widely as conventional wisdom that in the workplace you should never bring up a problem 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: 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
- 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.