In every organization, people have operational problems that they've learned to live with. These may be process issues with elegant workarounds, set-ups that only one person knows how to do, or paperwork that's routinely deferred until 11pm. These problems aren't always mission-critical but they can erode margin and elevate risk. More important, they become a part of the way work gets done and as such disappear into the background when leaders look for ways to improve performance.

Experience can make it harder to see familiar challenges differently

Running a business involves making decisions and communicating them to your team. General David Petraeus described this responsibility as getting the big ideas right, communicating them through the length and breadth of the organization, overseeing the implementation of those ideas, and determining how they need to be refined, changed, or augmented, before repeating the process. But even when we communicate effectively, it's easy to forget that each of our decisions has a lasting effect on culture:

• Guidance becomes part of the folklore
• A mantra becomes an unconscious aspect of the way things get done
• Leaders’ behavior establishes "what good looks like" and the team repeats it

If there were problems that were too knotty, too messy, or not urgent enough to get addressed on the spot, your team may take the initiative and develop workarounds. Over time, those workarounds become part of the workflow and eventually embedded in the way they see the task. This reflects something important about the way our brains have developed.

Our brains are like air traffic controllers insofar as they manage an array of different systems and activities. Like any complex system, they have a limited amount of resource (such as energy) available to conduct this activity, and so our brains optimize for efficiency. One way this occurs is by relying on interpretations that have proven reliable in similar situations. You’ll know this if you’ve fumbled to find the hazard light-button on your car's dashboard in a hurry: the button is visible, but it's so rarely required that you barely see it when you're driving regularly.

The same thing can happen as we become increasingly expert at a task. We tend to see what we have relied upon to get the job done. We refer to this as seeing through a lens of our experience.

Seeing a task through a lens of experience recognizes that our interpretation of our experience is already colored by our assumptions, our expectations, and our memory. This is valuable for survival - our prior interpretations are useful if we need to clarify the difference when confronted with a bear or a person in a bear suit - but it can get in the way when we want to think innovatively or see familiar tasks differently.

When we want to see a broader range of alternatives, an effective tactic is to approach problems through a lens of our expertise.

Interpreting through a lens of our expertise means analyzing a challenge objectively - standing back from it and bringing our knowledge and insights to that problem. Returning to the example of the dashboard hazard lights button, this lens involves isolating the visual elements and exploring how they relate to each other and the car's performance to determine if any overlooked elements can help us achieve our goals.

We've developed a straightforward method for achieving this perspective, which we describe later in this article. First, though, a survey we recently ran illustrates why this matters for the manufacturing industry.

When you assume…

We recently ran a mixed-methods survey focused on the quality of engagement between U.S. manufacturers and local machine shops - buyers and makers - and to understand what, if anything, may be impeding local collaboration. It identified a significant misalignment:

70% of machine shops told us that manufacturers rarely (if ever) contacted them to learn about their capabilities before releasing an RFQ

85% of manufacturers told us that they "usually knew" whether a capable local supplier existed prior to engaging them

In other words, many manufacturers may be making decisions based on assumed knowledge when engaging machine shops. This reflects the risk of operating through a lens of experience. Our prior interpretation of a situation may hold true, but for how long? Each interpretation is like a photograph of a river - representative of a point in time although the river is always changing. Machine shops may engage new staff with new skills, purchase new equipment, or upskill their teams. There may be a smaller gap between actual and desired capability that could be bridged through negotiation. Manufacturers that don't touch base may miss these opportunities.

We explored these insights through a method that helps to see alternatives within familiar problems. By breaking down what we were seeing and hearing from the industry, isolating what was driving those behaviors, and exploring these in an analogous model, our approach helped to identify underlying issues - the separation between buyers and makers due to digital platforms and internal bureaucracy, costs of doing business, and a globalized trade environment - that together contributed to this misalignment. We developed the concept of "local manufacturing marketplaces" and a set of recommendations for manufacturers and machine shops to re-build trust-based connections that strengthen local, regional, and national supply chains. This same approach can help your team unpack complex challenges that may have gone unaddressed.

A method for seeing familiar operational problems differently

1. Breaking down the problem into its components
2. Mapping those components as a system
3. Developing and testing a hypothesis in an analogous environment
4. Stress-testing the hypothesis through a low-fi model
5. Translating it into an action plan

If you've been to business school or have been trained in problem-solving methods, you may have been told to "start with the end in mind," or to begin with a defined problem statement. We argue that starting with a view of the outcome closes off options necessary for developing new perspectives. Our approach aims to keep options open to allow practitioners to recognize patterns that aren't immediately obvious. The first step is to break the problem down into its parts.

Breaking the problem down can be done on a whiteboard using a tree diagram or a hierarchical map. From there we ask questions about the relationships between those parts with a focus on causal drivers - what does each component cause to change in other parts, and what causes it to change? Once these are marked out, we go further, exploring how these changes occur and what needs to be true for that change to happen.

Mapping the parts and the causal drivers as a system helps to formalize the data we've extracted. It's also valuable as a communication model. Visualizing the data makes it easier for others in our team to see it as an interconnected whole. We recommend aiming to map the minimum set of parts and flows that explain the data clearly rather than mapping every element. Once the system has been mapped, we identify features or relationships that are unexpected or unfamiliar. We also take this opportunity to write down the problem statement, including a view of the desired outcome, along with a description of how the problem prevents us from realizing that goal.

We then develop and validate a hypothesized solution. We don't do this by tackling the problem head-on. Instead, we use the data we've gathered on causal drivers to identify an analogy that aligns with the problem structure then build and test a hypothesis based on the analogue. This is similar to extracting a DNA sample and studying it in a lab environment.

Working with analogies requires some caution. It's easy to get carried away and make associations that are not realistic. We mitigate this risk by creating a table that maps the causal drivers onto an analogous example. The components themselves won't map across - that's the nature of analogy, which illustrates structural alignment rather than sameness.

Instead, it's the causal relationships that are mapped. In exploring the misalignment between manufacturers and machine shops, for instance, we didn't look at other manufacturing relationships for an analogue. We chose marketplace business models - environments where buyers and sellers interact with or without an intermediary - and found that the connections, and specifically the trust relationships, between buyers and makers had been overlooked in the original interpretation of the problem.

Once the analogue has been mapped, we set aside the original problem statement and focus entirely on the analogous example. This involves researching the analogue thoroughly enough to understand it and exploring how our problem exists in that context. We want to understand how the problem is represented, whether it's already been solved, and what conditions make it possible. This provides a basis for developing a hypothesis for solving the problem which we then research and validate in that environment. Only once we are confident that the hypothesis holds in the analogous example do we then return to the original problem to validate whether the hypothesis may be effective there too.

Mapping a hypothesis from an analogue back onto the original problem is like taking a theory developed in a lab and applying it in the field. This is where the causal mapping comes into play - if the alignment with the analogy was close, the hypothesis should hold together for your core problem. Given that the hypothesis has been developed in an unfamiliar environment, it's possible that it's a non-obvious solution that draws on elements that were present but not immediately obvious. At this point, we refine the hypothesis and validate it through analysis prior to testing with a low-fi modeling exercise.

The purpose of creating a low-fi model is to surface assumptions that may be hidden in the conceptual hypothesis design. This is the step that can help to avoid an investment in a solution that isn't as effective as you'd hoped.

A low-fi model can be designed with simple materials. The primary requirement is that everyone on the team understands what each object represents. It should clearly represent the structure of the problem and the hypothesized solution, including its parts, flows (information, capital, work products, and so on), and the causal relationships. If the hypothesis doesn't hold up, the model is doing its job - it's a signal to return to earlier steps in the process and re-evaluate. We iterate the process until the hypothesis holds true in the low-fi model.

Once the hypothesis has been validated, we develop an action plan. This involves translating the hypothesis into a sequence of actionable steps, split by team as necessary, with a clear note of everything required to execute (people, capital, time, and materials) as well as milestones and go / no-go points to manage investment. Typically this would involve a limited pilot to manage risk, mapped in detail on the action plan, followed by an execution path to ensure there is a long-range view.

Operational problems that evolve into "the way things have always been done" can lead to margin loss and embedded risk. The same characteristic that makes them hard to see, their familiarity, means they tend to be underestimated. By recognizing how these issues become embedded in the way we perceive tasks, and applying a methodical approach to evaluate and solve for them, teams can bring latent improvement opportunities to the surface. The first step is the decision to look more closely.