Remote Work At GitHub, Inc.
San Francisco, CA
* As of February 2020
GitHub, Inc. Remote Company Q&A
Coby Chapple, Product Designer - Interview with Remote.co
GitHub is a suite of tools and workflows that is rapidly changing the way people build software—both in the open source community and within businesses of all sizes. GitHub enables people to collaborate in ways that haven’t traditionally been possible. It’s the place where your software projects live, and also the vital workflows surrounding each project, such as code review, issue tracking, and documentation.
I’m not sure I’d say remote work is connected with our business model, since it’s possible that GitHub could’ve been built by a non-distributed team. Facilitating asynchronous communication within distributed teams is critical to our product’s success though, so it would’ve been much, much harder to build something that does this job to the same high standard if we didn’t have first-hand experience on a daily basis with the problems involved in remote work.
At GitHub, we’ve seen a number of benefits to being a distributed company:
- Hiring. If you want the best talent, limiting yourself to the talent that’s available in a single city (let alone a single country) is shooting yourself in the foot.
- Diversity. Monocultures are dangerous, and hiring people from different locations naturally helps you avoid them by giving you a huge injection of diversity. When your teams have a wide range of cultural perspectives to draw from when approaching problems, your company will do a much better job of navigating challenges.
- Satisfaction. Being able to choose your own working environment means people can surround themselves with things that make them happy, trade the commute for more time with family and loved ones, and generally have more control over their work/life balance. If you’re building a business to be sustainable in the long-run, then you have to make sure people’s day-to-day is rewarding and enjoyable.
- Productivity. Having to get into the office extra-early or stay late just to get a solid block of time to work without interruptions is silly. When you work remotely, you control when you allow distractions and communication with coworkers into your day, which leaves more time for getting into the zone. Your ability to focus also improves significantly when you aren’t exhausted from energy-sapping twice-daily commutes.
- Community. At GitHub, engaging with and supporting our community has always been a high priority. There is no better way to give our company a face than for our employees to be involved in the local meetups and events that are already happening all around the world, and that’s easy when people are already highly distributed.
In the early days of the company, there was no physical office. The founders and very first employees in San Francisco all communicated using web-based chat services instead from wherever they were working, whether that was from home or a coffee shop. Many of our early hires were people who lived outside of San Francisco too, and this continued as the company grew. Remote work being the default has always made a lot of sense for GitHub, because it meant we could ensure our product worked for teams regardless of where people were located.
My personal opinion is that the things you should look for when hiring for a remote position are essentially the same things you should be filtering for with any position, remote or not. That said, there are definitely a few things that stand out to me as being key for anyone to be effective as a remote employee:
- Written communication. The importance of this cannot be overstated. When you’re remote, a majority of the way you interface with the world will be through written word, so it’s critical that you can articulate complex concepts and subtleties. Giant walls of text aren’t fun either, so it’s important to keep things concise.
- Discipline. Some people work best with lots of structure and external pressure, but working well autonomously is a big part of our culture at GitHub. We need people to be self-motivated enough to stay productive without someone looking over their shoulder and checking up on them all the time.
- Decisiveness. Timezones are tricky, and it’s often necessary for remote employees to make decisions with imperfect information, even if the right person isn’t around in the moment to make the decision themselves. Most decisions are temporary, especially in a growing company with a rapidly evolving product, so what’s important is that a reasonably sound decision gets made so that work can move forward.
- Interests outside work. If someone is going to be working from home, then it’s really important that they have hobbies, friendships, and things to do outside of work. Without something else to help them switch off and decompress, it’s much easier to end up burning out.
It depends heavily on the nature of the discipline we’re hiring for, but after collecting applications for the positions we post, we usually start screening with things like written questions or exercises to get a feel for a candidate’s communication skills and the depth of their abilities in the area we’re looking to hire for. We’ll then progress to having promising candidates speak with some of the people who they’d be working with via video calls, and then eventually for people we’re confident are good matches for the position we’ll bring them into HQ for a day of in-person interviewing. This process is the same whether it’s a remote position or an on-site role.
It’s important that our interviewing process isn’t just a one-way street too. Our aim is to do what we can to give candidates the chance to see what it’s like to be at GitHub. It’s as much about helping them understand how we do things as it is about making sure we feel they’re a good fit. We only want to hire people who genuinely want to work at GitHub.
We do what we can to be explicit in all our public job postings about which opportunities at GitHub are remote and which aren’t, but perhaps the most important way we communicate our remote culture is through our existing employees. We encourage all GitHubbers to engage with the community in whatever ways they can, whether that’s attending local meetups, speaking at conferences, or writing blog posts and articles to publicly share the way we work.
We believe that if we can all collectively do a good job of conveying our values within the communities our people are already involved in, then it will mean that when it comes to the recruiting process there’s a much better chance that candidates will already have a good insight into our values by the time they’ve submitted their resume.
Not to my knowledge, although we’re continually looking for ways to improve our hiring process to remove bias, promote diversity, and generally make it a better experience for everyone involved. It can be hard to ensure the whole process is smooth when you have third-parties involved, but when you find companies to work with that share your vision for what the hiring experience should be like, it’s definitely worthwhile.
It depends on the team. I don’t know of any teams in our company that mandate response times for internal communication, but plenty of teams have set up regular schedules for video calls, stand-ups, and patterns of communication to help make sure the whole team stays on the same page over time.
There are some areas like Support and Operations where we deliberately hire so that we can have round-the-clock coverage, but we believe strongly that it should be up to the individuals on each of those teams to coordinate the most reasonable schedule for everyone involved. There’s nothing worse than a decision being handed down from somewhere else in the company that fails to account for the needs of the individuals affected. You have to be flexible, and I think that’s the key. Do what makes sense for the team and the people on the team.
We get the whole company together for a summit each year, and various teams within the company meet in person at different times throughout the year too. Combined with a steady flow of people visiting the offices for various reasons, there ends up being plenty of opportunity to hang out with our colleagues in person.
We’ve found this to be vital especially as we’ve grown. You can get a long way with just online communication, but if you can build quality relationships in real-life between the people at your company, then that makes a huge difference when they disperse and go back to being distributed. It means that even when you’re remote, you no longer just see someone as an avatar—you’ve build up some background context and empathy for that person and that means you’ll be much better at working together and helping each other out. If you can effectively do that on a company-wide scale, then working remotely becomes far less isolating.
For us, remote doesn’t just mean location independent. We want to give people as much autonomy as possible about when and how they work too. The hours people work or the tools they use aren’t that important—what matters is results. Is this person doing important work? Is this person working effectively with their team? Is this person actively supporting GitHub’s long-term goals? These are the things by which we measure how someone is doing.
At GitHub it’s important to us that we look after our employees. We’re not just in this for short-term productivity, we’re in this for the long-haul, and that means that you need to view the health of your people and teams a bit more holistically.
What we’ve found is that it’s actually quite hard to ensure people are making full use of what’s offered to them. It’s easy to view policies as just sets of rules about what you can or can’t do, but in a distributed company you rely on written documentation much more than in non-remote companies, so one of the challenges we’re facing as we grow is how we can make sure our management practices and internal documentation are focused on encouraging healthy behaviour. That’s the only way you’re going to get sustainable productivity and growth in the long-run.
We don’t have a formal BYOD/A program like some companies do, however it’s important that people can do their jobs effectively, and that means supplying people with the tools they need whether that’s hardware, software, or things like an ergonomic chair or standing desk.
In terms of technology and devices, one of the biggest risks with mixing personal and professional use of a single device or app is security. We’re very security conscious at GitHub, so there’s a few security-related settings we require for devices that have access to internal information. As long as those safeguards are in place though, and the personal use of your equipment doesn’t put our company information at risk, we encourage people to use their equipment in whichever way makes them most productive.
At the end of the day it’s about trusting people to be responsible adults. If you aren’t able to trust the people you hire after communicating the goals of the company and the concerns from a legal and security standpoint, then you might have bigger problems than people using work equipment for personal tasks.
We have an unlimited paid time off policy. As long as people coordinate any leave they take with their teams to make sure the schedule makes sense and doesn’t leave anyone hanging, then we want people to be able to take the time off they need so that they can be as switched on as possible when they are working.
The biggest problem with “unlimited” though is that it often means people don’t end up taking enough time off, which is counter-intuitive. There’s been some really interesting discussions on this topic in the technology industry lately, and we’ve definitely been discussing internally how we can make our policies more effective too.
I’d definitely say it came about organically as a result of both the way the company grew and the nature of our product. We’ve always tried to be clear and explicit about our policies around remote work though, because it’s really important to us that everyone’s expectations are on the same page.
Absolutely, although it takes a lot of hard work and conscious effort. You simply have to be honest about the challenges of working remotely, actively look for ways to mitigate their impact, and consciously set good precedents so that everyone in the company (including people who start next month) know that it’s acceptable to call things out and question them.
Company culture evolves over time, and the way remote work fits into that needs to evolve too, so you need to view it as a continual investment and a constant work-in-progress. I’m not sure that you could ever claim that your company culture or your remote working practices are “done”.
The most critical thing to understand when it comes to remote working is it only works if you can commit. You can’t just nominate a single person or team to be a “remote guinea pig” for a month and expect it to be a raging success. If the rest of the teams and departments don’t change their communication habits too, then your experiment is destined to fail.
If anything, non-remote people have to be even more vigilant about their communication, because it’s easy and tempting to lapse into meatspace-only discussions and decisions that never get shared back with remote colleagues. You shouldn’t try and stop people having in-person discussions by any means, because there will always be undeniable value in that, but it’s critical to be mindful about how your conversations might affect people who aren’t in the room. Working well as a distributed company can’t just be the responsibility of the people who are remote.
Remote isn’t for everyone though, so you need to decide what’s important to you, and what choice fits best with your long-term vision for the company. Ask yourself this though—If your biggest competitor was completely distributed and you weren’t, would that give them an unfair advantage?
One thing we’ve seen is that you have to invest a lot of time and energy into hiring well. Growth is hard, but it’s much easier to navigate change if you know you can trust the people you’re hiring. Without that trust as a foundation, everything else related to building a good company (let alone a distributed one) becomes infinitely more difficult.
This depends on the team, since each team within GitHub decides how they want to organise and coordinate their communication. Most of our communication is focused around GitHub the product though, with other communication mediums supporting the written discussion threads on GitHub. Most teams have semi-regular video chats, and almost all teams will have their own dedicated chat room for short-form synchronous discussions too (as well as email of course).
What we’ve found is that everyone in the company needs a mix of communication tools for different situations and purposes. You need things that cover a few different spectrums: informal vs. formal, synchronous vs. asynchronous, short-form vs. long-form, and so forth. If your tools don’t match the types of communication you need within your team, then that makes working remotely considerably more difficult to do effectively.
The most noticeable change for me has been the size of the company and the effect that has on team (and inter-team) dynamics. When I joined GitHub in 2012 we had just over about 80 employees, and it’s been really interesting seeing that number almost quadruple in three years.
Since our teams are largely autonomous, the company’s growth has forced us to really level up the standards for how teams communicate—both internally, and also externally within the company at large. The tools and habits that work effectively at 80 people are radically different to what works at 300 people—your communication has to be far more regular, have more clarity, and requires much more forethought—and this is especially important when it comes to communicating organisational change. You have no choice but to evolve the tools you use and your habits around them in order to scale well.
I work from a fairly basic home-office. I have an adjustable-height desk for my laptop, an external monitor, and the ever-present mug of coffee. One of the things I like most about this room is the wide windowsill that catches the sun in the morning, and Annie (my dog) jumps up and basks next to me while I work.
When you work in a normal job, your daily commute enforces routine on your day and makes the mental jump between your personal environment and your professional environment really clear. When you work from home though, you have to find other substitutes for that process, so some of the things that I’ve found help the most are keeping a regular schedule, and using environmental cues to trigger the mental transition between personal time and work time.
I’ve had some really productive times working in coffee shops and mid-flight on planes, but also other times those same environments have been terrible. Most of the time what makes the difference to me is my frame of mind, so I find that to get a predictable level of productivity, nothing beats my home-office. It’s a known quantity, and I have almost complete control over distractions, so even in a poor state of mind I can still achieve a suitable level of focus.