The Problem with "Bring Solutions"
I wrote a while back about framing problems with proposed solutions - the idea that "this is broken and here's what I think we could try" lands better than "this is broken" on its own. I still think that's mostly right. It builds trust, it shows you've thought past the complaint, and it gives whoever is listening something to work with.
But I've been thinking about where that advice breaks down.
When "bring solutions" becomes an expectation - not just a good habit but a requirement before anyone will listen - it filters the problems people are willing to surface. Easy problems come with obvious fixes. Hard problems don't. If every issue needs a proposed solution attached, people will bring you the ones they can solve and stay quiet about the ones they can't. The organization ends up with great visibility into small things and almost none into the big ones.
I've seen this play out in a few places. Someone notices a pattern: maybe a system is quietly accumulating risk, or a process is producing results that nobody is checking, or a team's workload has shifted in a way that's going to cause problems in six months. They can describe what they're seeing clearly. But they don't have a fix. Maybe the solution involves budget or authority or coordination they don't have. Maybe they don't even know what the fix would look like - they just know something about this is wrong. Under a "bring solutions" culture, that observation stays in their head. The problem grows until it forces itself into the open on its own terms.
That's the same dynamic behind situations like the inherited NAS that nobody could shut down - someone probably saw the risk early, but raising "this RAID 0 array running our financial system could fail at any time" without a funded migration plan doesn't fit the "bring solutions" template. So the risk sat there, accepted through inaction, until it became someone else's emergency.
There's a power dimension to this too, even if it's not the main issue. Senior people can walk into a meeting and say "I think we have a problem here and I don't know what to do about it" and get taken seriously. More junior people raising the same concern without a plan attached tend to get told to come back when they have one. The policy applies unevenly depending on who's speaking.
The distinction that matters isn't whether you have a solution. It's how specific your diagnosis is. "Everything is terrible" isn't useful. "This specific system has this specific risk and here's the evidence" is useful, even without a fix. The value is in the identification and the specificity, not in having the answer.
If you're a manager, make it safe to raise problems without solutions. You can ask people to be specific about what they're seeing without requiring them to also solve it. Separate the diagnosis from the treatment. Some problems need a working group, or a budget conversation, or expertise the person raising the issue doesn't have. Requiring them to propose the fix before they can name the problem means a lot of problems never get named.
If you're the one noticing something, the useful thing you can do is be precise. Describe what you're seeing, when it started, and what makes you think it matters. That kind of specificity is what an early warning system looks like in practice. The original advice - pair problems with proposals when you can - is still good. The part I'd add is: when you can't, say so, and surface it anyway. The worst outcome isn't raising a problem without a solution. It's the problem that nobody raises at all.