Remote Team and remote way of working is today a common way of working, if not just the new normal way. But what is a remote team? And what does team work from home mean? Then, how to manage and lead remote teams leveraging the best practices with this new standard?
In thirty years’ time, as technology moves forward even further, people are going to look back and wonder why offices ever existed.
- Remote team is the new standard
- Team Topologies in a nutshell
- The Team API for Remote Team
- Good practices to deal with Remote Teams
- Inspiration from Remote Teams from of Open Source Software
- What’s next? Learn more about Team Topologies, Team Boundaries and Agile at Scale
- Do you want to learn more about Remote Teams? Here are some valuable references
Remote team is the new standard
As a matter of fact, new communication technologies have enabled a new way of working where remote collaboration is possible. To illustrate, people not only see each other in addition to hearing each other, but also can share and collaborate on a document or a digital whiteboard.
Nevertheless, not all the jobs fit for remote execution. Activities that require physical interactions like inventory management and shipping are definitively not candidates for remote working.
What is the definition of a remote team and a hybrid team?
A remote team is a collection of people working together and above all reporting to the same manager. In the Agile at Scale model described in this web site, it is a team working as a stable team on the same objective. Of course, as the name stresses it, in a remote team, people work from different locations, sometimes even in different countries. In addition, these locations can be offices or homes.
Teams working remote all the time is still marginal, but there is usually a part of the team that is not in the office and work from home. In this case, some people use specifically the expression hybrid team where a part of the team is in the main office and the rest of the team in other offices or working from home.
What is the difference between a remote team and a virtual team?
On the contrary to remote team, in the virtual team, people report to different managers, and they are assigned to the team on a temporary basis to achieve a short or medium term objective.
Remote team gains and losses
Remote team typical losses
Clearly, there are several elements that are highlighted as missing in remote work:
- Firstly, the level of interaction is lower than in office work. For instance, despite new communication technologies, you lose a part of the body language. Surely, there are situations that require sitting with your manager, managee or your colleagues in the same room. Either for crucial conversations or to reach optimal collaboration for complex and / or critical topics.
- Secondly, with remote working there is less imposed structure and process. Therefore, it requires more personal discipline and commitment to cope with day-to-day work.
- Thirdly, for some manager with old management thinking, remote work comes with a loss of control. Indeed, these kinds of managers consider that having someone under “direct supervision” means having them in line of sight literally. In other words, they think if they can see them, they can control them. Actually, the reality is quite different. Coming into the office does not guarantee productivity. To illustrate, it is not because people are in the office, they cannot surf the web all day long. Reinsuring this kind of manager can be done by starting small with remote work and demonstrate that the work is still done when working one day a week from home.
- At last, remote work may imply that people are not on the same time zone. This requires going from synchronous to asynchronous collaboration. In addition, it needs enforcing overlapping time period. At least 4 hours as proposed as guideline by David Heinemeier Hansson and Jason Fried in their book Remote.
Remote team typical gains
However, there are immediate gains with remote work:
- Firstly, working from home means no commuting. It is definitively saved time that means more time for personal and professional activities. Furthermore, it means less stress as commuting in packed common transportations or overloaded roads is a psychological, and even in some case, physical effort. Studies show a positive impact on health.
- Secondly, home work results in less interruptions. Really, creative and thoughtful works require long uninterrupted time period. As a result, people are more efficient with these activities.
A busy office is like a food processor—it chops your day into tiny bits.
Besides that, there are long term gains with remote work:
- To start with, home working makes it possible to reduce or even in some companies suppress the offices. For sure, that is the second expense after salaries.
- To continue, it is also an opportunity for companies to attract talents from all over the world. Not just the location close to the offices.
- At last, for employees, remote working gives new options where to live and access to locations with better quality of life and a lower cost of living.
Office work, remote work and boundaries
Truly, the physical office provides by default a structure that the teams inherit. In other words, boundaries coming with the way the physical space organizes. Really, boundaries are important for Teams to emerge and develops.
Boundaries are demarcation lines that differentiate a team from its environment and other teams. As a consequence, they enable this team to grow an identity, to concentrate on a focus and they protect this team from environmental interferences and disruptions. To go further, boundaries also impact tasks and behaviors reinforcing those that are aligned with the team’s values and standards and inhibiting those that are not.
Without a doubt, remote working makes boundaries inherited from physical space disappear. A real concern, all the more so, teams and their areas of focus, may be poorly defined from start. To put it differently, teams lose the palliative structure that physical office brings.
How to deal with that? This is the question that Matthew Skelton and Manuel Pais, authors of the reference book, Team Topologies, provide answers to, in their new book, Remote Team Interactions Workbook. As the authors elaborate on Team Topologies, let’s remind their model about the design of teams and team interactions, before exploring Remote Teams.
Team Topologies in a nutshell
The two pillars of Matthew Skelton’s and Manuel Pais’s model are the revers Conway’s Law and the Cognitive Load Theory.
The Conway’s law states that the system, in other words, the software architecture, results from the organization of the teams. On the contrary, the “inverse Conway maneuver” or “reverse Conway maneuver” starts with the organization of the teams to match the software architecture expected from the system. Clearly, this is more efficient than just relying upon teams to follow a mandated architecture design.
Cognitive Load Theory is the total amount of mental effort being used in the working memory. (quote from John Sweller, Educational psychologist from Australia)
As a result, teams, like human beings, have a limited cognitive capacity that you need to optimize. Therefore, teams’ cognitive load should focus on their core perimeters, and you should remove all other responsibilities and perimeters.
Taking into account these 2 pillars when designing teams result in creating small, independent teams with manageable scope of responsibility and knowledge.
Furthermore, the authors provide guidelines to define Teams and the way they interacts between each other.
The 4 types of teams in Team Topologies
– Stream-aligned team: a team aligned on a value chain such as a product or service, a user journey or a user persona. The result is empowerment to design, build and deliver value quickly, safely, and independently from other teams as far as possible
– Complicated-subsystem teams aligned on complicated subsystems to reduce the cognitive load of stream-aligned teams that include or use them.
– Enabling teams: try options and elaborate informed suggestions on relevant practices, frameworks and tooling to support the stream-aligned teams either on their functional and technical context. As a result, enabling teams make it possible for stream-aligned teams to acquire and evolve skills without having to invest the full effort.
– The platform team provides software as internal services to reduce the cognitive load of the stream-aligned teams. In other words, a platform team off-loads the lower level detailed knowledge, for instance provisioning, and deploying environment, and provides easy-to-consume services to stream-aligned teams.
The 3 types of collaboration in Team Topologies
– The collaboration interaction: relevant for exploration and innovation because it avoids costly and slowing hand-offs between teams. Then, it is is a good choice when exploring new technologies or techniques.
– The X-as-a-Service team interaction: useful where a team provides a service to another team like an API or a platform to be used with minimal effort and knowledge.
– The facilitating or coaching interaction: to reduce gaps in skills of the target team.
The Team API for Remote Team
The Team API is the core of the approach of the Remote Team Interactions Workbook to address Remote Teams. To clarify, the Team API Approach makes it possible to define and communicate the responsibilities and the Focus of Teams
Even if inspired from the technical API, this Team API is not just a code-level API. Really, it is the interface for human beings from a Team to interact with human beings from another team.
The team organization part
The first part of the Team API is for the Team itself. Truly, it helps the team clarify its purpose and how it fits into the organization. As a result, the Team API helps minimizing the cognitive load on the team and provides more processing capacity to focus on the core mission of the team.
The team interaction part
The second part of the Team API is for other teams interacting with the team. Nonetheless, smooth interactions with other teams will also benefit the team itself. Likewise, cognitive load is at stake as making access to information and the team as clear as possible, minimizes the cognitive load of other teams.
The Team API information in detail
The Team API structures over the following data to support other teams interact with the team:
- The information to identify the team:
- The Team name and its focus.
- The type of the team as described in Team Topologies (Stream-aligned team, Complicated-subsystem teams, Enabling teams and Platform team).
- The information about the means and the way of working of the team:
- The artifacts owned by the team (libraries, applications, services…).
- The wikis and the other documentations.
- The communication channels that we will develop further, with the team’s preference of channel depending on the use.
- The development process including the versioning and testing approaches.
- The information around the activity of the team:
- The roadmap and priorities of the team.
- The visual management of work and backlog.
- The governance of the team with its agile ceremonies.
- The other teams that the team is working with and why (Team Name / Interaction Mode / Purpose / Duration).
The Team API: zoom on the communication channels
Undoubtedly, the Team API describes in detail the communication channels of the team either internal or external. These communication channels should enforce product design understanding et discoverability principles to minimize effort from other teams.
Understanding: the meaning of the product with how to use the product and how to manage the product’s controls and settings to do so.
Discoverability: how easy it is to figure out what actions are possible with the Product and where, when and how to perform them.
The public channel of Remote Teams
Public channels enable people outside of a team to ask questions to the team rather than to individuals within the team. They helps reinforce team ownership and prevent people from reaching out directly to individuals.
Here are some examples of public team chat to illustrate:
#streamteam-green: the public channel for the stream-aligned team “Green”
#streamteam-blue: the public channel for the stream-aligned team “Blue”
#platformteam-data: the public channel for the platform team “Data”
#platformteam-infra: the public channel for the platform team “Infra”
The collaboration and support channels of Remote Teams
Furthermore, some examples of collaboration chat:
#enablingteam-k8s: the public channel for the enabling team “k8s”
#testautomation-facilitating-green: for communication between the test automation enabling team and the green stream-aligned team in the context of the facilitating interaction taking place
#facerecognition-collaboration-green: for communication between the face recognition enabling team and the green stream-aligned team in the context of the collaboration interaction taking place
At last, some examples for the specific case of support:
#support-environments: the support channel for environments
#support-logging: the support channel for logging
Other channels for Remote Teams
Other channels disconnected from teams may be created and normed regarding:
- Community channels to support exchanges within the community and enable external people to ask questions to the community.
- Topic channels, either short or long lived, focus on solving an issue and are archived once solved.
Sanity check of communication channels for Remote Teams
The authors propose also to perform a sanity check on a random 20-to-30-channel sample to review compliance of existing channels with these guidelines:
- Can you interpret the purpose of each channel?
- Could a new member of staff guess the purpose of the channels?
- Are the naming conventions the same all over the organization?
- How discoverable are the channels when someone has a given conversation to conduct?
The special case of Platform Teams
It is especially important to properly define The Team API of Platform Teams as by their mission, many teams are bound to interact with them.
Once again, as mentioned above, even if coming from the technical API, the Team API is more than a code-level API. Clearly, it is for human being to interact between teams.
In addition to the information described above, the Platform Team’s API usually covers:
- Operating hours
- A short description of the service(s) provided
- The documentation to use the service
- Typical response times
- And more detailed guidelines about preferred ways to contact the support team
A platform team may consider to design and conduct a Developer Experience Platform Survey based on main personas. Without a doubt, this kind of approach is especially valuable for platforms.
Good practices to deal with Remote Teams
Beyond the Team API, Matthew Skelton and Manuel Pais propose more good practices to deal with Remote Teams and remote work.
Scope of Remote Team
Team Topologies rely on Dunbar’s number to define optimal sizes of the teams, based on the required level of interaction and the need for trust.
Robin Dunbar is a British anthropologist who studied the link between primate brain size and average social group size. As a result, he proposed in the 1990s, numbers for size of social groups and for each the level of intimacy possible.
Truly, sizes of Agile Teams (7+/-2) and Tribes (around 150) directly come from Dunar’s works and other social studies.
Still because with remote work, boundaries fade, there is a need to take a special care with group sizes. In other words, manage online spaces the same way as physical spaces.
When the size of an online space reaches a trust boundary (such as 50 or 150 people), instead of adding more people to the same online space, create a new space. Each online space grouping should have people with a shared focus on a related flow of change.
At last, it is a good practice to conduct a sanity check on existing online spaces, to verify that their size is compliant with the expected level of collaboration and trust, and that no threshold is passed.
Dependencies between Remote Teams
Agile at Scale always comes with a special concern about dependencies. Before considering implementing synchronization mechanisms, it is smarter to first remove dependencies when possible. Do not scale if you don’t need!
So, when it comes to remote work, this good habit is even more important. First step is to identify the dependencies and make them visual with a good visual management. Then split them between dependencies that are manageable and those that are problematic. Surely, you should conduct additional effort to try to remove problematic dependencies.
A problematic dependency introduces significant delays, is too unpredictable, or increases work in progress (WIP) for the dependent team, slowing them down considerably. With remote work, it is impossible to simply walk up to the desk of someone on another team to ask about progress. Clearly, the result is a constant stream of chat messages asking for status updates becomes a cognitive burden.
Remote Team interactions
The trap of more collaboration
More collaboration is a typical palliative to ineffective organizations. In remote work, a good illustration is the use of indiscriminate broadcasting. As a result, not only people reach their cognitive overload zone, but they miss useful information for non relevant one. Really, in remote work, collaboration needs to be carefully trimmed for a more purposeful interaction between teams. Proof of this is the Team API that clarifies for a team, focus and interactions.
Overcommunicate just enough with Remote Teams
Nevertheless, the authors propose as a good practice to overcommunicate in a pull mode, so it is easy for interacting teams that look for information about other teams.
Overcommunication feels almost like an externalization of your key decisions and reasoning so that people can easily reconstruct the sequence of thoughts that led you to your current work.
Usual questions to clarify team’s context are:
- What you are working on
- Why you’re working on it
- How your work is being delivered
- When it should be completed
Illustrations of the team’s context are:
- Share small decisions in the public channel of the Remote Team
- Document large decisions
- Consolidate important concepts in a presentation. Actually, this can also be valuable for new joiners to the team as part of a welcome pack.
Sanity check of good team interactions
As a matter of fact, the quality of interaction for a given team with the others is a good indicator to identify needs for improvement.
For example, a platform team has produced a new service to help stream-aligned teams. If those stream-aligned teams struggle to understand the service or require a lot of help to use that service, then perhaps the service is a bit too complicated.
Routine and frame for Remote Teams
Remote is intangible
Remote work comes with intangible space but also intangible time. Likewise, some good practices are useful here:
- The first idea to structure time in remote work, is to set a routine so people can stick to it and emulate the rhythm of office work enforced with commuting.
- The second idea is to support a proper separation between personal and professional times.
Levers to manage the intangible in Remote Teams
You can achieve this with several levers:
- Dressing: separate the clothes you wear accordingly you’re in work or leisure mode. In addition, the type of cloth has an influence on your mindset: comfy sweatpants are perfect for physical comfort but may not turn you in a sharp state of mind for work.
- Space: dedicate a room for work or at least an isolated space for work, and make sure to work only when you’re in your dedicated home office.
- Hardware: either dedicate a computer for work and another for leisure. If not possible, at least split your work and home accounts for email and chat.
- Time: emulate your routine with dedicated time to work and personal matters with transition rituals. Start work with a morning coffee that you may share with coworkers. Market watch at the end of the day, as it is a kind of activity that is in between mandatory work activity and personal development. Furthermore, to support a routine, divide your work day into chunks like catch-up, collaboration and delivery work.
Agile to manage the intangible in Remote Teams
In addition to what the authors propose in Remote Team Interactions Workbook, Agile Ceremonies are a great way to provide a rhythm and enforce a systematic connection between team members. To illustrate, they provide a daily rhythm with the daily meeting usually opening the day.
Furthermore, they give a longer rhythm with the sprints of Scrum, typically between 2 and 3 weeks. A major event opens the sprint, the sprint planning and major events close the sprint, the sprint review and the retrospective. Actually, some companies used agile to support connection and coordination for teams partially offshored. To clarify, those are hybrid teams as defined above, with people split between a main office and an offshore office.
Remote Teams networking
A major concern with remote work is the decrease of human interactions, either in quantity, you see less your coworkers, and in quality, you miss a part of the non-verbal and informal communication.
Matthew Skelton and Manuel Pais consolidate many of the good practices to emulate networking in a remote work context.
Emulate office networking moments
When at the office, you do not meet and chat with people when in meetings. There are plenty of other opportunities to bond with coworkers and like at the coffee machine, by the water cooler or during the lunch.
Those moments are important and create a different kind of connection between people than work meetings:
- Firstly, they build and foster informal networks between people that will help collaboration and smooth interactions at the good time.
- Secondly, they enable trust to emerge between the participants.
- At last, they help create an awareness of what else is happening outside the team. A good way to enforce cross team collaboration out of day-to-day work are the communities of practice where people capture and share best practices on their area of expertise.
Organize collective remote events
Formal events can also support remote team building and networking. Nevertheless, it is important to adapt the format and keep in mind some good practices in remote configuration:
- Use familiar tools so you don’t add unnecessary cognitive load.
- Keep it shorter and sharper as it’s more difficult to keep people’s attention remotely.
- Create on the side, a virtual space for hanging out and for interactions beyond teams.
- Include participants proactively and seek for interactions. For instance, ask explicitly for people to turn on their cameras and react to live shared information with thumbs or other emoticons.
Organize collective physical events
In their book Remote, David Heinemeier Hansson and Jason Fried, complement that there is a need to meet physically at least twice a year for four to five days. In their case, as they have no office, they pick a location and all coworkers meet there.
Those exceptional encounters are about special topics and to take a step back. To illustrate, the typical subjects are presentation of the latest projects and brainstorming about the future of the department or even the company.
Surely, bonding and team building is deeper in this configuration. You really fully embrace the personalities of your coworkers sharing meals and laughs. Clearly all coworkers will bring with them the memories of those shared moments that will complement the digital interactions when back to remote work. But as memories fade with time, there is a need for a regular refresh, even for long known coworkers.
Socialize chat for Remote Teams
We all need mindless breaks, and it is better if you can spend some of them bonding with your team. In other words, it is a kind of virtual water cooler or coffee machine.
The idea is to have a permanent chat room where all team members hang all day long to share jokes, funny thought, pictures or videos. Yet, people can ask questions about work, but its primary purpose is to provide social cohesion.
The good thing about a chat room is that it doesn’t need a constant attention. Indeed, people can check in and check out during the day as they want and depending of their work constraints.
Client relationship in remote work
In their book Remote, David Heinemeier Hansson, Jason Fried, provide pieces of advice in remote work related to client management:
- Firstly, from start be transparent to your prospective clients and let them know that you work remotely. Surely, for this early step, you want to share references of your past clients to comfort them that it is a safe for their project.
- Secondly, during the project itself:
- Be proactive and show them work often, as it is the best approach to address their natural anxiety about this situation new to them.
- In addition, be very available to compensate the distance: return faster than the usual office standard, calls, emails and instant messages.
- At last, involve your client first in the follow-up, second in the collaboration around the project. As soon as they feel part of the project, excitement and anticipation replace anxiety and fear. To support that, leverage digital collaborative tools with shared schedule, chat, task management and document repository.
Tips and tricks about remote work
Let’s finish with a bunch of tips and tricks to enhance remote work, still coming from the book remote:
- Overlap hours: if part of the work can be done asynchronously, there is still the need for synchronous interactions. This requires, for people in different time zone, to enforce overlap in working hours. The guideline the authors propose is an overlap of 4 hours.
- Open resources and information: make everything available to everybody, all the time.
- Plan meeting sparingly: but this is true in physical office too!
- Manage by objectives: no task management.
Meetings should be like salt—sprinkled carefully to enhance a dish, not poured recklessly over every forkful.
Inspiration from Remote Teams from of Open Source Software
To complete this post, let’s wrap up with the example of the Remote Teams in the world of Open Source Software. It is a long lived and proven model that demonstrates that efficient remote work is possible.
David Heinemeier Hansson and Jason Fried, highlight 3 main characteristics that explain the success of this kind of communities:
- Intrinsic motivation: members of open source communities work by passion and because they feel part of a purpose. Undoubtedly, when people work on topics they are personally interested, they do not need a manager overlooking them.
- All is open: self-organization requires people to have the whole picture, and for each topic, the information with the context. Not only, this is true for people involved in a given topic, for them to take the good decisions. But also, when participants want to identify a topic where their skills can be relevant.
- Meeting occasionally: most successful open source projects can eventually support their own meeting events. As seen above, this is a valuable opportunity for members to bond in person and build a stronger relationship than online interactions.
What’s next? Learn more about Team Topologies, Team Boundaries and Agile at Scale
- Check my other post about Team Topologies where many of the concept of this post are developed.
- Review my other article about the Team Boundaries and how they make possible for groups to become teams.
- Discover more about Agile and Agile at Scale.
Do you want to learn more about Remote Teams? Here are some valuable references
References from Matthew Skelton and Manuel Pais the authors of Remote Team Interactions Workbook:
- The book Remote Team Interactions Workbook.
- The page of the website of the authors about Remote Teams.
The reference book Remote: Office Not Required from David Heinemeier Hansson and Jason Fried
Some other articles about Remote Teams: