From one to two: how to start a successful distributed engineering office.
Recently it feels like companies are moving beyond the single office model earlier and earlier in the lifetime. Maybe it’s improvements in video conferencing, perhaps it’s the increasing costs of operating in Silicon Valley, perhaps it’s just a fad, but in any case, effectively supporting additional company offices is an important and increasingly core skill for engineering leaders.
I’ve had the good fortune to work with several distributed offices, founding SocialCode’s San Francisco office after the Digg acquihire, working with Vaidas to expand Uber’s Lithuania engineering office, and supporting Stripe’s Seattle office site lead, Brian. The motivations for each of these offices varied considerably, but the foundation of success did not.
The foundations of a successful distributed engineering office are mission, investment, predictability and integration.
Distributed, not remote
Before diving into making distributed offices successful, a few words on “remote” offices. Remote offices are far away. Remote offices are not central. Remote offices are secondary. Selling folks to join a nascent office depends on them believing it will become an important, central part of your company’s success.
Each time you use the word “remote” to describe your new office, folks who are considering joining (or who have already joined) experience a moment of mental dissonance – how can this be a critical part of the company if leaders keep calling it remote?
The solution is easy: don’t call offices remote. I try to reserve the term remote for folks who aren’t working in any company office. It’s most powerful to just refer to offices as offices, dropping the qualifiers, and commit to not referring to your first office as headquarters.
When I joined Uber, the production on-call was so noisy that the on-call primary’s phone would at times run out of battery charge before their shift ended. The long-term solution was the shifting from recovery to prevention combined with managing spurious and redundant alerts, but in the short-term we decided to grow a full engineering office in Lithuania to staff a follow-the-sun rotation. (Why Lithuania? We already had two fantastic engineers on the team working from Lithuania.)
The team we hired in Lithuania did a phenomenal job of supporting the on-call rotation, and as they grew they started tackling more and more of the underlying causes driving the on-call cacophony. As they tackled those issues, they kept running smack into whatever existing team felt they were the owner of the alert-generating system that the Lithuanian team wanted to improve. Change how puppet is deployed? Another team owns that. Change how service routing is updated? Another team owns that, too.
After observing this problem a few times, it became clear that we hadn’t defined a sufficiently clear and important mission for the office. Acknowledging pages is valuable, but it isn’t a purpose. It’s not a mission.
After debugging the conflict, we worked to identify a large, critical area of responsibility that the office would take full ownership over. We made sure they could move forward in this area without approval from folks in other timezones, and finally we ensured the mission was important – it had to be something that would cripple the company if it wasn’t going well. Something important enough that we couldn’t ignore it if it wasn’t going well. Defining an important mission didn’t fix things immediately, but it created a clear mission for the team, a feedback loop on whether we were sufficiently empowering them to own that mission, and built-in focus from leadership.
Ensuring each office has an important mission is the single most important thing to do to make an office successful. If you can’t identify a clear, ownable mission, then you shouldn’t open a new office. If an office’s mission isn’t important enough for a senior executive to be the mission’s sponsor, then it isn’t important enough to serve as the office’s first mission. As an office grows it should accumulate multiple missions, and some of those will not be as pulsingly urgent as the first mission – that’s good and well – but the first needs to be critical.
Transitioning a critical mission to an office that isn’t well staffed is a tricky procedure, and I’ve found it works best to split ownership with an existing team and the new office for a short period of time, roughly the first six months. That said, I’d encourage you to err towards moving the mission early, even if the team isn’t quite at size yet, rather than waiting to be as fully staffed and slowing the new office’s culture of ownership.
You’ll know the new office has a clear purpose if every member of the company can mention something that office has launched in the past year, and they know at least one thing that they’d go to that office for first.
When the acquihired Digg team bootstrapped a new San Francisco office, I was initially the only senior leader operating within the office, and felt extremely responsible for the office’s success, but we hadn’t yet developed the notion of a Site Lead, which meant that I often felt out of position to advocate for the office in certain company processes.
I’ve come to believe that defining the role of a Site Lead _early _and with explicit responsibilities is the second most essential investment companies need to make into their new offices success. The first? Having a Site Lead to begin with. The other areas that are particularly important are sufficient initial headcount to create a real sense of community – let’s say at least twelve folks or so – and executive attention.
For those twelve folks, commit to having them be on one or at most two teams. Some folks commit significant headcount to a new office – let’s add fifty folks next year! – but then scatter them so thinly across teams that it ends up either preventing those teams from gelling or keeps ownership of their mission bridged across multiple offices since the teams aren’t at sufficient size to own a critical mission.
The simplest rule of thumb for executive attention is that executives need to visit quarterly for the first year or two as part of forging a successful new office. Your physical presence is the clearest emphasis of your priorities, and folks in new offices will literally track how frequently you visit.
You’ll know your investment is on track if you visit other offices and they still feel like home, and you’re mentioning their work at a healthy clip in company-wide events like All Hands meetings.
Recently I had dinner with a friend who described working at a company that opened a new office, hired a few folks into it, abruptly canceled the new office to instead open a different new office, decided to 10x the second new office over the next year, succeeded in 10x’ing it, planned to 10x it again, and then instead immediately moved into a headcount freeze. Folks hired into the office remained surprisingly enthusiastic but their implementation and hiring pitches grew hesitant – would the new office succeed and be important in the long run?
Uncertainty is always disruptive, but it’s particularly damaging for new offices which lack the history of successfully overcoming uncertainty that a broader company accumulates over time. Without history, there’s no resiliency. This makes it very important to maintain predictable, consistent investment in new offices for their first three-plus years.
I’ll give you one escape card here though, which is that you’re allowed a one-year hiring spurt in your new office where you defy all best-practices around team growth. If you want to grow to 50 engineers in your first year? Fine. If you grow to ten engineers in your first year and want to grow to 100 in your second year? Ok, sure, go for it. Just remember you only have one exception card, and after that you should return to a sustainable hiring rate of approximately 50% year-over-year growth.
You’ll know you’re staying predictable by measuring your performance against plan for office growth and ownership.
When Stripe engineering went global, we really went global, making major, simultaneous investments into our engineering offices in both Europe and Asia-Pacific (and more recently Latin America as well). With a few iterations on the details the offices are going quite well, but early on the timezone spread made integrating the offices more challenging than anticipated.
Each company has a series of communication and community touchstones that are its culture heartbeat, and there are both physical and cultural challenges to inviting more offices to participate in them. Physical challenges – if you have enough geographical office spread, then there is no time of day that will be effective for all offices; asking questions remotely feels different than asking them in the same room; video conferencing equipment keeps improving but retains a resolved commitment to inopportune failures. Cultural challenges – new offices don’t start with years-long relationships with the founders; new offices will be operating in regions that may have a different cultural or language context than the first office and/or the founders; new offices often surprise long-tenured folks by becoming a mirror into how the company’s culture has shifted.
There is a standard playbook for ensuring new offices integrate that works surprisingly well:
- Send a landing team. Identify a group of three to five tenured folks from an established office who can move to the new office for the first year, two years or permanently and become the new office’s initial communication and cultural nucleus.
- Ensure senior leaders travel to offices. This is more than a drop-in, but each visit should have a office-wide touch point, maybe a Q&A.
- Spread opportunity to every office. Create checks to watch for creation of implicit two tier systems, such as all Staff+ engineers operating in the first office, or using a structured DRI selection process.
- Rotate timezones for company-scale meetings. Company meetings are important rituals, and they happen infrequently enough that they are a powerful signal of your executive team’s priorities.
Fully implementing these practices will disrupt the standard operating procedure in your first office, and, yeah, that’s kind of the point. If you want your new offices to succeed similarly to our existing offices, the burden of accommodation must be spread across all offices rather than concentrated on the most recent ones. If opening a new office doesn’t create friction in your existing offices, either you’ve truly mastered the process, or you’re probably pushing too much burden on the new office.
You’ll know you’re integrating your offices well by segmenting the results of your periodic culture surveys by location and ensuring there is little if any delta across offices. For a shorter test, ask a few folks in an established office how they’ve adapted to incorporate the newest office, and if they can’t think of anything, spend some time reflecting on that.
As an aside, there is another aspect of integration, which is integrating into the city and community that you’re building the office in. Having a Site Lead who has long-standing community ties is exceptionally valuable for this, as can doing small scale community dinners or events. There’s less of a playbook here that I’ve seen, but it’s worthwhile to think about.
Considering all the ingredient for a successful new office, you might think to yourself that opening a new office isn’t worth all of this work, and if that’s your conclusion, then you probably shouldn’t open one! A poorly supported new office is an ignoble thing to be avoided. If you are ready to make the investment, then don’t worry about the little stuff – things like not referring to it as a remote office and ensuring you keep updated compensation bands for every region you’re hiring in – if you keep focused on mission, investment, predictability and integration, then you’ll figure out those as you go.
If you had to narrow all of this down to a single success pattern, I’d suggest: ensure there is one senior executive who is accountable for the gap in employee satisfaction across offices, and that they speak about progress on that measure to the entire company at least annually.
If you’re looking for more material beyond my thoughts here, some resources that I’ve found helpful are:
- A guide to distributed teams by Juan Pablo Buriticá and Katie Womersley
- Starting your second office with Brian Delahunty on Woven’s podcast. Brian was the first site lead for Stripe’s Seattle engineering office
- How To Build and Run a Geographically Distributed Engineering Team by Kim-Mai Cutler
- Six Virtues for Distributed Offices by Ron Pragides
- How to Build and Strengthen Distributed Engineering Teams by Cole Stryker, summarizing a discussion between Cate Huston and Matt Mullenweg
- The Fundamentals of Building and Managing a Distributed Engineering Team by Maria Gutierrez
- Building a Distributed Engineering Team by Bruno Miranda
That’s just the tip of the iceberg, feel free to send my way.