The problem was not how to redesign a portal. It was how to modernize a system without erasing the dependencies still keeping it alive.
The System We Inherited
When I arrived at Autodesk, the company was moving from a world of desktop software purchased episodically toward a continuous service relationship built around identity, entitlement, subscriptions, storage, and cloud access. The strategic direction was clear. The operational path was not.
Autodesk did not have one licensing system waiting to be redesigned. It had an accumulation of systems, interfaces, business rules, and ownership structures that had evolved across products and organizations. Each solved a legitimate problem at some point in the company’s history. Together, they produced an experience that customers found difficult to understand and that internal teams found equally difficult to change.
The existing portal was widely disliked, but “redesign the portal” was an inadequate description of the work. Its inconsistencies were not merely visual. They were the visible expression of fragmented decision rights, divergent product histories, legacy dependencies, and incompatible definitions of what a license—or increasingly, a subscription—actually was.
Customers encountered that fragmentation as friction. Internally, it appeared as delay, rework, and recurring uncertainty about who could make a decision, who could block one, and which system represented the truth. A cleaner interface placed over that structure would have made the disorder more attractive without making it more coherent.
No One Held the Complete Model
The first important realization was that no discipline, team, or executive possessed a complete representation of the problem.
Product leaders understood the commercial transition toward cloud licensing, subscriptions, and consumable services. Engineers understood the behavior of individual systems. Support teams knew where customers became confused and where internal explanations routinely failed. Designers could see interaction patterns repeating beneath interfaces that looked unrelated. Architects understood dependencies whose consequences were invisible at the surface.
Each perspective was accurate, but incomplete.
Complex transformations rarely suffer from a shortage of intelligent people. They suffer because intelligence remains partitioned. The expertise exists, but the organization provides too little surface area for one form of perception to alter another before decisions harden into commitments.
I did not arrive with the best answer, nor did I have the domain knowledge to manufacture one alone. Pretending otherwise would have narrowed the solution to whatever I happened to understand first. My role was to compose the conditions under which the organization could construct an answer that no participant held independently.
This is what I now call designing the collaborative surface.
Composing Capability, Not Merely Staffing a Team
Job titles told me who had been assigned to the work. They did not tell me how each person could improve it.
One visual designer had an exceptional ability to identify convergence. They could examine a collection of filtering experiences, recognize the common interaction beneath their cosmetic differences, and formulate a universal pattern without discarding the distinctions that genuinely mattered.
An architect on the team could map legacy dependencies with extraordinary fidelity. Where others saw a collection of applications, they saw technical sediment: services layered over earlier services, business rules embedded in unexpected places, and changes whose effects would propagate through systems that appeared unrelated.
Product and business partners understood how licensing models were changing. Customer-facing teams understood the difference between complexity the business genuinely required and complexity customers had simply been forced to tolerate. Engineering understood what could be changed directly, what required sequencing, and what needed to remain on life support while the new platform assumed responsibility.
These were not interchangeable representatives of functions. They were distinct capability vectors: differentiated ways of perceiving and acting upon the same problem.
The team became useful when those vectors entered productive contact. A technical constraint might alter a design pattern, which could expose a commercial opportunity significant enough to justify retiring a legacy dependency that had previously seemed permanent. Value emerged in the movement between contributions.
Making the Inherited System Legible
Before we could modernize the experience, we had to understand the system that produced it.
We began with ownership. Who controlled each system? Who could authorize a change? Who could delay or veto one? Where were decisions actually made, and where were they merely recorded after the fact?
This was as much an organizational audit as a technical one. A dependency diagram could tell us that one service called another. It could not tell us why a local team had preserved a particular rule, which executive promise had made that rule politically durable, or which support workflow quietly compensated for its failures. The formal architecture and the lived architecture were not the same.
Making both visible changed the conversation. Teams that had previously argued from local truth could see the full licensing path. Conflicts that had sounded like disagreements about interface design were often revealed as disagreements about ownership, sequencing, or the definition of the underlying object. We could stop negotiating symptoms and begin negotiating the system.
Transparency was not a reporting exercise. It was design material.
I had no formal authority over most of the systems involved, so progress could not depend upon mandate. It depended upon shared legibility, credible facilitation, and relationships strong enough to support decisions whose benefits crossed organizational boundaries. People had to see not only what we proposed, but how their constraints had influenced it.
Establishing a Working Language
Collaboration across disciplines becomes expensive when every participant must continuously translate both the problem and themselves. Shared language lowers that cost.
At Autodesk, we used Myers–Briggs as one provisional vocabulary for discussing differences in working and communication styles. I do not regard a personality instrument as a permanent taxonomy of human beings; people are more contingent and interesting than four letters can contain. Its value was more modest and more practical. It gave the team permission to discuss how we processed information, reached conclusions, and responded to ambiguity without treating those differences as defects.
That kind of exercise can look adjacent to the work. In practice, it helps establish the interaction protocol through which the work becomes possible. A person who needs time to synthesize is not disengaged. A person who tests an idea aloud is not necessarily committed to it. A specialist who insists upon precision may be protecting a dependency the rest of the room cannot yet see.
We were not pursuing interpersonal harmony. Productive contact requires friction made useful. Shared language helped us distinguish generative tension from avoidable misinterpretation, allowing more of the team’s actual capability to reach the decision.
Designing the Convergence Layer
The solution was not a clean-sheet replacement for everything Autodesk had accumulated. That would have been elegant in a diagram and reckless in operation.
Instead, we designed a modern licensing portal that functioned as a convergence layer. It gave customers and internal teams a coherent place to manage licenses, subscriptions, cloud credits, and access while the underlying ecosystem transitioned at a pace its dependencies could tolerate.
Visually and behaviorally, disparate experiences began to resolve into common patterns. Operationally, licensing decisions moved into a shared flow rather than being translated across disconnected systems. New subscription models could coexist with older licensing structures. Customers encountered a comprehensible platform even while portions of the legacy architecture remained active beneath it.
This was transformation without amnesia.
We did not pretend the company’s history could be erased. We made that history legible, determined which parts still carried essential value, and constructed a sequence through which responsibility could move from inherited systems to the new platform. Some dependencies were removed. Some were contained. Some remained alive long enough to protect customers from the consequences of our transition.
The interface was the visible artifact. The deeper design was the migration of coherence.
Productive Contact
The collaborative surface changed what the team could know and therefore what it could build.
Design pattern recognition reduced unnecessary variation without flattening meaningful product differences. Dependency mapping prevented attractive ideas from becoming operational hazards. Commercial context ensured that the platform supported the company Autodesk was becoming rather than merely reorganizing the company it had been. Support and customer knowledge kept internal elegance from outranking external comprehension.
These capabilities did not take turns. They revised one another.
That is the difference between participation and composition. Participation invites people into the room. Composition creates consequential relationships among what they know. A large meeting can still have a very small collaborative surface if hierarchy, vocabulary, or facilitation prevents one perspective from changing another. Conversely, a compact team can have an expansive surface when its differences are made visible and placed into deliberate contact.
At Autodesk, that contact allowed us to make decisions across technical, commercial, operational, and experiential boundaries without requiring any participant to become an expert in every domain.
Outcome
The result was a quantum leap from a fragmented, widely disliked portal to a modern platform capable of supporting Autodesk’s transition toward cloud licensing, subscriptions, and consumable services.
Customers gained a more coherent way to understand and manage access. Internal teams gained a shared operational view of licensing rather than a collection of partial records. Support friction declined because fewer issues required translation across incompatible systems and ownership boundaries. Decisions could move through a common flow, and responsibility became more explicit.
The modernization also avoided destabilizing the business it was meant to improve. Legacy systems remained on life support where necessary while customers and operational responsibility moved deliberately onto the new platform. The organization could advance without making its customers absorb the violence of the transition.
The work was recognized when I was named to Autodesk’s CEO Top 5 Up-and-Coming list. I value that recognition, but it is not the evidence I return to. The stronger evidence is that a system no single person fully understood became coherent enough for many people to change together.
What This Case Taught Me
Autodesk clarified a principle that has followed me through every complex domain since: the sophistication of the solution is constrained by the composition of the room and by the quality of the contact the room permits.
The visual designer did not need to become an architect. The architect did not need to become a customer researcher. Product did not need to dictate the interface, and design did not need to claim authority over the business. Each person needed enough shared language to place a distinctive capability into consequential contact with the others.
That is the philosophy in its most compact form:
Collaborative Surfaces × Capability Vectors = Productive Contact
The portal mattered. The licensing transition mattered more. But the enduring result was a way of working: make the whole system visible, compose the right forms of perception around it, and facilitate their interaction until the organization can produce an answer that none of its disciplines brought into the room.
I contribute at the edge of what I know, then use collaboration to move that edge.