An Aching Bone

Oct, 2025

Designing a Backbone for Experimental Work

After the project I wrote about in my previous post, I realized the issue wasn’t only communication or personalities. What was missing was a backbone—a simple structural logic that could carry ambitious, experimental work without requiring constant heroics from everyone involved.

The diagrams that came out of that period are my attempt at such a backbone.

They are meant to answer three practical questions:

1. When does exploration need to turn into commitment?

2. When we say “we’ll produce this,” what does that actually entail?

3. Given finite time, budget, and talents, where should work happen—inside the studio, with external partners, or through a hybrid setup—and who owns those choices?

This post is about what each layer of that framework is designed to do, and how I plan to use it in future projects.

1. Creating Common Knowledge

The first purpose of the framework is to create what cognitive scientists call common knowledge—a state where everyone not only knows the plan, but knows that everyone else knows it too.

In his recent book When Everyone Knows That Everyone Knows, Professor Steven Pinker—Johnstone Professor of Psychology at Harvard—argues that the distinction between private knowledge and common knowledge is one of the most consequential in human coordination. It's not enough for everyone to know something individually; coordination requires that everyone knows that everyone knows. Without that recursive awareness, people act on private assumptions, unsure whether others share them.

This maps precisely onto what I observed in exhibition-scale collaboration. People often inhabit different versions of reality:

•       A creative lead thinks in ideas, materials, and experiences.

•       Fabricators think in sequences, industrial capacity, machines and tools.

•       Producers think in contracts, deadlines, and external promises.

Each group believes it is working on "the project," yet the project they have in mind differs in scope, risk, and level of detail. Worse, each group often assumes the others share their understanding—a phenomenon Pinker calls pluralistic ignorance: mistaking others' public conformity for private agreement. Late-stage "surprises" are usually the visible collision of these hidden, divergent maps.

The pipeline diagram is a tool for generating common knowledge. It maps the journey from concept through planning and fabrication to installation and opening. Everyone can point to the same line and say, "This is where we are. This is what needs to be true before we move on." Crucially, they can say it in front of each other—which transforms private understanding into shared, public reality.

In practice, I will use it to:

•       Start new projects with a shared walkthrough of the full journey.

•       Ask each stakeholder to mark where they see their role and where they depend on others.

•       Return to the same visual at key moments and ask, "Are we still exploring, or are we already in execution?"

The goal is not just shared information, but shared awareness of that information—so that decisions in one part of the system are made with confidence that others understand the implications.

2. Distinguishing Exploration From Execution

A second function of the framework is to clarify which kind of work the project is doing at a given moment.

Early on, the work benefits from being open-ended. This is where sketches, maquettes, material tests, and speculative questions belong. Later, the work benefits from stability. Vendors are booked, materials ordered, and people are committing their time on the assumption that certain things will not move every few days.

The pipeline marks a deliberate shift between these modes. At a certain point we say, essentially:

•       "We have explored enough variants to make informed choices."

•       "From here on, changes carry explicit cost and schedule implications."

This transition, too, needs to be common knowledge. It's not enough for the producer to believe the project has entered execution if the creative lead privately thinks exploration is still open. The framework makes the phase transition public—announced, recorded, and visible to everyone at once.

In future projects, I intend to formalize this transition:

•       There is a clear moment when we state that the project has entered production.

•       Design changes after that point are accompanied by a short explanation of why they are essential and what impact we accept in exchange.

Change remains possible; the framework simply requires us to look directly at what each change demands from the rest of the system. This respects both the early wildness of the work and the later need for reliability around people and resources.

3. Treating Production Strategy as Design

Another lesson from the project was that questions of where things are made are often handled informally, even though they shape everything downstream.

Whether a component is fabricated in-house, outsourced, or split across a hybrid arrangement affects:

• cost and speed,

• quality control,

• who needs to be in the room for which decisions,

• and how much stress lands on the internal team.

The constraint diagram is a prompt to treat production strategy as a design decision.

It asks, for each major element of the work:

• Does this require specialized equipment or processes that we do not have?

• Is this piece central to the identity of the exhibition and therefore better held close?

• What does our internal capacity really look like—skills, time, and managerial bandwidth?

• Which risks are we comfortable managing through vendor relationships, and which need daily oversight?

I plan to use this lens at three moments:

• At kickoff, to have a frank conversation about limits and tradeoffs.

• Midway, to compare the intended distribution of work (internal/external/hybrid) with the reality.

• Afterwards, as a tool for reviewing what worked and what needs adjusting next time.

Putting these questions into a visual form makes them much easier to discuss across roles and seniority levels.

4. Aligning Authority With Responsibility

For me, the most important role of this framework is that it helps connect decision-making power with responsibility for outcomes.

In a complex project, many people influence scope, schedule, and safety: changing a material, adding a feature, revisiting a joint detail. Each of these choices can be valid, but none are neutral. They consume time, budget, and attention.

The framework gives me language to say, for example:

•       "This is a late-stage change; if we adopt it, here is what it means for fabrication and installation."

•       "If someone wants the authority to reopen this question now, they also need to be part of solving the consequences."

This is where Pinker's insight about common knowledge becomes most consequential. When consequences are stated publicly—in a shared document, in a meeting where everyone is present—they become common knowledge. Everyone knows the tradeoff, and everyone knows that everyone knows. That changes the social dynamic entirely. It becomes much harder to later claim ignorance, or to let consequences slide onto whoever is least positioned to refuse them.

The framework shifts conversations away from personality ("you're too rigid," "you're too demanding") and toward structure:

•       Which phase are we in?

•       What kind of decisions are appropriate here?

•       Who is accountable if this goes wrong, and do they agree with the change?

In future workflows, I want these visuals to function as a kind of lightweight social contract. They don't replace legal agreements; they sit alongside them and make it harder for consequences to migrate invisibly onto whoever is least able to refuse them.

5. From One Difficult Project to a Reusable Practice

These diagrams grew out of one specific project, but the underlying issues they address are common: unclear phases, unspoken assumptions, and mismatches between artistic authority and operational responsibility.

I now see them as living tools:

• adjustable for each new collaboration,

• useful for surfacing disagreements before they harden into crises,

• and valuable as records of what we believed the system to be at any given time.

If the first essay I wrote was about noticing how "greatness" can quietly become someone else's burden, this one is about the next step: designing simple, shared structures that transform private assumptions into common knowledge—visible, discussable, and therefore negotiable.

There is a deeper principle here: the denser the common knowledge, the less it costs to be flexible. When everyone already understands the constraints, dependencies, and stakes, a proposed change can be evaluated quickly—you don't have to re-establish shared reality before discussing the adjustment itself. Structure doesn't constrain flexibility; it subsidizes it. The upfront investment in common knowledge reduces the marginal cost of each subsequent change.

That is the kind of infrastructure I want to build around future experimental work—strong enough to carry the weight of ambition, and flexible enough to let the work still surprise us.