ProblemOps Principles

Audio Version

Here's an audio version of this article:

ProblemOps Principles

0:00

/684.152766

1×

The World Thinks in Solutions

It's not our fault: people like to start with the end in mind. Our brains don’t like chaos, and problems could be perceived as chaos. We respond better to what's working than what's broken (reference). When hearing the word “Problem,” people may assume the worst and avoid it.

So, humans sometimes frame things in "what if" scenarios that portray the future. “What if we introduced a new way to do this?” It’s nice to hear. It's exciting to think about. It brings concrete ideas to the table. This is how we bring change to the world. We may not understand what's happening in our current state before we try solutions. In the end, we learn from what changed, and what doesn't work, while moving toward the “what if”. We adjust and proceed. 

This translates to business life and to personal life. It applies to anything we do with other humans. Sometimes, in business, there's a lot of pressure to deliver quick solutions to move toward the “what if”. Companies often pride themselves on driving quick change to market. They want to achieve business outcomes and make an impact. They seek to grow. They seek to satisfy investors. They won’t know if it works until they bring it to market at scale, so they keep moving. 

Business Scenarios of Change

Different scenarios may happen at businesses where people think in the solution, or “what if”, first: 

The Quick Fix

In the Quick Fix scenario, customers complain about problems, and leadership pressures teams to resolve them. Teams prioritize the immediate issues without looking at the root causes. Each solution fixes issues while larger problems remain. Business leaders feel good hearing about solutions. This results in increased time in development and never-ending support issues.

The Emotional Workplace 

In the Emotional Workplace scenario, everyone wants to talk about the “good” and never the “bad”. Solution-focused management encourages teams to focus on "what's working". Everyone works on solutions and goals. They never discuss the problems out loud. They try to uphold a good impression of quality across the business. While team morale initially improves (Reference), persistent issues continue to cause lost sales.

The Innovation Dilemma 

In the Innovation Dilemma, the business seeks to continually innovate to make problems go away. Leadership prides itself on launching innovative solutions. Rather than investigate problems, the company invests in new technologies. They spend their time and money on new technology that changes the way teams work. Each new solution brings temporary improvements, while production costs continue to rise.

Keep The Lights On

The business may instruct teams to prioritize things that keep business operations running. Short-term fixes get worked on over long-term innovation. Long-term innovation is viewed as problem-solving where short term quick fixes to “keep the lights on”. This results in teams managing budgets and evaluating peoples' performance (Reference). 

You may relate to these scenarios. They happen often. These scenarios often result in:

1. Positive team thinking (reference)
2. Decreased profit 
3. Persistent customer issues
4. Increased costs
5. Increased time to delivery

What About the Problem?

Countless books and resources argue that we all should be “problem-first” in our thinking. Forget the solution; what’s the problem? People who prioritize the problems may devalue “solution-first” thinking. People who value solution-first thinking may avoid the word “problem” on purpose. Either people want to start with the problem, or start with the solution. This rift in the business world is wide. Business people misunderstand delivery teams. Delivery teams misunderstand business people. Teams may feel left out of conversations or decisions. They may feel their opinions are ignored in pursuit of the solution. Resentment grows.

A New Way of Thinking

Can’t we all get along? Yes we can. It’s all about words. We should think in both problems AND solutions. We all should change the way we talk to each other. The "Solution-First" and the "Problem-First" should change the way we talk to each other. Both sides are actually trying to say the same things, but not speaking the same language.

The problems LEAD TO the solution. There are many problems INCLUDED in a single solution. They are two halves of the same outcome.

Too many teams are stuck in this one-sided dynamic. They think either about the problem or the solution, but don’t create pathways to make change together. We're not participating together in problem-solving. We're not helping each other translate solutions to assumptions. We're not acting in unison. We’re not tracking change to prove the value of it together. We’re only arguing one side or the other.  Neither side is speaking the same language yet.

The key to making change lies in building the common language between the people who want to start with the problem and the people who want to start with the solution. We need to do it in a way where both parties feel heard and involved. Yes, there are ways to take less time to deliver and also solve problems. Yes, there are ways to validate our ideas and also move quickly toward delivery.  

It shouldn’t be either one way of thinking or the other. We need to build an experience in companies where we align around a common understanding. What if we trained people to focus on both the solution and the problem? (Reference). What if we built a unified voice over different departments of work? What if we trained teams to foster agreement and respect first? What if we trained people to problem-solve by speaking the same language as the business? What if we showed people that problem-solving can be iterative? 

If we did all of this, we could achieve a balance between speed, costs, and quality. We could realize that we’re all working towards the same outcomes. To do this, humans must work together. We must take action together. We must build a shared language.

Here's a New Scenario of Change

Imagine a scenario where people get together to define common terms first. They understand each other and the perspective they bring. They break down business language and technical language together. Then they agree to what they think is the solution, AND the problems, by discussing what they think is happening right now that should change. They define the expected goals and results. They define how they want to learn from the change. They agree they could be wrong, and agree to make change quickly by getting something to the hands of users to test. Then they work together after quickly defining what they're committing to.

This scenario could happen for any kind of team, and any kind of business, and any type of personal interaction. It applies to physical therapy; hospitals; museums; restaurants; mental health; software technology; public policy. This is the scenario that comes from practicing ProblemOps together with other humans.

Welcome to ProblemOps

ProblemOps is short for “problem-solving operations”. It deals with the practice of making change with teams. It’s centered around collaboration and teamwork. Let’s practice what we’re preaching and break this language down to the essence.

Problem-solving is how we make change in the world. Things happen for different people that we change through products, services, or interactions. Operations is the practice that people go through while making change. 

ProblemOps is not a single framework or method: it combines many things from a lot of different areas. It's a system that's flexible.

It's not dedicated to a single function in the business: it's a communal practice for all teams. Use what you know while practicing the principles of ProblemOps.

ProblemOps, when it comes down to it, is a set of communication tools. It’s a language builder. None of this is new. It’s being discussed in new ways within this system. Those who build products and services for a living will find these approaches very similar, because they are the same. We need a new language around them because of how they’re being perceived in the world today. 

The Principles of Problem-Solving Operations

People practicing ProblemOps should gather around their own shared understanding and common language.

People practicing ProblemOps follow these principles:

1. We believe in both solutions and problems.
2. We pursue a shared understanding.
3. We prioritize people over platforms.
4. We deliver change early and often.
5. We rely on failure as the engine for change.

How to Make Change around the Language of Change

Making change together can't happen in a silo. It starts with the 4 C's:

1. Develop criterion around the language of change
2. Commit to work together
3. Collaborate across functions
4. Change the current state

Let's break it down:

Criterion

To align, we need to speak the same language together. Solving problems and bringing change should start with:

1. What are the scenarios that are currently happening that people want to change?
2. What are the expected outcomes we, and users, want to achieve?
3. What do users expect to be in place to achieve the outcomes?
4. How do we know when we've succeeded?
5. What are the consequences they're trying to avoid
6. Why is this change valuable to those who are affected by it?

Commit

Teams should agree to the scenarios they are focusing on fixing first, even if they are based on guesses. They can quickly deliver it in to the hands of user to learn from it quickly, and iterate.

1. What scenario-based problems should we commit to now?
2. What scenario-based problems do we agree to take on in the future?
3. What outcomes should we work toward in the scope of work?

Collaborate

It's better to show instead of tell. Teams need to unite together and provide visibility into their work. Better yet, let's all work together toward the changes being committed to. Don't just tell the business about the progress; involve them in the progress. This could happen in many ways. Many methods and processes exist to collaborate together while doing the change. Use any of them that suit your needs.

Change

When the change is implemented it's important to understand what you're trying to learn from it. Defining how you know you've succeeded helps you measure change and define the impact. It could have negative or positive consequences. Either way, teams should use this data as learning to define the next round of changes.