A 1988 paper predicted the empty CRM

In 1988, a researcher named Jonathan Grudin presented a nine-page paper at the second-ever conference on computer-supported cooperative work, titled “Why CSCW Applications Fail” (PDF). It explains, with almost no misses, why the software your company makes you use fails the way it does: the CRM nobody fills in, the project tracker that’s always out of date, the timesheet that’s part fiction. We’ve spent thirty-eight years proving him right, and his one escape hatch—a throwaway sentence about neural networks—just arrived.

Start with the meeting scheduler

Grudin opens small, with a feature that shipped on networked office systems of the era: automatic meeting scheduling. Pick a distribution list, and the computer checks everyone’s calendar and finds a free slot. Simple, obviously useful, and it consistently failed. Why?

Who would benefit from automatic meeting scheduling? The person who calls the meeting: in general, a manager would benefit. But who would have to do additional work to make the application succeed? The subordinates, who would have to maintain electronic calendars that they would not otherwise use.

The scheduler works only if everyone diligently maintains a calendar. The people required to do that maintenance get nothing out of it; the benefit accrues to whoever calls the meeting. So the calendars sit empty, the scheduler happily books meetings into the void, “and conflicts will ensue.”

That’s the paper’s core observation, now known as the work/benefit disparity (you’ll also see it called Grudin’s law): collaborative software fails when the people who must do the work of feeding it are not the people who benefit from it. Grudin is careful to note this isn’t a story about lazy users:

The application fails because it requires that some people do additional work, while those people are not the ones who perceive a direct benefit from the use of the application.

It’s worth pausing on what eventually happened to shared calendars, because they’re one of the few pieces of 1980s groupware that won completely. They won when the disparity was engineered away—when accepting an invite put the meeting on your calendar by itself, and the thing you maintained for your own sake became, as a byproduct, legible to everyone else. The feature didn’t get better. The toll got removed.

Three problems, not one

The disparity is the famous part, but the paper actually names three compounding failures, and the other two explain why we keep rebuilding the same broken software anyway.

Problem one: the disparity. Grudin walks through the ambitious application categories of his day—project management, voice annotation, group decision support—and finds the same shape everywhere. On distributed project management, here he is in 1988, eleven years before Salesforce was founded:

It is crucial to ask who is the immediate beneficiary, who will be asked to take on additional work to make the application succeed, and what will be the incentive to do this extra work. The principal beneficiaries are clear: project managers. It is also clear that the success of such an application will be contingent on all group members keeping the information base current. This includes updating significant developments that occur around, rather than through, the system: in meetings, telephone conversations, and so forth.

Work that happens around the system, which someone must then transcribe into the system, for someone else’s benefit. If you have ever received an end-of-quarter email about CRM data hygiene, you have lived inside that paragraph.

Problem two: the buyers can’t feel the problem. Why does software with this flaw keep getting built and bought? Because, Grudin argues, the people who make the decision are the beneficiaries, and intuition only works for people like yourself:

Decision-makers see the potential benefits for people similar to themselves, but don’t see the implications of the fact that extra work will be required of others.

He notes that development attention flows accordingly—toward the dashboard, away from the data entry: “exclusive focus on improving the system for the person already its principal beneficiary seems ill-advised, although it might appeal to the manager sponsoring such a project.” Thirty-eight years later, enterprise software is still demoed to executives as the finished dashboard, and the question “who types all this in?” still goes unasked in the sales call.

Problem three: you can’t evaluate it in a lab. A word processor can be usability-tested on one person in an hour. Group software fails over weeks, for social and political reasons no lab reproduces—so vendors kept shipping the same failures, and buyers kept buying them. Grudin’s 1994 follow-up in CACM, “Groupware and Social Dynamics”, expands the list to eight challenges and includes a sentence I’d frame and hang in every workflow startup’s office: “descriptions of ‘standard process’ are often post hoc rationalizations.”

The saboteurs of 1988

The paper’s best passage is an anecdote, relayed to Grudin as a personal communication, about a deployed work-management system. I’m quoting it at length because every sentence lands:

An employee who reported identifying a priority problem began receiving system-generated requests for progress reports to be forwarded to the Chief Executive Officer! This quickly led to the end of priority problem reporting. The vigilant system noted that employees had stopped using the system, and alerted the administrator. The employees dealt with the resulting complaints by writing programs that periodically opened files and changed dates, which satisfied the watchful, automatic monitor. Thus “sabotaged,” the work management application was of little use, and was eventually quietly withdrawn.

Read that again: in 1988, employees wrote scripts to simulate activity in the tracking tool so that management’s dashboard would stay green. Every generation rediscovers this. The stale Jira ticket bulk-closed before the sprint review, the standup bot fed the same update three days running, the pipeline stages dragged forward the night before the forecast call—when a system measures the record instead of the work, it doesn’t get the work. It gets a performance of the record. Grudin saw the whole genre in one anecdote, including the ending: the tool, not the people, is what eventually gets quietly withdrawn.

The disparity hasn’t gone anywhere; it just finds new hosts. Grudin’s chapter on voice annotation observes that its “advantages are almost all advantages for the speaker” while the disadvantages are “overwhelmingly problems for the listener”—the speaker saves a minute, purchased with ten of the listener’s. He was describing dictaphones, but he was also describing every unsolicited ten-minute screen recording, and every bullet list inflated by AI into a memo that its recipient will summarize back into a bullet list.

He even prescribed the fix

The paper doesn’t stop at diagnosis. Grudin’s remedy is stated plainly, and it reads like a product spec nobody could build yet:

The best solution is to try to insure that everyone benefits directly from using the application… It certainly means eliminating or minimizing the extra work required of anyone.

And, in the sentence he italicized himself: “the organization may adapt to the computer system, but an application program must adapt to the organization.” The software must fit how people already work—not deputize them as data-entry clerks for a shadow copy of their own jobs.

For fifty years that advice was largely unactionable, because computers could only eat structure. If the record of a deal lived in conversations, someone had to retype the conversations as fields and dropdowns. The disparity wasn’t a design choice; it was a workaround for machines that couldn’t read.

Which brings us to the strangest paragraph in the paper. Grudin surveys natural-language interfaces to databases—a category then “absorbing 1000 developers and hundreds of millions of dollars” across more than fifty companies, none of which had turned a profit—and, in the middle of explaining why the whole idea is mismatched to computers, allows himself one hedge:

Perhaps if neural net or connectionist systems succeed in giving computers a more “fuzzy,” human-like intelligence, natural language will be a good match.

That’s 1988. It took thirty-five years, but the hedge came true. Language models can now read the primary sources of work—the threads, the documents, the conversations—directly. The constraint that made the disparity load-bearing is gone, and software that still runs on a toll of manual transcription is now failing Grudin’s test by choice.

The exception he flagged

One more detail, easy to miss on a first read. Having established that groupware generally taxes some users for others’ benefit, Grudin names the exception:

Not all CSCW applications introduce such a disparity—with electronic mail, for example, everyone generally shares the benefits and burdens equally. But electronic mail may turn out to be more the exception than the rule.

Email passed the test, and email won. It’s the one workplace system that needed no adoption initiative, no hygiene emails, no mandate. And so, for four decades, the real record of work—the deals negotiated, the commitments made, the relationships maintained—accumulated in email, while the systems that failed Grudin’s test sat beside it, half-empty, waiting for someone to retype what had already been written.

Here’s where I talk my own book, briefly. We’re building Carom on exactly that reading of Grudin: the CRM’s data has been sitting in your team’s email all along, and software can now read it in place—reconstructing the contacts, organizations, threads, and tasks with nothing to enter or maintain, private things kept private. Whether we’ve built it well is a separate question, and per Problem Three you shouldn’t take a vendor’s word for it: there’s a live demo, and you’re welcome to judge.

But mostly: read the paper. It’s nine pages, it’s a pleasure, and it will change how you look at every tool your company asks you to feed. (Academics revisited the eight challenges in 2024 and found modern groupware quietly absorbed into infrastructure—which is roughly what happens when a field spends thirty years being right.) Grudin closed with a warning about his own profession that generalizes to ours: “very frequently we see researchers studying other researchers, developers building systems because the technology exists, and managers supporting the development of systems that will appeal to other managers.” The first step, he wrote, is to see the problems clearly.