The Problem Solving Framework

Define your problem before jumping into immediate solutions

Jan 08, 2024

∙ Paid

Effective problem-solving isn't about jumping quickly into solutions; it's about solving the right problems in the right way.

Personally, I don’t like never-ending discussions, finding another blocker, or asking for one more requirement in your ticket. I prefer to move fast with limited information and some degree of uncertainty. I strongly believe in an iterative approach, where relevant data and good decisions emerge during the journey.

Yet, such an iterative approach only makes sense if we work on problems worth solving with the most optimal solutions to them.

Here, you can find a PDF cheat sheet that sums up this article.

How to Solve Problems?

For inspiration on building a problem-solving framework, I recommend the short, humorous, yet insightful book "Are Your Lights On" by Don Gause and Gerald Weinberg. This book emphasizes the importance of carefully defining the problem before rushing into solutions. It challenges readers to think critically, question assumptions, and consider multiple perspectives.

In organizations where the engineering team is viewed as a "feature factory", the discovery process can be perceived as wasteful. As long as software engineers don't produce something tangible (like pull requests or features), their work is undervalued. The trap here is the assumption that Product Managers, senior management, or the CEO have all the answers.

Side note: I have covered the true role of software engineers in empowered organizations in a few of my past articles:

In such environments, engineering teams come up with solutions too quickly. This isn’t surprising in the end, as they are inventors and creators with strong technical skills, often the only ones in the company who can build things. They are frequently assessed by what they produce, not by what they think through.

But here's the trap: in order to solve a problem, it must first be defined. If engineers jump immediately into the solution, it doesn't mean the problem is undefined. It means it's defined with some (hidden) assumptions, biases, and personal interests.

There is also another challenge with software engineers. If not jumping into solutions too quickly, they also tend to overthink their problems indefinitely, multiplying missing requirements, finding edge cases, and overall getting stuck in a quest for perfection.

What's the Problem?

In the complex world we live in, the initial solution is rarely the optimal one. Complex problems may have multiple definitions, none of which is ultimately the right one. A problem may have multiple stakeholders, each with their own solution, and these stakeholders may have different power to articulate their preferences (the loudest one in the room, the most senior on the org chart, or those who prefer to remain silent).

The book describes problems from a few different angles, For example:

A PROBLEM IS A DIFFERENCE BETWEEN
THINGS AS DESIRED
AND THINGS AS PERCEIVED.
—"Are Your Lights On"

This means that to solve a problem, you can either focus on achieving the desired state or change your perception of the problem. You can check the book for more ideas or continue reading for a systematic framework I came up with based on the lecture and my personal experiences.

The Problem-Solving Framework

Here’s a framework that will help both groups:

For teams that tend to jump into instant solutions, this framework provides perspective and support in problem framing.
For teams that overthink their problems, it helps narrow the focus to "just enough" information to start iterations.

Inspired by "Are Your Lights On", here is an 8-step framework to help find optimal solutions for problems faced by software engineering (or, more generally, product engineering) teams.

The 8 Steps of Problem Solving

Recognizing the problem (What’s a problem?)
Defining the problem (What are the facts behind the problem?)
Exploring the problem's depths (What are root causes of the problem?)
Identifying stakeholders (Who have the problem?)
Assessing the willingness to solve (Is it worth solving the problem? Is it aligned with broader goals and strategy?)
Developing solution strategies (What are options for solving problems? Which are the optimal ones?)
Implementing the solution
Monitoring and reviewing (Are success metrics defined and achieved through the solution?)

The 8 Steps of Problem Solving - Explained

Here are detailed descriptions for each step:

Recognizing the Problem: Acknowledge that a problem exists. This step doesn't necessarily require a deep understanding of the problem but recognizes that something needs attention.
Defining the Problem: Clearly articulate and define what the problem actually is. Gather and analyze data, synthesizing inputs to state the problem clearly and concisely.
Exploring the Problem's Depths: Look beyond the surface to understand the complexity of the problem. Conduct root cause analysis or interviews with users and team members, considering external factors.
Identifying Stakeholders: Identify all parties impacted by the problem, as well as those who will be involved in implementing solutions. Understand different perspectives and interests of these stakeholders.
Assessing the Willingness to Solve: Consider the pros and cons from different stakeholders' viewpoints. Decide if the problem is worth solving, considering factors like impact, business goals, and priorities.
Developing Solution Strategies: Brainstorm potential solutions and evaluate their feasibility. Encourage creative thinking and consider multiple approaches. Evaluate each proposed solution in terms of effectiveness, cost, and impact on stakeholders.
Implementing the Solution: Plan and execute the implementation process in detail, keeping all stakeholders informed.
Monitoring and Reviewing: Establish clear metrics for success and regularly review them. Gather feedback from all relevant stakeholders and be prepared to make adjustments if necessary.

I recommend going through the framework's steps with each significant problem you are facing:

Technical debt challenges, e.g., monolith breakdown, framework migration, dependencies update (and anything else you can classify with Ten Types of Technical Debt).
Product development, like creating new features or delivering new value to customers (stating your work as a problem to solve, not a task to deliver is a big shift on its own).
Challenges related to SDLC process, like delivery frequency, testing automation, CI/CD processes.
Team-related challenges, like team empowerment, expectations, and performance management, team empowerment and productivity (you can check Top Ten Factors of Developers' Productivity).

More Materials

I've prepared additional materials for paid subscribers who support Practical Engineering Management, including a FigJam Template, Markdown template and example problems from my professional career.