How to make new remote engineers feel like part of the team
Receiving Series A funding is a triumph, a milestone, and a rite of passage for any ambitious startup. But preparing for a burst of growth also carries a host of issues, none more crucial than the need to hire new engineers and get them coding quickly. Missteps regarding onboarding typically spring from one mistake: Moving too quickly.
Particularly when building a distributed development team (meaning one in which team members are working remotely, in different places or even time zones), too often startups approach onboarding software engineers as merely a matter of hiring a bunch of coders and firing the starter's pistol. Then they're surprised when the remote devs fail to understand how the company operates, don't feel at home in the company’s culture, or have trouble gelling with the rest of the team. In no time, the engineers' performance suffers, and the startup soon finds itself confronting a personnel pothole that needs repairing — just when refining its product or scaling its customer base should be the primary focus.
Want to head off this unfortunate situation? Then follow our advice and take a measured, thoughtful approach.
First: Factor for soft skills
It's a given that you want your distributed team to crack even the thorniest coding puzzles like walnuts. But it's easy for startups to over-prioritize tech chops when they hire remote engineers, placing less value on qualities like relationship management skills, diplomacy, and a flexible attitude.
"Soft skills" play as big a part as technical know-how in a new engineer's ability to get comfortable and produce their best work. Skills like knowing how to manage relationships, resolve conflict, and appreciate group dynamics are all part of the intangibles that help remote engineers to smoothly work as part of a growing team.
Vention Business Development Manager Alexey Pavlov prioritizes soft skills whenever he places engineers with growing companies, as he did with longtime Vention client StoneX. "Keeping five software engineers working as a team is very different from doing the same with 20 engineers," he says. "You've got different personalities, working styles, egos — it's enough of a challenge when everyone's together. When growing teams are remote, the chances of conflicts increase exponentially. To state the obvious, you want to avoid those."
Whether a company primed for fast growth hires remote software developers independently or through a vendor, Alexey urges that companies place some background or training in interpersonal relations alongside their other coder-selection criteria.
For our part, Vention has acted upon our belief that the less-technical aspects of coding teamwork are crucial to engineers' (and clients') success. We've made them a vital part of the training programs we run for our in-house people and students in Central and Eastern Europe tech hubs.
Take as much time as you can
Famed UCLA basketball coach John Wooden was equally good at winning games and dispensing life advice disguised as sports insight. One of his most famous lines is particularly apt for startups that are engineering-up: "Be quick but don't hurry." Quickness, he taught, is a virtue, while hurrying leads to mistakes.
Startups are always trying to go as fast as they can. But growing your team from five engineers to ten is a big deal. As for going from five to 30, or even 50? That's a way bigger deal. So to the best of your ability, try to grow fast without hurrying.
Based on our decades of experience in working with startups, we recommend implementing a staggered staffing timeline rather than welcoming dozens of engineers to a project right from the start. Bring on a small team at first — say, five engineers. Think of it as an audition for your onboarding process, a first step that will help you identify any hiccups before they make life difficult for your entire crew.
Plus, the take-it-slow approach to scaling a team delivers a bonus benefit: Once you familiarize a micro-team with your operations, you can implement a buddy system, tapping early arrivers to help show the ropes to devs who join the team later. Just like that, you’ve turned your first hires into a squad of mentors.
Document your processes in plain language
Once you've established a timeline for bringing in your distributed team, you can set the table for them by ensuring that all of your orientation and operations are readily understandable and available.
Start by combing through your product manuals, company policies, employee handbook . . . any materials your new software developers will use to get acclimated to your company. Jettison insider terms, uncommon acronyms, and irrelevant subject matter that might confuse an engineer trying to find their footing in their new position.
Vention Senior Engagement Manager Matt Stocker has had years of experience placing our engineers with growing clients (as he did with German fintech Upvest). "The easier you can make it for an outsider to mesh with your team, the better," Matt says. "Spell out how you like to work and what you expect from new hires as simply as you can."
You should also compose your technical documentation for maximum comprehensibility. Consider how your version of materials like these would read to an engineer encountering them for the first time:
- Your source code as viewed through your GIT-repository
- The setup manual for your local database
- Tracking of your project dependency versions
- Tool credentials and API keys
- Procedures for inputting sample data
- Test suites
- Any staging/production server deployment credentials
- Notes documenting applications' development
- Deployment process scripts/breakdowns
Another "welcome aboard" measure you can take is housing onboarding materials in a dedicated space in your project management tool, so new hires don't have to navigate another platform to do their reading. Notion, for example, has a wiki product built just for sharing onboarding and company-wide materials.
Appreciate that non-Americans aren't American
US citizens traveling abroad have earned a bit of a reputation for assuming that everyone they meet speaks English. Unfortunately, many Americans in the tech industry have expectations along the same lines — that every engineer who speaks English will do so like an American.
Education systems in engineering hot spots from Uzbekistan to Poland have done impressive work teaching young engineers to speak English (Poles are particularly well-known for their English-language skills). But, as anyone who has studied a foreign language knows, there's a difference between classroom instruction and real-world conversation. Many (if not all) of your remote devs will be fluent in English, but still, the slang, idioms, and pace that are natural to native English speakers can easily trip up a new hire.
"You can head off a lot of communication problems with your distributed team simply by speaking plainly and slowly," says Dave Hecker, our West Coast CTO.
In that spirit, try to go into one-on-one conversations with engineers from a position of patience, and plan for extra time and briefer agendas with team meetings. It’s also helpful to use generic English in both your spoken and written conversations — which means scrubbing your language of corporate jargon.
It's also important to be attuned to how casual American ways can seem to others. Engineers in other countries can come across as serious or formal, initially because their culture simply isn’t as forward and casual as American culture, so it can take time to register and adjust to those sorts of differences.
Create a culture of inclusiveness
Everyone likes to be invited to the party, and remote devs are no different. So while your team might be several time zones away, it's still worth making a sincere effort to include remote devs in conversations and events that might not be directly related to the work at hand, so they feel like valued, full-fledged members of your staff.
We encourage companies to welcome remote engineers' input on work-related matters by including them in team calls, Slack channels — however their group regularly communicates. We also recommend including your devs in virtual social meetings and events. If you're fortunate enough to have a travel budget, involve your remote teams in company-wide IRL get-togethers. If you don't have those kinds of funds, even sending a little swag — a hoodie, a branded water bottle — sends a message of unity to a far-flung team.
Steps like these will go a long way toward demonstrating that you recognize each engineer's individuality — and it usually doesn't take long for engineers who feel included to start revealing their personalities (which is when teams really start to cohere).
Give your distributed team real work
Finally, don't baby your new devs.
Many companies assign less-urgent tasks to new remote engineers because they think the engineers need time to settle into their new jobs — more time than an on-site dev. But this well-intentioned strategy often winds up not only wasting time but demoralizing remote developers.
It's understandable why a company might test their new devs with non-mission-critical tasks. If you legitimately need to see if an engineer is qualified to run certain operations, this is OK. But devs have a knack for knowing when they're being tested for no real reason.
"If all you give at first are bug fixes and busy work, you're telling devs you don't trust them with the real stuff — and they can immediately sense it," says Dave.
Dispense with the "warmup assignments" and start remote engineers off with the work you hired them for. This signals that you trust your new team, that you're glad they've come aboard, and that you believe in their abilities.
