3 tips for managing a remote engineering team
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.
