Everyone Hates the Spreadsheet, But Nobody Deletes It

Every large organization I have heard about has a spreadsheet that should not exist. It lives on a shared drive or, worse, in someone's email. It is updated manually, usually by one person who has become the unofficial keeper of it and who has tried twice to retire it. The enterprise system was supposed to replace it. The enterprise system costs several hundred times more than the spreadsheet. The spreadsheet still exists.

Star and Griesemer published their boundary objects paper in 1989. They were writing about a natural history museum, specifically how a museum could coordinate work across scientists, amateur trappers, and university administrators who had completely different vocabularies, different goals, different standards of what counted as good evidence, and different ideas about what the museum was actually for. These were not people who disagreed about small things. They had fundamentally different ways of understanding the same objects and the same work. And yet the museum functioned. Coordination happened. The question Star and Griesemer asked was: what holds that collaboration together when shared understanding is absent?

Their answer was the boundary object. A boundary object is an artifact, a document, a category, a map, a form, that is plastic enough to adapt to local needs and local vocabularies, while remaining robust enough to maintain a common identity across the different communities using it. The key phrase is "plastic enough to adapt but robust enough to maintain." Plasticity without robustness is just noise. Robustness without plasticity is a system nobody can actually use. The boundary object sits in the middle.

They identified four types. Repositories are collections that different groups can draw from without interacting, like a data archive. Ideal types are objects abstract enough that each community can interpret them through its own lens, like a species name that a taxonomist and a field naturalist use to mean somewhat different things. Coincident boundaries are objects that contain the same thing for everyone but mean different things within it, like a map of a region that different groups mark up differently. Standardized forms are objects that allow communication across groups by requiring a common format while allowing local interpretation of what goes into it.

The spreadsheet is a standardized form. That is why it survives. Finance reads the revenue columns. Operations reads the delivery dates. Sales reads the customer names. Each team adapts its columns, its color coding, its naming conventions. None of those local adaptations prevent any other team from opening the file and reading what they need. The format is shared. The meaning is local. That is the structure of a boundary object, and it is exactly what makes it resistant to replacement by systems that are too precise.

Carlile (2002) extended this into IS in a way I find genuinely useful. He argued that boundaries between organizational communities operate at three levels. The syntactic boundary is about shared language: do we use the same terms? The semantic boundary is about shared meaning: do we mean the same thing by those terms? The pragmatic boundary is about shared interest: even if we understand each other, are we willing to work together given our different goals? Boundary objects do different work at each level. A standardized form solves a syntactic problem. A prototype solves a semantic one. A jointly developed specification solves a pragmatic one. The implication for IS is that designing a coordination artifact requires knowing which type of boundary problem you actually have.

Levina and Vaast (2005) added a distinction that I think is important: a boundary object is not a property of the artifact but a property of how the artifact is used. The same spreadsheet can function as a boundary object in one organization and fail to do so in another, depending on whether the groups involved have actually developed a shared practice around it. An artifact becomes a boundary object in practice, not by design alone. That is why implementing a new enterprise system and announcing "this replaces the spreadsheet" does not actually work. The spreadsheet is a boundary object because practice made it one. The new system has not earned that status yet.

The IS implementation failure I keep seeing fits this pattern. A new system is designed for one audience with great precision: it is exactly what the finance team needs, with the exact terminology and the exact workflow finance uses. And then product, operations, and engineering are expected to adopt it. But the precision that makes it perfect for finance is the same thing that makes it confusing for everyone else. The finance terms do not match engineering vocabulary. The workflow sequence does not match how operations actually proceeds. The system is too precise to function as a boundary object. It requires shared meaning rather than allowing local interpretation. And so people keep their own versions of the spreadsheet.

Dashboards are another version of this. A dashboard that is built around the CFO's view of the world gives the CFO exactly what they need. It gives everyone else a report designed for someone else's mental model. The dashboards that survive and become genuine coordination artifacts tend to be the ones that are slightly underspecified: they provide enough shared structure that different groups can orient themselves, while leaving enough flexibility that each group can read the artifact through its own lens. That is the boundary object logic applied to analytics.

I think the design lesson from boundary object theory runs counter to most software development instincts. The instinct is to be precise: define the terms, enforce the schema, eliminate ambiguity. Precision reduces errors and makes the system predictable. But the same precision that makes a system technically excellent can make it useless as a coordination device, because coordination across communities of practice requires plasticity. The artifact has to be interpretable from multiple positions simultaneously. Too much precision collapses it into one position, and then only that community can use it, while everyone else keeps the spreadsheet.