This article is part of a series on remote working.

OK, a quick recap…

In the last article we looked at the spectrum of synchronousness, which showed how there exists:

• A continuum between synchronous and asynchronous communication.
• Implicit expectations with that communication depending on the medium and format you choose to communicate with.
• A need to shift right along this spectrum in order to better support remote and distributed working.

In this article we’re going to look at permanence.

Permanence

Whenever you communicate, you create artifacts. These can range from a memory of a conversation in a colleague’s brain through to a detailed written proposal. Similar to the continuum between synchronous and asynchronous, there is also a correlating continuum between permanence and impermanence. 

But what do we mean by that?

#define

• A permanent artifact is one that has a quality of lasting or remaining unchanged indefinitely.
• An impermanent artifact only lasts for a limited period of time.

There are several dimensions on which to determine the permanence of an artifact, both now and in the future:

• How relevant is it? Does it accurately represent a decision, system or process if somebody was to find it?
• How accurate is it? Does it fully document its subject matter, or does it require additional information from elsewhere in order to fully describe it? Could it even be out of date?
• How useful is it? If somebody was to search for and find this information, is it a good use of their time to read it?

We’ve all experienced permanent documentation that has been misleading. This is because as humans we are excellent at creating artifacts to address our current needs, but we don’t always bring our attention fully to what will happen to those artifacts in the future. We need to be mindful of this fact. Are we making the future better? Or are we setting a trap?

Look at the correlation between permanence and synchronousness in the diagram below.

As you can see, synchronous communication generates very few artifacts for the future. Asynchronous communication, on the other hand, does not work without these artifacts being created. 

In a workplace that is centered around physically colocated offices, our bias towards synchronous communication leaves no audit trail, which is why remote workers often find it difficult to feel integrated if they are not party to synchronous, in-person communication. Did it even happen?

There are some key principles to follow in order to make sure that you create good quality artifacts that last into the future and enable distributed and remote working. These principles can be applied at the individual, team, department or company level.

These are:

• Leave an audit trail
• Maintain an index, and
• Mark, file, tidy and delete.

We’ll look at these in turn.

Leave an audit trail

Some of the tools that we use to develop software have evolved to create audit trails as a feature. For example, take version control systems like git that allow us to inspect – and even replay and change – the history of commits in a software project. We can often go back in time and understand what happened and why. 

This is great.

However, we should be thinking of applying the same principles of leaving an audit trail from our communication and decision making. We should pay attention to showing our working by applying the shift right on the spectrum to whatever we are doing. For example:

• As we go about our day, we should keep our team informed about what we’re working on by writing updates in a team chat channel.
• When we have an informal chat and make a decision about something, we should broadcast that decision via a written form, such as in our team chat or via email.
• At the end of a week, we could write a brief update to each other about what we’ve been working on and why, and what we’re focussing on next week.
• When having meetings, we should maintain an agenda with notes that contains the history. Additionally, we should record each meeting in that series and store it in a shared file system.
• When starting new projects, we should work on our ideas in design documents that anyone can view, ideally storing all design documents in a central place so that anyone can discover them later.
• When we make a major architectural decision in a codebase, we should document exactly why we made that decision and how it affects the structure of the code going forward.

Leaving an audit trail can seem like hard work if you’ve not been used to doing so. However, once you start, you’ll notice that it has numerous advantageous effects on the way that you do your work. 

Even if you’re working alone, you gain more opportunities for interaction with others through your audit trail, which is especially important with remote working, and writing while you think helps develop your critical thinking skills.

Maintain an index

Regardless of whether you are an individual contributor, manager of one team, or of a whole department, creating indexes of information is essential for keeping your house in order, increasing the discoverability of artifacts, and also encouraging others to work in this way.

Search engines for our documents at work are not in any way as good as the ones we use to search the internet. You can just never find that document that you were after. What was it called again? Was it “2021 projects” or “team allocations”? Did it have a typo in the title? Was it even stored here?

Maintaining indexes can be a great way of making the important items discoverable for everyone. It could be as simple as a shared document with hyperlinks in it that anyone can edit. 

For example, for a team, the index could contain:

• A quick overview of what the team is called and what they are working on.
• The members of the team and how to contact them individually.
• Links to their team chat channels and email groups.
• Links to the code repositories that they own and are working on.
• Links to shared folders with design documents and architectural diagrams for current and past projects.
• Rolling meeting agendas and recordings.

This index could be linked to in the staff directory, their chat channel, and in the codebase documentation. It doesn’t take long to create, but it can be the beginning of numerous shift right habits that begin to contribute to making the index and the linked documentation increasingly better. 

Humans have a habit of mirroring other behaviors that they like, so it won’t be long before other individuals and teams start their own indexes as well.

Mark, file, tidy and delete

It’s all well and good continually shifting right along the spectrum and creating all of these new artifacts in order to better support remote and distributed working. However, artifacts often have a shelf life. 

A design document that assists a productive discussion and decision today may just waste an hour of someone’s time in a year when they don’t realize that it is no longer relevant. It is your duty to ensure that you are keeping your proverbial closets tidy with good habits.

Thinking back to our spectrum of synchronousness and permanence diagram, there is a general observation that we could make:

• Artifacts that are produced from communication closer to the left-hand side of the spectrum will typically have a short shelf-life.
• Artifacts that are produced from the right-hand side of the diagram will typically have a long shelf-life.

The video recording of a meeting probably isn’t going to be an artifact that you’ll want to come back to in several years, but it may be useful for people to catch up on the content in the weeks following it. However, the README file for a software project should probably be evergreen: that is that it’s as relevant today as it will be in the future.

So, what this means is that:

• Short-lived artifacts should be labelled as such. This can happen implicitly (e.g. an old code commit is implicitly short-lived, since there are commits after it in the same file) or explicitly (e.g. a written summary that is no longer useful is marked as “old”, or is archived away, or even deleted).
• Long-lived artifacts should be kept up to date. Any unmarked written document or wiki page should be occasionally revisited and updated to ensure that it is still relevant and useful.

Conflict usually occurs when there is a violation of these principles, which often happens towards the right-hand side of the spectrum of synchronousness. Wikis or READMEs stagnate, but it is often not clear that they have, and then they waste somebody’s time. Written documents can become irrelevant, but they are not marked as such.

Always make it clear when you are creating a short-lived or long-lived artifact. Appropriately labelled short-lived artifacts can be forgotten about, as future readers will understand that it is likely no longer relevant if they stumble upon it. Long-lived documents need tending to with time to remain evergreen.

Continually review, mark, file, tidy and delete your artifacts. Your future self and colleagues will thank you for it.

Takeaways

Here’s the homework for this week.

• Begin increasing your audit trail. Blog updates on what you’re working on in your team channel with links to pull requests, tickets and comments. 
• Write a daily or weekly update to your team about what you worked on, what went well, what didn’t, and what you’re focussing on in the next time period.
• Discuss the idea of creating an index with your team. What should be in there? Then create it!
• Search through your shared filesystem to find the oldest and most irrelevant document. Share it around if it’s humorous. How did it end up like this? What strategy would have prevented it getting into this state?

Next time we’ll look at the correlation between becoming more asynchronous and the effect it has on feeling connected to others.

This article is part of a series on remote working.

Consider this: what’s one of the most impactful skills that you can improve as an engineer? Is it your programming? Maybe it’s your debugging? I’d like to make the case that it’s your communication.

After all, software isn’t built in solitude. It is imagined, designed and implemented by teams of people. Being a better communicator will make you a better programmer. You write code for other humans. The compiler lets the computer understand it.

Communication skills will make you a better colleague, leader or manager. They will ensure that you are better able to find consensus around your ideas, designs and proposed architecture. Communication skills allow you to build rapport with your colleagues so you can develop your skills through constructive critique and feedback.

This has always been true, but it has never been truer in a remote world. Not only do you need strong communication skills that underpin your work, you also need to be able to pick the right tools and techniques to communicate the right way at the right times.

In the next few articles in our remote working series, we’ll explore some complimentary considerations for how and when to communicate. But we’ll start with looking at synchronous and asynchronous communication.

#define

Let’s start with some definitions.

• Synchronous means “existing or occurring at the same time”. When you have a conversation with somebody face to face, the exchange of information is immediate.
• Asynchronous is the opposite of synchronous. When you send somebody an email and they read and reply to it a few hours later, that communication is out of phase.

Typically, synchronous communication happens at the same:

• Time. This means that for the communication to take place, all parties must be interacting at the exact same time. This may occur without planning if two people met in a corridor, or it may require scheduling a meeting.
• Location. For communication to happen at the same time, it will often be in the same location. This could be a physical room, but it could also be a video call.
• Format. In order to exchange information immediately, all parties will use the same format, such as their voice and body language.

Given that asynchronous communication is the opposite, we could imagine that it could therefore happen at a different:

• Time. One person could send an email in the morning to another person on a different timezone, and they can then reply at their own convenience.
• Location. A message could be written on a phone whilst on a bus in Berlin and replied to via an email client on a laptop in New York.
• Format. That same email could generate some further thinking, which then generates a longer written proposal document to continue the discussion.

There’s another important distinction to be made first: it isn’t a binary choice between the two modes. It’s a continuum.

As you can see from the diagram, it’s rarely the case that something is purely synchronous or asynchronous. Often, it’s somewhere in between.

• Video calls or face to face chats are completely synchronous. Everybody involved needs to be somewhere at a specific time, since the communication is typically happening via voice and body language in the moment.
• Chat is written and is therefore less synchronous than a video call since it can be read later, however it has a short half-life because chats implicitly carry a temporal dependency. Are you catching up on a chat from a few hours ago? Sure, that makes sense. But are you reading through a chat from two months ago? It’s probably mostly irrelevant and noisy.
• Recorded video can be viewed later and requires more preparation than a chat, however its relevance decays fairly quickly (it’s also not searchable). A recording of a meeting from a few weeks ago, or a video updating everyone on the progress of an initiative probably won’t be watched again once it has been used once.
• Email is where we start producing more permanent asynchronous artifacts. Email by nature is archival and searchable, and is often used for important information such as delivering a confirmation of a raise, or confirming that a payment has been set up. Some people reply to emails quickly, but some take many days to reply, and that’s OK.
• A written document requires some effort to produce and may be used as the cornerstone of a project or proposal. Theoretically, a well-written document can last almost indefinitely, assuming the reader knows the date and context of which it was created for. Most online document software also allows collaborative editing and commenting.
• Wikis and READMEs are completely asynchronous, and typically have no interaction between the author and readers. If they are well-maintained, they can last, and be useful, forever.

The old world

When we primarily work together in an office, convenience and habit typically mean that we spend a lot of time on the left hand side of the spectrum. After all, when all of our colleagues are sitting across the room, it’s easy to go and have a conversation in the moment.

This is perfectly normal behavior, however it isn’t suitable for remote working. One could argue that it actually isn’t suitable for any company that has multiple offices, as this way of communicating severely limits the collaboration that can take place across multiple locations.

If you’ve worked in a large company, you’ve probably already seen the effects of synchronous communication being the default:

• Individuals are typically seated with their teams physically in the same office.
• Teams that collaborate frequently are often also located in the same physical location.
• The weakest bonds between different parts of the organization often occur when there is a geographical divide between them.

This can have a tangible and inconvenient effect on the software being created. Conway’s Law states that any organization that designs a system will produce a design whose structure mirrors the organization’s communication structure. When companies expand into different locations, opening another office to hire engineers might be an implicit design choice in how they architect their software.

They just don’t know it yet.

Shifting right

In order to fully embrace remote working, we need to shift our mindset and habits to the right of the spectrum.

Instead of choosing the convenient option, we need to choose to communicate in a way that enables an equal level of contribution from anyone, regardless of where they are located in the world.

Shift right.

That’s the habit that you need to instill in both yourself and your colleagues. Every time you communicate, can you purposefully shift right so that you better serve the needs of remote work? For example, could you:

• Turn a face-to-face conversation into an exchange in the team’s chat channel instead? This way, more people can have the opportunity to “overhear” what is being said and contribute to the conversation.
• Record a video call so that those that were unable to make it, or those that didn’t know that it was happening, are able to watch it back later.
• Decide to stop a long chat exchange so that it can be written up more thoughtfully and purposefully into an email?
• Take an email thread that is proposing an idea and turn it into a more detailed written document so that it can be read more easily in its entirety and then circulated for comment and consensus?
• Change an agreed upon idea in a written document and turn it into a more permanent wiki page that serves as the cornerstone of a whole project?

Shift right.

Every single interaction is an opportunity to shift right, and by doing so you are having much more of a dramatic impact than you may think. You are making your workplace more suitable for remote work. You are giving more people the opportunity to discover what is going on and then have a route to contributing to the conversation. You are breaking down geographical silos and fighting the tide against Conway’s Law.

Takeaways

So, all it takes is a shift right. Here’s your homework.

• Looking at the diagram of the continuum above, work out what percentage of time you spend on each form of communication during a given week. Do you use specific methods for certain people or teams? Why?
• What types of communication do you prefer? Has this preference changed over time?
• Do you find any of these methods frustrating? Why is that? Is it the medium itself, or is it how that medium is being used?
• Next week, apply the shift right mindset as much as you can. How does it affect your choice of communication medium and the responses that you get from those that you are communicating with?

That’s all for now. 

We’ll build upon this model next time by seeing how it correlates with permanence of the artifacts we create.