…and why you may be asking the wrong question(s)

I get into a lot of discussions that center around decoupling “problems” from “solutions”. The topic comes up most often when trying to define roles and responsibilities, and workflows (e.g. how early should Person-Team-Functional Group X get involved with Initiative Y)

.

It dawned on me the other day that these conversations are often missing the point…they’re avoiding the elephant in the room. It is easy to talk about handoffs and make broad “build the right thing” vs. “build the right thing right” proclamations, and much harder to ask:

Is it working?Because when you boil the issue down, there is typically a lack of confidence regarding outcomes. The whole discussion is a proxy.

Yes, sometimes I do hear someone say:

You know, our company knocks it out of the park every frickin’ time. We’re doing amazing work. I see the value my work brings to humans every day. I just wish I had a little more say in how we solve the problems.…but this is very, very rare, and most often in the healthy context of someone trying to craft (or advance in) their personal career.

So what happens is that you get into elaborate debates about frameworks, process change, methodologies, the org chart, and the history of certain roles (e.g. “well design has always been ….”). Instead of stating bluntly:

I’m all for solutions, but our solutions could be better.Or

You are an awesome subject matter expert, but a not-so-great designerOr

I really respect your sales skills, but I have a bit more practice in conducting ethnographic researchOr more personally…

I’m not sure you know/respect the depth of my expertise in this area. Sometimes I feel my contributions are diminished. I’m sure this is unintentional. I’d love to talk to you more about [some area of expertise]The proxy discussion misses an important point. Great solutions require diverse perspectives, experiences, expertise, and collaboration. Dividing up the organization into problem framers and problem solvers isn’t a great long term tactic. It may help in the short term — but you’re chasing a local maximum in terms of generating outcomes.

Why? Firstly, the vast majority of problems are nested solutions/tactics to a higher level problem. Unless the “problem” you bring to the team is “long term financial success of the organization”, there will always be a network of assumptions around causality, impacts, etc. So problem statements tend to be constructs that prematurely narrow the solution space, and can obscure the real impact of the work. Four lines of code can be a “problem” and a solution. A four year strategy can be a problem and a solution. No matter where you are operating, you’ll want to link the work to the highest level goals of the organization.

Second…why is it best to send people off into their respective corners? You’re avoiding really learning how to work together, to share data/context, to respect areas of expertise, and to exploit healthy creative tensions when they arise. This is HARD WORK, and not something you can represent with a RACI diagram (shudder). What would it take for a problem framer to contribute to a solution, but saunter away when they had nothing valuable to add? Or for a senior leader to swoop in to add valuable data, but do so in a way that was not inadvertently intimidating, or creativity sapping (the accidental HIPPO).

So… short post here, but here’s the gist:

1. Make safety a prerequisite. You’ll need it to have the tough discussions.
2. Then, try to have the real discussion about whether things are working. Don’t get bogged down in the theoretical proxy discussions. Reflect deeply and honestly about outcomes.
3. Then, have the discussion about what areas of expertise are necessary to improve those outcomes, respecting the fact that not everyone will know exactly what you do, or what you can offer (and vice versa). Consider also that you don’t need to be an expert to be able to contribute value. For example, business-non-designer-types can contribute great data in co-design activities, provided they realize that they probably aren’t contributing the end-solution.
4. Then, figure out how to really work together such that it amplifies those skills, shortens feedback loops, and allows people to contribute at the right time, and in the right capacity. And figure out a way to strike the fine balance between push and pull involvement, knowing full well that this will vary by effort.