Software development teams who strengthen their work processes to enable remote developers offer their companies distinct advantages:
- New recruitment is focused on talent and fit, rather than an applicant’s geography.
- Leads can build teams more quickly.
- Onboarding team members is faster and more efficient, as a result of shifting from centralized dependencies to a de-centralized structured process.
- Executives gain the flexibility to utilize outsourced contractors, local or offshore, because there’s considerably less disruption to the team.
- As a result, products get launched faster
Companies such as Automattic, makers of WordPress, Zapier, Basecamp, Help Scout, WooThemes, GitHub, Treehouse, to name a few, have written extensively about their remote teams, some with a central office, others without. Software engineering being highly structured with patterns, practices, and mature processes is well suited for distributed work.
Co-located teams, where all members work from one office, need not pursue the fully distributed model. They can reap the same benefits by enabling remote engineers to be effective, along-side their co-located team. If teams are well versed in Scrum or have well defined processes, the transition is minimal. In cases where teams are less mature in software processes, some training is useful to help teams better structure their work. Here we are referring to standard Agile Scrum practices, for example. The overall effect of strengthening process is a higher performing team, whether they are co-located or mixed with remote members.
Engineering teams I’ve worked with who have matured their processes, have improved their products, increased quality, evolved their architecture, and are making better decisions. Collaboration and decision-making improves, since teammates are more aware of what each is working on and can better participate in solving complex issues – the team no longer pushes the issue to “the only guy who understands it”.
We all know there’s real overhead in on-boarding and departing developers. In a co-located team it can take 2 to 6 months for a new member to become efficient. During this ramp-up, he gains knowledge mainly through examining the code and questioning his teammates. Yet when a team is skilled in working with remote members, it learns to develop repositories of conversations, requirements, business logic, and even designed software to be more easily understandable – because their peers need to understand it with less communication. There’s a fundamental peer incentive to depart from old practices of keeping knowledge locked up, to distributing knowledge and communicating more effectively.
The median tenure among even the most attractive tech companies such as Google and Amazon is 1.1 years. These numbers underscore the need to shorten on-boarding, distribute knowledge, and train in engineering practices that are more resilient to changing team members.