Beyond Code: The Human Element Driving High-Performing Remote Teams

Many startups may be short on cash but want to get their job done. Instead of hiring developers on payroll or outsourcing to big IT companies, they prefer freelancers.

So as a startup founder, you go on a marketplace, find a few efficient freelancers from different parts of the world and ask them to work as a team. The problem is that this group of individuals is  far from being a team. Each freelancer is focused on delivering a portion of the work and is not concerned with the finished whole.

Such teams need at least one or more people to act as a glue that binds them together. 

Forces

Let’s take a look at the reasons why it doesn’t work:

• If team members are paid separately, they are competing for a scarce budget.

• If a team is not co-located, team members are competing for airtime with the client.

• Team members with great communication skills will likely push out high performers with limited communication skills.

• People may be great developers but that doesn't necessarily mean that they are good at connecting with people.

Solution

To solve the problem, one may get tempted to come out with a recipe (list of steps) to make it happen. Here’s an example recipe:

• Someone who acts as a glue, interacts with the team-members using one-on-one conversations in order to understand who they are, based on their likes-dislikes, contexts, cultures, festivals, families etc.

• With these individual interactions, she starts building the trust.

• Identify common issues and discuss with team-members on how to deal with them as a team and make a connection between them. 

• Along with all above mentioned steps, ensure a team structure so that team-members work together on vertical functional slices rather than working with other team-members around their specialization only.

This sounds like a good plan. In practice though, one sees constant conflict between having to get fast results to celebrate versus making time to connect with all team members. 

As a result, it’s a constant balancing act.

The chances of failure are high in the recipe (structured) approach. Instead, it's important to have a bit of chaos (entropy) and ensure people feel empowered to do the right thing at the right time. Also, it helps a lot if there is more than one person in the group who acts as the glue, who can understand how important it is to have a smooth working process as a team.

At the outset, having a glue in a new remote team translates into clearly defined advantages. In practice it’s not that straightforward. Somebody needs to pay for this person in a team with the skills that do not directly contribute to the sprint goals.

Implementation

Ideally, each team member should have the skills to connect with the rest of the team. However, this is often not the case. When these skills are lacking, a ‘Glue’—one or more people—needs to step in to start bringing the team together.

This can be achieved in various ways, such as finding common interests among team members, like music, poetry, cooking, art, etc. Often, these shared interests have nothing to do with software development. Eventually, a ‘glue joint’ is formed, helping the team to work more effectively together.

The Relevance of the Glue in Context of Efficiency and Money Involved

Though the ‘Glue’ is important for building the team, the question remains: In the context of balancing team efficiency and costs, what is the practical relevance of the Glue?

We believe the Glue is the team! Ideally, each team member should embody a part of the Glue, and if that’s lacking, it can be taught by adding someone who knows how to be the Glue as a coach. The best way to coach is by being a team member—that’s how you earn trust. If someone is brought in solely to make the team work cohesively, they should be capable of fulfilling that role.

However, in cases where a person works specifically as the Glue, you might encounter situations where the customer says, “We really value what you’re doing and can see its necessity. But it’s becoming too expensive this way. Please step aside.”

Ideally, the ability to be the Glue should be a role and skill that team members can take on, working together to create a cohesive team.

This work, however, requires time, and it’s important to set the right expectations with the client. Beyond working efficiently as team members, it’s essential to dedicate time to building the team.

Example

Squads is an organization where every individual works from a different location, geography, country, and time-zones. 

Essentially, nobody works from the same location. Team-members working in Squads are located across 15-20 different time-zones.

Creating a team for every new project is expensive both from time and money perspectives, that’s why Squads focuses on having long running teams only. It means,  irrespective of the incoming work, the team remains the same. Currently, there are around 60 different teams working for various startups.

Let’s take a look at scenarios when a Glue is required in the team:

• Sometimes, there are cases in which some individuals have to work with the customer's developers. 

• Any long-running team before becoming long-running one must have started from somewhere. In such cases, there are vulnerabilities in the team. To handle such cases, it's important to look at them as a pitfall and see the mitigations.

Pitfall 1: Partial Collocation

In experience at Squads, partial collocation almost always fails. Partial collocation is where two or more developers work together from one location while the rest work from different locations. 

In these cases, the collocated team members will communicate through offline (face-to-face) means. So they will run ahead of the rest of the team. As a result, the remote parts of the team start to feel slow and ineffective in comparison. 

The remote team members’ disadvantages in communication channels gets amplified by this partial collocation, often to the point where the team becomes dysfunctional.

This pitfall is often worsened by the fact that the colocated part of the team is in the same place  with the client. That way, the collocated sub-team can groupthink with the client towards a sentiment against remote work.

To mitigate this pitfall, we distribute the collocated parts of teams. This means, for example, the naturally collocated team members start to work from different floors in the same building. Once the collocated team members become more empathic of their remote peers, things usually work better.

Pitfall 2: Specialist Teams instead of Cross-Functional Teams

In cases where backend, frontend, and designer work as separate teams, during instances of problems, there is almost always finger pointing which causes a ‘we vs they' thought process. The front-end team says it's a designer problem, the designer says it's a backend problem and backend says it's both designer and front-end problem. 

To mitigate that, the Glue recommends developers to pair across the bubble and always resist clients pushing in the direction of building “specialist only” teams.