I got my first job with a distributed company in 2012. We had about a 25 person team across three continents. It was the first time I had worked for a company where everyone wasn’t in the same office.
Overall, it was a great experience, I had a lot more flexibility with how I used my time – no more worrying about asking to come in late because of a dentist appointment and it was easy to pop off for a few hours to go work at a coffee shop or do a quick workout.
But distributed work also comes with unique challenges. Working with people in very different time zones often leads to not being able to shut off since someone is always online.
Though many companies fear that letting their people go distributed will lead to people slacking off, the far more common problem is overwork and burn out. The people that slack off were already slacking off in the office anyway and the people that were working hard will work even harder to make sure that they don’t seem like they are slacking off.
Regular readers will have heard me say that I think we are in the very early stage of distributed work, a phase akin to the very first factories being built using electricity as the main source of power rather than steam.
These sorts of technological innovations tend to require social innovations to get the most out of them, a process that typically takes up to a century as technology historian Carlotta Perez researched in her excellent book Technological Revolutions and Financial Capital.
In the case of the move from steam to electricity, the first electric factories were built just like steam-powered factories with everything crammed as close to the central turbine where the steam came out.
For a steam-powered factory, this was necessary. You lost too much energy moving the energy far away from the turbine so most steam-powered factories had all the machinery placed in a circle around the central turbine, sometimes on multiple floors.
With an electric factory, it was much cheaper to move energy around. It took a few decades, but eventually, factories were radically redesigned and the birth of the “production line” emerged. This was a set up that only became possible once the move from steam power to electricity happened and you could get power to the sub-stations along the line in an energy-efficient way using electricity.
To capitalize on the technological innovation of electricity required an improvement of the social technology around how we designed factories. The history of technology is the history of the co-evolution of technological and social innovation.
The same is no less true as it relates to distributed work. Zoom, a critical piece of distributed team infrastructure only IPO’d in 2019, so we are in the very early days of figuring out the social innovation needed to make the most of what the internet has made possible. We still have a lot to learn about how distributed teams best work effectively, but the importance is no less than that of the production line in the 20th century and the companies which are earliest on this shift will stand to benefit quite a lot.
I have experimented with many different approaches over the last nine years to how to work with distributed teams so I wanted to share my current approach to how I try to work with a distributed team.
The below is an annotated version of my current best practices approach.
General Guidelines
Take spatial context seriously: If we’re discussing a specific task, we discuss it in the comment section below the task itself. If we’re talking about a specific document, we discuss it in the comments attached to the document.
Communications stay attached to the thing we’re discussing. This provides the full story in one reliable place. The alternative is communication detached from the original source material, discussions all over the place, fragmented conversations missing entire chunks of time and detail leading to confusion, extra work, and frustration.
Poor communication creates more work. Getting in sync with your team and communicating to help your team stay in sync with you is not something annoying you have to do in addition to your job, it is a core and central part of your job.
Much of the issues from people new to distributed work (and even many that have been doing it for years) is a lack of appreciation about how much “bandwidth” is lost. Though we tend to focus on just the words people say, the body language, facial expressions, smells and all other sensory inputs you have in an office do a lot of the communication. Where this is the “default” in an office, it requires deliberate attention and focus for a distributed team.
In general, everyone should probably feel that they are “wasting” a lot of time keeping everyone updated. Once you account for the reduced miscommunication and truly wasted work this prevents, it ends up being an extremely productive use of time.
Communication Happens in These Places:
- Internal Knowledge Base (E.g. Google Docs, Notion)
- Messaging Apps (E.g. Slack, Teams)
- Task Management System (E.g. Asana, ClickUp, Trello, ToDoist)
- Video Chat (E.g. Zoom, Google Meet)
Communication Prioritization
Non-urgent but Important – Draft a longform explanation of the issue, relevant background, and proposed steps forward. Share it with all relevant parties and give them a date by which you need feedback and when a decision is going to be made (e.g. by creating a task for them in our task management system to review and respond). If appropriate, it can be added to the discussion notes to discuss on the next call for a final decision after everyone has read and responded.
Please try to send at least 1 business day in advance of a call to give everyone time to read and review. Speaking only helps who’s in the room, writing helps everyone. This includes people who couldn’t make it, or future employees who join years from now.
- Examples: Proposed New Marketing Strategy, updating outhe organization of our internal system
- Once a decision is made on any issue, write a conclusion for future reference.
- Guidelines
- Be conscious that if your words can be perceived in different ways, they’ll be understood in the way which does the most harm and seems the most hurtful. Words matter, choose them carefully.
Editor’s Note: Longform written communication is the best way I know of to overcome the bandwidth issue and avoid miscommunication. One person advocating for the change does the work of clearly articulating the issue and a proposed solution and everyone has time to think through and respond.
Non-urgent and Not important –
- Consider if anything needs to be said at all, if so then communicate via Slack.
Semi-urgent (requires feedback in the next 1-2 business days) –
- When it relates to a specific task: should be commented on in the Task Management System.
- Ex. We are waiting on Ellen to get the final details so the newsletter is delayed. In that case, comment on the newsletter task with the expected date of getting final details so the person in charge of that task can re-prioritize.
- When it does not relate to a specific task, send it via Slack in the appropriate channel.
Urgent – requiring feedback soon (hours) should be sent via Slack.
- Ex. The website goes down, a customer needs information before signing a contract.
Emergency – Call/text everyone ASAP
- Ex. Cybersecurity breach/compromise, some mistake leading to significant financial loss.
- These should be very rare. If you have more than 2-4 emergencies per year, then your systems are not properly built out.
Knowledge Base Guidelines
We call our knowledge base a standard operating system. It is the system we use to organize and execute these processes that make the company successful. It’s essential to us being a successful company that everyone uses the system by keeping documents organized, creating new Standard Operating Procedures (SOPs) for defined processes, and updating existing ones when necessary.
How the Standard Operating System is Organized
The Main Standard Operating Folder (SOF) has 6 Files:
- Projects Folder – These are files related to specific projects which are not ongoing and have a clear “finish line”.
a) E.g. Setting up a new entity, a product launch.
b) When you start saving project files, create a new folder with the project name. E.g. “June 2021 Product Launch”. - SOPs/Areas Folder – These are files and SOPs related to specific areas of the business which are ongoing indefinitely.
a) E.g. Newsletter, podcast, internal policies. - Resources Folder – These are any shared resources that are not specifically related to either a project or area but are still in current use.
a) E.g. Graphic assets. - Archive Folder – For any Projects, SOPs/Areas/Resources that are no longer in current use.
- Drafts Folder – This is a catch all for creating anything when it’s not clear which of the above folders it will go into. It’s a good place to store ideas and drafts of what might eventually become SOPs. Use this folder to keep from cluttering up the other folders so the essential documents remain easy to find.
- The Standard Operating Document (SOD) – This is a Text Document that organizes the Projects, SOPs/Areas, and Resources in an easy to reference way. It is like a table of contents or index for all our processes.
When Should an SOP be Created?
- Recurring – SOPs should only be created for tasks or projects which are recurring. One-off tasks can be managed in the task management system.
- Takes more than 30 Minutes – Recurring tasks that take less than 30 minutes do not need a separate SOP. A short SOP can and should be included in the description of the task itself in the task management system.
How To Create a Document in the SOF
General Guidelines
The Off-the-Street Test – SOPs should strive to pass the “off-the-street test”. That is someone should be able to come off the street (with basic qualifications for their position) and be able to execute on it.
- Do not assume previous knowledge or experience, everything should be obvious and logical.
- 95% Perfection – It’s not worth the painstaking effort to get it to 100%, but each SOP should be good enough to consistently achieve the desired result of the SOP.
Do it Now – An SOP should be created for any repeated task in the business. It’s fine if version 1.0 is extremely basic with just a few bullet points, the most important thing is to just get started with it.
- Anytime a SOP that already exists is executed, it should be improved or streamlined in some way. All our SOPs are living documents which need to be constantly updated. Always try to leave a SOP better than you found it when you use it.
- If a problem arises with a procedure, instantly adjust the procedure, do not circumvent it without updating the process.
SOP Formatting Guidelines
Document Name: [INSERT NAME OF PROCEDURE SOP]
Title: Same as Document Name – Centered in Style Title
Each SOP should have an intro answering the following questions:
- Why? – Why is the SOP executed? How does it create value in the business?
- Where? – Is the location executed in a specific place? (Physical or Digital)
- When? – Is this SOP executed at a specific time? After a specific action?
- Who? – Who executes the SOP? Use titles instead of names wherever possible so that as the company grows, the SOPs scale better.
Editor’s Note: I have a previous post that goes into more detail on my knowledge base/SOP system.
Task Management Guidelines
- It’s Our Centralized Task Management Center: Our task management system is the centralized location where tasks are assigned by team leaders. It’s also the location where we store all the tasks which are then linked to relevant SOPs (standard operating procedures) that help us run the business.
- Keep Task Related Communications WITHIN the task management system: As much as possible, all communications around a specific task should be made within the task management system by commenting on tasks and not by sending outside emails or communications. This gives one central place to get all information relevant to that task. Remember, we take spatial context seriously.
- Add a Real Profile Picture: Having a real picture of your face helps make the workplace and team more personal. Always have a real profile picture.
Messaging App Guidelines
Default Open – By default, share any message with the most possible people whom it would affect. Though it often seems like you are “bothering” people, it takes a short time to read a message and often saves hours of work due to a lack of context. Before sending a message always ask what is the most open channel in which it would be appropriate.
Corollary: Direct Messages are the root of all evil, confusion, and missed context. Use them only as strictly necessary.
Slack Channels – Channels should start limited and evolve organically as more are needed. While “default open” is a good starting point, there is a threshold where it becomes confusing. Having specific channels where any relevant participant can view things is the right balance.
Examples of Channels for a 5-8 person company:
- #Random – For comments not related to business functions (E.g. what you did over the weekend, funny meme, or article).
- #Sales and Onboarding – For anything related to getting an interested prospect onboarded (e.g. someone has a follow up question, needs onboarding info).
- #Marketing – Anything marketing-related (e.g. Newsletter, Podcast, etc.)
- #Operations – Anything related to internal operations outside of onboarding (e.g. compliance reports).
- #General – For anything business related but not included above.
- #Weekly Reports – For everyone to post their weekly update.
This provides enough specificity that there is context around a comment (e.g. a comment in #Operations will and should be perceived differently than one in #Random) without creating too much siloing of conversations that leads to missed context and confusion.
It may also be appropriate to create a channel for specific one-off projects as needed and shut them down once those projects are completed.
Meetings Guidelines
Virtual Meetings
- Take Notes – For any meeting relevant to others in the company, take (detailed) notes and share them with everyone else. This reduces the number of people that need to be on calls (since people that just want to “listen in” can just read the notes). Consider that five people in a Zoom for an hour isn’t a one-hour meeting, it’s a five-hour meeting. Be mindful of the tradeoffs and use notes where possible.
- E.g. Salespeople don’t need to be on all Ops calls but would benefit from reviewing a short summary of points covered.
- Have an Agenda – every meeting has a “lead” who is in charge of preparing the agenda and sending it to everyone (along with any relevant memos) in advance.
- Anyone that proposes a one-off meeting is in charge of the agenda for that meeting.
- Turn on Your Camera – when we are on video calls, turn on your camera. If you’re not somewhere that you can turn your camera on, it suggests you aren’t able to pay attention to what’s going on. It’s ok if you just need to “listen in”, but most of the times you probably can just look at the notes in that case.
- Always be screen sharing – Whoever is speaking should (almost) always be sharing their screen and showing what they are speaking about. It’s easy to talk past each other, looking at the actual thing together helps eliminate miscommunication and make communication faster and more effective.
In Person Meetings
- Try to spend at least two weeks per year in person to get synced. These can act as a “catch up” that helps to get everyone on the same page in a high bandwidth way.
Editor’s Note: Convertkit has a great explanation of how they run their team retreats.
Weekly Check-Ins
- Prior to the weekly operations meetings, everyone updates the task management system and writes a brief (~5-10 mins) summary of what they worked on the previous week and what their priorities are for the coming week. We review these on the call so everyone has a good “map” of what is going on in the company.
Quarterly Reviews
- Summarize the last ~12-weeks of work for a given team, department, or individual (if that person is a department of one). They’re written by the lead of the group, and they’re meant for everyone in the company to read. They summarize the big picture accomplishments, they detail the little things that mattered, and they generally highlight the importance of the work. They’ll also shine a light on challenges and difficulties along the way.
I don’t always perfectly follow the rules I laid out here, but things tend to work better when I do. I’m sure there are lots of ways to improve on this procedure (if you have one hit reply – I’m open to ideas!), but I think nearly every distributed company would benefit from having explicit guidelines around how and where they communicate.
H/t to Basecamp and Matt Mullenweg of Automattic from whom many of these ideas were inspired.
Last Updated on February 8, 2021 by Taylor Pearson