With the future of work upon us, an increasing number of companies are rethinking how they run their daily operations. While a decade ago allowing employees to telecommute was seen as enlightened and edgy, remote work and telecommuting are now the only way of life for some companies.
If you’re thinking of adopting a distributed software engineering team model, where your employees telecommute to work from wherever they’re located because there’s no central office, then you’re probably wondering how you build a distributed team to begin with.
After you build the team, a herculean task in and of itself, you then have to think about how you’re going to maintain the team and keep everything running smoothly.
Whether you’re the CTO of a company that has decided to embrace the distributed team model or a CEO of a startup that has decided to be a distributed team from the get-go, you’ve come to the right place. In this post, we’re going to show you how to build and maintain a distributed team for the best results.
Looking to hire the best remote talent? See how Arc can help you:
⚡️ Find the world’s top developers, designers, and marketers
⚡️ Hire 4x faster with fully vetted candidates
⚡️ Save up to 58% with global hires
Hire top talent with Arc risk-free →
What is a Distributed Team?
First, let’s talk about what a distributed team is so we’re all on the same page. A distributed team is a team (or company) that’s dispersed all over the country or world. Although it sounds very much like a remote team, a distributed team has no central headquarters. Team members work from home, in coworking spaces, or in coffee shops.
They communicate with one another through chatting applications like Slack and/or meeting software like Zoom. Work is done via cloud-based technologies, such as Google Suite, and some teams even agree to work asynchronously, which means that team members are expected to perform their tasks with some degree of independence and the understanding that a response from coworkers or management may not arrive the same day.
Read More: How to Implement a Welcoming Software Developer Onboarding Process
How to Build a Distributed Software Engineering Team
Determining Cultural Fit
“Why do I need to know what my culture will be before I hire?” you ask. The short answer is, that by knowing what kind of culture you want to foster, you’ll have an idea of what kind of person you want to hire. When you know what kind of environment you want to build, it’ll make it easier to see if the person in front of you fits the bill.
Cultural compatibility is important for both on-site and distributed teams, but because of the unique challenges distributed teams face, your potential team member’s cultural fit is even more important. There are, in essence, two components of determining your company’s culture in a distributed team model.
One component is the type of culture your company will have, while the other is whether the potential candidate can embrace remote work. For the first component, you can decide whether: your company will follow a hierarchical or flat power structure, you work synchronously or asynchronously, to hold all-hands meetings or not (and how).
These components will determine the general atmosphere of your team and how it will function, as well as what kind of person would be attracted to this type of environment.
For component two, established remote companies like Zapier and Buffer look for candidates who possess these qualities to fit their distributed team model: Do-ers Good at prioritizing Pros at written communication Trustworthy Have a local support system
It’s doubly important for asynchronous, distributed teams to hire someone who can act independently, prioritize, communicate with coworkers, and are trustworthy enough to work by themselves because of the nature of the distributed model.
When hiring developers for your distributed software engineering team, look for skilled developers with the attributes above and soft skills to boot. A developer’s soft skills are just as important as their coding ability for a distributed team because nobody enjoys working with unpleasant people, even if they are geniuses. Thus, you want a developer who can express themselves as well as they can do the job.
It takes a particular kind of individual to be able to work without seeing their coworkers, and by deciding your must-have traits beforehand, you can avoid heartache for both parties.
Read More: 10+ Software Engineer Interview Questions to Find Top Dev Candidates
How to Hire
After you’ve determined your company culture, you can now write your job description. Basecamp, a very well-known company in the distributed team space, suggests trying out the role you’re hiring for yourself (whenever possible) to give you a better idea of what the job really entails. This, in turn, will help you write a detailed job description with the ins and outs of the job duties laid out plainly and figure out whether your interviewee would be a good fit for that role.
While companies traditionally use job boards like Monster and Indeed, your own social networks, local meetups, and your own users (for established companies) are all places you can use to find candidates. Websites like RemoteOK and WWR are also potential platforms to recruit people who are interested in remote and distributed jobs. You can also share your job posting on Twitter, LinkedIn, Facebook, and AngelList to reach a broad audience.
Companies like Zapier and Buffer have potential team members do a series of short tasks that test the candidates’ basic ability to perform in the role they’re applying for. This serves a variety of purposes: it filters out the people who don’t want the job enough to do the tasks, helps you vet a candidate’s abilities, and can introduce you to a potential candidate you may not have considered from just looking at his or her resume.
When hiring a developer, you can consider giving them a coding test or a small project to do. We use coding tests and small projects to vet our Arc developers, as well as our own developer team. This will tell you whether they have the skills to do the job you’re hiring them for and your CTO or existing team members can evaluate their work for quality. In addition, your CTO or engineering manager can use the project and test during further interviews as a jumping-off point for discussion.
If the project is big enough to last more than a couple of hours, usually the candidate is compensated for their time. Some teams, like Automattic, even do a trial hiring period where the candidate works with the existing team. This gives you an idea of how the candidate works and collaborates, which can let you know whether or not they’d be a good fit culturally and in terms of ability.
Finally, if all has gone well, the entire team should talk to the candidate (when possible). If you have over 100 team members, this may not be possible, but at least the group that the candidate will be working with should talk to their new potential team member. If that chat goes well, and there are no glaring red flags, you are probably ready to hire!
Read More: Andela vs Toptal vs Turing vs Arc: Which is the Best Andela Alternative?
Welcome Aboard
Congratulations, you’ve found the ideal candidate for your distributed software engineering team. Now what?
Well, it’s time to onboard your new hire. It’s time to put your discussions about culture to use by creating a handbook to give to the new guy or girl. A handbook goes a long way to making the new employee feel at home. It can include anything from master passwords to introduction to Slack channels, to who to ask for what.
Automattic goes a step further and pairs new team members with a workplace buddy who can answer their questions and make them feel welcome. The work buddy can email their new friend to welcome them to the team and let him or her know that they’re there for advice or to answer questions as well as a check-in with them every week to see how they’re adjusting.
While your SOP may be different from Automattic’s, the key is to help the team member feel included in their transition to a distributed team. For those well versed in remote work, the transition may be easy, but for someone who is feeling the situation out along with you, they may feel completely lost. By going to extra mile to make their onboarding more comfortable, you can ensure a smoother transition and enhance their feeling of integration to the team.
Read More: 10 Ways to Avoid Failed Software Projects & Why They Fail to Begin With
You can also try Arc, your shortcut to the world’s best remote talent:
⚡️ Access 350,000 top developers, designers, and marketers
⚡️ Vetted and ready to interview
⚡️ Freelance or full-time
Try Arc and hire top talent now →
How to Maintain a Distributed Team
Sustaining Culture
Remember when you thought about what kind of culture you wanted to create and made a handbook when you onboarded your new hire? Well, here is where you put your ideas into practice. You want to sustain your company culture to maintain your distributed team.
One way to build up culture is to sustain relations among employees. Zapier, for example, has pair buddies, a weekly random pairing where two random team members are paired to catch up and converse. Help Scout shares a weekly video update about new feature releases, birthdays, and other company news.
Culture can encompass a lot of things, one of which is employee happiness. One way of maintaining your company is to do periodic one on ones. You can solicit feedback and give performance evaluations through one on ones that go both ways.
Employees can give their CEO feedback about how happy they are with the way things are going and vice versa. This helps nip performance or happiness issues in the bud but requires some degree of trust on both sides.
In addition, an increasing number of distributed dev teams are emphasizing a sustainable work-life balance when it comes to building their culture. By instituting policies that encourage your employees to avoid burnout by working 24/7/365, you can help maintain their overall productivity. Mandatory time off, unlimited vacations, and an emphasis on a work-life balance means that employees can recharge, stay focused, and be happier in the long run.
Read More: How to Write a Product Requirements Document (PRD) Devs Understand
Remaining in Communication
Distributed teams are maintained through communication, communication, communication. Now, this doesn’t necessarily mean conversations, particularly if team members inhabit very different time zones. This simply means team members communicate with each other asynchronously and through project management tools.
One way a distributed software engineering team can stay in communication is through all-hands meetings, where the team gets together as often as once a week or as infrequently as once a month or quarter to get an idea of where the company is heading. This means that the CEO or individual teams can present what the company is up to, what the team is up to, and what the goals are for the next week or quarter.
Now, all-hands meetings can take place either synchronously or asynchronously. Synchronous meetings are doable if a majority of people are in the same time zone, but companies like Help Scout also do them asynchronously, where all-hands meetings are attended by those in a convenient time zone and recorded for teammates who can’t make the time but want to catch up on company news.
Another way distributed software development teams can keep in communication is through project management tools like Trello, Asana, or Dropbox Papers. These tools give team members a way to collaborate as well as keep others apprised of what’s on their plate. This way, team members have some idea of what their coworkers are doing and project parts aren’t unaccounted for.
In the course of a normal working day, or even an emergency, Slack, Zoom, or other chat programs can help team members keep in touch and/or put out fires. These options are sometimes faster than email and foster a sense of familiarity that email cannot. Thus, it may be worth investing in specialized communication tools to keep in touch if you want to maintain your distributed team and keep it humming along.
Read More: How to Be an Engineering Manager Your Company & Team Respects
Meeting Up
One way distributed software engineering teams stay maintained is the annual retreat. Companies like Zapier, Basecamp, Buffer, etc. all have annual retreats where the team gets together for a week or two to meet up in person, bond, and (maybe) do a project or two. However, committing to flying all team members somewhere exotic may not be economically feasible for you.
If a retreat is not in the cards because of budgetary reasons, virtual meetups are an option. You could try having groups of people hang out virtually at a given time, either for a casual happy hour or for a movie night. Depending on the size of your company and the ratio of introverts to extroverts, you can either set a hangout theme or let the evening play out freeform.
Help Scout, for example, has monthly group chats centered around a theme and set on a specific date to give team members a chance to prepare. Themes can include team members’ favorite apps, favorite books, favorite recipes, movies, etc., and team members can share their passions with others to bond and have something to talk about.
Virtual hangouts can take place between members of individual teams or on a company-wide basis. They can help teams stay connected, which is what in-person retreats are for, but at a much more cost-effective price point.
Read More: 9+ Project Management Tools for Managing & Working With Developers
Build Away
While it’s undeniable that building and maintaining a distributed software engineering team is no easy task, if you succeed, the rewards can be manifold. Luckily, because of the pioneers who have succeeded and written extensively on the subject, we’re about to stand on the shoulders of giants and learn from their successes and failures.
Although companies like Zapier, Basecamp, and Buffer have excellent advice on building remote and distributed teams, it’s important that you do what you think is best for your company, even if it runs counter to what they say. After all, a policy that works for them may not be the best fit for your company — there is no one size fits all when it comes to distributed teams.
Therefore, put your own unique needs first and foremost when it comes to making decisions regarding your distributed team. A distributed team model runs best when team members can work independently, asynchronously, have access to great communication tools, and are supported by a strong, defined culture. How you go about hiring and setting up your distributed team is up to you.
Don’t be afraid to blaze your own path and leave your own mark on the distributed software engineering team landscape. If you end up discovering a radical policy that works great for you and nobody has tried it before, do give back and share it with the internet.
You can also try Arc, your shortcut to the world’s best remote talent:
⚡️ Access 350,000 top developers, designers, and marketers
⚡️ Vetted and ready to interview
⚡️ Freelance or full-time
