Taking CSCW Seriously, by Kjeld Schmidt and Liam Bannon

Working in an office is hard. (Remember working in an office?)

Wait, I'll try again. Working in a team requires dealing with many people. Each person in the team has to understand the project and its priorities. But they also have to understand how everyone else understands the project and priorities.

Thanks to the wonder of the computer age we can now keep all this information organised so everyone is always on the same page for every project.

Stop laughing.

In 1992, Kjeld Schmidt and Liam Bannon were the editors of a new journal (ie a very dull academic magazine) called “Computer Supported Cooperative Work (CSCW)”. Schmidt and Bannon also wrote the first article in that journal. The title of the article is “Taking CSCW Seriously”.

The paper begins with a lot of exposition about exactly what CSCW meant. It was still an emerging field. Some people said CSCW was only about “group work”. Others wondered whether there was some bigger idea to investigate. Schmidt and Bannon are on the big idea side. They said:

CSCW should be concerned with the support requirements of cooperative work arrangements

In 1992, there had already been a lot of research done on “cooperative work”. Anselm Strauss and Barney Glaser were anthropologists who researched how hospitals worked. They’d seen that keeping hospitals working required a lot of collaboration. Strauss and Glaser and their students like Susan Leigh Star (from the last issue) introduced the concept of “articulation work”.

Articulation work is what happens when people work together. Strauss and Glaser, among others, said: “cooperating workers have to articulate (divide, allocate, coordinate, schedule, mesh, interrelate, etc.) their distributed individual activities”.

That is, articulation work is what you do to make it clear to other people that what you’re doing is contributing to the current project.

In Schmidt and Bannon’s words, people “must engage in activities that are extraneous to the activities that contribute directly to fashioning the product or service and meeting requirements”. It’s for this reason that working together looks and feels different to working alone.

If you don’t care for the sociological language Schmidt and Bannon use, Fred Brooks wrote about this from an engineering perspective in The Mythical Man Month. Brooks described how adding more people to a project leads to the situation where people spend more time coordinating all the moving pieces of the project than moving the project towards completion.

What it means in 2020

Re-reading this paper, I was stuck by how well it describes our current situation. Schmidt and Bannon describe any number of cloud-based software products you probably use in your work today. In 1992!

By providing communication facilities in the form of file sharing, shared view, email, computer conferencing, and video conferencing that increase the bandwidth and reduce the turnaround time of communication, CSCW systems can enable small and relatively stable cooperating ensembles to exploit the powerful repertoire of everyday social interaction in spite of distance and thus augment the capacity of the ensembles in articulating their distributed activities.

When you and your colleagues are doing remote stand-ups every day, that's articulation. You're all saying how what you’re doing contributes to the bigger project.

Schmidt and Bannon also figured out why every loves to hate Jira, Slack, and the like. A tool that supports articulation also requires some amount of articulation. In less academic language, it’s turtles all the way down.

Because of the turtle problem you end up with the situation where everyone needs to be reminded about file-naming conventions. Or where and you need meetings about meetings. This is also why some teams that use Jira also have a wall of post-its that they use before entering all that information into Jira.

Schmidt and Bannon want to be clear that need for articulation work isn’t a bug but is an unavoidable fact of cooperative work.

It's for this reason that they caution against idea that if you're just well organised enough, you won't need articulation work:

being nothing but local and temporary closures, these mechanisms themselves require articulation work.

If you have some kind of project management software, even if it’s working well, it’s only a “local and temporary closure”. To make it work, and keep it working, there’s always going to be a need for articulation work.

You've probably seen those ads on Facebook for the latest project management software that is going to save you so much time because everyone will always know what they have to do. It doesn't work like that! You can’t design a system to completely get around the need for articulation work. You can’t replace articulation work. You can only support it. If you’re using an articulation system, or trying to design one, you should keep that in mind.

Bonus Unexpected But Related Insight

This paper also introduces the idea of the need for a “common information space” to support articulation work. You might call it a wall, a project room, mission control or something else.

Serious things

Formal reference

Schmidt, K., & Bannon, L. (1992). Taking CSCW seriously. Computer Supported Cooperative Work (CSCW), 1(1-2), 7-40.

Canonical URL

https://link.springer.com/article/10.1007/BF00752449

Publicly available source

https://pdfs.semanticscholar.org/c900/90eb7b27afaf0c7d3a537514a9463fe1c51a.pdf