Running a remote team is harder than you think. Here are 6 lessons I learned

Photo credit: Rawpixel

Most people hear about remote work and shoot it down right away, thinking it’s just a fad or that working together in person is so much better. But today, more and more companies are beginning to outsource software development to regions like Southeast Asia.

In the Philippines, I’ve worked on a dev shop, servicing clients in the Bay Area for three years (you can read about my learnings from running that company here). I have also built many enterprise SaaS platforms, one of which was valued at US$1 million and built by a team distributed across four countries.

In this article, I’ll be focusing on the challenges of remote work and sharing the hacks I’ve discovered.

Create a system based on a culture of building

It is essential to create a framework for discussion during meetings wherein everyone feels engaged. This often keeps individuals personally invested in their projects.

Our weekly sprint retrospective followed this format:

• The product lead answers: (1) what we planned to do for the sprint, (2) what we accomplished in the sprint, and (3) what we are going to do for the next sprint.
• Everyone in the team is required to give an insight on how the team could improve.
• Dependencies are also discussed.

Our own team’s solution was to have a weekly standup call and a daily standup through messaging. This normally happens in companies where everyone is physically together, but it is much more challenging across time zones.

There’s no one-size-fits-all prescription when it comes to remote work or management practices in general. So, prototype each operational method you wish to test, then assess your results afterwards. Once you find the ideal workflow, you can then build systems to streamline the process.

Bonus: Fifteen minutes before our calls, a bot usually privately messages everyone to type down the things they want to discuss. Because of that, everyone comes to the meeting prepared.

Do round-robin code reviews properly

One of our engineers kept deferring difficult tasks in favor of smaller and easier ones. We didn’t even notice because, every week, he would tell us, “I wasn’t able to do task A but worked on B, C, and D instead.” Next thing we knew, our project was three months off schedule.

Make sure code-checking applies to everyone, including the higher-ups. Everyone’s output needs to be validated by peers.

After the said developer left, we spoke to the other engineers who worked with him. They mentioned that they never said anything because they felt like their opinions didn’t really matter. Evaluating friends also felt like a personal attack with the way our meetings were set up. According to them, they would have told me if I had asked at all in private.

This seems like a dumb mistake, but it emphasizes the importance of building a system where everyone can give constructive feedback to each other. We should have implemented a code-checking rotation earlier than we did.

Choose the right KPIs to track

Schedule a “water-cooler chitchat”

Invest in physical workspaces

Initiate online team-building activities

Wrapping up