I wonder how that sits with "Don't bring me problems—bring me solutions" that I occasionally hear from non-technical managers...

There is a need for both approaches. If you have the expertise to be able to diagnose the problem, asking for the problem to be solved is the right approach. When dealing with non-technical issues, where the person coming to the manager is familiar with the process, it makes sense to ask them to bring solutions (as a first step) instead of imposing something on them.

Extremely well.

Stakeholders are supposed to present problems to engineers, and engineers are supposed to propose solutions to stakeholders.

The underlying meta-rule is that problems should be solved by the person with the most expertise.

One of my best managers ever was non-technical. His line was, "you're smart enough to fix this, so do it, do it right, and don't let it happen again." He did a great job getting the resources to back it up, too, while shielding his team from company politics. Right up until the point where he lost at company politics, anyway.

I guess the trick is to be an expert in Machiavellian games and intrigue without truly holding the values that typically drive such expertise.

I had a very similar experince with a similar boss, and similar conclusion.

But yes, best manager I've had.

I appreciate when they bring me a problem with a suggested solution. It's often quite helpful in determining the best possible solution, and so far as I remember, they quite often got that solution implemented.

But before I started asking that, and just implemented their solutions, I got a lot of kickback for it not actually solving their problem, which is how I learned to ask it in the first place.

A problem without a suggested solution is a complaint. If your people only bring you complaints, it is a drain on everyone; it breeds discontent in the workforce and contempt in management.

I feel that some people are very good at seeing problems, and some people are very good at finding solutions to problems.

I don't see any reason that the same skills should be present in any given individual, so you always need both types.

To me its part of the taxonomy of becoming a more experienced developer:

- First you can implement solutions (jr level) - Then you can design solutions (mid level, sometimes senior - most of time is spent here) - Then you can find problems that need solutions (senior, management)

I understand what you are saying. How does someone who is good at seeing problems communicate those problems and not come off as whiny and complaining?

I often hear "Ugh, it's tiring you telling us what all the problems are, why can't you tell us the solution?".

But I get "Man, I'm so glad you saw that problem way back at the design stage. We really dodged a bullet there." about 3-4 times as often.

What I generally don't hear is, "OMFG, our project is about to fail. Why did no one see that this issue was coming and do something about it!".

The assumption that anyone noting a problem is just whining and complaining is a good way to tank a project. I've seen that type of thinking prevail, and it sucks for everyone.

The client bring the problem, the vendor brings the solution

The problem they think they need to solve is usually not the problem that needs to be solved. Hence the 5X (or more) to reveal the actual problem to solve.

I think this really old article addresses it better. It's self-explanatory.

Managing Complex Design Projects (1995) http://www.dubberly.com/articles/managing-complex-design-pro...

I just read through that. Asking questions and planning up front? Documentation before code? Thats so waterfall. (And it works quite well for some projects). Certainly having a problem that isn't clearly defined is a good way build something that doesn't solve the problem well.