Things I learned managing a remote software engineering team

Tips for the day-to-day life in a long distance (work) relationship

Introduction

Two and a half years ago, my wife and I sold all of our stuff, said goodbye to our families and friends; we packed 4 suitcases, grabbed our dog, and moved our lives towards a new adventure across the ocean.

Fiverr, the company I was working for over 2 years prior to this adventure, decided to open a second, remote software engineering site in New York City, and as part of this decision, I relocated to lead the software engineering group, which was assembling there.

The company already had a pretty established software engineering organization in Tel Aviv, Israel, with tens of engineers, a robust development department, a platform engineering team and a mature engineering culture to facilitate its growth.

Why another site?

The reasons for opening a second software engineering office can vary, but in general, having a remote site can be a great thing, both for the company and for its employees.

Firstly, the company can tap into the local talent and enjoy a diversity of cultures, perspectives and backgrounds — something that can improve and strengthen the engineering culture.

Secondly, it can enjoy a longer working schedule. For example, in our case, a TLV + NYC team works around 16 hours a day, across 2 time zones and has one extra day (Friday) of work every week. Needless to say, that longer coverage gives the organization not just the advantage of a faster Time-To-Market, but also the ability to respond to crises on time.

Thirdly, sometimes (as it proved itself in the case of Fiverr), adding software teams to support the local efforts in the local office, can create a better synergy. Fiverr’s category management, corporate marketing and business development teams were in our NYC office from day one, and empowering those, with a software department right in their time zone, proved very efficient.

For engineers, both in the HQ, the new remote site and the ones relocated to pioneer it, a remote site offers the opportunity to experiment on a global culture of software engineering, as well as allows one to travel and feel part of something bigger and greater.

However, as with anything good, globally distributed engineering teams have their downsides. As time passes, running 2 teams in different time zones, with the various communication challenges, overlapping responsibilities and domains and collaboration overhead, can become challenging, both to the HQ and especially the remote team itself.

In this post, I will summarize everything I’ve experienced and learnt from managing a remote software engineering team — the things you absolutely have to invest in, and the things to avoid; I hope this will be helpful to anyone in a remote leadership role.

Tips for efficient management of a remote software engineering site

Brand yourself internally

One of the first important things you have to define for yourself, but also to constantly communicate internally within the engineering organization, is what makes you special.

What is your unique positioning within the engineering team, and the different scopes and domains the teams works on. It’s important to thoroughly consider, what “chunk” of the product or tech your remote team will be responsible for — ideally, it should be something very secluded with no collaboration overhead with HQ — remember, you are just testing the waters, start small and increase the scope of your domain.

When you define this unique positioning — never stop to communicate about it and constantly remind other engineers why they have to invest the time and energy in putting out the extra effort to work with you, even when you are remote.

Internal branding is not just for engineers in HQ to know you; it’s also to give a better self-definition for the engineers in your remote site — they have to feel that their workplace is not just an “extension” of a larger organization, and that it has its own unique culture and importance.

Brand yourself externally

One of the biggest challenges I faced when bootstrapping a new remote site, is the clean slate I had to start with in terms of the recognition of who/what is Fiverr and why would engineers want to work here.

In Tel Aviv, although surrounded by big names such as Google, Amazon and Facebook, Fiverr is positioned as a desired and popular workplace.

Arriving in NYC made me realize, that in the US job market, Fiverr is not a familiar “workplace brand”, and a lot of the work that had to be done when hiring here, was focused around creating the right selling point, and getting the buzz going.

How to do that? There are many options to consider. Here are a few:

• Tap into the local developers’ community — attend local meetups and mingle, possibly offer your space to host some relevant meetups as well.
• Encourage your developers to present in meetups — highlight some interesting key technologies you are working with and don’t forget to mention you are also hiring at the end of the presentation
• Create a profile in some local startup guides. Those guides are very effective in generating content about your startup, and creating a buzz. You will soon be published in articles such as “10 best startups to work for in NYC”
• Build the right selling point when talking with candidates. Focus on the uniqueness of working in a remote “second” site — autonomy and “get things done” atmosphere of a small startup. with the financial backup of a big company.

Think about who you hire

Getting people to join your remote team is not enough — it is paramount to hire developers with the right mindset and attitude.

Working in a remote office brings with it lot’s of challenges for developers starting with remote communication.

A great deal of expectation matching has to be done starting the interviewing phase — explaining what will be the day-to-day of a developer in your team — how much will he/she be required to collaborate with the HQ, how many calls a day are usually required to effectively sync?

A developer onboarding a remote team must possess great communication skills, a positive attitude, and patience. I cannot stress this enough — patience is tremendously important here — things which usually can be resolved by jumping by a colleague’s desk and nudging her about a PR she has been postponing and is blocking your work will sometimes take days in an inefficient remote collaboration (but on that — in a bit).

Lastly, hire independent, self-taught and “go-get-it attitude” engineers. This is of course true in general, but being remote, also brings challenges of knowledge transfer and lack of quick problem solving — you cannot get devops to quickly fix an issue with your deployment, you will have to probably do it yourself, you probably won’t get a fast ad-hoc advice from the SRE guru of the company — you will have to resolve that service monitoring issue you are debating about, yourself as well.

Become independent but invest in relationships

I’m a big fan of “Loosely coupled, tightly aligned squads” philosophy — a term coined by Spotify to describe one of the key elements of their engineering culture.

Our structure @ Fiverr, resembles this in a lot of ways — we call our teams ‘task forces’; they are cross-functional, and are autonomous — having their own tech and product vision.

This autonomy allows our task forces to run independently as mini startups inside a larger organization. Having this autonomy, makes teams run faster, and be more motivated. You can probably imagine how this autonomy is important when talking about remote teams.

I invested a ton of my time, to draw and discuss borders, boundaries, ownership swaps, domain transfers, technical handoffs, breaking of services into separate micro-services, splitting monitoring boards and discussing product vision and mission for the various teams — all for the purpose of creating autonomy. This would allow our remote site to run fast and create impact without waiting for an approval of a co-owner on the other side of the ocean, or some technical blocks from the platform engineering team in TLV.

Achieving this is not the end goal for a remote engineering team. Simply put — you don’t want to become a technical and product island. Cross pollination is important, especially for a creative team; moreover, collaboration with the teams in HQ is important — once independence is achieved, a strive for mutual technical ownership, or development of a mutual infrastructure that is needed by teams in your remote site and in HQ can be effective in strengthening the working relationship between teams, but as said before — this collaboration should come from a choice and not the lack of it.

Communication quality is key.

I’ve come to the understanding, that the quality of communication, both physical — the equipment you use, and mental — the quality of the process you define between HQ and the remote site, is what will determine the day-to-day level of happiness in your team.

Invest in the physical equipment you use on both ends — it’s really important for your remote team to be able to feel an equal part of any discussion or meeting they were invited to.

There is nothing more frustrating than not being able to express your thoughts and opinions in an all-hands gathering where you cannot see or hear the other side well enough. This situation impacts the will of your team to collaborate. Insist both in your office, and HQ that the level of equipment is satisfactory.

Create a remote-meeting rules of engagement

Imagine a hot topic being discussed in a room full of passionate colleagues. There will probably be little to no order going on, and people will eventually start yelling their opinions, interrupting other colleagues mid-sentence and even side track to other internal discussions.

This, on its own, is not perfect, and will most often lead to zero results, action items or decisions, but you will probably not avoid unstructured discussions in a meeting all together.

The problem starts where there are 2 sides in the meeting, conversing over video chat / phone (less likely nowadays). Ever tried having an unstructured meeting like that? It’s just not possible.

An easy thing to solve this, but actually really hard to follow, is a simple rule of engagement when having a remote discussion — pick an object, could be something present in the meeting room like a whiteboard marker. From now on, only the person holding the marker is allowed to speak. If someone wishes to speak after him, they need to ask for the marker first. This creates a passable token, which allows the meeting to gain more structure. I would lie if I tell you this always works, but it’s something to try out.

Create remote rituals

I usually try avoiding cross-site projects, since they are hard to manage.

I believe that if a project has to be done cross-site, it was either not well-defined ownership-wise, too big or sometimes just inevitable like a company-wide initiative.

When you have to collaborate on a cross-site project, the best thing you can do is create rituals around that process.

Create daily all-hands sync meetings, like a morning standup, especially for this project- make everyone over communicate about any small details — it’s better to hear things twice than not hear them at all.

Ensure the same roles in the teams have frequent one-on-ones. For example — 2 team leads from both ends going over the detailed plan of execution, or 2 frontend engineers discussing if the integration patterns they implemented are according to the defined protocol.

Open a mutual slack/hipchat/whatever communication tool you are using in your office channel, etc.

Celebrate Success globally

When your team creates impact — whether a feature goes live, be it a successful AB test, a new infrastructure being implemented or you just had a very interesting user testing session with local users — make sure these successes are communicated across the company.

Here at Fiverr, we have official all-hands meetings for all of the software teams, as well as the full production team including the product managers, BI analysts, etc. This is a great opportunity for people to share victory, “brag” and discuss their success.

Celebrating success for your remote site together with the whole company will help you improve your internal brand, as well as strengthen the relationships your team members create with other remote colleagues.

Conclusions

As companies become more global, more engineering teams will go down the pass of expansion to remote sites, which brings a lot of advantages but, as we have seen, a lot of challenges.

Mastering the way you manage your relationships with the main site, internal and external team branding, effective communication and smart hiring are key to successful long lasting remote engineering teams.

I hope this short list of important things will be helpful to any current or future engineering leader in a remote site management position .