According to Forbes Magazine, by the year 2020, almost 50% of people will work remotely. Whilst 2020 has arrived, and many of us suddenly find ourselves face-to-face with what six months ago we would have assumed to be an extreme outcome. Help seems to be at hand - a quick internet search will reveal that there are a myriad of books, blogs, articles and courses offering advice about how to work remotely with others. But despite this, many teams are right now struggling with the reality and productivity of remote working.
The author of this article, has worked in a remote, globally distributed team for more than 5 years now, we cover more than 17 time zones and we consistently deliver, support and run high quality software and we have some suggestions which might help.
One observation we make is that teams compensate for remoteness by attempting to replicate working like a co-located team. We suggest that this is a mistake, and that rather than compensating for remoteness, you should instead embrace it, and refrain from trying to work like a co-located team.
But how? We propose that the idea of design patterns may offer a solution.
The following is a behavioural pattern for building a successful remote-first team, as described by Martin Fowler in his article, Remote versus Co-Located Work. It is inspired by several classic GoF Design Patterns, The Mediator, The Decorator, The Chain of Responsibility, The Observer, The Strategy Pattern and The Adaptor Pattern.
The goal of documenting the pattern is to provide a set of repeatable techniques which can be used to build a high performing remote-first product team. These help take advantage of the many benefits arising from remote work, whilst attempting to correct for some of the possible disadvantages. This pattern introduces some restrictions on hiring, but team productivity independent of location is a key benefit.
Techniques
The Mediator Pattern
The Mediator Pattern is intended to address problems associated with tight coupling between objects as this causes dependencies. This is also a problem in a remote team, particularly where the team is spread across multiple time zones.
Based on the thinking behind the Mediator Pattern, we offer the Baton Relay - this is a technique which deliberately builds a team where every member is remote, and each is located in a time zone which provides reasonable crossover with most other team members. Careful selection of time zones can mean that a team is available 24 hours a day all within standard working hours. Ideally, there should be a remote pair in each time zone. This results in loose coupling between team members. Each person can happily work alone most of the time but is not completely disconnected.
The Mediator Pattern also proposes that it should be possible to change the interaction between a set of objects independently. A requirement supported by another important technique.
'Crossing the t’s and dotting the i’s' requires every team member to be able to pair on a wide range of tasks with any other team member. Careful selection of location supports this, as does ensuring that the team is broadly cross-functional.
One significant benefit of the two patterns described above, is that it also bakes in resilience. If something happens in one location and which impacts availability or productivity, team members in other unaffected regions are potentially unaffected.
The Decorator Pattern
The Decorator Pattern proposes that responsibilities should be added to and removed from an object dynamically at runtime.
The Chain-of-Responsibility
The Chain-of-Responsibility pattern proposes that coupling between the sender and receiver of a request should be avoided. These patterns also underlie the 'crossing the t’s and dotting the i’s' technique.
Dynamic Convergence
Dynamic Convergence is a technique supported by the Strategy Pattern, which enables the selection of an algorithm from a family of algorithms at runtime. This technique proposes that a team, as well as being broadly cross-functional, should have (more than just one) individual members who have specialist skills in one or more key domains, meaning that a great deal of the work is not dependent on a given individual. Being able to pair flexibly is important and each team member should also ensure they regularly pair with every other team member. This reduces business risk, and promotes collaboration, connectedness, knowledge sharing and a culture of shared ownership of a product or service.
Anchoring
Anchoring is a technique inspired by the Adaptor Pattern, which allows incompatible interfaces to work together. The technique states that every team member should see themselves as 'an anchorperson', whose role is to support and coordinate the sharing of information between other team members across time zones. This is an idea supported by the practice of Working Out Loud by John Stepper.
Ways of working and tool selection (or not)
A remote-first team is compelled to be heavily reliant on online tools in order to share their work, however, they should not be reliant on synchronous communication. Synchronous methods such as always on video connections may work for some teams, but they are not essential. In some circumstances, they may neutralise some of the advantages of remote work for some people. Video conferencing technology is improving, but variable bandwidth continues to be a significant challenge. Video conferencing can be physically and psychologically demanding and running large or long meetings is often a sub-optimal experience.
Using video conferencing as part of a larger toolkit, but preferring asynchronous means of communication such as online chat and shared documents, file storage and collaborative online workspaces, should be as important. Other techniques include creating multiple chat rooms for different focuses such as social conversation as well as a general team chat. Having a chat room into which such things as service alerts and card wall updates are piped, allows someone to catch up quickly with how a piece of work has progressed.
Working in fixed length iterations is challenging for teams whose working weeks do not coincide, equally, points based estimation is difficult, especially for a product team where the 'crossing the t’s and dotting the i's' technique is in use. This is particularly true where the product is required to have a high level of availability. For these teams, a kanban-like continuous flow approach, which does not separate delivering new functionality and service support, gives better results. With experience, a long-lived team's ability to estimate their ability to deliver new functionality improves, especially if tasks are sliced as small as possible.
In summary
The remote-first pattern has been developed over almost 5 years by a long-lived product team whose members are distributed across 17 time zones. The techniques and approach to tooling and ways of working described in this document have been identified as a result of a great deal of trial and error, but have contributed to the growth and ongoing success of the team.
Questions still remain about how well the model will scale, currently, the team’s size is eight, with two time-zone co-located pairs and four individuals without a pair. The pattern dictates that a pair should be found for the lone individual before additional time zones are considered.
Another challenge is that team members need a certain level of seniority and experience to successfully use this pattern. This makes it more difficult to do succession planning and grow graduate or less experienced individuals.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
