Dan Cowell Engineering Manager
Osaka, Japan (mostly)

Photostream

A model for thinking about problem solving

Published Saturday the 11th of December, 2021

Everyone solves problems on a daily basis. It happens subconsicously. We employ strategies to understand our world, identify and solve problems. It is a huge part of the human condition. Why do we need a model to understand something we intuitively know how to do?

Metacognition is a catchall term for "thinking about how we think." More specifically, metacognition involves thinking critically about our thought processes, evaluating them and developing our understanding and performance.

Building a model helps when talking about these complex and abstract processes. This becomes even more critical when reflecting on the problem-solving process in a group setting, such as in a team at work.

This model can be applied to understand your own problem-solving process, and that of a team. It is particularly helpful for teams, as it highlights where effort should be spent for maximum impact when tackling complex problems.

In the examples below I apply the model to solving technical challenges, howevever you will find it applies to most creative problem solving endeavours.

What is problem solving?

Fundamentally, problem solving is the process of taking an abstract problem, exploring the solution space and finally implementing a concrete solution.

Abstract
Abstract
Concrete
Concrete
Viewer does not support full SVG 1.1

When faced with a new problem the solution space starts infinite and is quickly narrowed down to a few tentative solutions.

As you develop your understanding of the problem, possible solutions and eliminate the known unknowns, you build confidence in your solution. Your confidence grows as more effort is invested in validating your approach and implementing your chosen solution.

Tentative
Tentative
Confident
Confident
Viewer does not support full SVG 1.1

The cost of change grows exponentially as you invest more resources in a concrete implementation. It's easy to change direction when all you have is an idea, it is substantially harder (and more expensive!) once resources have been spent building and deploying a solution which needs to be discarded or heavily modified to be fit for purpose.

Cost of change
Cost of change
Viewer does not support full SVG 1.1

Putting it all together

We have defined the main dimensions of our model. Next we need to evaluate where we are spending our resources and how we can optimize for efficiency and impact.

We do this by plotting a line that approximates how we have invested resources over the lifetime of our project. These resources may be financial, time, effort or whatever makes sense for your project. An ideal allocation may look something like this:

Abstract
Abstract
Concrete
Concrete
Viewer does not support full SVG 1.1
Tentative
Tentative
Confident
Confident
Viewer does not support full SVG 1.1
Cost of change
Cost of change
Resources invested
Resources invested
Viewer does not support full SVG 1.1

In this hypotheical project, the team invested time up-front exploring the problem and running thought experiments to narrow down the solution space. Everything was on the table, and the cost of change was zero.

The team investigated some tentative solutions and discarded obviously bad ideas. Those that remained were still pretty abstract and lacking in implementation detail. More work was needed to refine them.

Little time was spent early in the project on academic research and exhaustive documentation of each idea. The ideas presented needed validation, and that required testing.

The team hacked together safe-to-fail proof-of-concept implementations which were cheap to build and easy to throw away. Most of their effort was expended testing prototypes and validating assumptions before the cost of change grew too high.

After finding a solution that was fit for purpose the team committed to a concrete implementation and the cost of change skyrocketed as it was implemented into the product.

Using this model in your team

This model can be useful to guide project retrospectives in a team setting. It is particularly well suited for teams who have jumped into solution space too early, built the wrong thing and need to get back on track.

Note that this retro requires that the team either already recognises that they went too deep too fast, or has a facilitator present who can help them see it and guide them towards next steps. Applying it in a team who don't understand how things went wrong without guidance may result in even more confusion!

Start the retrospective by drawing the abstract/concrete dimension and cost of change graph:

Abstract
Abstract
Concrete
Concrete
Viewer does not support full SVG 1.1
Cost of change
Cost of change
Viewer does not support full SVG 1.1

Ask each member of the team to draw a curve that shows where they think the team spent the most time while working on the project.

Pick a different colour of pen and ask the team to draw another line showing their confidence in the solution over time.

After each team member has had a chance to draw their lines, take turns going around the room and asking each member to share their perspective on the differences or similarities between the lines, and if they feel like their time was well spent throughout the project.

Ask if, given the chance, the team would change how they allocated time and resources in light of the cost of change curve. What would they change?

Look for and discuss peaks and troughs in the confidence line. Ask the team what they could have done differently to ensure a steady growth in confidence over time.

Remember, this is only a model used to facilitate conversation. It isn't a project management methodology, and all teams will have their own results. Every problem is solved under different constraints, so remember the golden rule of retrospectives: we truly believe that everyone did the best they could at the time, with the knowledge they had and the resources at their disposal!


This is the first post in a series about how teams can talk about problem solving. In future posts I'll be breaking down the three phases touched on in today's example and what common team dysfunctions look like through the lens of this model. Here's a teaser for what's up next:

Validation
Validation
Ideation
Ideation
Implementation
Implementa...
Cost of change
Cost of change
Resources invested
Resources invested
Viewer does not support full SVG 1.1