Concept Translation

Trying to replicate a process across teams is difficult. If you simply copy it exactly, you risk losing the essence of the concept. Context matters. So where you add the process (the context) has a direct impact on its success. Without a fundamental knowledge of the motivation behind the process—the reason it exists—you can’t easily adapt it in a new context.

I’m starting at a new company this week, so this is top of mind. I have many systems I’ve built over the years, but they exist in a specific context: previous companies. There were unique collections of people, different processes, and different products. Copying won’t work.

It’s like poetry. When poems are translated to another language, they’re never directly copied word-for-word. The poem is modified so the translation makes sense. The essence of poem remains, but adapted to the new language (the context).

The same is true for a process. And translation is the key word. Translate, don’t copy.

This idea is called Concept Translation. It lives in the 🦉 Clarity Codex of the Claritorium.

• 🦉 Clarity Codex (Structure): The hidden structure of clarity. Models, language, and frameworks that guide sensemaking and decision-making.
• 🐍 Clarity Current (Motion): The invisible force of clarity. Roles, rhythms, and relationships that activate and sustain clarity.
• 🦎 Clarity Climate (Environment): The emergent environment of clarity. Behaviors, values, and patterns that make clarity natural, resilient, and scalable.

(You can read more about the Claritorium at claritorium.com.)

Concept Translation is about carrying the essence of an idea across contexts without copying its surface form. The three pillars of Concept Translation are:

1. Essence Discovery: Understanding the root problem or principle behind a process.
2. Contextual Reframing: Adapting the concept to fit the new environment.
3. Adaptive Expression: Expressing it in ways people can naturally use and apply.

Once we discuss the three pillars, we’ll talk about a specific expression with a real example where this helped me translate a process.

Essence Discovery

I remember basically nothing from history class. Everything I learned was about rote memorization—dates, names, places. It was just information without the context, which is why I retained none of it.

But I love history now. I’m in the middle of a 33-hour audiobook about Napoleon Bonaparte. I especially love biographies because they give you rich context that sterile facts never will.

You can’t understand the essence of things without understanding the motivation behind it.

The motivation is the reason for existing. It’s the infamous why we’re always seeking.

So how do you discover the essence of a process?

You need to identify the root problem a particular solution is aiming to solve. And the best way to get there is to keep asking questions. Let curiosity be the fuel and intuition your compass. The more you do it, the higher your curiosity and the better your intuition. Think Principles First (Issue #18) to identify the underlying principle that summarizes the idea in clear language. You can then reason with it, test it, and apply it to other contexts to see how it fits.

A principle is transferable because it’s a general truth that extends across contexts (teams, companies, domains). “Fixed time, variable scope” is a principle that can be applied outside of software development—like building a house. And if you get even more abstract with a principle like “less is more,” then you can apply that even more broadly to more areas.

Find the right level of principle abstraction that fits the given context.

Contextual Reframing

With the principle in hand, you have the seeds to plant. But you need to understand the soil and surrounding environment to make sure the seed grows. That’s the context. You understand the problem—driven by a key principle to define the motivation—and now you need to understand the environment where the new solution will live. What system exists to manage the “problem”?

Language is one of the most important forms of context. Understanding the taxonomy of the new context is a great way to orient yourself in a system. Language defines meaning, but it also establishes what systems thinking would call ‘stocks’. Stocks are the accumulation of items in a system, such as the population in a country. Population is the stock, and it’s affected by births (birth rate) and deaths (mortality rate).

In a software company, these would be things like:

• Raw ideas and feedback.
• Prioritized work in the form of projects.
• Issues and tasks as the individual units of work.

Understanding these stocks helps you understand the context because these are the items that are meant to grow or shrink. Depending on their individual quantity, and their relationship to the other stocks, they will tell you how the system works.

• Raw ideas and feedback should continue to grow, but you need to convert them into projects, issues, and tasks that stabilize them.
• Projects should cover the resourcing capacity of the team, but not exceed it. And if there’s more prioritized work than people available, hiring (resourcing is another stock) is a consideration to maintain balance.
• Issues and tasks need to be high enough to make the work known, but not so high that the team is unable to keep up with the work. Again, resourcing is a related stock here.

The key to understanding the context is in understanding the system—the inputs, stocks, flows, outputs, and feedback loops. In general, think about:

• What flows in (inputs), accumulates (stocks), and flows out (outputs).
• How feedback reinforces (grows) the stocks.
• How feedback balances (shrinks) the stocks.

This is part of an idea I call System Maps, which I’ll share in a future issue. For now, though, you just need to know about the general idea in order to understand the context and reframe it effectively to fit the new idea.

Adaptive Expression

Finding your expression of a process is how you integrate a specific version of the process that fits your unique context, while making sure to maintain the essence of the process.

You know why the process exists (motivation) and what problem it solves.

You know the new context and how the system is constructed.

Now you need to adapt the process (your expression).

If a 5,000-person company has a problem where goals aren’t effectively communicated, then that requires a different solution than a 20-person startup needs. The startup can bring everyone together in a weekly meeting, share a spreadsheet, or just post a message in their team chat. The big company cannot do any of those things and expect the problem to be fully resolved. Their expressions must change.

A principle is a transferable synthesis of the problem articulated in a way that allows for many interpretations. So if the problem is an insufficient lack of communication around goals, then the principle could be:

Goals always visible.

The startup’s expression could be a public spreadsheet and rhythm to keep it updated.

The big company’s expression could be translated by each department, whether it’s marketing using a spreadsheet or sales using a custom dashboard.

The principle is fixed, but the solution to the problem (the expression) is adaptive.

This thinking is a requirement to have a Product Mindset (Issue #38). It requires a shift from service work where you just copy requests, to product work where you translate intent. You adapt the idea into a usable form that solves the core problem. If a request is made to “add another button,” a Service Mindset just adds the button. A Product Mindset, on the other hand, surfaces the real need—making a secondary action clear—and translates that into a more intentional action that aligns with the ethos of the product. This is why so many products became Frankenstein-ed into a jumbled mess.

Translate intent instead of copying requests.

Example Expression

Here’s an example of Concept Translation in practice.

Problem: I wasn’t creating space to reflect on my wins and learnings each week.

Principle: Look back to look ahead.

Process: Weekly Pulse (Issue #22).

When I started doing weekly 1:1s with my direct reports, I ran into a similar problem. The time was supposed to be for them to bring topics to discuss, but it was easy to forget because there was no rhythm in place to reflect.

So I went back to the principle of look back to look ahead and started a new process.

Before each 1:1, they filled out a Google Form to list their wins, three learnings, and three takeaways from the previous week. This was the same process I followed, but expressed differently for this context—the poem translated in a new language.

If I didn’t understand the problem or the essence of the solution, I couldn’t translate my process to them. And I couldn’t continue to improve it after creation. The wins, learnings, and takeaways are both the language and the stocks of the system. Viewing a process as a system of components, understanding the language, and establishing clear guiding principles creates a structure poised for translation across domains, companies, and teams. That’s how you leverage knowledge and see the hidden structure of things.