Don't bring me solutions, bring me problems!
Left on a whiteboard at a Google event, probably by an American Collegue!

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:

  • Missed Opportunities: Nothing is 'broken', but something is not happening that means we miss out. Jane sells tea towels door-to-door, sometimes customers ask for dish cloths instead. If Jane had dish cloths, perhaps she could sell more stuff.
  • Risks: Nothing is broken, but something is happening that could result in something really bad happening. Most of Jane's customers pay with cash, so she is carrying a lot of cash when she's walking the streets.
  • Morale Drains: Nothing is broken, but something is happening that makes people uncomfortable or unwilling to do the job. Sometimes people are so offended at being disturbed by Jane knocking at their door, that they yell at her.
  • Process failure: Something is actually broken, and we can't do the thing we said we were going to do. Jane should be able to take credit cards, but the device she's been given to do it doesn't work.

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:

  • Park it: Talk it through, does this really impact the organisation? What would be the cost of fixing it vs the benefit? Maybe we just need to come to peace with it?
  • Escalate it: We can't solve all the problems, sometimes we have to ask for external help.
  • Share it: A problem shared is a problem halved. Sharing problems with other people or groups can offer solutions, but it can also just build rapport, help others to see they are not alone, or form the basis for a broader collaboration. As Ian says in the comments, it's also a great 'coachable moment' for team members :- "Great point, that is a problem, if you were me, what things would you suggest?"

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!

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.

回复
Stuart Payne

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."

Leeroy Mathias

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!

Ian McDonald

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.

要查看或添加评论,请登录

Tom Grey的更多文章

  • Auras, NFTs and the Problem of Scarcity in Digital Assets

    Auras, NFTs and the Problem of Scarcity in Digital Assets

    "Aura" and authenticity in art In "The Work of Art in the Age of Mechanical Reproduction", Walter Benjamin writes on…

    2 条评论
  • Readymade Day Dreaming with Stable Diffusion

    Readymade Day Dreaming with Stable Diffusion

    I am very lucky to be able to walk every day and day-dream! As I walk, I sometimes snap photos of things I might use in…

    10 条评论
  • Don't sell propellant instead of payload

    Don't sell propellant instead of payload

    When you are launching a rocket, you generally have two types of things you send up into space - 1) the things you want…

    3 条评论
  • How much is 'enough' Technology?

    How much is 'enough' Technology?

    Someone asked me the other day: how much technology the businesses in Launchpad should have? Of course, I gave the…

    7 条评论
  • What is Career Progression now?

    What is Career Progression now?

    Someone was asking me about career progression, and it triggered me to think about what that means nowadays. I was…

    15 条评论
  • Leading in Agile Organisations: Structure

    Leading in Agile Organisations: Structure

    This is second part of my series on things I've learnt leading teams in agile organisations. In the first part, I…

    10 条评论
  • Leading in Agile Organisations: People

    Leading in Agile Organisations: People

    I've been reflecting on the things that I've learnt in my career so far about leading in agile organisations. I started…

    14 条评论
  • Hard and Soft Skills for Solution Architects

    Hard and Soft Skills for Solution Architects

    I was recently asked what I look for when I'm hiring new Solutions Architects and I thought it was interesting enough…

    18 条评论
  • Quantifying opportunities together

    Quantifying opportunities together

    Historically, "qualification" was something that sales people did to prospects. They lined them up, judged where the…

    8 条评论

社区洞察

其他会员也浏览了