Designing the Collaborative Surface

Yesterday, someone asked me to describe my design philosophy.

I gave the sort of answer an experienced designer learns to produce when unexpectedly asked to compress a career into something conversationally manageable. I talked about human-centered design, Design Thinking, Lean UX, and the Five Ds. I may have mentioned iterative validation. If given another minute, I probably would have found a way to work “double diamond” into the answer and complete the entire collection.

None of it was wrong. I have used those methods, taught them, modified them, and discarded portions of them when circumstances demanded it. They are useful frameworks, but they are not my design philosophy. Confusing the two is like describing your philosophy of cooking by listing the utensils in your kitchen.

The question stayed with me because my answer felt conspicuously incomplete. After reflecting on the teams I have built, the products I have helped create, and the conditions under which my best work has emerged, I arrived at something more precise:

I build collaborative surfaces that bring distinct capability vectors into productive contact.

Yes, “collaborative surfaces” and “capability vectors” sound like terms a consultant might charge by the syllable to explain. Every design paper is apparently required to invent a vocabulary, and I see no reason this one should be denied the pleasure. In my defense, I chose these words because the familiar alternatives—collaboration, cross-functional teams, expertise, participation—were insufficiently precise. They describe the presence of people without adequately describing the topology of their interaction.

If that distinction sounds academic, stay with me. The consequences are entirely practical.

---

Methods Are Not Philosophies

A design method gives a team a repeatable way to move through a class of problems. A philosophy determines how I understand the problem before selecting the method. It shapes who participates, what knowledge is considered legitimate, how disagreement is metabolized, and what conditions must exist before a group can produce something better than the aggregation of its individual contributions.

I use frameworks pragmatically. Lean UX can help a team expose assumptions and accelerate learning. Human-centered design can redirect attention toward the lived experience of the people affected by a system. Design Thinking can help an organization widen its inquiry before converging on a solution. None of these, however, relieves me of the responsibility to compose the right team, establish a shared vernacular, govern the interaction, or facilitate the encounters through which different forms of intelligence become mutually useful.

A framework can organize activity. It cannot guarantee cognition.

My philosophy begins with a simple admission: I do not possess the whole answer, and neither does anyone else in the room. This is not ritual humility. It is an operational premise. Complex products sit at the confluence of human behavior, organizational incentives, technical dependencies, commercial constraints, historical accidents, and institutional politics. No single discipline can perceive that entire system with equal fidelity.

The appropriate response is not to search for a sufficiently brilliant individual. It is to compose intelligence.

---

Capability Vectors

Organizations tend to describe people through disciplines and titles: visual designer, architect, researcher, product manager, engineer. Those labels are administratively convenient, but they reveal surprisingly little about how a person changes the quality of a decision.

I have worked with a visual designer who could examine a dozen disparate filtering experiences and recognize the universal interaction pattern hidden beneath them. Her value was not exhausted by the phrase “visual design.” She possessed an exceptional capacity for pattern convergence: the ability to perceive that apparently different interfaces were variations of the same underlying problem.

I have worked with an architect who could map legacy dependencies with a fidelity no one else could approach. He could see the technical sediment accumulated over years of compromises and explain how a seemingly local change would propagate through systems most of us did not know existed. “Architect” was his title. Systemic dependency mapping was one of his defining capabilities.

These are capability vectors: distinct ways of perceiving, evaluating, or transforming a problem that materially alter the solution available to the team. I borrow “vector” deliberately. A vector has both magnitude and direction. Two people with equivalent seniority may exert profoundly different forms of influence because their capabilities point toward different dimensions of the problem.

A person is not a capability vector, nor does each person possess only one. People carry constellations of abilities, some formal and some tacit, some obvious on a résumé and others visible only after watching them work. The leader’s task is to recognize which of those capabilities matter to the problem and compose a team whose perceptual range exceeds that of any individual member.

This is why I build vertical teams. I am not simply placing representatives from multiple functions into the same meeting. I am trying to create vertically complete decision-making: enough complementary perception in one working system to examine an initiative from customer experience through technical feasibility, commercial viability, operational durability, and organizational consequence.

That composition does not eliminate specialization. It depends upon it. The visual designer does not need to become an architect, and the architect does not need to become a researcher. The value resides in the difference between them—and in our ability to make that difference productive.

---

Collaborative Surfaces

A collaborative surface is the set of opportunities through which different capabilities can meaningfully influence a decision before it becomes expensive or irreversible. Its size is not determined by the number of people invited to a workshop. A room can be crowded and still offer almost no genuine surface for collaboration.

I have attended ostensibly collaborative sessions in which the consequential decisions had already been made, the permissible questions had been tacitly constrained, and participation existed primarily to manufacture the appearance of consensus. That is not a collaborative surface. It is theater with sticky notes.

A large collaborative surface permits relevant expertise to enter early, allows assumptions to be interrogated before they harden into requirements, and creates multiple points at which the trajectory of the work can change. It does not mean that every person makes every decision or that all opinions carry equal weight. I am not describing plebiscitary product development. Leadership still requires judgment, curation, and accountability.

The surface exists so that judgment can be informed by more than the leader’s original field of view.

When I lead an initiative, I deliberately enlarge that surface. I invite people to contribute from where they stand: the engineer who sees an architectural constraint, the researcher who recognizes a behavioral pattern, the support lead who hears the same customer frustration every week, the accessibility specialist who identifies an exclusion everyone else has normalized. Each contribution changes what the group is capable of seeing.

If well facilitated, those contributions do not merely compete until one survives. They recombine. A technical constraint may alter a design pattern; the revised pattern may reveal a commercial opportunity; the commercial opportunity may justify retiring a legacy dependency that previously seemed immovable. The final solution becomes hybridized—its intellectual provenance distributed across the room.

This produces a second outcome that is psychological but no less consequential: everyone leaves a fingerprint on the work. People tend to support what they help create, not because participation tricks them into compliance, but because they understand the reasoning embodied in the result. Even when their preferred idea is not selected, they can see where their contribution affected the synthesis.

Shared ownership is not manufactured after the decision. It is designed into the process through legitimate influence.

A broad collaborative surface can make the beginning of the work feel slower because it admits consequential questions before execution begins. In practice, that early friction often accelerates everything that follows: fewer late discoveries, fewer reversals disguised as refinements, and less time spent manufacturing support for decisions people were never allowed to influence.

If I were forced to reduce this to an equation—and apparently I am—it might look like this:

CS × CV = PC

Collaborative Surfaces × Capability Vectors = Productive Contact

It looks reassuringly scientific, sounds expensive, and could almost certainly sustain three unnecessary presentation slides. More importantly, it captures the reciprocal relationship between composition and interaction. Distinct capabilities without a collaborative surface remain isolated. A large collaborative surface without distinct capabilities amplifies redundancy. The value emerges when differentiated ways of seeing are brought into consequential contact.

---

Preparing the Surface

Putting capable people together does not automatically make their capabilities interoperable. Before a collaborative surface can function, its participants need enough mutual understanding to interpret one another’s contributions. They need some awareness of how others communicate, respond to uncertainty, process disagreement, and revise their thinking.

At Yahoo!, I took my team to an improv class. The exercise was not an eccentric diversion from “real work.” Improv develops attentiveness, trust, and the ability to extend another person’s contribution rather than reflexively replacing it with your own. A team becomes more generative when its members can treat an unexpected idea as material instead of interference.

At Autodesk, we used Myers–Briggs to discuss working and communication preferences. I do not regard a personality inventory as a taxonomic revelation of someone’s immutable nature. Used with appropriate skepticism, however, it can provide a provisional vocabulary for differences that teams otherwise experience only as friction. The point was not to assign identities. It was to make interaction more legible.

At CA Technologies, shared reading became part of the connective tissue of the Accelerator project. Ash Maurya partnered with us, and every founder received a signed copy of his book. We accumulated a bookshelf of Lean literature: Lean Canvas, Lean UX, Lean Startup, Lean everything. Had someone published Lean Lunch, we probably would have bought that too. I should probably check whether anyone has published something Lean AI–adjacent by now.

The library did not exist to make everyone think alike. It gave founders, designers, engineers, and business leaders a common language for discussing assumptions, experiments, evidence, and learning. Shared vocabulary reduced the cognitive overhead of translating between professional dialects. We could spend less energy establishing what we meant and more energy examining whether it was true.

The language of Git played a similar role at Dremio. Branches, commits, histories, merges, and conflicts were not merely technical terms; they carried mental models that people from different disciplines could use to reason about the product together. A shared vernacular did not eliminate differences in expertise. It made those differences communicable.

This distinction matters. Homogeneity of language need not produce homogeneity of thought. At its best, shared vernacular allows people to think differently while remaining mutually intelligible.

The purpose of a common framework is not to standardize cognition. It is to make diverse cognition interoperable.

---

Governing the Surface

Every room contains hierarchy, whether we acknowledge it or not. Personalities arrive with reputations, authority, loyalties, grievances, and varying confidence in their right to speak. Inviting everyone to participate does not neutralize those forces. A collaborative surface without governance will eventually be governed by the strongest personality in the room.

Before substantive work begins, I establish the rules governing the surface and ask the group to agree to them. We define how decisions will be made, how disagreement will be handled, what belongs within the session, and what will be placed in a parking lot for later consideration. This is not administrative preamble. It is the provisional constitution of the room.

The agreement matters most when the most important person present takes the conversation on a tangent. A facilitator must be able to acknowledge that the issue is legitimate but not germane, place it visibly in the parking lot, and return the group to its purpose. If rank exempts someone from the rules, the collaborative surface immediately contracts around that person.

This is where collaboration meets transparency and trust. A command-and-conquer leader can participate, but only after agreeing that authority will not determine the topology of the conversation. Without that agreement, everyone else quickly learns that participation is ceremonial and begins editing themselves accordingly.

The most powerful person in the room must agree to be governed by the surface before the surface can be trusted by anyone else.

When a room becomes too hot, the facilitator protects the inquiry from becoming personal. When it becomes too quiet, the facilitator examines what—or who—has made candor expensive. In either case, the task is not to restore comfort. It is to restore productive contact.

This is also why my natural intervention is rarely, “I think you are wrong.” That phrase can be appropriate, but it directs the conversation toward the correctness of a person and the defense of a conclusion. I am more likely to ask, “Have we explored the alternatives?” or “What have we ruled out?” The questions challenge the completeness of the inquiry rather than the legitimacy of the person offering the idea.

They also expand the collaboration surface. Each question creates another place where someone’s knowledge can enter and alter the outcome.

---

Making the Work Legible

A collaborative surface must be intelligible not only to the people participating in it, but also to the organization surrounding it. This is particularly important when the work does not resemble the organization’s conventional image of productivity.

At Yahoo!, we conducted an ethnographic study and covered one side of an enclosed skybridge with our findings. The bridge connected two buildings, stretched perhaps half the length of a football field, and had solid glass windows running along both sides. We filled an extraordinary amount of it with Post-it notes. I briefly considered buying stock in 3M.

Inside the design team, the wall represented observation becoming pattern. Individual fragments could be moved, juxtaposed, contested, and synthesized until relationships emerged that none of us could have perceived from the raw research alone. The physical scale was not decorative. It gave the inquiry enough surface area to become collectively intelligible.

To many people outside design, however, it looked like a colossal waste of time. Engineers and product managers saw a group of people at a technology company standing in a hallway instead of sitting in front of computers. They could see the activity but did not possess the vernacular necessary to interpret it as work.

That experience taught me that a collaborative surface is not self-explanatory. The people working within it may understand how observation becomes inference and how inference becomes design, while the surrounding organization sees only conversation, colored paper, and an alarming consumption of office supplies.

It is therefore not enough to create the surface. Leaders must also build translation interfaces around it: explaining what the group is doing, what forms of evidence it is producing, how decisions will emerge, and why this mode of work is appropriate to the problem. Otherwise, the organization will evaluate an unfamiliar cognitive process using the visible conventions of familiar production.

In a technology company, work performed at a computer looks like work. A group thinking together may look like it has wandered away from it.

This is an organizational bias toward production over sensemaking. Production leaves artifacts the company already knows how to count: code commits, completed tickets, roadmaps, releases. Sensemaking often leaves fragments whose significance exists in their relationships rather than their volume. The wall of Post-it notes was not the outcome. It was an instrument through which the team could perceive an outcome that had not yet become obvious.

The skybridge was doing two jobs. It was a cognitive surface for the design team and a potential translation surface for the wider company. The first worked. The second needed more deliberate design.

A collaborative surface that only its participants understand will remain fragile. The surrounding organization must be able to recognize why the work exists, how it changes decisions, and what becomes possible because people temporarily stepped away from their individual screens.

---

LEVEL Studios: Predictability Through Proximity

In agency work, uncertainty becomes contractual. Before a team has done the work, someone must define it, estimate it, assign skills to it, and translate all of that into a statement of work a client is willing to sign.

At LEVEL Studios, I became almost freakishly accurate at estimating the hours required for a project. This was not an occult gift, nor was it simply the residue of experience. It was the result of designing forward teams that could go to a client site, engage directly with the people who understood the problem, and quickly assemble enough heterogeneous data points to SWAG a credible SOW.

Design, technology, strategy, delivery, and client knowledge were present early enough to influence the estimate. Each capability reduced a different category of uncertainty. The resulting forecast did not depend upon one person’s intuition being miraculously correct; it emerged from a collaborative surface designed to expose what isolated estimation tends to miss.

The practical outcome was predictability. We could move quickly without confusing speed with recklessness, and we could establish commercial expectations that remained credible once the actual work began.

---

Autodesk: Transformation Without Amnesia

Autodesk’s legacy portal was not a coherent product waiting for a visual redesign. It was an accumulation of disparate experiences, business rules, and legacy systems that had acquired interdependencies over time. Customers experienced the fragmentation at the surface, but much of its causality lived deep inside the organization’s technical and operational history.

We assembled a team capable of perceiving the problem vertically. Visual design could identify recurrent patterns across inconsistent interfaces. Architecture could map dependencies that constrained the migration sequence. Product and business expertise could explain cloud licensing and the purchasing of consumables. Customer-centered disciplines could distinguish necessary complexity from complexity the organization had simply learned to tolerate.

Together, we transformed a hated portal into a modern, comprehensible platform while keeping the legacy systems on life support long enough to transition customers away from them. We could not indulge in the fantasy of a clean-sheet redesign followed by a ceremonial switch-flip. The new experience had to coexist with the old infrastructure, progressively absorbing its responsibilities without interrupting the people who depended upon it.

The result was, honestly, a quantum leap. Yet the interface was only the visible manifestation of the achievement. The deeper accomplishment was collective legibility: we made enough of the system intelligible to enough of the right people that we could change it without pretending its history did not exist.

---

CA Technologies: Velocity Through Precomposed Capability

The Accelerator project at CA Technologies demonstrated what this philosophy could produce at speed and scale. We could spin up a new startup in under a month, including funding, hiring, problem validation, MVP definition, and the beginnings of credible marketing and sales plans.

UX design was hands-on throughout that process. We worked directly with founders to determine whether the proposed problem deserved to be solved, examine the people and contexts surrounding it, and define the smallest product capable of generating meaningful evidence.

My agency experience resurfaced here. I could help founders translate an emerging concept into approximate design and engineering hours, identify the capabilities necessary to build it, and create a plausible scope for the MVP. The estimating mechanics were familiar, but the surrounding collaborative surface was broader. Funding, hiring, design, engineering, marketing, and sales were not sequential services waiting downstream. They were capabilities available to influence the venture while it was still malleable.

That composition made the Accelerator fast, but speed was not its most important property. The more significant capability was reconfiguration. When evidence contradicted an assumption, we could pivot without rebuilding the entire organization around the new direction. We changed the composition of the conversation, brought different capabilities into contact with the problem, and moved.

The Accelerator did not merely make individual startups faster. It made the organization better at repeatedly creating startups.

---

Dremio: Contributing at the Edge of Knowledge

I entered Dremio with only marginal domain knowledge. I was not a data analyst, and I did not pretend to possess fluency I had not yet earned. Within approximately six months, however, I was producing meaningful designs for SQL editors, data repositories, and sophisticated analytical workflows.

I did not spend those six months studying from the sidelines. I began with interfaces where my existing capabilities could contribute immediately, particularly the first-time experience. Onboarding sits at an unusually productive intersection: designing it requires understanding what new users expect, where the product’s conceptual model diverges from those expectations, and which elements of domain complexity must be introduced in what sequence.

The work produced immediate value while functioning as a form of situated learning. Engineers, product leaders, data experts, customers, and the product itself supplied context I did not possess. I contributed interaction design, systems thinking, pattern recognition, and the epistemic advantage of not yet having normalized the domain’s assumptions.

Over time, the boundary moved. I developed enough fluency to work on increasingly specialized surfaces without needing to become a data analyst myself. I could combine my design capability with the domain expertise surrounding me, allowing designers who were not analysts to help create what I regard as a best-in-class analytics cockpit.

Dremio taught me how to describe a practice I had followed for years:

I contribute at the edge of what I know, then use collaboration to move that edge.

This is not unique to me, nor should it be. A well-composed team does not require every participant to possess every capability before meaningful work begins. It creates a surface through which knowledge and capability can travel. People contribute while learning, and they learn through consequential contribution.

The alternative is to treat domain expertise as an admission requirement: first master the territory, then earn the right to influence it. That approach undervalues the outsider’s perception precisely when it is most acute. Newcomers notice terminology, assumptions, and conceptual discontinuities that experts have learned to see through. The objective is not to preserve naïveté, but to convert it into insight before familiarity erases it.

A productive collaborative surface allows the domain to benefit from the newcomer while the newcomer is learning the domain.

---

Facilitation as Design

None of this happens merely because a leader invites more people into the room. Enlarging a collaborative surface without facilitating it can increase noise, diffuse accountability, and reward the most socially dominant participants. Collaboration has failure modes, and participation is not intrinsically virtuous.

Facilitation is therefore not ancillary to my design philosophy. It is the mechanism that converts heterogeneous capability into synthesis.

Good facilitation establishes where influence is still possible, identifies which perspectives are missing, makes assumptions available for examination, and prevents hierarchy from masquerading as evidence. It creates enough psychological safety for someone to ask whether the team has adequately explored the alternatives without requiring the conversation to become adversarial.

It also requires a willingness to close portions of the surface at the appropriate time. Divergence cannot continue indefinitely. There is a point at which leaders must synthesize what has been learned, make a decision, explain its provenance, and accept responsibility for the consequences. A collaborative surface is not successful because it remains perpetually open. It is successful when it improves the quality and legitimacy of what eventually emerges from it.

This changes how I understand leadership. My job is not to have the best idea in the room. It is to compose the room, prepare its language, govern its interaction, and facilitate the encounters through which the room can produce ideas none of us would have had alone. I remain responsible for the decision, but authorship of the thinking is deliberately distributed.

If the surface depends upon my presence to remain productive, I have designed a dependency rather than a capability. The vernacular, ground rules, and facilitation practices must become legible enough for others to reproduce and adapt, allowing productive contact to survive the absence of the person who first composed the room.

The distinction is not semantic. Leaders who optimize for personal authorship progressively shrink the surface through which corrective information can reach them. They may become more efficient at issuing decisions while the organization becomes less capable of learning. Leaders who design for collective cognition accept a more demanding premise: authority increases responsibility without conferring omniscience.

---

Outcomes, Not Ceremonies

The outcome of a well-designed collaborative surface is not more collaboration. Collaboration is a mechanism, not a deliverable.

At LEVEL Studios, the outcome was unusually accurate estimation and greater commercial predictability. At Autodesk, it was the safe modernization of a fragmented customer experience without abandoning the legacy systems still supporting it. At CA Technologies, it was the repeatable ability to fund, staff, validate, and launch new ventures with extraordinary velocity. At Dremio, it was the ability of designers to cross a formidable domain boundary and contribute to specialized analytical products without surrendering what made them valuable as designers.

Across these examples, the recurring outcomes are better prediction, faster learning, safer transformation, stronger ownership, and solutions whose sophistication exceeds the independent capacity of any participant.

That is why I resist describing my philosophy as Lean UX, Design Thinking, human-centered design, or any other named methodology. I will continue to use all of them when they are useful. They are instruments for structuring inquiry, exposing assumptions, and making work visible. They can help prepare the collaborative surface, but they do not tell me how to compose the capabilities the problem requires or how to make those capabilities interoperable.

The philosophy sits above the framework.

I build collaborative surfaces because complex problems deserve more than one way of seeing. I seek capability vectors because professional titles are poor proxies for the forms of intelligence people actually contribute. I establish shared vernacular because difference is useful only when it can become mutually intelligible. I govern the surface because hierarchy and personality will otherwise govern it for me. I make the work legible because unfamiliar forms of cognition are easily dismissed by organizations that cannot see what they produce. I facilitate synthesis because a collection of perspectives does not spontaneously become collective intelligence.

Most of all, I do this because I know I drift. I have blind spots, preferences, habits, and convictions that can quietly harden into constraints. I do not regard awareness of that fallibility as a reason to surrender judgment. I regard it as a reason to design relationships and working systems that make correction possible.

My design philosophy is therefore not a preferred sequence of activities. It is a theory of composition: bring distinct capabilities into consequential contact, give them enough shared language to interact, establish rules strong enough to withstand hierarchy, and create the conditions under which their collisions can produce something none of us brought into the room.

That is how I build teams. It is how I enter unfamiliar domains, modernize inherited systems, estimate ambiguous work, and help organizations move faster without asking them to think less.

I contribute at the edge of what I know, then use collaboration to move that edge.