Trailhead: Juan Pablo Buriticá, The future of work is written, Increment, Issue 15 (2020-11)

As engineers, I offer you this: We’ve learned how to measure the effectiveness of the communication networks we’ve built. We know and manage latency, throughput, packet loss, and retransmission of our communication infrastructure. So, what’s the latency of status updates? How can we improve it without people being constantly on their email or on Slack? Are we losing packets as we pass around meeting notes? Is there a better way to compress transcripts without losing the quality of the message? We’ve already solved many of these problems in distributed systems of computers—perhaps we could help solve them in systems of people. But not by trying to engineer our way to a place where asynchronous messages or writing replaces other human interaction.

To decide, to move on; to move on, perchance to forget; ay, there's the rub. With apologies to Shakespeare, etc.

Even in the best of times at work: meetings are had, decisions are made, work is done, decisions are forgotten, work continues, meetings are reprised, work is redone, and round and round and round we spin. It's frustrating, and exponentially so as more people are added to a team.

Writing things down is a solution that dampens the spin— small "s" solution, not the Solution. Bad writing is still bad writing. Good writing that can't be found on the server is wasted effort. Difficult writing tools are crimes. And, besides, one of the commandments of agile that Moses brought back from the mountain was to rank working code over comprehensive documentation, which is translated as all but an invitation to ditch writing altogether.

You can—and should—work with people to improve their writing skills. Clear ideas written clearly are indispensable. But without a culture (read: staff) to handle editing and knowledge management properly, the effort of writing is wasted, and a team reverts back to the old problems of lost information, but with a new resistance to the next scheme to improve it.

I enjoy writing things down, so I often absorb some of the work roles that call for that—meeting notes, guides to software tools, re-descriptions of processes (I mean, process documentation is its own description, but it's often written as if the purpose of the thing was to pass an audit, not for the end-user to actually be able to understand and use the thing, rant rant rant). But more than just writing things down, I'm a fanatic about making the outcome digestible by whoever might have to use it later, and about organizing the information so it can be found, and about linking the information to other information (give me an installation of MediaWiki at work and I will rule the world), and about constructing the information so that you can run a script over it and mash it up with other information. It rarely (read: never) works as elegantly as I wish it would, but there is no reaching the final goal anyway, only approaching it until the environment changes or the project is over.

Anyway—too much abstraction here. The teams that can write, that know to organize the writing, that maintain the writing (as infrastructure or as a stream), that respect writing, are the ones who are going to rule in the distributed work world. A steady diet of teleconferences and emails doesn't seem to be cutting it.

I don't know for sure. I'm relatively new to it (ten months in now) and there are millions of test cases out there to examine. Maybe it makes more sense to consider the teams who are working remotely well, and whether effective writing is a positive differentiator.