The Remote Engineer

A “remote” engineer is anyone geographically separated from the majority of his or her primary team. In this post, we’re referring to a remote engineer as any engineer that works in an office outside of Twitter’s San Francisco headquarters. Based on interviews conducted with remote engineers and their managers, we’ve identified six main challenges faced by such teams.

Scheduling. In addition to time zone differences, there is an unofficial culture of “no meeting Thursdays” at the office (common among tech companies), leaving a very small window between 1pm ET to 6pm ET, four days a week, for team meetings.

Information gaps. When teams are distributed across offices, not all teammates can participate in casual or “water cooler” conversations. Remote engineers may not be able to participate in key decisions and might miss other important information.

Latency and increased effort for interactions. When an employee is remote, just getting someone’s attention can be harder. Within the engineering community, getting code reviews completed can be especially challenging for engineers who sit away from the rest of their team.

Loneliness or lack of community. Since he/she isn’t required to interact regularly with other engineers as part of the daily job, it can actually be quite difficult to build meaningful relationships at the workplace. Without a healthy social network and personal ties, it may be more difficult to keep and retain engineers in the distributed office.

Work is potentially less visible. Perhaps one of the less obvious hazards of working remotely is career growth. Without regular face time with key decision makers, the contributions of remote employees may be less visible to leaders and colleagues.

Why do we allow remote engineering if there are so many related issues? There are three key reasons why we allow and, in some cases, actively support remote individuals.

The engineer is embedded in or supports another team. Teams such as SRE (site reliability engineering) and QA (quality assurance) are structured such that engineers are deployed to support other teams and work much more closely with the engineering teams in which they are embedded. In these cases, it would be important for the engineer to be co-located with his or her assigned product or project team, possibly more so than the functional team.

A related but alternate scenario is one in which the team provides a global support service to the rest of the organization. In this case, it would be necessary to deploy engineers across multiple time zones in order to ensure 24-hour availability of service for teams around the world.

The engineer is too good to refuse. Let’s face it — sometimes, an engineer is so skilled (or his knowledge is so niche/valuable) that we would rather take a risk in order to keep him on the team.

There are plans to expand the team at the distributed office. If there is a clear strategy to grow the function at the distributed location, then it may make sense to start out (or “seed”) with a lone senior engineer who can be trusted to source and hire a strong team around her.

About one-third of Twitter’s NYC engineers belong to various teams based in SF. When possible, we prefer to have teams concentrated within the same office; however, at times the benefits do outweigh the costs to alternative arrangements. In these situations, managers at Twitter have a few best practices they employ that help to address some of the primary challenges we mentioned above:

Simulate in-person conversation. Nearly every team is in constant communication over chat or video call but some teams get even more creative. Most recently, we had a lone engineer in NYC who programmed a robot to sit in SF by his team, so that he can send it to physically “poke” his fellow teammates when he has a question or issue that needs an immediate answer. Another inventive solution for one of our infrastructure teams is to have a mandated video conference “happy hour,” where all the team members book conference rooms in their respective offices, and everyone gets together for a beer and non-work related chatter. The more you can simulate physical, personal interaction, the better.

Frequent and formalized team updates. Most engineering teams have some form of a daily stand-up, where each person on the team provides a brief update on their accomplishments from the previous day and plans for the current day and helps unify the larger team.

Regular visits. Nearly every distributed team requires its lone engineers to travel to HQ approximately once every 4–6 weeks to further develop relationships with senior team members, internal clients and team members.

Clear advancement plan. There should be a very clear strategy to ensure your engineer gains exposure to other senior engineers and teams at HQ, and that she takes on projects and responsibilities that will lead to advancement. This could mean giving a remote engineer a tech lead or mentorship role for a project, even though the rest of his team is based out of another office.

Engineers at Twitter’s NYC-based office are spread across over a dozen separate teams of varying sizes, and there is a clear need to have a leader for the office. In Twitter’s case, we have not only a site lead for the entire office, but we have one for the engineering organization, as well (Vijay Pandurangan). Ultimately, their purpose is to be the point of contact (POC) and decision maker for high-level operational and cultural issues, and their mission is to ensure the healthy growth and development of the local office.

Based on experience from our NYC engineering site lead, as well as my own as the NYC-based engineering operations manager, we’ve collected and categorized some suggested practices for effectively building and scaling a distributed engineering office. Here they are:

Appoint a site lead and build relationships with support functions at HQ. This is particularly important when hiring or transferring engineers to your remote location. To ensure that you (or your assigned POC) is appropriately informed, it is important to build (and then maintain) relationships with all of the operational teams, especially if they are mostly or entirely based out of another office, such as HQ. Since distributed offices often start out quite small relative to headquarters, you may find that the mindshare of your office at HQ is equally small. Make it easy for these functional teams to reach you, ensure that you follow up with each of them at some level of frequency, and advocate for your office when you need more support.

Identify a clear growth trajectory for the office. If you currently have multiple, lone-person teams sitting in your office, it might make sense to either start consolidating (i.e. recruiting) these engineers into larger, local teams, or else working with their managers to develop clear growth plans for the team at the local office. There are a couple of ways that the different distributed offices at Twitter have expanded.

• Functional expansion. This tends to be the case for offices that came to be as a result of an acquisition. For instance, our Boulder office was established through acquisition of a data team, so it has remained a hub for this specialty.
• Skillset expansion. For some offices, it may make more sense to build out one or more “pods” of engineering teams that can work on projects independently (i.e. not require any engineers from other offices). For instance, a pod might consist of an iOS engineer, Android engineer, web engineer, SRE, a couple of backend engineers, a product manager, and a UX/UI designer. Note that this setup would require localization of projects to your office, which means that you, as a leader for your office, would likely be in charge of building out a pipeline of projects for these teams.

Build local engineering culture and foster inter-team communication. In the NY office, we’re focusing on building an engineering-wide culture in the midst of an office that is largely driven by sales, marketing, and business development. It is by no means a stretch to say that all of the engineers can get to know each other at this size, and culture building can happen at the engineering-wide level, as opposed to within specific verticals. Nothing surprising happens on this front — we have #NYEngineering swag, engineer-specific group activities or off-sites, monthly leadership meetings to include reps from each team, and a local engineering all-hand to highlight each team’s work and contribution to Twitter as a whole).

Develop relationships with each of the teams. It is obviously very critical to personally know each team in your office, though this may not be as easy as it sounds. Depending on the processes instituted at your company, it may be quite easy for a remote engineer to suddenly show up one day at your office without any prior warning. Ensure that you are aware of all the engineers in your office, and reach out to any new names or faces that you come across.

Encourage people to be open with you about their concerns regarding the health and/or growth of the engineering team. We have found that quarterly 1:1s with at least one representative from each team is essential to maintaining the lines of communication. This is especially important for smaller teams, since their voices are most likely to get drowned out by the larger, weightier teams in your local office.

Ensure the flawless execution of video conference (VC) capabilities. I know this sounds trivial, but ensuring that there is an easy, seamless video conference systems saves time and frustration so that teams can quickly and easily sync. Vijay wrote extensively about this on the Twitter blog.

Market the hell out of your office to the rest of the company. In a company as large as Twitter, it’s not immediately obvious to anyone which teams are based out of, or have a presence in, each of the distributed offices. Some of the tactics we’ve used to internally market our office are the following:

• Intranet page for NY Engineering: (1) org chart of the engineers in NY (including the hiring managers or POCs and a brief description of each team), (2) logistical information for visiting the NY office, (3) ways to embed into the NY office (HipChat room, Google calendar link, contact for operations manager), (4) events calendar
• Ensuring this page is linked from all the relevant intranet pages company wide, so that it is easy to find for anyone looking for information at HQ
• Marketing your team’s intranet page via TV screens at HQ, which are used to rotate through general announcements for engineers
• Last, but certainly not least, as the leader for your site, it is absolutely critical that you regularly (and frequently) visit headquarters in order to network with different HQ-based teams, spread knowledge about your local teams, identify opportunities to collaborate with HQ-based teams, and/or simply hear about high-profile opportunities that your local teams could take on. This will be more critical as your company scales, as communication of information can become less efficient or transparent at the company-wide level and the importance of informal networks increases.