Working in the Open — 7 techniques for Tech Companies Going Remote

9 min readApr 19, 2020

Transitioning a company to remote work takes a culture and mindset shift for every person in the company. The easiest way to transition to successfully work remotely as a distributed team is to work in the open.

What’s ‘working in the open’

Every person’s work should be visible to almost everyone in the company. Companies need to have a Working in the Open practice that is understood across the board. Documentation may be shared may only be shared within teams, the whole company, or publicly.

The principles of working in the open are:

Make work visible — through Kanban boards, documentation wiki, shared folders, dashboards, and process. Also, including instructions on how to use the documentation, and how to find information in the right place.
Share work early and often — don’t write things down in your private space then move it into the public space later. The goal is to have as much information as possible stored in a shared space within the company and make sure everyone feels comfortable sharing unfinished work.
Hold conversation where the work is — use tools with good commenting and notification features to be able to track conversations in a format that is connected to the location of the work.
Treat documentation like an internal product — documentation needs product and design thinking so that your company can utilise it as a resource in the best way possible. It also needs regular maintenance and upkeep to maintain value.
Give status updates in writing or record a video — when status updates are not visible, it means that someone has to interrupt a person’s day to ask them to share the status of a piece of work. Interrupting a developer may cost up to 2 hours of productivity loss per interruption. This could look like a comment on an epic in Jira, or a update to a brief in confluence.
Default to public slack channels — private channels create silos of knowledge and may slow down collaboration. It doesn’t mean that you should not have direct messages, or 1–1s, nor does it mean that you should have all members of the company in every communication channel. Make sure that your channels are not private, so team members can still see the content of the teams conversation without joining the channel.
Limit side-chats — when it comes to the work itself, all decisions should be documented where the work is. If a design decision needs to be made, that decision is best documented where the solution is being prepared.

A company that does not Work in the Open spends a majority of its time in meetings. For these companies, it’s easier just to hop on a call to share domain knowledge kept in someone’s head than it is to make it accessible to be shared without having to ask someone. Each person in a company becomes a domain expert, and when they leave the organisation, that knowledge leaves with them.

Benefits of ‘Working in the Open’

Benefits of working in the open are:

Less time in meetings,
More shared knowledge,
Less dependence on a single person to hold the context,
Faster staff onboarding and training,
Improved agile governance and risk reduction, and
Increase in productivity.

All of these things help us work remote and get more buy-in for decisions relating to product development.

Visibility is not micromanaging

Working in the Open provides a practice for everyone in your company to show how much effort they are contributing to solving your companies problems. It’s culture that makes the what, the how, and the who visible, but it is not a method to micromanage staff. Keep in mind that your team is made up of incredibly smart people who all want to make progress, have some sense of autonomy, and have a sense of belonging. Visibility of work helps increase asynchronous communication and accountability, it is not a tool to remove autonomy over work.

It’s not just a software problem

The two problems are:

Software — Software used by the staff prohibit people from working in the open.
Culture and practice — The culture of the company prevents people from having conversations in a shared format.

Launching a new program or picking a new piece of software requires change management. Change management involves investing money to achieve a change. Much of the money is invested in people to help orchestrate the change across the organisation and the training or other resources needed for the change to be successful. In bigger and established companies, change management costs a lot of money. Implementing a new change across the company is a considerable amount of the budget for a new initiative.

The older a company is, the more established with staff who have worked there a long time, the more effort it is to make a change to the way that the company works. These types of business are at risk of decreasing productivity in a remote work environment. Companies that use older, legacy, software systems can not function efficiently in a remote setting and could have improved efficiency if they adopted newer cloud software designed for collaboration.

The culture challenges

Reasons why people don’t work in the open may include:

They don’t want to create too much clutter or too many notifications for their coworkers.
They don’t want people to see their work while it’s still in a draft state or not ready.
It’s too hard for them to use the tools provided by the company to communicate asynchronously.
There is no shared place for communication or documentation.
The protocols for communication are not made clear and shared by all team members.
Too many cooks in the kitchen, a worry that too many people working on something makes more work.
They don’t want to be told ‘No’ too soon.

Learning to talk in the right channel

“It’s OK, we’ve started using slack.” Says many companies entering the modern age of technology. Cool story bro.

Slack does not make remote work easier if it is the only collaboration tool that you are using. Slack will increase the amount of communication each person has to manage per day and decrease the shared knowledge across the company. This is because people can set up an endless number of channels, and the conversation is now held all over the place.

Using the wrong software can make Working in the Open a challenging practice. Using a tool like slack actually creates many micro meetings between co-workers because of the expectation that everyone is available to respond in real-time to messages.

Have less private conversations. Keep conversations open and public, put them in the relevant channel so more people can engage. Best practice for chat tools is to send a link to the comment that you wrote in the relevant location as a reminder for the person to take a look at it.

Limit side-channel chats

A side-chat might be a conversation, meeting, or private message group. If you’re talking about a piece of work and having that conversation in a private channel, though it may feel more comfortable and safe, you’re creating a silo of information and preventing other stakeholders from understanding what’s going on. If you side-chat, it’s good practice to provide a status update about that chat to all stakeholders on the comment thread related to that work.

Commenting on work, and having conversations in the documentation reduces meetings, and gives others the ability to make informed decisions in the future.A distributed team has a goal that all information in the organisation is searchable. Side chats prevent this from happening.

Build a space for living documentation

Documentation represents information about the work, services, and policies for your company that should be shared within your organisation. This may be either a wiki or folder structure or a ticketing system.

Documentation needs to be:

Clear with understandable navigation and structure. (e.g. is the information nested in a hierarchy or flat like Wikipedia?)
Well designed easy to read. The most readable text on a computer has a line-width not wider than 70 characters, with sans serif font, 14–16pt, 127% or larger line-height spacing, and is written in plain English.
Use headings and iconography to scannable and quickly absorbable.
Capture decisions that were made, and discarded ideas.
Updated regularly.

Publishing draft documentation frequently by default

Publish your documentation frequently, even if it’s still a work in progress. There are a few good reasons why people should not be able to access documentation that you wrote in your company. By default, people should be able to see any documentation even if it’s in a draft state.

👍 good → tools that have all documentation in a draft and edit state and the default is that the draft is always visible.

👎 bad → tools like Confluence have 3 states, editing the draft, viewing draft, saved draft, and published. This draft functionality prevents living documentation. It also increases complication because editing is not shared by default, and the documents look different when in edit state vs view state which leads to switching between edit and preview increasing mental overhead and effort. Additionally, you want to be able to easily make edits to a document and resolve comments in real-time.

You can use callouts at the top of the document stating the status.

What is living documentation?

Living documentation:

Is always being updated and improved on. Work is always changing, and documentation needs to reflect that.
Tells a story.
Is the central hub for communication in the company.

For example, distributed teams need shared meeting notes. Meeting notes should be collaboratively written by more than one person during a meeting. To do this a team needs to agree on how they write up their notes, where they live, and choose a tool that allows real-time editing while a document is in draft state. This way when everyone joins a meeting, they know how to find the new notes for that meeting without asking.

Commenting in place decreases cognitive load

Use tools that allow you to have a comment thread in-line so you can highlight what you want to talk about and then talk about it.
Use tools that have a good notification system for managing and working through all of the comments that you need to see
Use tools that are easy to navigate to find the right place to start a conversation.
Use tools that make it easy to resolve a comment, and edit the content that was commented on quickly.

Commenting in place can work for all levels of documentation from general documentation, to design, to tech. For example, Github allows inline comment threads on pull requests, and Figma allows for inline commenting on design. Commenting in place builds a mind-map and uses a technique call the memory palace to make it easier to remember where to find the right piece of information.

Blogging

Blogging, in general, is a way to share extra context or learning. It helps distribute insights to be shared across the company. Writing articles with a target audience of your co-workers provides an open forum to talk about anything that you think is relevant to the rest of the company.

Blogs not only give staff the ability to articulate their thought, it also gives them an opportunity to proof-read their work before announcing that it is available instead of a random comment in a shared slack channel that will quickly get lost in the channel history.

Define an order of importance

Where is the first place that someone should comment when they have something to talk about? Define your companies strategy and priority for expected response times and communication within the company.

For example:

Dev ticket (e.g. Jira, Github, Trello, etc) — prefer all communication here if possible if relevant to tickets. Always @mention people when possible.
In the documentation wiki (e.g. Confluence, Notion, Gitbook, etc) — comment on-page, or comment inline. Give status updates for features and areas of work — @mention people when you want them to look at a page or respond.
Chat (e.g. slack) — random channel banter and general comment threads and questions to the team members.
Email — More formal channel, but expect a slower response time. Most people check their emails in the morning or the evening. Emails are perfect for communication where you require a response. Emails are not recommended for distributed team communication.
Calendar meeting — 100% expect you to show up to the meeting and be present if you agreed to the invite. Also, calendar invites come via email.
Other systems with comment functionality (e.g. Figma, Miro, etc.) — these tools may be checked irregularly depending on the notification settings of that tool. @mention people when you want them to look at a page or respond then follow up with a message in slack if it is more urgent.

The more tools you have with comment options, the more likely it is that some comments will not be seen by the person that you want to see it. Define how your team works for communication — different roles tend to use different tools for the majority of their communication.

Recommendations

Design your companies wiki and documentation strategy.
Have a majority of communication in the open, make sure that it is searchable.
Make process and progress visible.