Move the problem solvers closer to the problem to be solved

Problem solvers are best suited to solving problems. They come up with solutions, they soundboard them off each other and then they converge on what seems like the most viable, feasible and desirable solution based on the information that they have.

Problem solvers in the software world include but are not limited to:

• Software & DevOps Engineers
• UI/UX Designers
• Product Managers
• Data Folk

Give them context and I’d bet — with a little savviness in the team and close collaboration — 99 times out of a 100, they’ll come up with a fantastic solution to the problem framed based on the context they have around the problem to be solved.

And, the times they don’t come up with a fantastic solution, it’s likely that they’ve got 2 or 3 other solutions that they didn’t end up choosing that are likely to solve the problem, it’s just that they plumped for something else. It’s also highly likely that plumping for that “something else” isn’t an irreversible decision so some harm, but not major harm done.

That all sounds quite easy then if you’re accountable for such a problem being solved, right? Get a team together, frame the problem and then give them autonomy and ownership. Think about the next problem to be solved and then rinse and repeat.

And it is easy — but the baffling thing is that, again, the vast majority of those accountable for problems being solved don’t do this — they put the problem solvers far, far away from the actual problem being solved. They do things like:

• adding in project and programme managers
• adding in business analysts and quality assurance engineers
• creating business requirement documentation and throwing that over the fence
• sending solutions over email or inputting them into tools like Jira with no context of the actual problem being solved
• telling them of an area to “explore” then giving them a deadline and a vanity metric
• bringing them in for status meetings that are then tactically used to influence the solution and muddy the context waters

…and every time that happens, you get outcomes like the ones depicted in Jeff Gothelf’s blog on the pitfalls of “projects” where prescriptive tasks are handed down like Moses on the mountain; and the problem solvers are so far removed from the actual problem to be solved that they may as well be freelancers working remotely across 9 different timezones.

Hey team, here’s the solution to the problem I may or may not have full context of.

Next time you have a problem to solve:

• assemble a team
• provide as much context as you can
• set some guardrails such as time-boxing
• get out of the way

…and see the difference it makes.

If you follow Dan Pink, you’d know that mastery and purpose are critical to the right outcomes being derived but so too is autonomy.

Without autonomy, you’ve got yourself a bunch of lemmings that will trudge off the edge of a cliff — and they won’t be coming back.