The Distributed Teams X-Factor

Distributed Teams X-Factor
Over the last several years, I've had the opportunity to be a part of 4+ distributed teams and have experienced a variety of different styles. I've also been in various roles on distributed teams, ranging from front-line employee, to manager, to a co-founder. Additionally, I've worked on distributed teams before product-market fit and after product-market fit ranging from pre-revenue to ~$80m ARR. Some approaches worked, others failed.

I've had the chance to collect quite a few data points over the years about how effective distributed teams are run and pitfalls that should be avoided.

I recently read this article by Tomasz Tunguz and it prompted a bit of reflection. I thought it would be useful to outline a few additional thoughts and learnings based on my own personal experience.

The Discipline of Distributed Teams

The article listed above appears to have been prompted by an insightful quote from the CEO of Gitlab in the following video:

"Remote forces you to do the things you should be doing anyway earlier and better"

This is a great observation and mirrors my own experience. Distributed companies are thoughtful about creating discipline around the key foundational elements of the business. This ranges from behavioral expectations, to company culture, to communication habits like CEO updates, 1-1s, etc.

In the article, Tomasz correctly outlines the factors that drive distributed teams to establish routine in the early days. Unlike co-located teams who craft an informal "structure" of doing things, remote teams must articulate this and create process from the early days.

At its core, this is fundamentally a different way to mold and shape a company culture. Co-located teams feel this pain when they scale, but distributed teams experience it much earlier.

I have a few additional thoughts I'd like to share, but first, let's talk about culture.

But first, what is culture?

First, we need a useful way to think about an abstract concept known as "company culture."

While I don't typically recommend HR books, but I first came across the three levels of organizational culture in Edgar Schein's book, Organizational Culture & Leadership. Accordingly to Schein, an organizational culture has three levels:

1.) Artifacts

Artifacts are what you see and observe at the surface. Imagine your first day of work at a new job - what behavior exists? Some of it may seem strange because you don't have context. As a distributed team, it might be something like watching conversations in Slack, or the use of emojis.

2.) Beliefs & Values

Believes and values are further down the stack and reflect someone's sense of what should be vs. the current state. These beliefs and values undergird decision-making and other key aspects of the business.

Some companies will create slide-decks where they outline their company values as a way to "glue" the organization together. Many organizations will hire based on these beliefs & values too. Unfortunately, these beliefs and values documented oftentimes do not reflect the reality of how the organization actually works in practice.

Over time, as beliefs & values are iterated upon, they become underlying assumptions, which is the third pillar of organizational culture.

3.) Underlying Assumptions

An underlying assumption can be classified as the byproduct of repeated success when implementing beliefs & values. For example, let's say the company culture is move fast and break things. If this approach over time works, it will become an underlying assumption. If someone deviates from this approach, it will become a problem with the rest of the group. In some sense, these underlying assumptions are gospel truths and are very difficult to change.

I love this framework because it provides a useful way to think about how culture forms with a group of people. Now, let's talk about how this applies to distributed teams.

The Distributed Teams X-Factor

The most successful distributed teams rely heavily on the written word over spoken word/observable behavior.

A co-located team may start working together and work their way down the organizational culture stack, building up shared assumptions over time. Unless this is documented, it can only be adopted through observation by newcomers to the group. This takes time to unpack. I'd argue this is not the most scalable approach either. 

Smart co-located companies will persist & document these beliefs, values, & assumptions as the company grows, but effective distributed companies are forced to do this earlier. When I see this approach used by co-located organizations, it signals that there's a principle to follow.

Distributed teams have fewer data points to build their organizational culture stack, so they are forced to create guardrails earlier, otherwise chaos ensues.

Most importantly, these guardrails must be documented. It's not enough to talk about it on a Zoom call. This information must persist and be visible and referenced constantly. It's the glue that binds the organization together. It there's no glue, things will fall apart.

For example, look at Gitlab's handbook. It's like a Bible for the organization. I'd argue that creating necessary structure in certain areas like meetings is a reason why they have been massively successful and scaled to ~1000 employees.

Gitlab Values

Their organizational culture is derived from a persistent document, not from personal observation. This can scale, even if people see each other in-person a few times a year.

The Yin/Yang of Workplace Communication

This brings me to my final observation, which should apply for distributed and co-located teams. Put simply, I believe that effective workplace communication is a balancing act between synchronous communication and asynchronous (or persistent) communication.

There are benefits to in-person (synchronous) communication. There's a fast feedback loop and there's a lot of data (tone, body language, etc) that can be processed. This is an effective approach when collaborating on an ambiguous project.

There are benefits to asynchronous communication. It persists. It can be revised. It can be easily shared within a large group of people. This is an effective approach for information sharing, especially across timezones.

In conclusion, I think you need to figure out what makes the most sense for your team or company. But I'd encourage you to strike a balance and use the best communication approach for the job. In the future, I will discuss how you can create effective communication habits as a distributed team.

p.s. - I'm writing a book on distributed teams if you'd like to follow-along and read more posts in the future.