Inovia Sessions: Building Distributed and Remote Teams from Seed to IPO

The global pandemic has forced practically every company to operate as a globally distributed remote team. In the tech industry, this trend has long been rooted in both startups and big tech companies’ efforts to attract and retain the world’s best engineering talent. What lasting change can we expect in startups’ ability to operate distributed engineering teams? What will the next generation of distributed and remote companies look like? What should founders consider when starting and scaling remote teams? Inovia’s Antoine Nivard sat down with Atlassian’s Anutthara Bharadwaj, Shopify’s Farhan Thawar, and Databricks’ Reynold Xin for a conversation about their experiences building and operating distributed teams.

Antoine Nivard: Broadly speaking and pandemic aside, what is your take on whether remote-first is right for your team, and how do you think founders of all stages should approach deciding whether or not to build a remote or digitally distributed engineering team?

Farhan Thawar: It’s up to the company to decide that, and of course in today’s pandemic world, we’re all forced to work remotely, but that doesn’t mean that every company will then adopt remote-first or remote always.

What I would first figure out with the founding team is to sit down and say, well, what do we want to be? Where do we want to play? Where do we think we can have an advantage? That might still mean moving everyone to the Bay Area, opening up the company there, and not being remote. It might mean starting by building remote-first and evaluating how that works in terms of scaling, tooling, and working together as a team.

I think that what some people try to do is copy what some other company has done. There are great materials out there from companies like Basecamp, Gitlab, etc, and their playbooks on building remote, but that doesn’t mean it’s going to be right for your company. There are pros and cons to the approach. There isn’t a one-size answer, but once you do choose an answer, you should be very deliberate about what that means. When people tell me now, every company is going to be remote, I don’t believe that.

Reynold Xin: It’s actually fairly similar, we haven’t pulled the trigger to go all the way remote yet, even though everybody’s working from home. As a matter of fact, before the pandemic, we were already hiring a lot more senior engineers and were willing to hire them in any location, anywhere in the world.

The way we approach it is to look at the teams that are the hardest to hire. Some of them are the ones working on infrastructure, some of them have very specific knowledge about tooling. That’s just harder to find anywhere. We started hiring a lot of those distributed, but we haven’t pulled the trigger on fully-remote; we might do that in the future.

Right now the biggest challenge, as we’re hiring a lot of people, is for junior hires and interns; it’s actually a much tougher time ramping up because of the lack of organic interactions with existing senior team members. For the more senior people, they’re typically already coming in with a lot of domain expertise and management experience to proactively reach out and talk to people.

Antoine: If you’re building a second engineering HQ, what do you think founders should consider in selecting that geography?

Reynold: For a company founded in Silicon Valley, it is a no brainer in my mind to start looking at more than just one engineering office early on. At Databricks, the most important consideration we had was to find a strong enough local leader in that geolocation. That needs to be somebody we trust somebody who has a great cultural fit and who ideally has experience of scaling offices in the past.

All of this is relative, but for us, we’re thinking about, can we scale that office to maybe a couple of hundred people in a year or two? So you want to find the right leader that can do that. That is the first-order effect because, with the right people on the ground, you can actually make a lot of magic happen.

Then there’s a lot of second-order considerations which are: What is the actual talent market? You want reputable universities around you. It would be very difficult to grow talent without that.

Then there’s an important consideration in choosing time zones. There are actually two different perspectives in looking at this. In general, you want the time zones to be closer because the closer they are, the higher the communication bandwidth, the higher overlap you will have with your HQ. But there is another view, especially for companies operating like software services or software systems like SaaS, which is, around the clock coverage to avoid waking your engineers up all the time in San Francisco. That’s not a great way of building your team. There’s a real tension between those two views because the closer you are in time zone, the less global coverage you have. You have to look at what would actually fit your product and serve your customers best.

Then there is obviously immigration. If your company wants to build a second office, I’d probably recommend outside the United States right now. So to us, the most important thing is to find the right leader, even in the best market; if we can’t find the right leader, it’s going to end up in disaster for sure. Then there’s a bunch of other important but more secondary considerations.

Anu: Throughout Atlassian’s growth, we ran into a few issues not finding the cultural match we were looking for. Atlassian is an Australian company and we have quite a unique culture, it’s also quite different from Silicon Valley. While sharing the same values of irreverence, self-exploration, curiosity, all of that. That being said, we don’t always follow a lot of the templated rules that are commonly found in Silicon Valley.

Very much like Shopify, we’re seen mostly as an outsider company. In some cases, it was hard to find the right site lead, and in other cases, we didn’t really think about English speaking requirements. Language turns out to be a barrier when you’re trying to open a Dev centre and you have a bunch of folks that you’re trying to train up on a tech stack, while also trying to teach them their second language. That’s jus
t a lot of change rolled up together into a single project.

Antoine: What’s important for you to consider when picking a site lead, especially if you put yourself in the shoes of early-stage founders doing it for the first time?

Reynold: Typically, at Databricks, when we start hiring for senior roles, we write down a scorecard, and we take the most important points we have to match, and then identify and assign different interviewers to screen them. Some of them are easier to assess, some more difficult and others are closer to evaluating cultural matches.

The site lead needs to be able to have high bandwidth and high trust communication with a lot of the senior people in HQ, all the way up to the CEO. Being able to build trust is key.

Second, the side lead should have experienced to draw from. Ideally, the site lead has done exactly that job, scaling from zero people or to ten or a hundred people, whichever are your targets for the next two or three years; so, the site lead can draw from a playbook.

The third is actually a little bit opposite of the second, which is that the site lead must be able to reason from first principles. A lot of management and building of a site and engineering growth is about company growth. It’s very situational. You can’t just blindly apply exactly what you have done in the past to a new situation. We have met a lot of people that have done that, they always use exactly the same playbook. They’ve been lucky to replicate their playbook every time, but if some of the underlying assumptions have changed drastically, the playbook doesn’t work. It’s very important to actually filter that out in the interview.

Anu: To expand on the point of culture, it makes a phenomenal difference to have the right site lead. It’s day and night. When your team comes to work, they really are a living, breathing representation of your company at that site. We have this “boomerang program” at Atlassian (yes, we’re an Aussie company and give our programs Aussie names) to send our leaders to new sites for a set period of time where they’re in charge of hiring the permanent site lead.

How do you do this over Zoom? I’ve found it exceptionally hard to do it because it’s a critical hire. This is somebody that’s going to really set the tone for an entire country to represent your company. I don’t have great tips on how to successfully do it during COVID times other than the usual remote interview content out there, but this is going to make or break your remote site, and definitely something to attribute outsized importance to.

In terms of transforming a newly established site to match your culture, it’s rarely fully the case. The likelier reality is to have microcosms of different cultures. It’s okay for the culture to not be exactly the same in the remote sites. However, what you want to keep constant is your values. If you are able to find ways in which you can disseminate your values remotely across the sites, those are really good places to start.

We now have nearly 11 sites at Atlassian and we do this with both the little things and the big things. How the workplace looks when you join, the kind of starter kit that you get, the origin story of Atlassian. We have centralized celebratory events; we have quarterly all-hands where everyone gets together, even though it’s a nightmare in terms of time zones, but our teams attend because it fosters a real sense of belongingness. Our quarterly hackathon is another great way for our people to realize they can make a lot of change or invent something from scratch even though we are now over 5,000 employees; everyone’s encouraged to look somewhat beyond their hierarchy. The founders get together with everyone to find emerging themes and there’s a real buzz and energy for 48 hours. That’s a great way to really bring all sides together and experience the culture of what it means to be at Atlassian.

Farhan: You bring up a really good point, which is that every remote company spends time, money, and coordination to get everybody together, in person, at least a few times a year. Only right now during the pandemic, are we trying to do this version of remote, which is 100% complete remote, where no one ever gets together in person. That actually doesn’t happen in any remote company.

We have this saying at Shopify that this is probably the worst version of remote you’re ever going to see because it is not going to be like this. If you decide to go fully distributed as we have, you are going to get together and you are going to fly to different destinations. You are going to try to get physical contact because that is actually required to have human connections. It is something that all those remote companies do. Thanks for reminding us about that point because it is something you want to make sure founders bake in.

Antoine: What would be the most helpful information and resources etc., to have when considering building an engineering team in a second HQ? In terms of playbooks, resources, introductions, how do you make sure your new geo or your remote team get up to speed as fast as possible?

Farhan: For me, I ended up meeting with different site leaders and chatting with them about my experiences in that geography. Now, I get pinged all the time by people opening up remote offices in Toronto to see what it is like to hire product managers, UX people, engineers, how to think about compensation, the average tenure, etc.

Reynold: I can describe the stories of how we started two sites. The first was via an acquisition, which was all about how to organically assimilate the talent on the other side. The second one was a site we wanted to start from scratch in Toronto. The reason we did it was that there were actually quite a few Canadians at Databricks, including myself, so we had a unique edge. We already knew the local market, we knew exactly who the top employers are, how much they paid people, what kind of specialty talent were there, etc.

We then went back and we looked at the type of work we do at Databricks. We started looking at self-contained components or a micro-service that we could actually ship to that site over time. The way we did it was to hire a few engineers in Toronto, with the right leader. So, the leader could actually drive engineering and hiring. Potentially, you’d have two or three engineers we’d hire as part of the same team that currently owned a specific piece of the product in our San Francisco office.

Over time, we’d slowly transfer more and more of the ownership over to the Toronto site to then expand it from that core function into other adjacent functions or microservices. Then, they started or created new things that didn’t exist before. A
t scale, when you have a sense of one or two critical successes, you can start thinking about other things that are completely unrelated to those initial functions. That’s how we usually did it.

Part of the reason is that the opportunity cost is very high. We need to avoid failures as much as possible. The way we try to guarantee high success is by doing experimentation and very iterative development. If you think about how to build a massive engineering project, you don’t start with a grand waterfall model or blueprint and go design and implement that. Rather, you start with something small and then you grow from that to build up expertise.

Antoine: Once site lead is in place, where have you seen the most success with leveraging technical recruiting firms to help hire your first 1 to 10 engineers? Does that vary across geos?

Reynold: We’ve only used recruiters for very senior people, head of engineering or VP-level people in the Bay Area. We have actually wasted a lot of money with recruiters in Europe. In Toronto we didn’t engage any. One of the major functions of the site lead is actually to grow the site and hire. In finding the right person, you are entrusting that person with building out the site. That typically means the site lead should attract local connections. If not, LinkedIn is actually a great source for the site lead, himself/herself, to generate the pipeline.

Once you have 50–100 people, the whole model changes. You have in-house recruiters and sourcers, but in the initial bootstrapping phase, I think it is completely fair and probably the most important part of the job for the site lead.

Farhan: The way I always think about recruiting is always as a time game, so I’ve never really tried to optimize for dollars, although you should because there is a significant component in recruiting fees if you use a recruiter for a lot of your roles.

That being said, because it’s a time game, you can do a lot of things in parallel. I would do what Reynold talked about in addition to using recruiting agencies; potentially do a bulk deal where you hire 10 people through them, to pay less than the typical 30% fee for every hire.

Spending time is critical. What I do when I talk to founders having a hard time recruiting is to ask how much time they are spending on recruiting. Most of the time, it’s less than two to four hours a week. I know that when I was recruiting for Helpful, we were starting from scratch. I probably spent 50% of my time on recruiting. I was never in the office at the beginning. I would tell my co-founder, “I’m not going to be in this week because I’m meeting 20 engineers. I’m going to be downtown all day.”

I think spending time and finding out what sources are going to work for you. That could be LinkedIn, Twitter, job boards, events, speaking, writing blog posts, or even crash machine learning courses like I did back then. There are all kinds of things you can do to try to find people.

But whatever you do, I would definitely try to add recruiting agencies to that mix in parallel. Talking to other site leads already in that geography will help, because they will know the best recruiters for the specific skill set you’re trying to hire for. Try to learn from their playbook and see what’s going to work for you. Finally, I think that there’s a bunch of things you just have to try for yourself as well. Not every piece of the plan is going to work for your company.

Antoine: Post pandemic, some companies are thinking of keeping a hybrid distributed/remote structure, what are your thoughts on that?

Anu: You could either be fully distributed or you could be fully co-located. The hybrid model is a tricky one to pull off. I’ve seen many teams fail by saying there will be a satellite team that will be co-located and then we will distribute a part of the team remotely. What happens is that the remote team members, unfortunately, devolve to be second class citizens of the team. You’re unconsciously excluding them from meetings. They don’t really stay in the loop as tightly etc.

Trello, as a fully remote team from the very beginning, when we acquired them, had a really interesting tactic to avoid doing that. Even though there were 10 people in an office and the remaining 90 people were completely remote, when they ran meetings, they would have everyone dial in remotely. Everyone would have to be included via the same channel; everyone had to be digital. Otherwise, subconsciously what happens is if a colleague and I are in a room and we are having physical cues that we’re passing to each other, it’s easy to exclude the people that are dialed in remotely. Having the discipline to do that in a hybrid situation is very important and it’s hard to keep it up. If you don’t invest the time in doing that, I would suggest then it’s better to go for fully remote or fully co-located.

This transcript has been edited for clarity and length.