Contrary to popular belief, distributed work isn’t a modern invention. The Roman Catholic Church, for example, has been working at a distance for centuries; so have organizations like the Hudson’s Bay Company.1 Distributed work is the evolution of telecommuting, which originated with in-home sales like the Tupperware parties of the 1950s. Telecommuting itself was later adopted by government institutions like NASA, motivated by the 1970s energy crisis, and eventually found its way to technology companies like IBM.
Contemporary distributed work is enabled by the internet and software tools and fueled by the increased demand for experienced talent regardless of their proximity to an office. The competition for software engineers has encouraged companies to expand their hiring pools beyond their immediate geography, increasing the bargaining power of workers with desirable skills. Companies that adapt to distributed work can access global talent markets where remote workers have the autonomy to decide where to work from and when. If we’re deliberate about how we approach communication within our organizations and manage our collective knowledge, working at a distance can unlock opportunities for workers and companies alike. Here, I invite you to join me in a thought exercise exploring possible paths to those opportunities—and what the future of work might look like.
When we work remotely, our distance might be physical, temporal, or cultural. Organizations that evolve to depend on proximity across any of these incur a productivity cost when they find themselves separated. (For example, a software team that depends on holding their daily stand-up in the same physical space every day can fall out of sync if half the team attends a conference.) But most fast-growing teams are eventually distributed. They outgrow offices, floors, and buildings. And change can come quickly: As we’ve all recently learned, a worldwide event can require office workers to work from home for the foreseeable future.
From issue 5
Ask an expert: How do you maintain Rust?
From team structure and annual surveys to RFCs and the release process, a staff research engineer on Mozilla’s Rust team shares what it takes.
Rather than reacting to accidental separation, teams and companies can and should proactively learn to work together from a distance. Organizations that do this well become more resilient and adaptable, which may advantage them to survive rapidly changing market circumstances. One of the best ways we have to bridge distances—to overcome our separation—is writing. The ability to send written messages across physical space enabled the expansion of collaboration across the world. Once we added the internet and email, correspondence over any distance great or small had the potential to be instant, increasing the efficiency of our communication. We gained access to real-time information and more informed decision making.
But companies that depend on proximity for their operations may struggle to shift to distributed work—even if they see the value in it, and even if the circumstances aren’t dire—if they don’t reconsider their motivations and expectations. Trying to just do the same things we used to do in an office but over a video or phone call isn’t necessarily productive (video call fatigue is even becoming a grudging trend) and doesn’t always play to the many positive things remote work can offer. Instead of replicating earlier structures and constraints, remote work can allow us to do our best work in environments where we’re trusted, autonomous, and can reclaim some of the time we lose to commutes. While it’s not ideal for everyone, for those of us who struggle to be productive in open offices, the option of a private work space can be a major perk. Prioritizing cheaper real estate over worker productivity is a misalignment of business incentives, and being flexible on worker location can help balance costs and employee focus. By providing workers with tools and resources that enable collaborative and creative exchanges, and don’t rely on presence or proximity, organizations can transition to remote work with less friction.
Writing can transcend our distances in all their forms and lengths. Constitutional governments are great examples of how written artifacts can survive—and influence work—across centuries. For example, the U.S. Constitution passed down detailed instructions on how to make decisions without telling future participants in the governing process what decisions to make. Companies can learn from our enduring governance experiments by deliberately designing internal communication and decision-making strategies meant to be passed down and carried forward. By building predictable communication patterns, we also build an operational cadence. It’s much easier to operate when employees have access to relevant documentation that helps them stay informed, unblocked, and aligned. Written decision-making frameworks are also helpful for empowering individuals and decentralizing authority.
Every decision we make gets us closer to our goals, and for creative workers, making decisions is the heart of the job. Every line of code is a decision we make on behalf of our team to improve our product, fix a bug, or test a hypothesis about our users to enhance their experience. Positive business outcomes rely on good decision making, which in turn is enabled by access to relevant information, good judgment, and agency to decide. Team meetings are helpful venues for decision making when they work—but they don’t always work. We can make them work better by keeping them small, but this limits who can participate in discussions and who gets access to the thinking and methodology behind decisions. And relying on someone else’s interpretation of what went down during a meeting might not always be so useful. Things tend to get lost in translation—remember the schoolyard game of telephone? Even when there are written minutes available, we’re subject to experiencing discussions through the lens of others, because who are we kidding? We’re usually too busy to read the transcript or watch the video of the meeting we missed or weren’t invited to; we get a partial rundown from a colleague; we still don’t know if we’re launching next week.
Knowing and then deciding what to write is often more valuable than writing everything, but knowing what matters is more of an art than a science.
Some decisions require presence and discussion, certainly, but not all. Many can be made both responsibly and asynchronously. Collaborative documents, for instance, can become self-documenting meetings, and writing the foundations and reasoning for critical decisions might produce a better result, even when brainstorming.2 And while they can be impressively effective, they’re no silver bullet: For all their benefits, these sorts of documents can also get out of hand quickly if participants don’t communicate mindfully, with awareness of the limitations of written discussions. Community management, then, becomes a consideration of modern distributed workplaces, so that collaborative practices in documents, chats, and forums can be maintained as psychologically safe spaces that nurture ideas and those who share them.
Writing, though, offers us possibilities far beyond meeting documentation. When we write, we get to freeze ideas: They stop evolving and become accessible to others to establish a consensus or working frame, which later can be collaboratively reshaped. Documents can be replicated cheaply or freely and then shared, modified, edited, and revised. Texts are an age-old microcosm of what we consider open source—and collaborative writing can facilitate the convergence of an understanding. Modern tools help us get context through hyperlinks and enable in-line discussions that can lead to increased clarity or the evolution of an idea. Documents can also be archived, revisited, analyzed, summarized, or published for others to utilize in the future. The internet itself originated and continues to evolve through collaborative distributed work, and those who built it—and are building it—employ requests for comments (RFCs), collaborative documents used to discuss and make decisions asynchronously, to do so. After 50 years, this collaborative practice has produced almost 9,000 collaborative documents determining the fate of the internet’s infrastructure. Modern software projects like the Rust programming language also rely on RFCs to make substantial decisions, and RFCs can help your team too.
It’s worth underscoring that capitalizing on written processes isn’t an easy feat. Knowing and then deciding what to write is often more valuable than writing everything, but knowing what matters is more of an art than a science. Writing is hard. Doing it well takes time. Comfortably sharing work in progress requires psychological safety, so ideas can see the light and be nurtured when they’re the most fragile. And words can also cause conflict. A poorly worded email can create hours of crisis management because written words don’t always carry tone. Even the meaning of emojis can diverge 😉.
Poor management of abundant information can impact a workplace in the same way as a lack of information.
Finally, someone has to do all the reading—usually, many someones. If reading every message and document is important, then nothing is really that important. When the volume of written artifacts scales, it falls on individuals to decide whether something requires their attention. Inboxes saturate. Incident alerts get ignored. Your coworker sends you a Slack message, wondering if you saw the email they just sent. Tsk, tsk, tsk. We’ve become very familiar with the concept of technical debt, but we don’t talk enough about document debt. Poor management of abundant information can impact a workplace in the same way as a lack of information. Trying to decipher whether a document is relevant, or a decision is stale, or where to find the most updated process can slow employees down and lead to mistakes. Companies that want to get better at writing need to invest in how they manage written information.
Imagine a future where distributed workplaces reroute a portion of their real estate funds toward supporting employee reading and writing. The office (whether distributed or not) can become a magical place where workers have access to professional editors who can help them answer the right questions about the quarterly update. One where marketers are working alongside engineering managers to help them explain how technical debt impacts the business, and how it’s not just about learning how to use Svelte.js. (Okay, maybe it is, a little.) An organization with librarians on staff who know how to catalog and organize the hundreds of collaborative documents you produce every week. (A hopeful idea that I would rather see developed by someone with a degree in library science, not a technologist like me with a shallow understanding of the domain.) If we push it, maybe we’ll see more companies that figure out how not to use 17 different tools for internal communication. Today, for many, this seems further away than Pluto, but the decisions are as close as our minds, hearts, and keyboards.
Also in this issue
Open-source excursions: A journey into remote record keeping
A new column exploring engineering topics through an open-source lens.
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. Instead, we have to accept that these problems aren’t engineering challenges that need more or different tools—they’re opportunities for human collaboration, rooted in our flawed perceptions and insecurities. We can help the distributed companies of the future recognize that humans don’t communicate like computers, and that the same request might elicit a different response from different people. We can be advocates for written communication and models of asynchronous productivity, while supporting systematic shifts that support both people and progress.
If we believe that our industries can be supported by asynchronous work, it might be possible to write our way to a future where the work we do is better balanced with our lives.
Remote work isn’t necessarily better or worse than other modes of working—it’s simply different, and it might not be for everyone. But to me, it seems a more compassionate way of working. If we believe that our industries can be supported by asynchronous work, it might be possible to write our way to a future where the work we do is better balanced with our lives. Balance is key. Embracing writing doesn’t mean an isolated, meeting-less future: Even if we shed our commutes and offices and write to our collective heart’s content, many collaborative practices will continue to depend on presence for their effectiveness, and we should have space for these, too.
If we embark on a journey of communicating better at a distance, we’ll have to consider that we’re all still human. We interpret differently. We require safety. We react well to stories. Our sarcastic humor doesn’t always travel well in written form. Leaders who move us closer to a written and remote future, who truly understand the value of communication, will invest holistically in tools, staff, ideas, and infrastructure.
Wide adoption of remote practices has given us a chance to learn and grow. Software engineers influencing our way to #remote #work might not solve all our #workplace #challenges, but as technologists, we have an opportunity to help create and support solutions that bridge literal and proverbial distances. Let’s focus on making distributed work effective and sustainable as we encourage organizations toward asynchronous written collaboration. If we do it right, the next chapter we write will be a good one—and we can write it together.
1 Hinds, Pamela. “Distributed Work over the Centuries.” In Distributed Work, edited by Pamela J. Hinds and Sarah Kiesler, 27–54. Cambridge: MIT Press, 2002.
2 Brian Mullen, Craig Johnson, and Eduardo Salas, “Productivity Loss in Brainstorming Groups: A Meta-Analytic Integration,” Basic and Applied Social Psychology 12, no. 1 (1991): 3–23, https://doi.org/10.1207/s15324834basp1201_1.