Congratulations! You’re On A Remote Team–Now What?

March 19, 2020
John Janek

Amidst the angst of global pandemic playing out like a game of the same name, you have found yourself either part of, leading, or coordinating remote teams. This isn’t for the faint of heart; it may feel like a management crucible. The reality is simply a challenge in facilitation and management. With some thoughtful approaches it is easy to succeed and excel in a remote-first or remote-only environment.

There is one reality of remote work that is useful to surface: remote work will make the things that work in current teams obvious, and it will make things that don’t work in current teams obvious as well. Keep this in mind for when pain points are discovered. These exist in your team regardless of interaction medium, they are simply more obvious in a remote environment.

It is worth noting that these observations are shared from a perspective of over twenty years of working with remote and co-located teams. Our teams at Dev Technology Group have been working in co-located and remote capacities for years, and this week we have transitioned to 100% remote work. All this time going back and forth between teams and working in hybrid environments has highlighted two critical things teams should be focused on now:  People First and Transparent Process.

People First, Process Via Discovery

You may have heard the whole People, Process, Technology discussion at one point or another. It is always important to remember that in any work, people are always the first and last stop. Everything else is just something to help that interaction. People First may sound a bit trite, and even a bit overused. In this context, it means something specific: from happiness to psychological safety to alignment, teams that put people first perform better.


The first lesson in putting people first is embracing communication. Ask this question: how do we communicate when we are together? And then ask this question: how do we create the same types of interaction in a remote setting? There is a fine balance between too little communication and productivity-sapping over-communication that comes across as micromanagement.

The team, together, should document responses based on type of communication how they perceived it in an office environment, and how they might replicate it in a remote work environment. Those communications types are collisionable, informal, delivery, and planningThese are largely tasks–activities that are executed through the day.  They differ from interactions, described below.

Sample matrix to capture communication sustainment:

Type of Communication How do we describe it now? How do we sustain it?

Collisionable communication is the most difficult to replicate in remote environments. It isn’t because of the nature of the environment–collisionable communication is hard to achieve even in physical design. This type of communication is random interaction–the ability to spontaneously trigger new ideas, concepts, or approaches because people are in the right place at the right time. It is essentially the venture capital of communication; a lot of little interactions in the hopes of hitting on a big idea. From lolcatz to gamer talk, collisionable communication is critical to human social constructs.

Informal communication, while highly aligned to the idea of collisionable interaction, is more aligned to specific delivery functions. Stopping by a coworker’s desk to talk through a new process; asking for assistance on how to approach a specific problem; or jotting down some notes on how to remove a blocker. These are all informal. They represent critical interactions that are typically not captured in either delivery or planning.

Delivery communication is purposefully used to describe the type of communication that involves a final product. Sometimes this is a very formal act, and sometimes this is the conclusion of a series of informal communication processes. Delivery communication is especially dependent on external processes. Teams will learn about their dependency on other teams, information sources, and access to delivery points. Whether it is a memo, a report, presentation, or even a website, delivery communication is how the work gets done.

Finally, there’s planning communication. Ever seen the meme “This could have been an email”? That’s a great example of planning communication.  Knowledge workers spend a lot of time planning. In fact, one of the more insightful reveals of this exercise is unraveling how much communication (and relative time) teams spend planning verses delivering. Meetings, planning boards, and scrums–they are all a form of planning.

Get the team to fill the above matrix out collaboratively.  Use it as an opportunity to learn some of the remote toolkit. Most importantly, iterate on this matrix. It is a living document and will continue to evolve over time.


Just because the team is now remote doesn’t mean that feelings get left behind. Emotional Intelligence plays an outsized role in remote team environments due to the lack of in-person contact. Implementing a good care plan is critical to a successful remote team. When thinking about the care plan, it is possible to follow the same construct as the matrix above, considering the type of interaction, the way the interaction is carried out today, and the way the interaction should be sustained in a remote working environment. Interactions can be simplified to social, reactive, and proactive.

Sample matrix to capture interaction sustainment:

Type of Interaction How do we describe it now? How do we sustain it?

Social interactions are the most challenging to replace, because they are highly complex. Remote work simplifies social interactions down to text at worse, voice and video at best. Technology can create barriers to entry and the better the simulation, the more likely to enter the uncanny valley.  Social interactions, even more so than collisionable communication, is a necessary component to a successful remote team. Teams need mechanisms to be human and also need to be prepared for the inevitable pain points that will come with the sustainment of those interactions. Remember, remote teams make strengths and weaknesses more evident.

Reactive interactions are those times when the team is responding to an external stimulus. It is intentionally broad because whether it is a feedback cycle or a delivery request the interaction will intersect with the people very similarly. This will become a discussion about information flow. Remote teams introduce a lot of methods of moving information, which external participants will have varying methods of interacting with. Taking the time to think through what that interaction looks like will help remote teams understand and create constructs for adapting to information delivered in a remote context.

Proactive interactions are simply where the team wishes to affect some other delivery communication or impact a planning communication activity. How does the team actively reach out to others?  Is it consistent?  Is it planned?  These types of interactions are fundamentally different from reactive interactions.

As a team exercise, walking through this process of discussing what the team communicates and the interactions in which they communicate will reveal a tremendous amount of insight into the work processes of the team. It will make picking remote tooling easier, as well as rationalizing existing or new tools. Most importantly, it will document the expectation. Managers and supervisors themselves might find some interesting discrepancies between what is perceived in the team and what is being done, or what management thought is being done.

Transparent Processes

The final outputs from the effort should be a series of lists for each type of communication or interaction.  As teams reflect on these generative lists, there should be some insights into that arise. As a follow-on activity, try to connect the communications and interactions by collection with the types of outcomes. With any luck one of two things will happen:

1) The team will have some clearly documented lines of effort.

2) Some processes that should have been accounted for will show up as orphaned processes, or new processes will pop up.

Technology Rationalization

Teams can now look at these collections to start driving conversations around how they align to the facilitating tools. Look at the processes and the outcomes that the team is trying to generate, and then start to align the available tools to those lists. Ideally, each process should have some set of facilitating tools and provide discrete capacity to facilitate the outcome.

As the lists of processes, outcomes, and facilitating tools come together, there will be an opportunity for rationalization. When teams review these lists, it may become obvious that multiple organizational tools can support a process. Ask the question: do the tools have a specific need? Is it a capability that is an exact match for the process and outcome, and if so, are there other organizational tools which may meet that need specifically?

The full process of rationalization is multi-faceted and often used as a cost control. That’s beyond the scope of this discussion and not the purpose in this context. Rather, rationalization should be designed to collaborate around what tools are being used to facilitate processes and help drive outcomes, and where multiple tools are being used either make it obvious and transparent or as a team consolidate the tool suite. Focusing on People First is always a winning approach. Teams can add value to the discovery of their communication types and interactions by aligning those lists to process and outcomes.

Finally, looking at the list of available tools and how they interact to drive the desired outcomes creates an end-to-end look of what is done in a co-located environment and what should be done to sustain the work in a remote environment. Remote teams can and do excel–and how they do that is largely dependent on ensuring the people on the team clearly understand those process and technology components.


John Janek

Chief Technologist

Dev Technology