Developing a Shared Language and Taking Action
The world is full of words that are interpreted different ways by humans. To make change together, we must develop a shared language. In this article, learn about the components of building shared language and how to take action towards change with others.
Audio Version
Here's an audio version of the article:
Overview
ProblemOps starts with the theory that we must speak the same language and build a shared understanding in order to make change together. This article describe how the communication is developed that leads to action. Making change can and should be incremental, and experimental in nature: teams should not seek "perfect plans", but should seek to get change into the hands of humans to learn from the change and define the next step. Building a shared language is key to working across teams and functions toward the same outcomes. Let's learn how a shared language is developed, and how it leads to action.
Components of a Shared Language
A shared language starts with understanding each other, building willingness, living a day in the life, and setting expectations.
Understanding Each Other
Instead of seeking to be understood, we need to seek to understand each other. We need to pay attention to different business perspectives and acknowledge them (Reference). What does the person mean when they use the terms they use? Do we know how they define those terms? Are they the same definitions we have? Assuming we mean the same things is risky. Taking a step back to define common terms before we move forward helps us say the same things in the same ways. When we understand different perspectives we can form agreements together. This helps us form an allyship between different work functions.
Building Willingness
You have to be open to this approach to act on it. Willingness is intentional. Teams must be open to seeing other points of views, and open to new ways of working together. They should desire to speak the same language. With willingness we can learn how other people define the terms we use, and how they may differ. When teams are not willing to build shared language, it’s important to build influence and trust without forcing your perspective. Provide space for teams to show the results of the work instead of talking about the work. People who are unwilling will make conclusions on their own time when they see results of change.
Living a Day in the Life
Teams shouldn't take sides. All business functions are in it together. Everyone in the business is aiming for the same outcomes of success. Other teams may have different perspectives than you do, but it’s your job to understand them and it’s their job to understand you. Different world views and professional views affect the way teams decide. Teams need to build empathy with other teams who are not in their same function. UX professionals build empathy with users to build the right solutions. Teams can build empathy with each other to build a shared language.
Setting Expectations
Building common expectations leads to better collaborative outcomes (Reference). Teams can work together to define their current viewpoints about the world. We must speak the same language before we can all agree to expectations. Once the expectations are met, all teams can move ahead together and decide together.
Let’s Define the “Language of Change”
The “Language of Change” was first introduced by Watzawick (1978). Watzawick suggests that therapists must learn patients’ language to help them make conclusions. The concept applies to problem-solving work too. When we use the terms we know, we’re forcing our language towards others. We create rifts. When we use others’ language, we can speak in common terms and understand each other. To make effective change, we need others to understand, and we must use their language. We must share language to align across functions. We can’t use “UX” or “Agile” or "Design" or “Product” or “Research” because that’s our language. Thus, we define the Language of Change as the common language between everyone to understand what we’re moving towards. This language builds agreement.
The Four C's of ProblemOps
Problem-solving operations is human-centered. We cannot work in silos to make change. People need to bridge understanding and create shared outcomes. The approach relies on four key points, driven by the Language of Change: Criteria, Commitment, Collaboration, and Change.
Criteria
Building the Language of Change with a shared language is a key first step that we must take together.
With the Language of Change in place, teams can unite towards the outcomes. A shared language helps teams build criteria for change. Here is the Language of Change that teams should build so that they can all align:
- What scenarios are happening for audiences right now that need to change? (Scenario-based problem statements)
- What outcomes do audiences want to achieve? (Situational Goals)
- What outcomes does the business want to achieve? (Situational Goals)
- What do audiences expect to be in place to achieve their goals? (Situational Needs)
- What does the business expect to be in place to achieve their goals? (Situational Needs)
- How will we know when we’ve met expectations? (Success measurements)
Taking Action
The Language of Change helps teams commit to work now and later. After committing to outcomes, teams can collaborate to make change together. They'll measure the impact of the change, and refine the next priorities to develop new criteria. Taking Action includes committing to work, collaborating on the work, and delivering the change. Taking action means that we compromise and build agreements. Action takes place through the following steps:
Commitment
Teams should use the Language of Change to commit to the most important work to deliver first. Here are the components of commitment:
- Do we all agree about how we describe the language of change?
- What should we change first and later? (Vision and Scope)
- Why is this work meaningful to the larger picture? (Value)
- What scenarios should we support after the change? (Use cases)
Collaboration
Teams must collaborate together to implement the change. Here are the components of collaboration:
- How’s it going? (Release tracking)
- Are we on the right track? (Release tracking)
- Do we need to change our plans? (Iterating on vision)
Change
Change is the action that teams take together. New changes bring new challenges, and the cycle of continuous problem-solving operations starts again. Here are the components of change:
- What impact have we made?
- How does this affect the overall end-to-end experience?
- What should we prioritize from here?
