Transformation Without Amnesia

Organizations often describe modernization as though the old system were an unfortunate object sitting in the way of the new one.

The language is revealing. We retire platforms. We sunset applications. We eliminate technical debt. We migrate users. The future waits on one side of a diagram, the past occupies the other, and between them sits an arrow so clean that it could only have been drawn by someone who will not be awake when the cutover fails.

Real systems are less obliging.

The systems an organization inherits contain far more than aging technology. They preserve decisions, accommodations, promises, workarounds, political settlements, and customer expectations. Some choices remain valuable. Others survive because nobody remembers why they were made. Most resist classification until someone tries to remove them.

That was the situation I encountered at Autodesk in 2012 as the company moved from desktop software purchased episodically toward an ongoing service relationship built around identity, entitlement, cloud access, subscriptions, and consumable services.

The existing licensing portal was widely disliked, and with good reason. Customers experienced different products through inconsistent interfaces and incompatible models of ownership. Internally, teams worked through a collection of systems that each carried part of the truth. Licensing decisions moved across organizational boundaries, and the authority to resolve them was often distributed among people who understood only one portion of the path.

It would have been easy to call this a portal redesign.

That description would also have been wrong.

---

The Interface Was Telling the Truth

Inconsistent interfaces are often treated as evidence of inadequate design governance. Sometimes they are. They can also be remarkably accurate portraits of the organizations that produced them.

Autodesk’s portal was fragmented because the underlying system was fragmented. Different product histories had generated different licensing rules. Teams had developed local solutions around their own responsibilities. Legacy services had acquired dependencies that extended well beyond their visible purpose. A record might live in one system, the authority to alter it in another, and the customer escalation that finally forced a decision somewhere else entirely.

The interface did not invent that disorder. It disclosed it.

A visual redesign could have concealed some of the symptoms, at least temporarily. It could not have established coherent ownership, reconciled incompatible definitions, or determined which dependency had to move before another could safely change. A clean surface laid over a fragmented decision system would have given customers a more attractive way to encounter the same uncertainty.

The work therefore began with legibility.

Who owned each system? Who could change it? Who could block a change without formally owning the decision? Where did licensing authority actually reside, and where was it merely recorded after the fact? Which support practices compensated for failures in the product? Which technical dependencies were unavoidable, and which had become permanent only because the organization had learned to route around them?

The investigation was architectural and organizational. Formal diagrams showed how services connected; the lived system revealed how work moved through people, history, and influence.

Both were real.

---

No One Could See the Whole System

Complexity creates an uncomfortable asymmetry: the more consequential the system, the less likely it is that any participant can perceive it whole.

At Autodesk, architects could see dependencies whose effects were invisible at the interface. Visual designers could recognize common interaction patterns beneath experiences that appeared unrelated. Product and business leaders understood how cloud licensing and subscriptions were changing the company’s commercial relationship with customers. Support teams knew which forms of complexity users could navigate and which had simply become normalized internally.

Each view was accurate. None was complete.

The appropriate response was not to locate the most senior person and ask for the answer. Authority could resolve a dispute, but it could not manufacture the missing perception. We needed enough of the system to become intelligible to enough of the right people that their different ways of seeing could revise one another.

That required more than attendance. A room can contain every relevant discipline and still produce a narrow decision if hierarchy, vocabulary, or facilitation prevents one perspective from changing another. The work became possible when technical constraint, customer experience, commercial direction, and interaction pattern entered consequential contact.

An architectural dependency might alter the migration sequence. The new sequence could require a different interaction model. That model might reveal that several apparently unique workflows were variations of one recurrent pattern. The shared pattern could reduce enough complexity to make a legacy service containable, and perhaps eventually removable.

The answer emerged through movement among perspectives. Nobody brought it into the room intact.

---

Modernization Is a Sequencing Problem

Clean-sheet redesign is seductive because it permits the future to be considered without the inconvenience of the present. The new model appears internally coherent. The architecture is rational. The interface behaves as though everyone arrived on the same day with no history and no work already underway.

Customers do not live inside clean sheets.

They had purchased licenses under older models. Internal teams still depended upon services that could not disappear on schedule merely because the new experience was ready. Subscription models needed to operate alongside legacy structures. Cloud credits and consumable services had to become understandable without destabilizing the products and entitlements already carrying the business.

We designed a modern licensing portal as a convergence layer. It gave customers and internal teams a coherent place to manage access, licenses, subscriptions, and credits while the underlying ecosystem transitioned at a pace its dependencies could tolerate.

Some legacy systems remained on life support while the new platform progressively absorbed their responsibilities. Dependencies that could be retired were separated from those requiring containment. The difficult decisions concerned sequence: what could move immediately, what needed an intermediary, and what had to remain operational long enough to protect customers from the consequences of our change.

The interface was the visible artifact. The deeper design was the migration of coherence.

---

The Ethics of Transition

Legacy modernization is usually discussed as an economic and technical problem, although its consequences make it an ethical one as well.

Organizations create the conditions that make their systems difficult to change. Customers rarely do. Yet poorly managed transitions routinely transfer the cost of accumulated organizational complexity onto the people least able to influence it. A user loses access, a support team improvises an explanation, an administrator reconstructs entitlements by hand, or a customer is asked to understand the internal distinction between two systems that the company itself has failed to reconcile.

There is a quiet violence in making customers absorb an institution’s transition.

Responsible modernization acknowledges that the old system may need to remain alive while its responsibilities are being transferred. This can look inelegant from inside a transformation program. For the customer, it can be the difference between a strategic migration and an arbitrary disruption.

Preserving continuity does not mean preserving every inherited decision. It means changing the system with enough understanding that we can distinguish what deserves to survive from what has merely survived until now.

That is transformation without amnesia.

---

Collective Legibility

The resulting platform was, honestly, a quantum leap from the experience it replaced. Customers gained a more comprehensible way to manage licensing and access. Internal teams gained a shared operational view. Support friction declined because fewer issues required translation across incompatible systems and ownership boundaries. The company could support new commercial models without requiring its legacy architecture to vanish in a ceremonial switch-flip.

I was later named to Autodesk’s CEO Top 5 Up-and-Coming list. I appreciated the recognition, but the more durable achievement was less individual: a system no one fully understood became coherent enough for many people to change together.

I think of that condition as collective legibility.

Legibility is usually discussed as a property of an interface. In complex organizations, it is also a property of the work itself. People need to see how a local decision affects the larger system, where authority actually resides, which history a constraint carries, and what another discipline is protecting when it resists an apparently obvious solution.

Without that visibility, transformation becomes a contest among partial truths. With it, disagreement can become useful because the participants are finally arguing about the same system.

This experience became one reason I build collaborative surfaces. Distinct capabilities cannot improve one another while the object connecting them remains illegible. Once the system becomes visible, architecture, design, product, support, and customer knowledge can operate as more than adjacent functions and begin composing an answer.

Legibility cannot eliminate conflict, confer authority, or make every dependency negotiable. Its value is more practical: the organization gains a chance to understand what it is changing before asking customers to live with the result.

---

This article is supporting content for Designing the Collaborative Surface. For my role, process, and project outcomes, read the professional case study: Composing the Transition at Autodesk.