THE DELEGATION PROBLEM
Newsletter sent on Monday, Oct 24, 2022
Faced with a new product development project, you will want to involve more managers, designers, engineers, or other experts to further design the solution or carry out tasks at some point. Intuitively you want to narrow the scope of inquiry with each delegation level. You have a problem, and the solution seems to be to do A, B and C, so you may reframe those pieces of solution as new problems before pushing down the delegation chain.
That’s in line with conventional wisdom, which often emphasizes the dichotomy between problem and solution. Problems are thought of as well-defined isolated short statements and solutions – recipes that practically guarantee a result. With both of them on hand, verifying a match is easy, like checking a jigsaw puzzle by comparing it with a picture on the box.
This simple model works well for telling a story about solved problems or making minor improvements to existing solutions. But it’s insufficient for solving complex or novel technological or business challenges that look more like riddles than jigsaw puzzles.
Hence, it’s a mistake to delegate a problem without full access to the whole background of objectives starting from the very top business goal, which (surprise, surprise) you may not even fully realize yourself.
Here’s a small thought experiment. Imagine that this plan has to be carried out by a group of people.
- Need to expand to adjacent market
- New product developed
- Go/No go decision on a specific idea
- Validated data from the target audience
- Demoable prototype
- Pick features that can trigger feedback
- Build document search and dashboard
- [Something-something] search engine and dashboard
- [Something-something] to implement a search engine and dashboard.
Now imagine Alice responsible for #3 - #6 and want to delegate #7 to her team. They begin working on “how”, which puts them face to face with hundreds of design choices. If they can’t understand and use the business context comprised in objectives #1 - #6, the only way to make those choices is to fall back on a mix of prior experience and widespread ripped-out-of-context “best practices”.
What could be a small project of tight collaboration between design, engineering and Alice, resulting in a compact system perfect for a series of quick self-service demos with some customization slack, becomes a quest to solve a problem that is not on the list. The focus is not on the ASAP start of interviews to clear #4 but on tuning the search precision, recall, cluster scalability and dashboard latency to satisfy the assumed requirements of #8.
Setting a tighter deadline won’t solve this. Pushing down “hows” won’t help. Hours of PowerPoint presentations won’t make a difference, but here’s what will.
Gather people responsible for several levels of the problem in one room and let them build the problem-solution list together.
They can do this by:
- Starting with the objective that seems the most important at the moment;
- Asking “why” to broaden the scope, reveal structure, uncover assumptions and understand validation criteria;
- Asking “how” to narrow the scope, face choices, determine needed specialized knowledge and get closer to a solution.
This process will unearth connections between lower and higher levels of the list and transform them into a map. With this map, your team can make much better judgements.
