That sounds like discovery. And sometimes it is. But it is also something more consequential: the organization is choosing how to see itself. The way a company sees its work shapes what it believes it can change about that work.

James C. Scott’s Seeing Like a State is a useful lens here. Scott writes about how states make complex societies legible to themselves through maps, censuses, naming systems, property records, standards, and administrative categories. But the idea travels well because organizations do a version of this all the time. They create models that allow complex work to be seen, compared, governed, funded, automated, and improved.

Legibility is a design choice. The models we create are not neutral descriptions of reality. They determine what becomes visible, what becomes measurable, what becomes manageable, and what becomes easier to ignore.

Transformation depends on the model

A lot of companies talk about transformation as if the hard part is execution. The strategy is clear, the business case is approved, the roadmap is built, and now the organization needs to move faster, align better, or adopt the new tool. But in practice, many transformation efforts struggle much earlier than that. They struggle because the organization does not have a useful enough model of the work it is trying to change.

That model might be a customer journey, a product architecture, a workflow map, a service blueprint, a taxonomy, a governance model, a capability map, or a set of metrics. Whatever form it takes, it becomes the lens through which the organization understands the problem. It defines what is in scope, what is out of scope, where the boundaries are, who owns what, and what kind of change seems possible.

This is why the modeling work matters so much. A bad model does not just describe the work poorly. It leads the organization to make poor decisions about the work. It can make the wrong problem look urgent, the right problem look invisible, or a local workaround look like resistance instead of intelligence.

Good transformation work starts by treating the model itself as something to design. The question is not simply, “What is happening today?” The better question is, “What way of seeing this work would help the organization make better decisions about it?”

Making things legible is only half the job

The business version of this is the familiar line: “what gets measured gets managed.” What Scott adds is the step that comes before measurement. Before something can be measured, it has to be made legible. It has to be named, categorized, bounded, and turned into something the organization can see and compare.

That is often useful. It is hard to improve a workflow, govern a system, or make decisions across teams without some shared way of seeing the work. Once something is legible, it becomes easier to compare, report on, fund, optimize, automate, or manage. A vague concern becomes a metric. A messy set of behaviors becomes a process. A local practice becomes a standard. A set of customer interactions becomes a journey map that the organization can improve.

But there is a trade-off. The parts of work that are easiest to make legible are not always the parts that matter most. Trust, judgment, context, quality, informal coordination, customer nuance, and local knowledge are all harder to represent cleanly. If the model does not leave room for them, they can become invisible to the organization even though they are central to how the work actually gets done.

This is one of the most important risks in transformation work. The organization does not just manage what it measures. It also starts to believe that what it can measure is what matters. Over time, the official picture of the work can drift away from the lived reality of the work.

Useful legibility, not maximum legibility

The answer is not to avoid simplification. Organizations need simplification. No one can operate inside total complexity, and no team can coordinate if every local context remains entirely local. Shared language, common metrics, standard processes, reusable patterns, and consistent product architectures all create real value.

The problem is not simplification itself. The problem is forgetting that simplification happened. Every model leaves something out. Every taxonomy resolves ambiguity. Every operating model privileges one way of seeing the business over another. Every dashboard narrows attention. Every workflow map turns a living system into a sequence of named steps.

The design challenge is to create useful legibility. Useful legibility makes the work visible enough to improve without pretending the model captures everything. It creates enough structure for people to coordinate, while preserving enough context for people to use judgment. It helps leaders make decisions without turning the organization into a reporting abstraction.

This is where the nuance matters. Standardization can be incredibly valuable. It can make collaboration easier, reduce waste, support scale, and help ideas move across the organization. But standardization can also flatten the differences that make a situation meaningful. A customer segment becomes a row in a spreadsheet. A workflow becomes a compliance path. A product experience becomes a funnel. A team’s expertise becomes an undocumented exception to the official process.

Useful legibility means being intentional about that tradeoff. It asks where standardization creates leverage and where it destroys value. It also asks whether the model is being designed to help the work get better, or mainly to make the work easier to monitor from a distance.

Adoption is a design signal

The key distinction in Scott’s work is the difference between coordination and coercion. Some standards work because people adopt them. They make life easier, reduce friction, or help people do something they already need to do. Other standards work only because the organization enforces them. They create compliance, but not necessarily better work.

That distinction maps directly onto transformation. When a new workflow, taxonomy, dashboard, operating model, or AI tool has to be constantly enforced, that is a signal worth paying attention to. It may mean the organization has a change management problem, but it may also mean the design is not useful enough to the people being asked to use it.

People route around bad models. They create side spreadsheets, private naming systems, informal escalation paths, shadow processes, and local workarounds. Those behaviors are easy to dismiss as resistance, but often they are feedback. They tell us that the official model does not fit the work well enough.

This does not mean every model has to emerge organically or that every standard should be optional. Large organizations need shared structures, and sometimes those structures have to be implemented deliberately. But adoption is still a design signal. A model that helps people do the work will behave differently than a model that only helps the center see the work.

The better question is not, “How do we get people to comply with the new model?” It is, “What would make this model useful enough that people can see why it matters?”

AI raises the cost of getting the model wrong

When companies bring AI into their operations, work has to be broken down, represented, sequenced, measured, and connected to systems of data and decision-making. That can create real leverage. It can help teams move faster, reduce manual effort, and make expertise more available across the organization.

But AI also raises the cost of getting the model wrong. If a workflow is poorly understood, AI can automate the misunderstanding. If a taxonomy is shallow, AI can scale the shallowness. If the official process ignores local judgment, AI can make that omission harder to see. If the data model does not represent the reality of the work, AI can create confident outputs from a distorted picture.

This is why AI transformation should not start with the tool. It should start with the work. What is the work trying to accomplish? Where does judgment matter? What context do people use that is not captured in the system today? What decisions are routine enough to support, accelerate, or automate? What parts of the work should remain human because they depend on trust, ambiguity, negotiation, or care?

AI does not remove the need to understand how work happens. It makes that understanding more important. The more powerful the system, the more important it is to design the right way of seeing the work before we ask the system to act on it.

Standardize the substrate, preserve the judgment

There are parts of an organization that benefit from being boring, stable, and shared. Common data definitions, reusable workflow patterns, clear decision rights, consistent product architecture, shared language, and well-designed governance can all make the organization easier to operate. They reduce the amount of energy teams spend translating between local systems of meaning.

But not everything should be standardized to the same degree. Judgment, customer nuance, team expertise, market context, and product differentiation often need room to vary. The goal is not to force every team into the same mold. The goal is to create enough shared structure that local variation becomes easier to understand, support, and learn from.

This is an important distinction for product and business design. A company may need a common product architecture, but not a generic experience for every customer. It may need a shared operating model, but not identical rituals in every function. It may need a consistent way to evaluate opportunities, but not a process that strips out strategic intuition. It may need AI-enabled workflows, but not workflows so rigid that people stop exercising judgment.

Good transformation work does both at once. It creates the common substrate that allows the organization to coordinate, and it protects the places where local intelligence creates value.

The model should become more accurate through use

Another way to say this is that the model should be allowed to learn. Too often, organizations treat the model as something created at the beginning of a transformation and then rolled out. The operating model is defined, the workflow is approved, the taxonomy is published, the metrics are set, and the organization is expected to conform. But if the work is complex, the first model is almost certainly incomplete.

That does not make it useless. It means the model should be designed to improve through use. People should be able to challenge categories, identify missing context, surface exceptions, and show where the official view does not match the real work. The model should not be so fragile that feedback feels like a threat.

This is especially important in fast-moving environments. Markets change, customer expectations shift, technology creates new possibilities, and teams discover better ways to work. A model that was useful six months ago can become a constraint if it cannot evolve.

The best models act less like fixed diagrams and more like shared language. They give people enough structure to communicate, but they stay open to refinement. They help the organization coordinate without freezing the organization’s understanding of itself.

Designing the way the organization sees

This is the deeper design problem inside transformation work. We are often helping organizations turn ambiguity into action. That might mean clarifying a growth opportunity, designing a product strategy, rethinking how teams work, introducing AI into a workflow, or helping leaders make better decisions about technology and change.

In all of those cases, the first move is not just to solve the problem. It is to decide how the problem should be seen.

That is not abstract. The way a company sees a market shapes where it looks for growth. The way it sees a customer journey shapes what product decisions feel obvious. The way it sees a workflow shapes what it chooses to automate. The way it sees performance shapes what behavior gets rewarded. The way it sees capacity shapes whether efficiency turns into value or just more work.

This is why clarity matters, but not as an end in itself. Clarity is only useful if it helps the organization make better choices. A clean model that points the organization in the wrong direction is not clarity. It is just a cleaner abstraction.

The real work is to create models that are clear enough to act on and honest enough to preserve what matters.

Seeing differently to change better

Before you can transform work, you have to decide how to see it. That decision is embedded in every map, model, taxonomy, metric, workflow, product requirement, AI use case, and governance structure we create.

The question is not whether to make the work legible. Transformation requires legibility. The better question is what kind of legibility you’re creating — whether it serves the people doing the work, or only those managing it from a distance.

The organizations that get this right do not treat transformation as a matter of imposing a cleaner model on messy reality. They treat the model as part of the design challenge. They ask what needs to be standardized, what needs to remain flexible, and how the organization will know when its way of seeing no longer matches the world it is operating in.

That is the balance: make the work visible enough to change, but not so simplified that the organization loses sight of what makes the work valuable in the first place.