(How to) Be Solution Oriented

There's a piece of advice I've often heard regarding being successful in your job. Actually there are a lot, but the one I'm think of is that you should not bring problems to your manager, and instead bring solutions. Or more generally, focus on solutions instead of problems. Sounds great. I even see this happening a lot in practice. People will run into problems and then start trying to work around them. Also great.

There's always a but

But what about when a problem keeps recurring? What about a problem that never gets a solution? I've seen two reactions. One is to keep repeating the expensive and unreliable work around. The other is to try to ignore it. A more preferable third option is that you bring the problem to your manager. Then your manager gets you more resources, or gives you some authority to make changes, or puts it on some other manager that already has the resources and authority to fix the problem.

It's rare that I see anyone take my preferred solution, and even rarer that I see it work out the way it seems it should. What happens instead is the manager suggests some thing or other to try as another work around, or some short term way to minimize the harm. Or maybe they call a powwow with the team to spend an hour brainstorming new workarounds and minimizations.

There's a very good chance that when the manager hired the team, it was based on job descriptions that required things like "being a self-starter" or "taking initiative". And that's what's happening. Everyone is taking it upon themselves to solve every problem they can. If I bring a problem to my manager, it's because I already tried every solution that I have the authority and capability to attempt (and maybe a few others besides, because getting forgiveness is easier than permission). At this point, I'm not looking for advice or ideas. I'm looking for my manager to exercise their superior resources and discretion because if I had a solution, I would be doing that. I'm bringing you the problem because I'm out of options. If in the process of my explaining the problem to you, you actually come away with the impression that I haven't exhausted every option, then go ahead and double check. But when every response I have is along the lines of "I would but I'm not allowed." or "I tried that, it doesn't work." then please stop doing my job and do yours instead.

Bringing a solution

I wrote most of this post on the 4th consecutive day of "the environments being down". Meaning development and QA environments. It's a frustrating problem which happens entirely too often, and no one who is affected by it has both the ability and authority to fix it. But instead of just continuing on in this rant, I'll instead try to explain how I think this should work, and why that would be better. And like any good software developer, I'll start by applying an off the shelf solution. Shutl had a very detailed write up on the topic. The cliffnotes version has 3 parts.

1. Expect people to fix the things that make their job difficult.
2. Empower them to make changes beyond the normal scope of their team or project or department in order to implement those fixes.
3. The pace and quality of their work improves in a surprisingly short period of time.

You could point to any number of explanations for why this improves the work people do. My explanation is that they have more agency (which is a very good thing, and a topic for another time) and have to switch context less often (or are less distracted if you prefer). Specifically, many distractions become tasks in their own right, and are then focused on and resolved so they won't reoccur. The time spent on any given surprise change in context may thus be quite large, but the time lost to switching contexts is minimized, and over time the number of unplanned distractions falls so low that you come out way ahead.

If you need an incentive that is more digestible to a business audience (business in this context meaning the department that funds other departments), Sumologic has a more concise post on the topic. They go into much less detail, but the story is the same: Do what needs to be done to solve recurrent technical problems; produce a better product in less time and get happier customers. The Sumologic post is mostly about production support, but the concept generalizes to just about anything that gets in the way of actually building software. It could be technical debt, difficult product deployments, or (my personal favorite example) unreliable test environments.