We won’t bury the lede here: good hiring and management strategy is good hiring and management strategy, whether your team is remote or local. The difference? Remote engineering teams allow for growth and directional change more fluidly than the alternative, if you know what you’re doing. And if you don’t - that’s what we’re here for.
As we mentioned at the top of this article, managing a remote team is no easy task, and not for the faint of heart. There are critical mistakes you can make when trying to leverage the vast amounts of remote talent out there in the ether of the Internet. Here are but a few to watch out for:
Forgetting that remote workers are people too
This one might sound a bit obvious, but the lack of proximity to a person and communication only through email can create a syndrome where you stop thinking of your colleague as a person and you start thinking of them only as an outcome. It’s a very human thing. Bad bosses have been doing it to employees in traditional office structures since the dawn of the 9-to-5. Bosses get busy too, and it becomes easy to forget that people are going through all kinds of crap day in and day out, just like everyone else in the world. And if you lump a distance of thousands of miles and several time zones on top of that, it becomes even easier to create a toxic culture of neglect for the human on the other side of that email chain.
The solution: Communication, lots of it. Video communication, daily stand-ups, one-on-one check-ins and (if possible) a once a year “retreat” where everyone can get some face time. Use email for long-form communique that you want to have documented, use Slack for everything else. If you’re the leader of the team and you sense someone withdrawing, reach out and suggest a one-on-one. Start a public Slack channel about a general off-topic where everyone can contribute, food, cars, movies, recipes, Jiu-Jitsu, literally anything that gives people an outlet within the working group that is not just about work.
But, it goes without saying, don’t let that chat get outta hand—and avoid divisive topics. Guns, politics, religion… basically, anything that might set someone off.
Burning out your team
It’s been proven that remote workers tend to completely ignore the confines of “working hours” and will work late into the night and sometimes into the day to accomplish a task irrespective of how long it takes. A study conducted by HBR in 2017 also concluded that remote workers also experience other anxieties like “feeling shunned” and “left out” when it comes to the rest of the organization. This toxic mix of overworking and feeling undervalued is a perfect recipe for all manner of psychological issues related to remote operations if those operations aren’t functioning correctly. We’re not just talking about lost productivity—family issues can develop, people can manifest depression and anxiety. Serious stuff. Burnout is a huge concern that you must prepare for.
The solution: a lot actually rests on the worker. They have to be disciplined and set boundaries for themselves about when they are, and are not, going to perform work. As there’s nobody around them to compare their productivity to, there are certain ways they can set a cadence that will keep them on track through a typical workday while also allowing for relaxing breaks that can work wonders for a person’s sanity. One method is called the Pomodoro technique where they literally set an egg-timer that will run for 25 minutes while they work. As soon as it goes off, they take a five-minute break, then they reset the timer and start another 25-minute “sprint.” After four “Pomodoro sprints” they take a 30-minute break. Rinse and repeat until they’ve reached the end of their time-boxed work day. As a manager of a remote team, you can encourage techniques likes this so they maintain a healthy work-life balance. At the very least it shows that you have concern for their well-being.
Wandering into technical debt
There have been entire treatises written on the topic of tech debt, and how to claw your way out of it, slowly, painfully and (not always) successfully. The chance of releases going out with legacy bugs that just never got fixed can be dramatically amplified when you’re dealing with distributed operations unless everyone is on the same page from the very start. However, if you just start building a thing without having someone in charge of architecture, you’re going to encounter worse than average technical debt. And it will only get more extreme as you keep building new features right on top of those old bugs that never got fixed, and probably never will.
The solution: A single person needs to own the architecture of what you’re trying to build, and must have put substantial thought into it before one line of code is even written, and everyone must be aware of that plan. Agile methodology has built-in safeguards for heading off tech debt, and some may be just right for your team structure. But the most important thing to remember is that someone must own architecture. This role isn’t even necessarily best-suited for the team leader either as it requires a great deal of cognitive power to think about and anticipate how a product may evolve from release to release and iteration to iteration and write code that can accommodate for those eventualities.