Table of Contents
When I co-founded my company in 2009, I had no choice about whether I was going to be running a remote, distributed business.
I was living in student accommodation, halfway through my second year at university. Money was limited so I built the initial product with one of my friends, bootstrapping the company from savings and then customer revenue. We couldn’t afford an office, and were happy working from home anyway – much easier to get to lectures on time!
Over the following 9 years, we grew the company on a remote-first, distributed model. All our engineers worked remotely and we only opened a physical office after 3 years so that we could bring the London team together. Later this evolved to deliberately building the commercial team in the office, but still operating using a distributed model for engineering.
At the time (2009), there were very few companies doing the same thing. Remote work was weird and rare. Most people commuted to an office.
That is still the majority of cases, but there are now companies operating at significant scale in a mostly or entirely remote, distributed way.
It is becoming clearer that office-based jobs can be done more effectively from home. It doesn’t work for everyone and remote working is not a magical cure to all the problems of an office. Indeed, remote working has its own challenges but it is becoming more desirable with clear benefits to both the employee and employer.
I fell into this mode of working through necessity, figuring out what to do through trial and error. This post is about how that worked and the lessons learned scaling to 20+ people globally.
Does working remotely work? #
Yes, there are many of examples of successful companies operating on a remote, distributed model. It is not an unusual way to work.
The number of remote workers in the US grew by 79% between 2005 and 2012. The US Government issues annual reports on its approach to teleworking. For fiscal year 2017, they report:
improved attainment of goals in almost every area: improved employee attitudes; emergency preparedness; recruitment; retention; reduced employee commute miles; improved employee performance; and reduced real estate costs
Cost savings were also tracked:
Over a quarter of Federal agencies were able to track some form of cost savings due to telework (29 percent). Those agencies increasingly reported cost savings achieved through telework, especially in the areas of transit/commuting, rent/office space, and reduced employee absences.
Similar effects have been studied in private companies, too:
Nicholas Bloom and graduate student James Liang, who is also a cofounder of the Chinese travel website Ctrip, gave the staff at Ctrip’s call center the opportunity to volunteer to work from home for nine months. Half the volunteers were allowed to telecommute; the rest remained in the office as a control group. Survey responses and performance data collected at the conclusion of the study revealed that, in comparison with the employees who came into the office, the at-home workers were not only happier and less likely to quit but also more productive.
The evidence is there to show that remote working has tangible benefits. The list of companies implementing this at scale is impressive.
Examples of remote, distributed companies #
One of the big challenges I faced growing my company was there were very few businesses that were operating remote-first. Emphasis on “first”. There are thousands of distributed companies – any business that has more than 1 office has to deal with employees in different locations. However, whilst they might use many of the tools you will find in a remote-first company, they still apply office-based thinking to solving problems.
Today, we not only have startups adopting a remote-first model, there are companies at large scale doing this successfully.
Examples of remote, distributed companies: Automattic, GitLab, InVision, Zapier, Buffer and Basecamp #
Automattic, the business behind WordPress, Jetpack and many other projects, has been doing this for over 15 years. They are now approaching 900 people.
Much like WordPress sought to change the way we publish on the web, Automattic has set out to change the way we work. We are an entirely distributed company — with more than 800 employees working from more than 62 countries, and no physical headquarters. We are a company that works on, and for, the web.
Another company doing this at scale is GitLab. They have over 650 people working from 50 different countries, all-remote. To make this work, they have also adopted a culture of transparency both internally and externally. This has proven extremely helpful for sharing how they manage the company and setting them up to be a shining example of how to run a remote business.
At GitLab, everything is documented in a 2000+ page public handbook. From their all-remote manifesto to how they manage hiring and how their customer success team operate is covered. Writing is key to success for all businesses and GitLab go one step further by sharing this so others can see what might work for them.
Remote working has an influence on how your own products develop. Automattic developed the P2 theme which is what they use internally for communication. InVision have over 1,000 people working for them remotely, and this has influenced features in their own products.
For the team behind InVision Studio, working remotely has helped them do more than just communicate and collaborate better—it’s allowed them to spot gaps in their own workflow and then apply those solutions to Studio as they build it. What better way to know whether your platform’s features are intuitive, accessible, powerful, or complete unless you were thrust into the exact scenario in which they’d be most needed?
On the smaller side but still quite big (and growing), Zapier has over 100 people all working remotely. Another tech startup offering a technical product, Zapier have written extensively about how their company works and how to succeed in a remote, distributed model.
It’s not just companies selling to engineers or those in the same industry. Buffer is 80+ people, all remote. And Basecamp, one of the original remote-first companies who’s founders wrote Remote all about distributed work, are currently at around 50 people.
So is the remote, distributed model the future of work? Matt Mullenweg of Automattic certainly thinks so.
Core principles for a remote, distributed company #
The tools used to run a remote, distributed company are relevant but you have to apply some core principles first. A degree of process is necessary in any company but is particularly important where remote work is concerned.
Many companies focus too much on technology and not enough on process. This is akin to trying to fix a sports team’s performance by buying better equipment. These adjustments alone might result in minor improvements, but real change requires a return to fundamentals.
Communication is the hardest part of running any company. It is important for everyone to have a clear sense of the company mission and values, how things are going and what their impact should be.
This is harder in remote-first companies because it requires more effort than simply talking to someone sitting next to you.
That said, many of the strategies for addressing this will significantly improve the working environment and culture of any company, remote-first or not. I’ve written about this is much more detail so won’t cover it here:
Establishing a regular communication and reporting cadence is a standard part of running a public company – financials and progress get announced in an expected format on an expected timeline. If public companies can do this on a quarterly basis, there’s no reason why smaller companies can’t do it too, and likely much more regularly.
There are industries where trust is not necessary. Those are often environments where the job is based on rapid, repeat assembly work. Factories or perhaps certain types of manual labour. In these roles, employees are tracked so closely to try to engineer trust out of the equation.
That said I’d still argue that regardless of the job, you want to hire people you can trust otherwise you end up depersonalising the role. That’s not a good working environment.
The context of this article is knowledge-work such as technology, engineering, science, research, i.e. roles that could be office-based.
If you can’t trust your people to do what they should be doing without you standing over their shoulder, you’ve hired the wrong people. That’s not a process problem, it’s a people problem.
The worst kind of work is where you are simply following orders.
Sometimes issuing specific tasks is necessary e.g. preparing a spreadsheet of KPIs or fixing a reported bug. However, most knowledge-work is best driven by outcomes, leaving the individual to decide how to achieve it (guided by the company mission and values).
Managers should not be defining “how” and need to take deliberate steps to avoid being controlling.
Very few knowledge workers bill by time increment. Engineers, programmers and academics are usually paid fixed salaries.
Lawyers are a good counter-example. Some projects can be scoped to a fixed budget but legal questions often require research which can’t be time estimated. Such things require reading, writing, editing and conference calls plus discussion with colleagues. You are paying for their ability to locate and synthesise information so as to form a technical, legal opinion.
Another example might be software engineering. There are many freelancers who will charge based on number of hours. Whether this is the correct way to charge for development is debatable. The best consultants work with customers on the basis of the value they deliver, not the amount of time spent.
The main thing holding my rate down for the early years was personal discomfort with being “worth” the types of rates which I desired to charge. I dealt with (deal with?) impostor syndrome frequently and had little context for what alchemy one needs to work to justify professional rates.
Spoiler alert: there is virtually no difference in the mechanics of work done between $100 an hour, $200 an hour, and $30k a week — all of the leveling up there is in sophistication on who you go after, what engagements you propose and deliver, and how you package things for clients.
By the end of my consulting career, I pointed to a small pile of mostly satisfied customers and other evidence that I could do the work, sketched out a “Here’s how I plan to create a couple million dollars of value for your company” in proposals, and then just announced my rate. I received rather less pushback than I expected and virtually never negotiated on rate, using a trick from Thomas Ptacek (“If a client says you’re out of the budget, start talking about the scope of the engagement to find something they can afford rather than slipping your rate.”)
Understanding whether someone is performing in a salaried role is more complicated than correlating minutes tracked, lines of code written, emails sent, bugs fixed, tickets replied to, or whatever arbitrary and irrelevant metric your manager might be able to come up with.
This is ultimately about working to outcomes and not micromanaging your team.
Being deliberate #
Linked to communication, this means taking extra effort to ensure everyone is in sync. Symptoms of not doing this properly include:
- Information disseminated by rumour.
- Inaccuracies and mixed messages leading to confusion.
- Incorrect understanding of roles, goals, methods of working and deliverables.
- Not knowing how the company is performing.
- Misunderstanding what everyone is working on and how you should be contributing.
- Inability for teams to “do the right thing” and needing to wait for specific directions and task assignments.
The most common approach to address this is to write everything down, share everything, record/transcribe meetings, be as transparent as possible and not rely on informal methods of communication.
An engineering driven approach is to think about how to set up an organisational commit log.
This is where tools start to come in and becomes crucial for scaling past a couple of people. Do you use Slack as the primary communication method? Or email? What goes into a Google Doc vs a text file in a code repo? These are all important decisions but what you do and how you do it don’t really matter. It’s making a decision that counts. Everything should have exactly one “correct place” and everyone should know where that is.
Without formally documenting how the company operates, you end up with multiple channels and information all over the place. Sharepoint, Google Docs, Slack, Confluence, email, [other random tool used by just one team].
GitLab’s handbook offers a great example of how to they this. You could adopt the same approach or create your own. The point is to just make a decision, then document it.
How do you motivate a remote team? #
There are 3 key elements to motivating remote, distributed teams:
- Meaningful work: This is one of the main advantages of smaller startups – each person is a significant part of the company and has a large impact on overall success. As the organisation grows, roles necessarily become more specialised and the meaning of the work changes. In startups, you work on a large part of something used by a small number of people. In large corporates, you work on a small part of something used by a large number of people. This is leverage. Otherwise, it can be challenging to see what impact your work has. Bored people quit.
- Care about your people: It might sound obvious but so many companies clearly do not care about their people. This can still be a competitive advantage in how your company culture, values and approach to management bring out the best in everyone. This isn’t about providing free lunch, unlimited holiday (which actually doesn’t work) or book allowances, it comes down to the fundamentals of managing humans. Do you feel like your manager cares about you as a person? Are they regularly making time to talk about not just work-related topics? Do you trust them and feel like they have your back? Companies are not families but they are quite close it it. The relationship is always going to be professional but it is in the interests of the company not just to care about revenue and profit because it is actually the people delivering those numbers. People don’t quit bosses, they quit jobs, but who is responsible for what the job is like? The boss.
- Communicate regularly: This is a running theme of the post so I won’t add any more here other than continuing to highlight how important it is.
Notice how these are not unique to remote, distributed companies? You can apply them to any company. It is only the implementation that is different in a remote company.
Challenges of remote, distributed working #
Personal connections #
The most crucial lesson I learned was about how important it was to get to know the team in-person, and for the team to get to know each other.
Whenever we hired someone new at Server Density, I could separate their time with the company into two phases: before they met everyone, and after. Although new hires usually got on with everyone fine via chat and video calls, there was a noticeable difference in their engagement once they had met the whole company.
Early in the life of my company, full meetups were more ad-hoc and less frequent. But by the time of the acquisition we were trying to get the whole company to meet every quarter.
…even the best video chat experiences can’t quite match the fidelity of a face-to-face conversation in a physical space. There is so much nuance and context to human communication that is lost, especially when conversing in groups. It’s why distributed companies (like mine, Automattic) still have in-person team meetups and all-company gatherings — technology simply can’t replace the human connection of being together.
There are many ways to organise these meetups, from flying the whole company away for exotic retreats to just a few days all working together in one place. What matters isn’t so much the format but getting everyone together to work, socialise and get to know each other.
We try to get together every 9 months or so to get face-time with one another, build community, and get some work done! Since our team is scattered all over the globe, we try to plan a different location for each GitLab Contribute.
Contribute is not a mandatory trip or a department offsite, nor is it a vacation or incentive trip. It’s a chance for everyone to meet fellow GitLab team-members across all departments and regions: part team building, part education, part customer interaction, and hopefully all fun.
This can be expensive, especially as the company grows, but is definitely worth the cost for the improvements to team morale and productivity in the long run.
Remote, distributed working is not a method of cost-saving. Money not spent on an office will instead be spent on travel expenses.
Buffer wrote about how they handle their meetups and also recorded a more recent podcast that goes into detail about how it all works.
Working on a single mission #
Sometimes it’s necessary to bring everyone together for a sprint towards a single goal. Such occasions should be rare but where that shared sense or purpose is really necessary, it is beneficial to all be in the same physical location.
If I was starting a new company, I would include significantly more time working together from the same location. Critical times call for working in-person.The formation of a new startup is one of those times.
This is one of the arguments behind a tweet by investor, Arianna Simpson:
In a followup podcast she elaborated on the specific scenarios where she thinks it does make sense for everyone to be in the same location.
One thing I’ve noticed about startups that end up being very successful is often there is this strong sense of shared mission and shared energy, and that I find very difficult to replicate if you have people in different locations because you don’t have the same sense of camaraderie, the same sense of “You know what, this sucks but we’re gonna stay here until 10 PM and pound it out until we’re done ’cause we’ve gotta get this release out,” or whatever it is. So that is a really difficult intangible that’s hard to replicate if you have people in different time zones or different locations. It’s hard to muster up the same level of enthusiasm.
Starting a new project is a similar situation where you might want to have the team together for the kick-off, planning, design and initial implementation.
The end of a project can also be a good time to have everyone together. Celebrating the launch and completion of a major project in person can have a major, positive impact on morale.
Remote, distributed-first does not mean exclusively remote, distributed-only.
You’ll note that communication is a common theme when thinking about remote, distributed teams. This is because it is so difficult to get right.
If the problem of working in an office is the constant interruptions, then the problem of remote working is the default to using real time chat. Slack is the most common example, but it applies to any kind of instant messaging.
I’ve written in detail about the challenges of communication in general and also about chat:
I personally dislike Slack (and any real-time chat) for anything other than general, social chat or deliberate collaboration on an ongoing project e.g. triaging a customer issue with a group of people in real time, doing incident response, or backchannel chat between participants during a sales meeting. These are all instances where a small number of people come together for a specific task and for a specific period of time, after which they disband. Real time chat is an awful tool for anything else because it implies everyone must be available and responsive immediately, at all times. Information is too easily lost.
My favourite article on the challenges of chat is “Is group chat making you sweat?“. Email is my preferred method of communication because of how flexible it is – I can choose my client, layout, set up filters and decide when to check it. It’s not perfect but it really does beat instant messaging:
So what about IMs? In short… they combine the worst of both worlds while having the strength of none of them.
In theory, IMs are supposed to be fast (“instant”), but in practice typing takes enough time, to make instant messages much slower than simply talking. Ironically, the expectation of a fast response forces everyone to write short and rather poorly structured short phrases that are hard to understand, especially out of the context of current circumstances.
In theory, IM communication is persistent, but in practice because of lack of structure, intertwined topics, and insufficient metadata, what have been persisted is mostly useless. Searching through the history of a Slack room is difficult, and rarely useful.
That said, we have gone through a similar transition in the past – from no email to email – and similar problems arose. Email is certainly not universally loved.
In a 2011 study published in the journal Organization Science, researchers noted that while email was widely regarded as a “growing source of stress in people’s lives,” research also suggests that it affords people “flexibility and control by enabling them to communicate from anywhere at any time.” To attempt to address this contradiction, the researchers drew on interviews from nearly a decade earlier, conducted when email itself was still ripping through American offices, and producing its own stories of relief, ambivalence, and horror. Employees’ worries will sound familiar, and in hindsight maybe not unwarranted. “Although, in theory, email’s asynchrony should have granted recipients the leeway to respond at a time that was convenient for them,” the study said, “our informants described strong cultural expectations about not keeping senders waiting.”
As with any workplace culture, it is important for management to set the example of what is acceptable.
Stephen R. Barley, a professor of technology management at the University of California Santa Barbara and a co-author of the paper, remembers subjects lamenting, nearly 20 years ago, the erosion of work boundaries as symbolized and enacted by email. “I think what they’re really expressing, and most white-collar workers would never say this, is that these technologies are appropriating time at the beginning and end of days, without any kind of payment,” he said in a phone interview. “It’s an encroachment of work into other spaces in your life.”
But with Slack, there is no perfect equivalent to inbox zero; an instant message from your boss during the day might demand not just a quick response, but an instant one; it will be up to us, but mainly our bosses, to establish what a late-night Slack message means or demands, as compared to an email, and what noise or vibration it should cause in the phone that many of us have moved closer to our beds.
Chat is here to stay and so this means developing a simple set of rules for where communication should take place. One approach is to delete messages after a short period of time. This makes it clear that chat is ephemeral. How often do you actually search chat logs and find something useful?
Density of expertise #
Despite the major advantage of remote, distributed work being that you can hire the best people anywhere in the world, expertise still clusters in specific locations.
My conclusion is that whilst you can quite easily build out product, engineering and customer support teams within Europe and the UK, it is very difficult to do the same with early stage commercial teams. There’s the occasional highly talented individual who has done it before in the UK, but otherwise it’s almost impossible to recruit for commercial roles here. The initial sales, marketing and customer success hires need to be in the US.
Whilst you can build these teams remotely, it may place you at a disadvantage against competition who can leverage the benefits of a specific location.
If you are building a high-growth, venture funded startup in a very competitive industry, this will matter at very specific stages of the company lifecycle. It matters who the initial founding team are. It matters when you start to build out that first commercial team. And it matters again when the company goes into scale mode, leading into an IPO.
So why are industry towns so powerful?
1. Talent base. Great engineers, sales people, product people, etc. exist all over the world. However, the highest concentration of outstanding ones are concentrated in industry towns (just as the highest concentration of great actors in the USA live in Los Angeles). Similarly, the people who know how to scale technology companies are concentrated in the tech epicenters in the graphs above. Many companies come to the SF Bay Area to fundraise post product-market fit to access this talent base and know-how.
Outside of those critical turning points, and for businesses that are operating on a different growth model, then this matters less.
It will be interesting to see how GitLab progress towards their Nov 2020 IPO date but despite being an amazing example of how to run a remote, distributed company, it is interesting that the CEO is based in San Francisco.
Tips and tricks for remote, distributed teams #
At Server Density, we developed a number of mechanisms to help run the remote, distributed team. These evolved over time from 2009 to the acquisition of the company in 2018.
Weekly roundup #
This started as a weekly standup for the whole company to report on what they had been doing that week but it eventually changed primarily to be a social discussion.
Meetings are a necessary part of working with multiple people but using them to distribute status updates is very inefficient and expensive. Status updates can be provided in writing, asynchronously. Meetings are for discussion and debate. But when you have a team all working remotely, regularly getting together to “see” each other also has a social benefit.
It was also the only compulsory meeting during the week. Unless you were on holiday, you had to be in this call.
At one point, we stopped the meetings for a few months and experimented with just using written updates. We quickly had requests to bring back the meetings so we could talk to each other!
The format we ended with was as follows:
- CEO Update (~5 minutes): Any announcements or important news as well as a quick update on the key business metrics, with a more detailed writeup shared later. I also highlighted one or two things I’d seen during the week that particularly stood out – deals closed, great responses to support issues, tricky bugs fixed, etc. The important thing was to mention one or two people and some specific piece of work I thought deserved everyone knowing about.
- Team updates (~1 minute each): Every person would say something they found interesting during the week. Updates could include work as well as something they had read or watched. We used a random order generator to mix up the order of speakers every week. After each person had finished speaking, there was an opportunity to ask questions. This often prompted some good discussions.
- Anything else: An opportunity for anyone to mention something not already discussed.
With 20 people we were usually able to complete this meeting within 30 minutes. It breaks some of the rules for meetings e.g. no status updates but we were deliberate in what the format was about – hearing from your colleagues about what they had been doing.
This worked nicely for us but I’m not sure how far this would scale. Even being strict about times, people tend to go over their 1 minute. The format we used above worked for us at 20 people but is quite different from what we used at 5 and 10 people. GitLab have blogged about how they changed their weekly 40-person meeting into a 10-15 minute podcast.
Random calls with team members #
Working with people in an office usually means some socialising outside of work hours where you get to know your colleagues personally. This is more difficult for remote, distributed work because “out of hours” should mean disconnecting completely!
Every week, everyone was paired up for a 30 min call with someone random from the company. There was no particular agenda so they could discuss what they liked. Even on a small team, this helped connect team members who might rarely (or never) talk to each other.
This scales well even with large companies because as the team grows, you become more siloed in who you interact with on a daily basis.
What have you been working on? #
Knowing what your colleagues are doing is one of the challenges of communication made more difficult by remote, distributed working. One fix we tried was a regular prompt for people to answer the question: “what have you been working on [today | this week | recently]?”
We used Basecamp to automatically ask this every day (and also tried it more infrequently e.g. a couple of times per week). It was never compulsory and different people wrote at different frequencies to suit them, and when they had done something worth broadcasting to the whole company. There are Slack bots available to do this too.
The important thing was that it was voluntary and non-specific. Anyone could write whatever they liked. Tracking of bugs, epics, tasks, stories and other precise units of work is for other tools.
This worked for a time but usage declined over time to the point where not enough people were using it to make it worth continuing. It was replaced by the weekly roundup (see above).
However, one thing we did find was that there was a weird political element to “likes” of posts. Feedback I received indicated that there was an almost addictive aspect of checking posts for likes, seeing who had liked them and whether your own post had more likes than others.
Not having to think about likes having ditched Facebook and Instagram is a nice side benefit I’ve noticed. It definitely influences your behaviour in negative ways. Basecamp discovered this themselves, replacing the feature with Boosts. A good move.
Final thoughts #
There is no “one true way” of running a company that will automatically deliver total productivity in every situation. Whether you run entirely in an office, entirely remotely or a mixture of both, every organisation needs properly thought through processes.
Those processes will differ as the company grows. Smaller organisations need minimal overhead to remain agile and able to iterate quickly. Larger firms need to be able to coordinate multiple teams working on various projects. But no process at all is just as much a decision about working practices (probably in an environment of chaos) as writing a detailed handbook would be.
The challenge of remote working is that it needs a much more deliberate approach to running things. There are fewer organisations using remote, distributed working methods. Not as much shared knowledge exists. But that is changing.
Companies that do not allow remote and/or do not properly consider how to effectively incorporate remote working into the long-term are going to fall behind and fail to attract the talented people that are crucial to success. The form that takes will be different in every case so it is important to avoid “remote purism”. It is clear when things aren’t working but there are many ways to make it work well.