33 min read

7 Things I Learned Scaling a Global Engineering Team

This article was written by ALICE's VP of Engineering, Rafael Neves, and originally published on Medium.  
Photo by Capturing the human heart.

When I started as a software engineer working in finance years ago, I would spend hours commuting. The companies I worked for would spend tons on amazing offices and working from home was not even an option. I never thought about writing a post like this. In fact, remote work statistics blow my mind.

In the next 2–3 years, an estimated 59 million people are considering the life of a “digital nomad”. 43% of US employers say they plan to allow their employees to have more remote working opportunities in the next year. We’ve also started to see the first hallmarks of this revolution with distributed companies like InVision and GitLab crossing the 1,000 employees mark and GitLab planning an IPO in late 2020. The 2020s are destined to be the decade of remote work.

Inspired by all these changes in the remote work landscape, I wanted to share my experience of building and scaling a fully distributed Engineering team at ALICE from 3 to 35 people including Software Engineers, Architects, DevOps, and InfoSec. I started in this organization as a remote individual contributor and moved up to my current role as VP of Engineering while building and scaling the department. Having experienced remote work from both of these roles gave me a more accurate picture of its realities.

Over the years I had the privilege of being able to start a remote-first organization and then grow it with a strong culture. Our employee net promoter score (eNPS) is 65 which is considered excellent by industry standards. Our team is distributed across 8 time zones, 10 countries and 28 cities. I always like to say that our headquarters is the internet, and now it is the right time to share what I’ve learned.


Lesson 1: Make your communication intentional

blog image one

Photo by Volodymyr Hryshchenko

In a remote team, you don’t have the luxury of randomly bumping into team members or the occasional coffee chats that typically happen in an office environment. This means that intentional communication is critical for employees. You need to make this part of your culture by creating an environment that fosters social connection and group interaction.

Besides the Scrum ceremonies, we created a cadence of videoconferencing calls that fosters a culture of intentional communication: regular 1x1s, an Engineering All Hands, regular technical discussions where anyone can teach others any Engineering-related topic that can be applied to the company, and a few others. There are two important rules for every call: first, you need to respect people’s time zones when scheduling. Second, you have to turn on your video so everyone can see you and you can see everyone. This helps a lot to increase the feeling of connectedness amongst our remote team members.

Our team calls need a slide deck where a presenter shares his/her screen to go over the content, and the content is put together in advance by the participants involved who collaborate asynchronously (via Slack) and sometimes synchronously (by having a planning call). Also, our team calls are recorded — so in case you missed something, you can always go back to it.

For managers, to communicate with intention means you have to be much better at communicating with your team; listening to them, understanding their needs and wants, and ensuring expectations are clear. Overcommunication really shines here.

Lastly, documentation (everything from system architecture to process documentation) is critical for distributed teams to ensure everyone is on the same page. We use the Google Suite for collaboration and sharing documentation.


Lesson 2: Trust people — even when it scares you

Photo by Bernard Hermant

It may be scary for many managers to even consider that some days they will not see or not even speak with some of their direct reports. It can be a frightening thought, especially for people who have been managing people in an office environment for years. After all, how do you know if your employees are actually doing any work, right?

Remote teams across time zones are far more asynchronous than co-located teams. Trust is mandatory for any team, but in an async environment, it is foundational. You won’t be able to get the satisfaction in looking over to other people’s desks or getting a quick reply sometimes. If you don’t trust your people, please, please, do not run a remote team. Period.

I’ve heard countless horror stories from some remote companies — from checking in often whether your remote engineer is at his or her desk to actually tracking how many lines of code were produced on a given day and firing people that were below target. These are different versions of a pervasive lack of trust which is toxic. Luckily for us, some great engineers left these companies to join our team.

At the end of the day, whether you are managing people in the office or over the internet, to build a high performing team you should always manage by outcomes (is the team or the individual meeting goals?) and not by throughput (what your team or individual do on the day-to-day to achieve the goals).


Lesson 3: A Global team needs local managers

Eurotrip, anyone?

Having a geographically distributed team means you are going to have a very diverse team. This is fantastic. According to research published by Harvard Business Review, diverse teams are smarter and more innovative; and I definitely can attest to that after years of working with such teams. But, with diversity, your team now has different cultures.

As you scale your organization, you want your managers to be based in the main regions where your team is located. For instance, have managers in Eastern Europe, managers in Latin America, etc. Since the manager is part of the culture, he or she is aware of all the cultural nuances and can more effectively facilitate communication and alignment. Another benefit is these managers will also be in a similar time zone as their direct reports, although this is not a hard and fast rule as some managers cross borders based on availability.


Lesson 4: Remote is not for everyone — plus, some might not want to be remote forever

Our team in Rio de Janeiro at their co-working space

While many engineers jump at the opportunity to work remotely, it is not for everyone. Feelings of loneliness and difficulty in separating work from personal life are tough challenges that almost a third of all remote workers face. Also, some engineers want to be part of a community that an office can provide. There are also some people who will enjoy working remotely for a while but eventually, they will miss going to an office; and that is OK.

You can manage this by offering the flexibility of a co-working space in some cities where engineers can go occasionally. That way, they are still remote but actually working out of an office, seeing other people and being active in the local community. It is a great way for them to learn what other engineers are doing and share those learnings with your team. Also, encourage your team members to take part in local meetups and communities.

Another thing you can do is to encourage engineers to travel and visit their peers in other countries. For example, they can go to a conference together in a different city. Also, promote Engineering Offsites (I will talk more about this later in this article).

Lastly, managers need to be well trained to look for some natural impacts of remote work. They should be constantly checking in with people on how they are feeling about working remotely at your company and putting in the effort to improve that experience. It is also important to understand the person’s motivations early during the interview phase (I may write another article on the topic interviewing for remote later).


Lesson 5: Yes, you can do Agile with Remote teams!

One of our Scrum teams running their Daily Standup representing Colombia, Brazil, Russia, the Philippines, and the US.

As we planned our Agile Transformation two years ago, we started asking people in the industry if and how Agile would work with a distributed team. We received a lot of pushback and comments from many people saying that Agile only works effectively when everyone is uder one roof and that is how the creators of Agile intended it to work. We questioned this and were excited by the challenge of making Agile work in a fully distributed organization.

After 1.5 years running Scrum in a distributed Technology division (involving remote Engineers, Product Managers, Designers, and QA), we were able to prove that remote Agile can not only work effectively to achieve company goals, but it actually IMPROVES the remote experience for our team. Think about it: the biggest challenges people mention around remote work are loneliness and poor/lack of communication. Scrum teams are autonomous and they sync on a daily basis with the Agile ceremonies.


Lesson 6: In-person meetings are key (and their impact lasts)

6 countries in one picture enjoying NYC during our last Company Town Hall

Humans are social beings. While working remotely has its benefits, meeting face to face frequently is very important for a healthy remote culture. We’ve found that once people meet in person, the impact lasts for a long time.

Team Offsites and company Town Halls are all great examples of gatherings that foster this type of interaction. Remote employees go back to their cities and countries feeling very positive about the fact they were able to spend a few days bonding together with their colleagues from other parts of the world. They are also able to spend time building relationships outside of work-specific topics, which strengthens the culture of trust.

We have an annual Engineering Offsite in different countries in Europe. This year we are considering Turkey — which I’m personally very excited about! Our team members from all over the world fly to a central location where we work and spend time together for a week inside one giant house. We do hackathons, align on tech strategy, review the system architecture, discuss what we can do to improve our processes and, of course, have a lot of fun. Last year, the team got together in Minsk and together we came up with a roadmap to accelerate our DevOps transformation!


Lesson 7: Embrace remote work as a perk

Yes, you can work from a beach!

The flexibility that comes with remote work is huge and has an enormous impact on employees’ personal lives. People can define their own work hours, and they can work from anywhere they want. It allows people to travel to new places, spend more time with their families because they no longer have to commute, and exposes them to opportunities outside of their cities.

Very often we have team members flying to different countries to work from there, sometimes for months. Examples are as diverse as our team: one of our Senior Software Engineers from Russia once worked from Bali for three months; one of our mobile developers moved to Thailand for half a year and one of our Engineering Managers from Colombia spent months traveling in Costa Rica, the USA, and Italy while working (you can read an interview with him about remote life here).

With strong remote culture and processes, employees can have harmony between their personal lives, growing in their professional careers, and continuing to achieve business objectives.

My hope is that these insights inspire others to join the Remote movement with the right foot, avoiding some of the pitfalls and setting your people for ultimate success. This post is based on experiences and reflections over the last several years, but we are only at the beginning. It is important to mention that those lessons were the result of working with our team on this journey, listening to their feedback and iterating. Your people are always your best source of insights.

What about you? What have you learned doing remote? Post in the comments and share your thoughts


Rafael Neves

Vice President of Engineering, ALICE