Make the invisible, visible

"Make the invisible, visible" means revealing the hidden but relevant information so we can understand things clearly. This principle is, in fact, at the root of understanding all things.

Having access to the relevant details helps us to understand things better so we can work more effectively. It means better behaviours, problem-solving, and results. When the relevant information is invisible, there’s naturally a deficit in understanding. How can you understand anything properly — whether it’s a team, an organization or a code base — if there’s a knowledge gap due to invisible relevant information?

How to determine relevancy

In any system you’ll always find more details that are irrelevant than relevant, so it is crucial to be able to determine what is relevant. Let's take a coin as an example of this phenomenon. A coin has two sides, often with the date it was minted on one side and the currency value on the other. Its many other properties include: weight, mass, electrical conductivity, melting point, metallic composition, etc. Focusing on just one of those properties, such as the metallic composition, reveals an even higher number of possible attributes, such as a mixture of numerous elements. Within those elements are various atoms and within the atoms; quarks. Most of those properties are invisible and usually irrelevant, but depending on your perspective, some are relevant but - unfortunately - invisible. To make the invisible visible, we first need to find what information is relevant and then make it visible.

Two related questions can help you determine relevancy:

  1. What information would be helpful for me to understand that I currently don't have? - This will generate many answers while ignoring your existing limitations.
  2. What information would be helpful for others to understand that they currently don't have? - This will help you think about your users and other perspectives.

Going back to our coin example, you and I probably only care about the monetary value of a coin. But what if you were a precious metal dealer? Now, what is relevant to you about coins is different - we care about what the coin is worth. To know its worth, we need to know the type of precious metal, its quantity, and its purity.

This sixpence is a precious coin, but it wouldn't make a good coin for precious metal dealing as its relevant properties are invisible. We need to find out what it's made from, the weight of that material, and its purity. To make those properties visible, you would need to test the metal to determine its properties or rely on documentation elsewhere.

The relevant properties of the Britannia on the other hand, are visible. The coin is made of gold, 1oz of it, with a purity of 999.9 (24 carats). If the sixpence was going to be used in the trading of precious metals, we’d need to make the invisible visible and display its properties in a new design similar to the Britannia.

Unfortunately, relevant information is obscured in most systems, limiting our understanding. Behaviours are a widespread example of relevant information being invisible. Hidden behaviours result in teams that are not properly aligned, as well as dysfunctional organizations, and overly complex code bases. Because those behaviours are known in our minds (consciously or not), they’re often not made visible. From a leadership perspective, it means that people don't know how to act. From a coding perspective, engineers don't know why the code is written in the form it is. Problematic hidden behaviours can be addressed by establishing principles that create visible, sharable behaviour which others can interrogate and align to. Making the invisible visible is why we even define principles in the first place.

Examples

Further examples of making relevant information visible.

Data

  • Create visualizations that provide insight..
  • Convert data into visualizations that are easier to understand. (e.g., grafana, splunk)
  • Run calculations on the data to understand the content (e.g., average price, top sales)
  • Use analytics within a system to increase feedback cycles.
  • Reveal hidden patterns through data mining.

Code

  • Use diagrams. Represent code in less abstract, more concrete ways, such as drawing diagrams of a system using pen and paper or graphics design programs.
  • Log and visualize the results of a running application or process.
  • Utilize debuggers to peer inside a system and view changes over time rather than the black-box method, which views results from only the input and outputs of the system.
  • Use performance tools like flame graphs to visualize the stages of a program.

Teams

  • Use principles to communicate and build mental models that everyone in the team can share.
  • Ask questions that seek to understand and illuminate.
  • Ensure all members are able to access information in a coordinated way e.g., what gaps could exist between the technical customer service team and engineers?
  • Use personality assessment tools to build alignments within the team of how members prefer to process information, which can be used to create tailored best practices

Individuals

  • Identify and share your knowledge, codifying your approach into clear actions and principles.
  • Query your assumptions and blind spots to find new ways of identifying relevant information