A couple of weeks ago Emilia Bell published The problem with solutions, an interesting take on some of the problems with the management mantra I encountered a lot in my earlier years in the profession: Don't bring me problems, bring me solutions. Emilia explains fairly succinctly why this is a dumb thing to say as a manager, but it reminded me that this is one of the reasons that at my work people do something they think is helpful, but is actually not: they bring me solutions, when what I want is problems.
In my current role at MPOW, I manage a team of technical specialists. They have expertise in web development, library discovery systems, open education, and digital file management. We manage the library discovery systems, configuration for the library service platform, and the library's websites, amongst other things. One of my enduring frustrations is that despite this pool of expertise, when colleagues come to us for assistance they usually articulate a specific task they wish for us to perform rather than asking us for advice on how to achieve a desired outcome. That is: they come to us with solutions, rather than problems.
There is always a well-known solution to every human problem—neat, plausible, and wrong.
I'm not sure exactly why this happens, but I have a few theories. Partially, it is probably due to the experience some people like me have had with managers telling us to come with solutions, not problems. Partially it is a lack of understanding of–or perhaps respect for–the expertise of the team. And partially I suspect it is an unfortunate side-effect of too many keynotes telling librarians we're geniuses who know everything.
What exactly is expertise? I think perhaps a misunderstanding about the answer to this question is at the heart of the problem I experience. Intuitively we assume that "expertise" means knowing lots of solutions. Engineers know how to build bridges. Comedians know how to tell jokes. Computer programmers know how to write high quality code. Librarians know how to organise and find information. But I think this is a mistake. What expertise brings, more than knowing the solutions, is understanding the problems.
Civil engineers know how to build bridges better than you because they know a large number of things that can make bridges collapse. Experienced comedians can more reliably make people laugh than the average person because they have a lot of experience telling jokes that fell flat. Good computer programmers know a lot of ways that code will make your computer hang, or expose you to security problems, or work, but very inefficiently. Anyone can think of a possible solution, but it takes domain expertise to understand all of the possible problems.
This is why the powerful professions of every society always overestimate their ability to understand problems and provide solutions. Medieval Europe had it's Church Fathers. Soviet Russia had its technocrats. Our current moment has Silicon Valley tech bros. These are people who articulate solutions without understanding the problems outside their own domain expertise.
The best results come when people responsible for providing solutions have a clear articulation of the problem, consult widely about their proposed solution, and receive clear information about it based on experience and knowledge, rather than merely opinion. There is a good reason that the software industry often bases feature development around "user stories" in the formula "As a [type of user], I want to [do something] so that [desired outcome]". But for those of us working in maintenance rather than development, we need a different model. Perhaps an expansion, like: "As a [type of user], I want to [do something] so that [desired outcome], but [experience] makes this difficult because [reason]".
A request like this would allow my team to develop a potential solution and go back to the team requesting a fix to check whether this actually resolves the problem they have identified. We understand most of the possible problems within our domain (mostly technical). They understand most of the possible problems in their domain (often social, or technical in a different domain). It is then a matter of finding a solution that resolves or avoids both types of problems. But it is only by including all the relevant domain expertise that we will find a suitable solution: only considering the technical, or the social, or some other single type of expertise, will result in a "solution" that is at best sub-optimal. We need and want our colleagues to identify issues with the way we're doing our work. Those issues are likely problems identified from outside our own domain expertise – that's good! But the solution to that problem may well come from outside the domain expertise of the person who identified it. In other words:
Don't bring me solutions, bring me problems.