Eating soup with forks

We need you to build a fork. We have the budget and it’s approved for development. When can you deliver our fork?

A Company Executive / Line of Business

And we respond affirming the request.

We’ll have that done by next quarter (or some other timeframe that may or may not be reasonable).

The Execution Team

An order has been placed. The solution has been defined and the team responsible for building it may or may not know what problem the fork is supposed to solve. But somebody somewhere decided that this was the answer.

The problem is in the mindset. We budget for solutions. Instead, we should budget for problems.

This isn’t another essay on why you should fall in love with the problem. (If you haven’t heard that cliché before, let me google it for you.) I am advocating a change in how we approach our work and the impact that has on resource allocation, budgeting, and planning.

Everything should be made as simple as possible, but no simpler.

Albert Einstein

The problem with solutions

When we focus on solutions, we place our trust in someone’s judgment — that they know what the fix should be. Frequently, this is someone that’s on the front lines, an executive, or a small group tasked with defining requirements.

Even when we have someone explore the problem and devise a solution, they often focus all of their energy on a single idea. This is the magic bullet approach. We take a shot and move on — regardless of whether or not we hit the target.

Consider the soup fork.

Someone points out that we have a problem eating soup. It’s messy. We occasionally burn our nose or fingers trying to get it from the bowl to our mouth. We suck at eating soup.

Someone has an epiphany that if we only had a fork, we could eat soup so much better. And they’d be right. We would keep our hands clean. Soup wouldn’t spill. And we’d be able to get those tasty chunks of meat and vegetables. So much less waste.

But what about the broth?!?!?! We’d be leaving behind the essence of the soup! Plus, forks are generally terrible with anything that can’t be stabbed.

Ignoring the broth problem, we race forward with the fork research. We convene a committee to define the requirements — the length of the handle; the number of prongs (one, two, three, or four?); and the material. We ask people which fork design they prefer and watch them use the different designs.

No one bothers to question if the fork is the right solution. We’ve been told by higher ups and that discussion is out of scope. (Where are your contrarians?)

With the requirements defined, we bring in the utensil builders and hand them all of our artifacts — sketches of the fork, high fidelity mockups, and possibly even competitors’ forks. You only hire the best utensil builders, but when they ask questions you dismiss them because your solution has been tested.

After six months, the utensil builders deliver the fork — assuming they didn’t get pulled off to work on a higher priority project. We deploy the fork and move on.

The fork-using soup eaters provide feedback that most of the soup is left in the bowl. But the committee has been disbanded and the utensil builders are focused on the next project. Still, someone promises them that we’ll make a better fork. Someday.

The focus on solution building has its own set of systemic issues that need to be addressed.

1. Resource planning. We need to keep the utensil builders busy. Because of that, we need to have shovel-ready work at all times. We can’t have any slack in the system.
2. Roadmaps. Related to resource planning, we need to know what they will be working on for the next 12 to 18 months. We also need to be able to communicate to the organization what will be delivered when. To manage this, we hire someone to manage a PowerPoint showing this schedule.
3. Half-built solutions. Inevitably, a project will be interrupted and the solution won’t be finished. Not only that, what has been built isn’t releasable. And by the time we could return to the project, the world moved on and the solution isn’t viable.

While there are other systemic issues, these are the most obvious.

The solution is in the problem

It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.

Steve Jobs

By prioritizing problems, we simplify our lives, our organizations, and the risk of building solutions to the wrong problems. We have the freedom to act from the position of humility. We don’t — and won’t — have the answers when we start. But we will be reducing the impact of the problem on the organization throughout the effort, not only at the end.

About that soup-eating problem.

Once we determine that improving the way we eat soup would have the greatest impact on the organization, we assign a capable team to focus on this. The team has utensil builders, soup eaters, possibly even a soup maker. We give them an initial time box of six months and tell them to make eating soup as easy as possible.

For the next six months, this team cycles through the following questions.

1. How do we know this is a problem?
2. How do we know this is a problem worth solving? (Will the affected change their behavior? Will someone pay for this solution?)
3. How do we know our solution worked? (Are the affected changing their behavior? Is someone paying us for the solution?)

It’ll go something like this.

How do we know we have a problem eating soup? Because we are in the soup eating business but can only seem to consume half of it, spilling the rest. We have soup eaters spilling it on the table, on their clothes, and burning their lips and noses when they put their faces into the bowl. We have a lot of waste.

How do we know this is a problem worth solving? The soup eaters are asking us to help. We also have the accounting department asking if we can reduce the cost of eating soup.

As we observe the soup eaters — even eating some soup with them — we notice that it’s served in a bowl. This leads to our first attempt at a solution.

First hypothesis: By picking up the bowl and drinking the soup from it, we can decrease the wasted soup.

With this change made we find that we are able to reduce wasted soup. They were able to consume most of the broth along with the meat and veggies. And we didn’t even have to build anything!

However, we still had soup eaters spill some on their clothes, and burn their lips. They also mentioned that they’d prefer to have a free hand when eating soup and lifting the bowl required two hands. Those that tried one hand spilled more and were more likely to drop the entire bowl.

Coming back from lunch at a nearby sushi spot, someone suggests trying chopsticks.

Second hypothesis: Chopsticks will reduce waste when eating soup.

This has mixed results. Yes, it helps with the solid objects, but does nothing to improve the broth situation. As a possible solution, the hypothesis is disproved.

The team keeps at it, interacting with the soup eaters and testing new hypotheses as quickly as they can. Within the allotted time for the project, they run several experiments. Some are disproved and others allow the organization to improve.

By the end of the allotted time, the organization is using an insulated cup. It’s not perfect, but has drastically improved the organization’s ability to eat soup.

At any point during the project, the team can communicate what they’ve learned and how we know the current approach to solving the problem is viable.

The organization has a simple decision to make now. Do we give the team more time to persevere or do we pivot them to tackle another problem? That depends on if improving the way the organization eats soup will have the greatest impact (aka value).

Budgeting to tackle problems, instead of building solutions, gives organizations more flexibility to adapt. This approach also simplifies the demands on the doers and the managers.

The simple life

A backlog, not a roadmap. Since we are budgeting time, we only need to maintain a backlog of problems facing the organization. This list is prioritized by the most pressing to the least important. Once a problem is no longer the highest on this list, we re-prioritize it and move on to whatever is on the top.

By managing a backlog, the roadmap becomes irrelevant. The information conveyed on the roadmap was a fuzzy best guess (aka lies), so trashing it will improve trust and moral.

Resource planning SIMPLIFIED! Teams will be perpetually productive. You won’t have to worry if there’s enough shovel-ready work to hand off. The only resource question you’ll need to answer is if there are enough teams to tackle the critical problems facing the organization.

Organizational agility. Gone are the days of waiting for the current project to be delivered (after months or years!) so that we can pick up the next solution. Or pausing the current effort only to have a half-built, never delivered solution that adds no value in its current state.

Instead, value will be delivered at the conclusion of each iteration. The organization will know more about the soup eating problem and likely have a better way to consume it.

Your organization will also be capable of adapting to new challenges and market changes as quickly as leadership can identify them.

Change the perspective

Since time is money, think in terms of time and not money.

Don’t ask how much is this going to cost me? Instead, say I’m willing to give you a set amount of time to reduce the impact of this problem as much as you can. At the conclusion of that time box, you get the freedom to decide if that problem is still painful enough to persevere or if you should pivot your team of experts towards more pressing matters (read: other problems).

How to lead problem solvers

The way to lead problem-tackling teams is different than how to lead any organization. It requires constant vision casting, constraints, and protection from distractions.

Vision casting. Why does your organization exist? What massive problem are you out to rectify? Similarly, if your organization ceased to exist, what would be the societal ramifications (to non-shareholders and employees)? Vision casting requires that you understand this and communicate it to everyone you encounter on a daily basis. If you need help with this, Start with Why by Simon Sinek should be your next audiobook (or you can watch the TED Talk).

Constraints. Your problem-solving teams will feel empowered if they know they have autonomy. They need to know what they can and can’t change without someone else approving it. To minimize this, the team composition is crucial. Make sure the team includes the appropriate SMEs — or has the executive air cover — to make the necessary changes to systems and processes.

Focus. Multi-tasking is terrible. It’s destructive to productivity. Protect your team from distractions by allowing them to be dedicated to this effort. Even protect your SMEs and executives necessary for the team to operate with autonomy.

In short, be clear as to why your organization exists and where it is going, how much power your team has, and that the team is protected from distractions.

tl;dr (aka the conclusion)

Stop worrying about how you can fit fork building into your budget. Instead, give your team of experts a set amount of time to improve your ability to eat soup.