Don’t bring me solutions, bring me problems

Picture courtesy of Liz Henry@flickr

Title of this post is a paraphrase of great quotation, namely “Don’t bring me problems, bring me solutions” which is or rather should be sometimes used by project leaders and product owners (also referred as managers later in this post). However bringing problems to Scrum Master is a very good idea – some problems are out of your control, especially those managerial ones (but this is a subject for separate post).

We, engineers, are taught to solve problems and we do it right. We are creative and intelligent people, hungry for non-trivial puzzles to solve. We should receive problem as an input and give solution as an output – that’s it (of course we need a lot of communication in between, clarifications, details, etc.).

Why managers/leaders/product owners sometimes treat developers as machines to write the code? Why they don’t trust developers and don’t believe they really have knowledge and skills to solve many business and technical problems and turn them into working software? Why don’t they accept the fact that when development team encounters any problem they will try to solve it and if they fail they will let them know.

Of course, it’s not fair to say that every manager and leader has such mental problems I described above (I was lucky for most of my professional life) but let’s focus on guys that really think they know everything and thus kill team’s creativity.

Where all think alike, no one thinks very much — Walter Lippman
Imagine such situation: as a developer you are asked by your manager to implement some new features. You discuss with her the details, input/output, UI, whatever… When you are done and you know roughly what to do she starts describing you how she would like to have it implemented. She talks about technology, about probable problems you may encounter, about technical decisions you have to take. Basically she gives you one of the solutions just like that.

What would you think after such conversation? Personally, I’m getting furious inside because I’ve just been treated like brainless, thoughtless, whaterverless coding “professional”. I always wonder why they need me if they don’t even want me to think. I feel useless after such conversation.

You just got the problem to solve but a second after you also got a solution (to be more precise PROPOSAL of the solution). If I think like my manager it seems I don’t think too much – if I try to modify her solution (which is likely to happen because I have other ideas and I know technical constraints better) I may have problems during yearly evaluation… You know, people often treat their ideas like their children – would you dear to say your manager’s child is stupid? I don’t think so.

Suggesting solutions kills creativity
It’s true – suggesting solutions drives you to them, even if you would invent something more creative and smarter. If you hear about the possible solution to the given problem you are somewhat contaminated by it and it’s really hard to get out-of-the-box. It’s really hard to think about all technical consequences of such solutions because when you hear them you may think “Hmmm, that could really work – it may be a good idea”.

Suggesting technical solutions to engineers is sometimes dangerous. Manager’s solutions can look good at first but as manager is not “deep inside” there and doesn’t know all technical constraints they can lead to serious project’s delays. I know about many such managerial “solutions” that were very crappy; “solutions” by which teams were loosing precious time. These “solutions” were not stupid or bad – not at all. But those solutions didn’t take into account many technical aspects managers couldn’t know – only developers knew about them (see tacit knowledge).

Don’t bring me solutions, bring me problems
Most of the times development team members know better how to solve problem given by product owner or manager. If you are product owner you should focus on the feature from the user’s perspective – development team will deliver you technical solution. Even if you have some ideas you should probably wait with telling about them until developers ask you if you have one. Giving or suggesting technical solutions to engineers is example of micromanagement IMHO and should not be emulated.

Product owners/managers – bring developers problems, not solutions. If you bring engineers solutions it means that you don’t need them. And it’s not nice to be a developer then. If I feel useless I will not deliver good quality stuff and I will probably start looking for another – more challenging – job. Engineers need responsibility, they need to be owners at least of their solutions.

Next time when someone from the management or product side will give you problem together with solution just tell them that if they are so smart they should start developing it themselves. They have everything they have to know. If you think it’s too drastic solution just tell them “Don’t bring me solutions, bring me problems”

What do you think? Should managers give us solution or only the problems? What is the value of such managerial “solutions”?

6 thoughts on “Don’t bring me solutions, bring me problems”

  1. Managers and architects can produce slideware (in powerpoint), but unfortunately there is no ppt to asm compiler :). Few times I got a really cool slides for some very hardcore problems, which occurred useless of course, but maybe someone had an illusion of doing something important.

  2. I fully agree with your points; mangers can always suggest a probable solution but that should not be enforced at the end of it solution given during requirement gathering should be taken with a pinch of salt and developer can later analyze the problem with his perspective and if he finds a better solution or discovered that what manger says is not possible so he should inform the manger of same.

    Cheers to you for nice post keep the good work; how seldom I get such things to read 🙂

  3. Excellent post, thanks for taking the time to write it.

    I find myself in this situation fairly regularly; in fact it got to the point that I asked my superiors if I’m not meeting their expectations as an engineer. They assured me that their expectations are satiated, to which I asked the following: “Then why don’t you trust me to work these problems?”

    The answers varied from apologetic to a condescending “I only want to make sure this gets done right.” Regardless of their response, I wind up feeling, as you describe, like a powerless, useless, keyboard-monkey.

  4. If no one would be lazy or ignorant we would live in a wonderful world where managers wouldn’t have to provide solutions for problems. Unfortunately many engineers have poor problem solving skills or try to avoid problems at all costs so managers have to impose a solution to make sure the problem gets solved.

  5. Why do you hire such engineers? Fire them! If I was unable to solve problems I get I would leave my company by myself.

    If you hire poor engineers it means that your hiring process is even poorer.

    But there is a seed of truth in what you wrote – this world is not perfect

  6. If you are unable to get skilled engineers (for example, because all the top guys are already working), you might be able to help you engineers develop. In fact, I consider coaching being one of the direct [line] manager responsibilities.

Leave a Reply

Your email address will not be published. Required fields are marked *