Working remotely is not for any 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, countless questions ran through our minds: Will they be productive? How will decisions be made? How do we keep the culture alive?
Today, we lead an outside team of about a dozen engineers, and we’ve learned a lot along the way.
Here are some tips that we hope you find effective. These are likely to apply to earlier stage startups and less so to larger organizations.
Pair programming
In an office environment, employees have ample opportunities to interact with colleagues, and these conversations organically create a sense of authenticity. But in a remote work environment there is no such privilege.
Some of our founder friends have used services to monitor or micromanage their employees during work hours, but we believe this is unproductive and contradicts building a positive culture.
The introduction of pair programming, an agile software development technique where two engineers work on the same problem at the same time, promotes collaboration and creates opportunities for developers to have conversations as they would in an office pantry. We try to pair two programmers for a longer period of time (about 10 weeks) before considering a rotation or transfer.
Some might argue that pair programming is a waste of time because if each individual can produce X output, it makes sense to produce twice that output by having each of them work on separate problems.
We find this view limiting. First, pair programming results in higher quality, because two brains are generally better than one. When engineering systems are incredibly complex, it’s almost always a good idea to have a thoughtful “sanity checker” in place, 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 troubleshooting. To clarify 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.
