On Distributed Collaboration

18 Oct 2022

Background

Back in my early days of experiencing eXtreme Programming, I enjoyed the way our team at Cirrus Technologies would gather at the same time each morning for our daily stand-up ritual. Mind you, this was two decades ago. We were co-located, and our team did stand up, passing a “talking token” from person to person, around our circle.

As practitioners of XP, we observed what was proposed for stand-up meetings. In particular, we took notice that:

“Communication among the entire team is the purpose of the stand up meeting. A stand up meeting every morning is used to communicate problems, solutions, and promote team focus. Everyone stands up in a circle to avoid long discussions. It is more efficient to have one short meeting that every one is required to attend than many meetings with a few developers each.”

Fast forward to 2022, when many teams, including the one within which I work, are all working from home. In my team’s case, as well as us all working from home, we are split across three time zones. A few are in New Zealand, several are on the East coast of Australia, and one is in Perth. So, we are a long way from being co-located.

This presents challenges compared with the co-located morning stand-up of years gone by.

Collaboration in a distributed team

A team that is split across many different locations and several time zones presents challenges for collaboration in general.

Gone are the days when a team member could simply tap a colleague on the shoulder and ask for help, with this request naturally unfolding into a collaborative conversation.

In a distributed team, collaboration requires deliberate, conscious effort.

Personalities differ. Some folks are by nature more content to work independently, striving to solve problems on their own. Others crave connection. Whatever an individual’s preference, at some point collaboration of some form will be necessary, even if it is of an asynchronous form such as a review of a pull request.

Then again, arguably, collaboration should begin well before this during the evolution of a solution to a problem. Early feedback avoids time wasted going down paths that eventually prove to be unacceptable to peers.

Communication vs Collaboration

In a distributed team it can sometimes be challenging to promote sufficient communication, let alone collaboration. That begs the question, what’s the difference between communication and collaboration?

I like the way Rick Kick and Kennedy Collins express it in their recent article about lack of trust and collaboration slowing down product growth:

“Teams that meet regularly to discuss their work are communicating. Teams that openly seek and provide input while actively working are collaborating. Having regular status meetings where teams give updates on different components doesn’t mean a team is collaborative. Collaboration happens when teams actively try to understand each other and openly seek and provide input while working.”

When we focus on that definition in the context of a distributed team, it brings home the need to be very deliberate about collaborating. We need to reach out to each other. We need to actively try to understand each other. We need to openly seek and provide input from and to each other.

In a distributed team, that requires continued, deliberate effort.

Why Collaborate?

But why collaborate at all?

If you’re a member of a team, you’re going to be expected to collaborate at some point in order to have your work accepted. In the case of a solution expressed as code, there will most likely be an expectation that a colleague review your work before it is approved, and implemented.

So, at a minimum, there is likely to be an expectation to collaborate in order for your work to be accepted.

However, let’s consider the potential benefits of collaborating. By reaching out to colleagues, we may:

receive valuable early feedback about an intended approach to solving a problem;
gain valuable insights about system architecture;
understand how a colleague’s professional experience can help;
learn from a colleague who knows more about an area of technical expertise;
learn from a colleague who has greater domain knowledge

In doing so, we may also strengthen professional relationships within the team.

Connection

Whilst some humans are happy to live as hermits, most crave various degrees of connection. As members of distributed teams, we would be well advised to be mindful of this aspect.

Without the opportunities that present themselves in a physical office, we need to compensate. From time to time, hopefully we will have opportunities to meet face to face as a team. However, in our day to day, distributed work, we will need to be deliberate in creating opportunities to connect via the communication tools at our disposal.

I think that the challenge to create sufficient connection in a distributed team is vital. I hope to return to this theme in later posts.

References

This has been a short post in which I have shared a few thoughts about distributed collaboration. If you’re interested in this topic, you may like to delve into the following two books that I have, like many books, started but not finished reading:

From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver by Johanna Rothman and Mark Kilby
Effective Remote Work: For Yourself, Your Team, and Your Company by James Stanier

Conclusion

Remote work is here to stay. Collaboration remains important. Individuals and teams need to find ways to facilitate distributed collaboration.