I’ve been managing a fully remote, fully distributed team, covering timezones from UTC-8 through UTC+10, for the last couple of years. Through that time, I’ve learned a lot on organising work, interpersonal relationships, and ultimately how to overcome a lack of promximity to my reports.

Undercommunication Will Destroy You

Shortly after I met my partner, circumstances required us to maintain a long distance relationship between London, UK and sunny California, USA - a time difference of 8 hours. As my day finished, her day was just beginning, requiring us to be deliberate about maximising the time we could spend with each other during our waking hours, and figuring out ways for us to communicate effectively when we didn’t cross over - voice notes, letters, email and so on. Leaving little things for her to wake up to.

Operating a remote team is a lot like that! Especially with the time zone differences I’ve had to overcome. There are a few key tenets, including using the tools for a culture of writing.

There Is No Communication Like Overcommunication

The old adage is to say something several times before it is truly heard, and the goes doubly for remote teams. Say something in a meeting? That meeting better be recorded, transcribed, summarised (see bottom line, up front) and the key points posted in your collaboration tool of choice. LLM-based tools can help a lot with this, but it is still your responsibility to ensure the summary is accurate and useful - I personally prefer to write my executive summaries by hand.

Why do this? Team members may be unable to make a given meeting, either temporarily or permanently, but no one should ever be out of the loop. Some folks may consider holding “off the record” meetings where no recording takes place - in those cases, take notes, respecting the speaker(s) by following the Chatham House Rule and/or being judicious about omitting information from notes, but share it with team members who could not make it verbally. Don’t let information fall into a hole.

As a result of the timezone disparities, the team has opted for a written-first, asynchronous-first approach to information sharing. Daily standups are written, most projects are driven through task trackers, documents and IM, with sparing use of synchronous meetings - usually for our retrospectives and weekly team meetings to ensure we have some regular face time.

On that note, we strive to have regular in-person off-sites. These are partially structured, to allow for high value synchronous collaboration, but also leave some unstructured time to allow the team to “be people” together.

The Team Is The Unit Of Delivery

I think I first heard this term back in 2014, maybe 2015? It comes from the UK’s Government Digital Service, and has been the way I feel about teams ever since.

What does this mean? Through individual performance and collaboration, we deliver value to our customers. “The team” transcends my reports into our wider organisation and the cross-functional relationships we build.

What About The Individual?

This is not to say I don’t value the individual - we must recognise that the team is successful because of individual skillsets and ability, and that we cover each other’s bases. Shipping a product as complex as ours is simply not possible by an individual. I generally recommend that my staff maintain a brag doc, and I track their individual contributions within the context of providing feedback and performance management.

Performance management aside, I try and avoid focusing on “individual” failures - we succeed and fail as one unit.

Session Musicians, Not Rockstars

Assembling a team that can function as one unit and be healthy is tricky, especially in a remote environment - there can be interactions that you are not privy to via DMs, private channels and so on. As a result, there must be a high level of trust between each team member, as well as the staff and the management layer. It is a lot like constructing a high performing sports team, and the relationship between the front office and the back office.

I’m often heard saying that I’ve learned more from the great sports coaches of our time (Phil Jackson, Nick Saban, Pep Guardiola) than most management trainings and material, and part of this is construction of a strong team. I don’t enjoy managing egos, so intentionally select for folks who display high levels of coachability and curiosity with the right amount of appropriate professional drive.

As an example of this practice, consider session musicians - consummate professionals quitely behind some of the most influential music produced in the 20th and 21st centuries. A great example of this were the Swampers, with Rick Hall conjouring a kind of magic rarely seen before or since.

Sure, rockstars are great for the spark of inguinity and allowing lightning to strike, but software engineering is a long game, and niche of managed database services and database service reliability engineering even more so. I need the longevity of a good session group.

Work Is Fungible, Team Members Are Not

Along the lines of longevity, one of the more painful lessons learned is that work is fungible, team members are not.

In short, teams can learn (as a function of time and funding) pretty much anything you need them to, so moving work to different teams is “free”. However, breaking that team up to align closer to the work is extremely expensive.

The thesis is that, as a team is one unit, breaking that unit creates a new team. Think of a team as a graph of nodes and edges - when you pop a node from the graph, the graph has changed. Adding a new node or nodes to the graph? A new graph.

Thinking this through even more, a software engineering team is generally in a metastable state. There is probably a theoretic stable state of extremely strong bonds between individuals, but in real life this is rarely, if ever, achieved - even the very long term session groups or sports teams eventually break up due to internal or external forces.

We want to maximise the stability of the team, and to do that, we bring the work to the team, rather than take the team members to the work. As an example, a team that ostensibly works on an integration product picked up work to enable billing for new regions. The originally proposed option was to “air drop” members from that team into the billing the team, but doing so would have unacceptably disrupted the effectiveness of the original team. Moving the work has much lower cost.

The PR Machine

Last but not least, one of the key lessons I’ve learned in remote leadership has been that as all interactions are intentional, you have to be the PR machine for your team. This loops back around to overcommunication - if a major project is shipped and no one hears about it, did it even happen?

Your job is to take your team’s accolades and broadcast them wide and far. Have your team be known as one that Gets Stuff Done. Have your team be known as one that is a benchmark for quality and reliability.

A lot of this work is a continuation of generating artefacts for your teams work, and using those artefacts as part of your PR campaign towards other teams and upper leadership. This is not entirely altruistic - a successful, high profile team reflects well on you as a manager, furthering your career.

A previous version of this article used an AI-generated header image. This has been replaced with something hand drawn.