Remote work is not for every business and it may not be everyone’s cup of tea. When my co-founder and I decided to build a distributed engineering team for our startup, numerous questions raced through our minds: Will they be productive? How will decisions be made? How do we keep the culture alive?
Today, we manage a remote team of about a dozen engineers, and we’ve learned quite a bit along the way.
Here are some tips we hope you find effective. These are probably applicable to earlier-stage startups and less so for larger organizations.
Pair programming
In an office setting, employees have ample opportunities to interact with colleagues, and these conversations organically create a sense of authenticity. But in a remote work setting, there is no such privilege.
Some of our founder friends have used services to monitor or micromanage their employees during work hours, but we feel this is unproductive and antithetical to building a positive culture.
The introduction of pair programming, an agile software development technique where two engineers simultaneously work on the same issue, fosters collaboration and creates opportunities for developers to have conversations as they would in an office pantry. We try to pair two programmers for a sustained period of time (about 10 weeks) before considering a rotation or switch.
Some may argue that pair programming is a waste of time on the basis that if each individual can produce X output, then it makes sense to produce twice that output by having each of them work on separate problems.
We find this view limiting. Firstly, pair programming results in higher quality, since two brains are generally better than one. When engineering systems are incredibly complex, having a thoughtful “sanity checker” is almost always a good idea, as this prevents mediocre decisions and helps thwart downstream problems, which can be time-consuming to resolve in the future. In my experience, it also leads to faster problem resolutions. To elucidate this point, if problems can be solved in half the time, then in the same time frame, the output of two programmers working as a pair will still be 2x.
Moreover, this method of operation helps prevent a single point of failure. At early-stage startups, where teams are lean and execution speed is paramount, you do not want to risk a situation where the absence of a developer slows down progress, or even worse, causes a critical bug to linger in production. This system also fosters a sense of accountability and responsibility in the programming partners.
Manage, but do not micromanage
Working in an office helps employees establish a clear separation between work and their lives, but working remotely often blurs that line. Distractions are bound to rise when you’re working from home.
We tried to manage this without being overly controlling. Some of our founder friends have used services to monitor or micromanage their employees during work hours, but we feel this is unproductive and antithetical to building a positive culture. In our view, trust goes both ways, and trust is critical for a remote work culture to thrive. After all, people will always find ways to “game the system” if they want to.
We took a different approach by scheduling recurring, mandatory standups on Mondays, Wednesdays and Fridays. Monday morning meetings are the most extensive (i.e., usually takes an hour), because we share company-level announcements and provide project overviews. Wednesday meetings provide midweek updates and usually last around 15 minutes. We hold end-of-week meetings on Friday evenings so that the whole team has full visibility into each project’s progress. Other than these meetings, we keep our calendars free so that we can focus on work.
We also collectively agreed that all of us would be fully present from 9 a.m. to 12 p.m. everyday. Thereafter, we are more flexible, but we expect Slack messages to be replied to within an hour, that everyone be reachable if we call them and that we would work responsibly with our assigned partners.
Finally, we give each new engineer a one-off “$1,500 remote package.” They can spend it on anything, such as decorating their work station or purchasing noise-canceling headphones to be more productive at home.
Carrots and sticks
One question we had when we first started was: How do we build a high-performing remote engineering team that enjoys working here? We came to the conclusion that a combination of carrots and sticks would be necessary.
Most companies conduct quarterly reviews of their employees, but we chose to do monthly reviews just because we move faster as a startup. These reviews are based on the quality of the projects completed during the month, overall contribution to the team, as well as feedback from other team members, with programming partners’ inputs given greater weight.
The purpose of this monthly review is not to grade or score each engineer, or compare one employee with another. Rather, it is to identify the top performers and those that do not meet our expectations. Engineers that consistently outperform get quarterly bonuses as a recognition of their efforts and contributions. If someone’s performance continues to be poor, we reevaluate their suitability within the company.
We try to avoid letting employees go, but if we have to, we do so decisively and with empathy. Most importantly, we have a stringent recruitment process, which helps to prevent this situation from happening in the first place. For example, when we recruit, every potential hire will meet at least four members of the team throughout the interview process.