Best Practices for Operating as a Remote Team
COVID-19 has forced most startups to be heavily remote for the foreseeable future, but having all-remote operations is new to the majority of companies out there and can introduce significant challenges. How do you replicate the casual conversations and brainstorming of an office? How do you maintain a strong culture and team bond without being together? How do you maintain communication to ensure the team remains aligned on the product vision and strategy without creating endless Zoom calls?
Questions like these are critical to maintaining an effective and high-morale team, but the answers aren’t obvious. As a result, these topics have been top of mind for almost every team we work with at Innovation Endeavors over the past few months.
In order to help answer some of these questions, we recently brought together a panel of experts who have led large-scale remote and distributed organizations to share their best practices: Darren Murph, the Head of Remote at GitLab; Marten Mickos, CEO of HackerOne and former CEO of MySQL; and Harpinder “Harpi” Singh, a partner at Innovation Endeavors and former founder of Slice Technologies and FiberTower.
You can find a recording of the session here. We’ve synthesized some of the key takeaways from this session below, as well as provided a full transcript here. Finally, we’ve linked to a number of the best resources available that delve into this topic at a greater depth.
The 8 Key Things You Should be Doing as a Remote Team
1. Rethink your “9–5”
One of the first topics we dove into was how to make yourself effective in a remote environment. A lot of people we know have struggled with the shift to remote for the following reasons:
- It’s much harder to focus at home, versus at an office where the entire reason you’re there is to work
- It’s easy to overwork and burn yourself out at home given that the whole day kind of blends together
- There is a lot less social, casual, or relaxing time than what you might get in an office
The first suggestion mentioned to deal with these types of challenges is to put constraints and boundaries into your schedule, as if you were commuting or going to an office. Put a calendar event, with a reminder, in your mornings and evenings and use that to ease into and out of work. In the morning you might use that time to read or listen to a podcast, and in the evening you might use that time to take a walk before engaging with your family. As an example, GitLab’s CRO found scheduling an evening wind down time was critical for him, so that once he engaged with his family, he was in “father mode”, not “CRO mode”. These sorts of events are also very valuable in terms of creating clearer delineations between when you are working versus when you are not. What you want to avoid is being partially “on” 24/7, which can easily lead to burnout.
Tied to this, you need to make sure you’re not simply copy pasting how you worked from before. It is worth rethinking your schedule, the meetings you attend, and the way you break down your days to fit this new normal. For example, in a remote environment, you may find that you really benefit from a 1–2 hour exercise break in the middle of the day given that you’re now sitting all the time at home, versus how you used to walk around a lot in an office. Or, you may find that certain types of things you used to do in casual meetings are now better off done asynchronously. Another idea raised was to proactively plan and engage in social activities with those who you are quarantined with or live near during the day. For example — have a socially distanced coffee with your neighbor in the middle of the day. You need to be cognizant that remote is fundamentally different, and as a result be open to changes and experiments like this. It will hopefully lead to a much more productive outcome.
You also want to be thoughtful about designing your working environment at home. Darren Murph from GitLab had a great point that it is somewhat of a fallacy — the workspace just happens to lead to so many accidental and productive conversations — offices are thoughtfully designed the way they are for a reason! There’s a reason the water cooler or coffee machine is where it is. There’s a reason for the desk layouts. And there is a whole profession of individuals whose sole job is to design workspaces to lead to happier, more productive employees. As such, you should try to take a similar approach to how you work remotely. Study your schedule, your patterns, your equipment, and don’t just take it for granted — plan it. This, combined with an open mind about the fact that what works best remote won’t match what worked best in the office, will really enable you to take care of yourself.
As a final point, Marten Mickos mentioned how our ancestors all primarily engaged in remote work. They were fishermen, hunters, gatherers, and 90+% of their day was spent alone. As such, humans are genetically wired to be capable of excelling in these environments. You just need to find how to achieve the right balance.
2. Leadership and culture matters more than ever
While there are a lot of things you can do to make yourself more effective as an employee, a lot of what enables a remote team to be successful comes from leadership, from the CEO all the way down to the managers. First of all, you need to ensure that your employees know and trust that they have the flexibility to experiment with different working styles in remote environments. If you expect everyone to stick with the exact same 9–5 from before, and you expect all the meetings and processes you had before to fully carry over, you’re putting undue constraints on your employees and significantly hurting your productivity potential.
Related to this, the importance of strong leaders that don’t micromanage, but rather set an extremely compelling and clear vision for the company that everyone can follow, is more important than ever when you have a highly distributed team. You will not be able to micromanage in this kind of environment, and much more work is going to be asynchronous. As such, it’s critical that employees fully grasp the story and the values of the company so they can be a “manager of one” in terms of then figuring out for themselves the right thing to do next.
Harpi brought up an interesting example of this from his time at Slice. The company had offices all over the world, ranging from Ukraine to the US, and they didn’t want any given office to be incapable of making progress without getting some sort of sign-off from another office. As such, it was critical that the company’s vision, story, and values could act as guide rails that anyone could use to know how to act and operate.
Tied to this, Harpi’s leadership team at Slice focused a lot on the concept of “one-team” — all employees and locations needed to be treated equally so that no one felt like a second class citizen. They did this in numerous ways, from putting key executives such as the data engineering lead for the entire company in the Ukraine office, to having a similar comp structure regardless of location, to figuring out how to create health insurance for the Ukrainian employees even when health insurance was not the norm in the Ukraine. These actions engendered a huge amount of trust and loyalty (and proved the company wasn’t just paying lip service to it’s values, but actually acted on them), which was vital given the naturally more decentralized nature of a highly distributed company.
Another aspect of leadership that was brought up a lot by all of the panelists is the importance of openness and transparency in a remote environment. If your team doesn’t understand what decisions are being made or why they’re being made, it is going to be much much harder for them to act effectively in their own roles. GitLab takes this to an extreme by publishing every single piece of information about the company — from org charts to compensation structures to strategy to OKRs — in a publicly viewable online handbook. But, while not every company may go to this extreme, all of our panelists agreed this was critical to their own success running remote companies. Again, this comes back to creating a more “self-service” organization where every individual has the tools, resources, and knowledge they need to operate without needing to create more communication overhead, which is extremely costly in a remote environment where people are not co-located.
While the above tips all reference how to be a leader with respect to the business itself, another facet of leadership that was continually referenced by the panelists was the importance of putting your whole self out there as a leader. In other words, showing things outside of work, from your vulnerabilities to your personal interests to your family. The reason this matters is that it is essential for remote companies to adopt channels, systems, and processes around informal and casual conversations (in order to recreate the social comradery that is a bit easier to achieve when you’re physically together), and it is going to be the leader who sets the example for your organization around what is acceptable to discuss and share. If you don’t do it, no one else will, but the result will be a company where people feel no affinity or cohesion with their coworkers.
A number of examples were brought up that demonstrate this point. HackerOne recently held a Juneteenth day full of programming across all of their channels — Slack, Zoom, Email — where people shared stories of what the day meant to them, their lived experiences, and other similar things. People cried and emotions were on full display; it was an intense day. But, by the whole team coming together, all the way from the executive team down to any individual employee, and putting their weaknesses and vulnerabilities on display, it truly deepened the bond within the team. Another simpler, yet no less impactful example, was that Marten has some “physical” emoji sticks he uses to express emotion over video calls. The panelists even discussed the value of being open about sharing how your kids might have left the bathroom messy! It might seem trivial, but situations like that will allow your whole team to then open up and ultimately still feel close even when they are thousands of miles away from each other.
3. Be intentional about cultivating team camaraderie
Our discussion on leadership branched into the topic of culture and team cohesion more broadly. It is certainly harder to make an all-remote or highly distributed organization feel like “one team”, as Harpi put it, but it is possible, and a few suggestions were raised.
First, and this extends off of the leadership advice above, is the importance of being intentional about informal communications. Informal communications matter a lot because they create trust and empathy between employees, and that is the currency that then allows such employees to collaborate effectively in an asynchronous manner. But, informal communications will not happen by chance in a remote company — they need to be planned and curated.
One key recommendation was to define “channels” in whatever communications tools you use, whether that is Slack, Gmail, Tandem, or something else, that are designed for non-work related discussions. Harpi’s company Slice Technologies had a “daily pics” channel where everyday people were encouraged to post a picture of them doing whatever they were doing, from the most mundane to the most exciting, and everyone could comment on it. GitLab hosts all kinds of events regularly, such as a “global” pizza party where everyone can go out for Pizza with their friends or family and then share the stories or pictures back with the whole company, or a “virtual talent show” for their marketing department with judges and prizes. MySQL has Slack channels to celebrate every possible thing — from business wins to personal stories — and every time someone posts something, the whole company responds with hundreds to thousands of emoji reactions. As he put it, “It feels like fireworks!”. The medium and the tools themselves don’t really matter here — what matters is creating a structure that enables the team to share who they are beyond the work they do. Humans yearn to make emotional connections, and it’s your job as the leader of a remote company to enable that.
Another tip that was mentioned by every single panelist was creating structures for celebrations and giving thanks. By default, we tend to be far more comfortable giving congratulatory remarks in person than online, likely because we tend to associate business communication channels with “serious” discussions. However, in a distributed company, you don’t have the in-person option as much, yet the importance of congratulating others in terms of the motivation and happiness it provides doesn’t wane. As such, there is immense value in finding ways to enable your employees to thank each other, and in giving thanks openly as a leader. As an example, Harpi’s companies had an internal system called “Shout Out” awards where anyone could give anyone else a $50 gift card to thank them for going above and beyond, and all they had to do was write a paragraph that they shared with the company about why they were giving it and what the person had done that was so impactful. GitLab has a “Thanks” Slack channel that essentially the entire company uses. MySQL has a “High Five” Slack channel. These approaches also echo a long-beloved practice within Google called “gThanks” where you can publicly send a thank you message, associated with a small cash bonus, to anyone you feel did an amazing job. The message was shared with that person’s manager and broader team, and it was an amazing way to make people feel appreciated for their hard work.
Finally, something that GitLab has seen work in terms of developing team cohesion is setting up more “casual” remote events together. This could be as simple as all being on a Zoom together, but no one is talking — you’re just individually working, together. Maybe you take turns having the participants be the remote DJ for the room. Remote happy hours can also be effective and something GitLab does a lot. Darren’s ultimate point was that you just need to be creative and try things, and don’t feel like they need to be big productions. You can keep it simple.
4. Prepare for the tough conversations
While it’s one thing to build systems and processes for giving thanks and celebrating wins in a remote scenario, it’s often even harder to have the hard conversations. Situations like delivering tough feedback, sharing bad news, or even firing someone are never easy, but doing them when you’re not with the person or team on the receiving end makes them that much harder.
With that said, there are a few strategies you can adopt to ease the burden of such situations. First, establishing a culture of openness and transparency mentioned earlier matters a lot here. The more that people feel open sharing and receiving information, the easier it will be to communicate even the bad news. Employees will know that, good or bad, you are open and clear with them, and the trust that engenders can really transform the way conversations like this go.
Second, it’s even more important to be prepared. Marten discussed how he writes down exactly what he is going to say beforehand, and then tells the person he can share the document with them immediately afterward. People may not always absorb all the information immediately in situations like this and it’s harder to give them the time to process in a remote environment, so having something they can go back to, re-read, and reference is extremely valuable.
Finally, you need to be willing to just wait, and sit, and listen. Doing these things is harder on something like Zoom — it’s a lot more natural to be saying nothing when you’re together in person. But, giving the person time to process matters even more in these scenarios, so make sure you provide it.
5. Rethink the way your team meets and collaborates
Meetings as a remote team are a challenging topic that most startups we’ve talked to are struggling with. There are two big problems that lead to this. The first is that the team wants to reproduce the amount of direct communication that previously happened, and as such introduces a ton of new meetings that weren’t there before, and now everyone feels like they are in meetings 24/7. The second is that the team adopts a skeuomorphic approach and tries to simply copy over all the meetings that existed before, without considering whether they make sense in a remote environment.
Darren talked extensively about this topic stemming from GitLab’s very unique meeting culture. GitLab does not allow a meeting to be scheduled unless there is an agenda on the invite from the second it is created, and after every meeting, the organizer must submit a change request uploading the output of the meeting to GitLab’s handbook. While this might seem extreme at first glance, it offers GitLab a lot of benefits.
First, it pushes as much communication as possible to asynchronous, which Gitlab has found is generally far more effective as a remote team. Asynchronous communication doesn’t require people to be in the same time zone or on the same schedule and scales much better for more complex decisions that require input from many people (meetings tend to be a lot less effective the more people you add).
This strategy also ensures that meetings always have a clear purpose, and that decisions are always captured, recorded, and preserved for the rest of the company to see. This has an immense benefit over time as there starts to be a true lineage of all the decisions in the company and why they were made. People will never question “Why did we do this?” or erroneously second guess a former decision, and similarly when new information comes in, you can easily go back and re-evaluate past decisions that were made.
But, even if you don’t plan on adopting GitLab’s approach, there are lessons to take from it. You need to be thoughtful with meetings as a distributed company; you should think carefully about whether each of the meetings you had from before translate well to a remote environment.
With that said, there is one type of “meeting” that all panelists agreed is seemingly even more important in a remote scenario, that is meetings which are more focused on team cohesion and social bonds, rather than a pure business decision. GitLab very much supports meetings being used to simply get to know another person within the company, and this approach was also very valuable for Harpi at his companies. It is far easier to develop a bond with someone in a synchronous environment, so make sure that your meetings emphasize this in some way. As one example, Slice had a weekly 60 minute engineering standup where each engineer had 1–2 minutes to just share what they were up to. The value of the meeting didn’t stem from making progress on business decisions, it stemmed from everyone hearing everyone else’s voice and the empathy and trust that creates. This then enabled much more effective asynchronous work that required less business decision making meetings.
6. Adopt a culture of writing and documentation
The other productivity tip for remote teams on which there was clear alignment from all of the panelists was the importance of a culture of documentation and writing. It is extraordinarily hard to be productive as a remote team if you still rely heavily on tribal knowledge being internalized by different people in the company, because you no longer have the ease of communication or discussion that you find in an office. This will especially start to hurt as your company scales. Darren’s pointed out how, when the 1500th employee onboards at GitLab, they can learn from knowledge that has been documented over the last 10 years, and that is infinitely better than what any human, or set of humans, could remember and walk the employee through. While documentation may seem short term inefficient in certain moments, medium and long term it is incredibly efficient. The work to write something down right now is nothing compared to the time that will need to be spent retelling that to people in the future, and the information degradation that occurs over time.
As such, virtually every remote company adopts a very strong cultural stance towards writing. GitLab takes this to an extreme with its handbook, but MySQL, HackerOne, Slice Technologies, and FiberTower all adopted similar approaches. For example, Slice had an internal “wiki” that all the employees contributed to which was critical for them. It enabled individuals, teams, and offices to have access to all the knowledge they needed to make decisions and build on what others had done, and as a result massively reduced the communication overhead of the company.
One common mistake companies can make in this pursuit is not having a single source of truth for knowledge. A culture of documentation will not work if each team documents things differently. If some information is in Google Docs, and some information is in Notion, and some information is elsewhere, you still have inaccessible silos that won’t effectively act as knowledge transfer mechanisms. You need to adopt a single source of truth, and as a leader to need to aggressively enforce a culture of adherence around that. For example, at GitLab, if someone posts an announcement in Slack and there is no corresponding handbook link, people will respond and all ask “Where is the link?”.
Documentation is also a key enabler for creating the culture of openness and transparency that has continually been mentioned above. In addition, writing everything down helps create buy-in from employees, as they now have the opportunity to contribute to that corpus of information. In this sense, documentation helps employees feel like “owners”. GitLab is famous for allowing anyone to submit a merge request to their handbook with a suggestion, and that has been extremely impactful for them. They’ve had designers help fix the onboarding documentation, and they’ve even had non-employees make suggestions that improved the handbook! Finally, documenting decisions and decision-making enforces equity, consistency, and clarity of thought in a way that decisions which aren’t written down simply don’t.
This ties into the question of — “How do I onboard an employee remotely?”. The biggest tip the panelists had was around documentation. The more methodical you are, the more regimented you are in your knowledge transfer approach, the easier the process will be. While, of course, you will still need to check in with the employee, see how they’re feeling, and help expand on things that aren’t clear, this will be substantially simpler if 90% of the knowledge is written down for the employee to learn. This isn’t as needed in office environments where anything that you forget to mention can simply be explained in real-time as the new employee sits over your shoulder for the first 1–2 weeks, but it is critical in a remote environment where they are more on their own.
One final thing that was brought up is the importance of documenting not just knowledge, but systems and processes.
7. Automate and systematize your processes
A final way that remote can really stress your organization is the burden it places on systems and processes. In most companies, various employees hold an internal picture in their heads of the steps that need to be stitched together every time Y happens or X occurs. This can lead to problems in a remote or distributed environment when it becomes much more challenging for employees to share those processes with each other, or coordinate within those processes.
As such, it’s typically in the best interest of remote startups to do a few things to address this. First, you need to make sure you document all systems and processes with the same rigor with which you document knowledge. Second, you should consider which of your processes can be automated or streamlined in order to remove the communication and coordination burdens associated with them.
As an example, Harpi touched on how one of his companies was forced to adopt fully automated CICD (continuous integration, continuous delivery) at a time when this was far, far from the norm. But, it paid enormous dividends because it freed up the need for engineers across the world to constantly be coordinating and communicating just to get a release out of the door. Marten referenced how software is the ultimate expression of human intent, and how documentation is simpler a weaker form of software. So, try to automate and/or document every internal process within your company, and you’ll find you have a far more effective remote organization.
8. Rethink the way your company operates coming out of COVID
A final point that was touched on is what companies might need to deal with, or consider, as COVID-19 wanes and they return to the office. It’s likely that most companies will transition into some kind of hybrid environment, with some employees staying remote (such as those who are older or have more comorbidities) and some returning to the office. The challenge here is that managing a hybrid company is far, far more difficult than managing an all-remote company. GitLab’s handbook talks in depth about this, and Darren touched on it further during the panel.
The basic issue is that it’s easy to regress into a situation where the office workers become the “first class” citizens, and where the communication standards of the company assume some degree of colocation. This will create a huge degree of disillusionment and discouragement among your remote employees. In a sense, Darren thinks this is why so many companies have realized things have been better than they expected during COVID. Because they were forced to be all-remote, it was easier to adapt, but you need to be far more thoughtful and intentional about leading a hybrid-remote company.
While Marten was quick to say he does think hybrid models can work — MySQL for example did well under this model — it only works if the leadership really enforces best practices from the top down. The office has to be just another “remote” space and the culture can’t be defined by the walls in the office. The things mentioned in this article matter even more, because they won’t come effortlessly; the natural inertia of the company will be towards haves vs. have-nots.
Additional Resources on Operating as a Remote or Distributed Team
- GitLab’s Guide to All-Remote: This links to all of Gitlab’s resources on remote work (e.g. GitLab Onboarding Guide)
- 9 Ways to Make Working Remote Work for You (DataDog)
- Collaborating at GitHub with a 60% Remote Workforce
- Onboarding as a remote engineer with Mattermost
- How to build (and sustain) culture in a remote environment | Inside Design Blog
- How to set up remote teams during coronavirus
- GitLab’s Secret to Managing 160 Employees in 160 Locations
- 2019 Distributed Development | Sid Sijbrandij, Co Founder & CEO, GitLab
- Why GitLab Hired a Head of Remote
- Podcast by Marten Mickos, former CEO of MySQL, on working from home
- Darren’s README
- Creating GitLab’s Remote Playbook With Darren Murph (Changelog Podcast)
- How MySQL’s distributed organization worked
- CNN Money: How to manage employees who work from home (Marten Mickos)
- How to Get The Most Out of Employees Who Work From Home (Marten Mickos)
- Basecamp’s Remote book
- HashiCorp’s Principles for Remote (A series of tweets by Mitchell Hashimoto, HashiCorp Founder)
- Remote Without Warning: How to adapt and thrive as a suddenly-remote company (GitLab)