Don't bring me solutions, bring me problems!
Truth is subjective, it changes with perspective. When I was a new graduate, building my credibility as a subject-matter-expert, I used to hate managers who said "don't bring me problems, bring me solutions". It seemed so arrogant, and dismissive, and like a dereliction of duty, after all, my job was to escalate, their job was to be escalated to.
When I was a new manager, building a team, growing in confidence, I came to see the wisdom in "don't bring me problems, bring me solutions". Of course it was good to understand the problems, but seriously, I didn't have all the answers. Occasionally it was exhausting, one or two people seemed to do little else save bring little problems they had found, like dutiful cats presenting me with dead birds and mice. "Well done", I used to joke, "here are five more problems, we have plenty of problems, it's like shooting fish in a barrel!".
And yet, I was reflecting last week that actually "don't bring me problems, bring me solutions" is potentially very toxic. The worst thing you can do in an organisation is to make people perceive that they are only bring you answers, and that they have to keep other problems to themselves.
I may not have answers to all our problems, there may not even be answers, but I still want to know what is broken, I still want to know where we can improve.
"Problems" are not really one kind of animal. There are lots of different creatures in the problem-zoo:
When people talk about 'problems', we mostly think about the last sort, but actually my experience has been that most 'problems' are actually one of the first three sorts.
领英推荐
I've come to think that what really matters with "problems" is what you can do with them, or equally, what is the consequence of not doing something with them.
There are lots of things you can do with problems, solving them is just one possibility.
Of course, everyone wants to solve problems, heck, that's what we do, we are problem solvers... But actually, often that's not what's needed. For instance you can:
Within the agile set of frameworks, a backlog is a great tool for capturing and acknowledging these problems that we are either unable or unwilling to solve, or that we will solve, just not yet. As Ian pointed out in the comments, Agile also advocates the use of root cause analysis, using frameworks like the "5 whys". Without such techniques, we often solve the wrong problem - if poor Jane in our example above got mugged, we can use root cause analysis to determine that we need to fix her credit card reader, not give her karate lessons.
I hope you found this interesting and/or useful! Let me know. Just remember, problems are great, so don't be stingy, don't keep all those great problems to yourself!
Consultant
2 年If you hire someone and all they ever do is bring you problems, you might wonder why you'd bother. Unless you're hiring a lawyer whose specific job it is to get very critical about the shortcomings of a contract or deed, surely what people want is productive employees who identify problems, but because they are solution oriented, bring solutions to you as well. If I hire a tradesman and they add no value, I consider the exchange to have been a waste of time and money. I also don't expect them to get very far in life because the market rewards productive people not obstructive ones. Apply the same to everyone you deal with, and you'll understand the wisdom of the phrase.
Talks About - Business Transformation, Organisational Change, Business Efficiency, Sales, Scalability & Growth
3 年Great post?Tom, thanks for sharing!
Bill Gates used to advocate having a corporate culture where bad news travels upwards. Another Microsoft adage was "It is better to fail and know why, than to succeed and not know why."
Structural Mechanical Engineer at Medgulf Construction Co W.L.L., Qatar
3 年Great stuff Tom! Some different ways to go about for it sure with all the options you mentioned- parking, escalation and sharing. Well written!
MSc BSc PGCE Dip CEng MIET CPhys MInstP MBCS CITP; ISEB Test Practitioner; Former Mayor; Consultant. Conference speaker. SC cleared 2024. Semi-retired. Open for audits, training, short test / QA / PM contracts.
3 年Interesting Tom. The reason I use “bring me solutions...” is to stop the discarding of responsibility. I usually say, “I want to know about problems, but before you do that, stop, think and bring also (if possible) 3 potential solutions and your recommendation. We can then discuss and adopt one or come up with a 4th. There is also the issue of cost benefit.” Now the reason for this is to train staff and make the point that spotting a problem is one level, solving it is another! Cost benefit also helps with training- realising that spending has to save or bring some other benefit. On a couple of occasions I have developed new products as solutions. In one instance the new test product sold more sets than the product it tested! Root Cause Analysis, is a pet subject at the moment. The problem with Scrum is that the retrospective often fails to really examine root causes and is really not effective at improving quality. Part of the reason for this is poor training, which escalates with each new generation of Dev lead.