Managing Distributed Teams Effectively
Managing distributed teams can feel like management on “hard mode”, but it doesn’t have to be.
While the COVID pandemic made working from home mainstream only recently, distributed teams and remote work have been around for centuries, despite far more limited technology.
When Magellan set out to find a westward route to the Spice Islands, he was effectively leading five distributed teams, with no way of communicating back to his boss – King Charles I of Spain – after departure.
When British America was governed from London, messages took six to eight weeks to cross the Atlantic – a situation that continued for nearly two centuries.
The point is not that managing distributed teams is easy, but that the principles involved are well understood. Technology has added nuance, but when companies struggle to align teams across time zones, it’s usually due to weak fundamentals.
In this article I outline the core principles of managing distributed teams, and review the practices followed by leading remote-first organizations.
I also explain why many managerial tools commonly relied upon in in-person environments – which remote work naturally restricts – are actually net negative for productivity rather than practices worth preserving.
What’s lost in remote work
To understand management struggles around distributed teams, we can start by reviewing managerial tools lost when not co-located with staff. This allows us to consider the root of these issues, which prepares us for finding the solutions.
Unbounded interruption
In the office, there’s a lot of finding people at their desks and interrupting them with questions and requests – because it’s easy.
If I want to get an answer, I stand next to them and ask – and they can’t ignore me no matter how focused they are.
I’ll also face no accountability for the productivity loss caused by breaking their focus [1].
The equivalent in remote communication is a DM on Slack – which is far less disruptive.
Remote work acts as a natural barrier to unbounded interruption, allowing longer stretches of deep focus time, which boosts productivity.
The real management challenge then is: what’s the correct way to structure requests for attention?
Meetings
Co-location invites more meetings, for longer, with more people.
There are several reasons behind this, which are beyond the scope of this article. But meeting volume drops far closer to “only holding a meeting if it’s unavoidable” when people are distributed.
Remote also takes the edge off inefficient meetings. An in-person all-hands meeting pauses work for everyone present; when remote, people can keep working during segments that aren’t relevant to them.
Remote work therefore improves productivity by keeping downward pressure on meetings and ameliorating their costs.
The management challenge then is: in what circumstances should we have meetings, and what are the more cost-performant alternatives?
Ad hoc conversations
In an office setting, it’s very easy for people to have spontaneous chats at people’s desks or in the hallway.
This is often held to be a strength, and forms part of a common collaboration narrative – the claim that these ad hoc interactions are where much creativity originates (a topic I address later).
It comes, however, with an obvious weakness: few of these conversations get documented.
This means not only that other people don’t share the context produced from those conversations, but that they’re not even aware the context exists, or whose heads it rests in. This is not scalable.
Remote work helps operations by taking this option off the table – forcing context to be distributed via publicly available records.
Management’s real concern then is: when do we need these free-flowing conversations, and what are the substitutes in a distributed setting?
Physical media
In-person collaboration enables the use of whiteboards, post-it notes, and physical Kanban boards.
These tools work for short, co-located exploration of ideas, but they scale poorly beyond the room.
Information written on physical media like post-it notes is difficult to search for later. It is also not possible to run reports on physical Kanban boards placed throughout an office.
Remote work removes this option, to the benefit of the business – forcing the use of better processes and technology.
Management should ask: what were the motivations behind these activities, and how can we accommodate those desires as a distributed company?
Consensus-based decision making
The default method for making decisions is by consensus. This can be effective in small, tightly aligned groups that share context.
There is a tendency, however, to maintain this approach long after organizational scale has made it unworkable.
Remote work acts as a pressure against this, compelling more localized autonomy and thereby improving decision speed.
Management should instead view this as a signal and ask: are consensus-based decisions working for us – and where they aren’t, what approach should we take?
Line-of-sight supervision
In-person work provides managers with direct visual feedback: I can see my workers, and I can see if they’re working or not.
The problem with this visibility-driven management approach is that it treats visibility and activity as a proxy for progress. But high performance is about ensuring outcomes, not ensuring activity, because activity by itself does not move the company towards its goals.
In fact the opposite is often true – resources being wasted.
Managers should not need to be constantly monitoring staff to sustain progress. That’s not scalable.
Remote work takes away this option, necessitating other approaches which are more effective – like improving hiring processes to make sure candidates are passionate and self-motivated, and making sure the company operates in a way that sustains this motivation.
The real question then comes down to: what signals should management be paying attention to to know they’re getting the best results from their staff?
Office culture building
Co-location does offer the advantage of allowing closer social connections, and thereby the opportunity to create a better sense of community and camaraderie. There is no arguing around this, this is an advantage – for many people – of having an office job.
So too is having a dedicated out-of-the-house workstation – a place to “go to work”.
However, the advantage of this has eroded.
One of the fascinating things about the movie Office Space (1999) is that it was made as a caricature of how bad office jobs were considered at the time – but it actually looks luxurious by modern standards.
Staff had private cubicles to themselves, full of their own dedicated furniture and equipment. Today, we’ve gone even further than open-plan offices – many people don’t even have their own desks and have to “hot desk”.
There are alternatives available to distributed companies who are looking to support their culture, which I’ll cover later.
But ultimately, for managers of distributed companies the question comes down to: what does good culture mean in a distributed setting and how do we maintain it?
How not to fix distributed management
We now have a clear picture of the real questions that management needs answers to. But before we move to those answers, there’s one solution that needs ruling out early.
When faced with difficulty coordinating their distributed teams, management may reach for a pre-existing generic framework. The logic is that a highly structured framework will surely bring order to a disorderly situation. Selecting a popular framework is also perceived as a low risk decision.
I recommend not to do this unless the framework has been designed specifically with distributed teams in mind, and has been proven to work in that specific setting.
To take a popular example, the SAFe framework did not permit their courses to be delivered remotely until 2020 – forced by the corona pandemic [2]. There’s a lot to be praised about this framework, and if anything I’m biased by holding an SPC badge. But as a framework designed to introduce Agile into large, co-located enterprises, many of its core practices do not translate well to distributed organizations without significant modification.
Instead, management needs to approach it from first principles and to follow the leaders in this space.
Distributed management fundamentals
1. Autonomy
Responsibility and decision-making authority need to be pushed down to the lowest level at which they can be borne.
This means managing by outcomes, not through surveilling activity. It also means narrowing responsibility down to individuals, rather than allowing diffuse collective responsibility.
Of course, this is harder. But even in in-person settings this yields highest performance.
The main ingredient here is trust. Placing trustworthy people – i.e. those with convincing track records – into positions, and trusting them to execute autonomously.
Think: this person pushes ahead – they don’t need to be pulled. There is no need to fear if someone is working hard when you know that person likes it.
However, as the Russian proverb goes, “trust, but verify”. Situations change, mistakes in judgement happen.
This verification is done by outcome signals, not activity.
Do projects get shipped, or excuses get made?
Do fires get put out, or responsibility passed to others?
Do decisions get made quickly, or deferred and brought to committee?
Hence the most important input to a distributed company is strong hiring and promotion processes, followed closely by well-designed systems of accountability.
Which unsurprisingly, are best practices at non-distributed companies anyway.
This doesn’t mean a lack of support. Support is just as present, but it takes different formats.
The key with autonomy is that it must be allowed by higher ups – and not taken back if mistakes are made.
If a subordinate makes a mistake, and the response is disempowering – “next time run it past me for approval first”, rather than empowering – “I’ll teach you these skills so you can avoid making that mistake next time”, autonomy will not survive.
That applies recursively – if a subordinate disempowers one of their subordinates, they should be taught how to empower them instead.
2. Documentation
Distributed organizations rely on common context created by open and transparent written communication.
The core of this is documentation. Anything which anyone else might ever need to know must find its way to a permanent, open access, easily searchable repository.
In practice this means a corporate wiki – like Confluence, and public messages – e.g. Slack public channels.
This concept of documenting results of conversations is already well known: minutes of board meetings. It just needs to be applied to any interaction that produces new information (e.g. a decision) that anyone in the present or future might need to know.
This doesn’t just mean writing new things down. It’s even more important to delete or edit existing documentation when it’s found to be out of date. False documentation is far worse than none at all.
This won't happen by itself, and accountability needs to be present if anyone takes the easy route of not documenting something.
There also needs to be a culture of calling out private communication. If someone DM’s someone else about a project or to ask generally applicable questions, instead of asking in a public channel, a DM should go in the opposite direction reminding them not to do that.
The flip side of this is that managers need to be keenly protective of psychological security. No one should ever face negative consequences for good faith public communication.
3. Asynchronous communication first
The synchronous Zoom meeting should be a last resort where there is no better option.
It’s still unfortunately common that “meetings that could have been an email” do not become emails. I’ve even seen recurring meetings where prerecorded videos were played.
This is inefficient when in-person, but it’s painful when it's forcing someone in another timezone to attend at midnight.
This is not a technical matter. It’s obvious that holding an information sharing meeting requiring synchronous attendance, which has no back-and-forths and where most information is irrelevant to most attendees, is not an ideal use of company resources. It’s also obvious that better alternatives exist.
Instead this is a cultural matter – does the company demand meetings be cost-performant.
Distributed teams means asynchronous communication first. Mainly this means messages on apps like Slack, with a preference for public channels.
Most companies just provide communication tools to staff and leave it at that. But instead, there should be defined ways to use these tools, and it should be documented which tool is used for what and when.
Synchronous work-related communication is reserved for any specific matters that have failed to be efficiently settled via async. There, the thread has already laid out the opinions and talking points, and the meeting is to converge to an agreement.
Sometimes synchronous will not be available even in that case, in which case someone with authority needs to appoint a specific person to settle it.
4. Diagnostic control systems
There is a fear due to Goodhart’s law that metrics on development performance will inevitably lead to the metrics being used as targets.
That will then be compounded upon by the McNamara fallacy.
This fear is not unfounded, as many organizations have succumbed to the desire to reduce software development activity to numbers.
Unfortunately, software development is uniquely hard to measure individual and team performance on. It’s one reason that it’s common in the industry to find someone performing above average and being paid below average, and vice versa. You won’t see much of that in sales.
But the solution is simple: ban the use of metrics as targets, and explain why.
You need diagnostic control systems like metrics dashboards to give you signals if anything is going off track.
The leading metrics in software development are the DORA metrics: deployment frequency, lead time for changes, change failure rate, and mean time to recovery.
The other leading diagnostic technique is surveying staff. If you ask staff where they are seeing problems, and make the survey anonymous, you’ll get strong hints where problems are arising. Then it’s a matter of executing on that data.
5. Systems thinking
Scaling any business effectively requires working on it as a system, rather than just in it.
But with distributed teams, it’s critical for everyone to understand the systems you have in place.
What happens if there’s an emergency? The baseline behaviour in an in-office setting is for a leader to rapidly call big meetings until a solution is underway.
That’s merely inefficient in an office setting; it’s impossible with teams and staff spread out over multiple locations and time zones.
This means creating processes and making sure everyone knows them. One effective way to do this is through working agreements.
6. Deliberate culture
Being distributed doesn’t mean a company can’t or won’t have a culture.
In-person settings tend to create a culture through social osmosis. People observe what others value and what behaviours are expected, and follow along.
Distributed companies instead have to make culture explicit.
This means writing values down, and following up whenever it appears they haven’t been stuck to.
Distributed companies also formally create social opportunities, which help improve a sense of cohesion and mutual trust.
This includes making one-on-ones primarily about connection, intentionally holding random online social get-togethers of various kinds (which also helps mitigate silos), and holding periodic non-work online activities (my favourite being casual multiplayer games, with simple games with a strong element of chance like Flip 7 being well-liked).
Another thing that helps culture is mailing “swag” to staff. It makes a genuine difference when staff receive company merch like shirts, caps, cups, and so on, as well as gifts at typical yearly events like Christmas. The effort shows the company cares, and staff-only company merch acts as physical evidence of belonging (with bonus points if you include some for their family members too).
Finally, it’s typical for leading remote-first companies to hold occasional get-togethers of various forms and sizes. It can come out of the budget that would otherwise have gone to leasing and equipping an office.
Does remote work reduce creativity?
The most commonly claimed benefit of in-person work is that it creates a collaborative environment – through hallway conversations, whiteboard & post-its meetings, and a fluid social atmosphere – which causes innovative and creative juices to flow.
The problem with this claim is that it lacks detail.
This is not how, for instance, Einstein came up with Special Relativity, nor how J.K. Rowling created Harry Potter, nor how Michalangelo designed the Sistine Chapel ceiling.
It is, however, how The Beatles made their songs, how Pixar Animation Studios developed its stories, and how the Apollo 11 moon landing was accomplished.
In essence, the answer to this question is: it can go either way.
Co-location has the edge in cross-disciplinary brainstorming or in contentious discussions. Remote has the edge in generating novel ideas or in creativity that requires long incubation.
So the issue is not which is better, as neither are a clear winner. Rather, it’s in knowing what’s the most effective way to accomplish a given outcome, and where remote or co-location have weaknesses, compensating accordingly.
On hybrid
Since the passing of the COVID period – which revealed the broad feasibility of remote work – there has been a tendency for companies to offer a compromise of “hybrid”, usually meaning a week split between days in the office and days remote.
However, while commonly adopted as a pragmatic compromise, the weekly hybrid approach takes away many of the benefits of remote, limits the in-office experience, and makes coordination more difficult for everyone.
Whenever people are in the office, everyone who is remote immediately feels it: everything goes radio silent. Those onsite are now conversing in-person only, and the automatic documentation effects of remote communication cease until they go remote again. DM response times drop from minutes to: today if you’re lucky. Remote staff can no longer see their colleagues' faces, and are now looking at tiny dots in a Zoom tile of a conference room and trying to work out who’s present and who’s talking.
It also prevents one of the major benefit offerings to staff – the ability to relocate further from the city – which reduces hiring competitiveness.
Leading distributed companies do hybrid, but they do not do weekly hybrid.
How leading remote-first companies manage their teams
The following well-known companies are remote-first, meaning everyone works remotely by default (although occasional in-person gatherings are common).
All were working fully remote prior to the COVID pandemic.
Since they’ve had many years to figure out what works and what doesn’t, the easiest way to manage distributed teams is to copy these leaders.
GitLab
GitLab publishes their handbook on how they run their company – now totalling over 2000 pages – all online for the world to see.
They have been remote since incorporation in 2014, and as of 2020 had 1300 employees in 65 countries – making their handbook one of the best resources available for understanding how to operate a remote-first company.
Principles they emphasize include:
Documentation and Async. GitLab calls asynchronous communication “the art of eliminating meetings”, and teaches their staff how to respectfully decline meetings.
They consider strong documentation to be a prerequisite for this, and follow a “handbook first” culture – all proposals exist as proposed changes to the handbook.
Transparency. They hold that all communication should be made public unless there’s a good reason not to be.
Deliberate social time. Leaders are expected to “formally organize informal communication”, and to design an atmosphere where team members can get to know each other.
GitLab also supports “Onsites”, where teams can meet in-person in certain circumstances.
Directly responsible individuals. GitLab wants there to always be a single individual who has the final say on any matter (the “DRI”). They point out that this does not reduce collaboration, because a DRI risks impairing their results if they fail to consult others.
Automattic (WordPress)
Remote since inception in 2005, Automattic has over 1400 staff in 82 countries.
They emphasize:
Remote-centric hiring. Automattic interviews replicate how their staff work – via messages, rather than Zoom interviews. They emphasize the importance of autonomy and self-direction in candidates, and they incorporate a paid trial period in the hiring process [15].
Long-form asynchronous communication. Automattic prefers to use their P2 internal blogging platform to communicate via long-form content [14], considering Slack to be relatively “synchronous”.
Periodic meetups. Automattic regularly flies teams to meet up together at various locations, for both work and social purposes [16].
Buffer
Buffer started with an office in San Francisco, but shut it down and transitioned to full remote. It currently has staff in 22 countries.
Some principles they emphasize include:
Transparency. Buffer is famously transparent – going as far as publishing the salaries of their staff online.
Clear expectations around communication. They detail how communication tools should be used, which tools should be used in which circumstances, and set explicit expectations around communication timeliness [13].
Manager as coach. They view the primary role of the manager being to unlock intrinsic motivation in staff, through helping them achieve higher levels of autonomy, mastery, and purpose. They believe the manager should empower staff, and help remove roadblocks that interfere with their work [11].
Remote.com
Remote.com was set up from the start as a remote company, to align with its primary business – global payroll services.
They emphasize:
Async-first. Their CEO & Founder states “the best way to manage meetings is not to have them” [10]. They are intentional about what circumstances indicate a meeting, and they are strict on meeting formats. They prefer to lean heavily on documentation and well-defined asynchronous communication protocols.
Strong hiring and onboarding. They make sure candidates are a good fit for a fully remote organization, and pay close attention to the quality of their onboarding processes.
Trust starts on day one. Remote.com places a high importance on trusting people to autonomously get the job done, but also on doing intentional trust building – such as using one-on-ones primarily for building connection [3].
Stating times in UTC. For very distributed teams, having all staff reference the UTC timezone rather than any local time zones removes the mental arithmetic around what stated times mean [4].
37signals (Basecamp)
37signals has been remote since they started back in 1999, even writing a book about it [9].
Their principles include [8]:
Asynchronous communication and reporting. Staff are expected to “radiate information” on what they are working on, and what they plan to work on, with a regular cadence.
Managers of one. 37signals relies on everyone to self-direct. They expect that even if someone was left completely to their own devices, they would be highly productive.
Cooldown. Their work cycles include a deliberate period of flexibility, to avoid the constantly sprinting effect that wears teams down.
How do distributed companies plan?
None of the above companies use quarterly execution planning.
GitLab uses roadmaps and quarterly OKRs, leaving execution up to teams [12].
Automattic, consistent with its emphasis on autonomy, does not have a common planning system across its teams [6].
Buffer uses a six-weeks–two-weeks cycle: six weeks for execution, two weeks for planning, experiments and side projects, and pure engineering work (e.g. refactoring) [5].
37signals also uses a six-weeks–two-weeks cycle – calling the two weeks “cooldown”, and does not have roadmaps [7][8].
Conclusion
Managing distributed teams isn’t easy, but the principles are well-worn.
Distributed companies rely on:
- Autonomy, responsibility, and trust;
- Asynchronous communication and clear expectations;
- Rigorous documentation;
- Transparency;
- Systems of management;
- Strong hiring; and
- Intentional culture.
Since these are good practices at any well-run company, this is not about developing new ones, but about disciplined application of established ones.
References
[1] Cannelevate, “Understanding Context Switching: Productivity Research and the Hidden Cost of Modern Work,” Dec. 21, 2025. [Online]. Available: https://www.cannelevate.com.au/article/context-switching-productivity-hidden-cost-modern-work
[2] Scaled Agile, Inc., “Remote Training Policy,” Scaled Agile, 2026. Available: https://scaledagile.com/remote-training-policy/
[3] Remote, “How to manage remote employees,” Remote.com. [Online]. Available: https://remote.com/resources/insights-center/how-to-manage-remote-employees
[4] Remote, “What’s wrong with time zones,” Remote.com Blog. [Online]. Available: https://remote.com/blog/global-expansion/whats-wrong-time-zones
[5] Buffer, “Why we work in 6-week cycles,” Buffer Resources. [Online]. Available: https://buffer.com/resources/6-week-cycles/
[6] Automattic, “Design hiring FAQs (planning cadence),” Automattic Design. [Online]. Available: https://automattic.design/design-hiring-faqs/
[7] J. Fried, “I’ve never liked roadmaps…,” LinkedIn post, 37signals. [Online]. Available: https://www.linkedin.com/posts/jason-fried\_ive-never-liked-roadmaps-we-dont-have-activity-7379647962374733824-1zVx/
[8] Basecamp, “How we work,” Basecamp Handbook. [Online]. Available: https://basecamp.com/handbook/how-we-work
[9] J. Fried and D. Heinemeier Hansson, Remote: Office Not Required. New York, NY, USA: Crown Business, 2013.
[10] Remote, “How to run remote meetings,” Remote.com. [Online]. Available: https://remote.com/resources/insights-center/how-to-run-remote-meetings
[11] Buffer, “Why great managers matter,” Buffer Resources. [Online]. Available: https://buffer.com/resources/why-great-managers-matter/
[12] GitLab, “OKRs,” GitLab Handbook. [Online]. Available: https://handbook.gitlab.com/handbook/company/okrs/
[13] Buffer, “Communication expectations for remote teams,” Buffer Resources. [Online]. Available: https://buffer.com/resources/communications-expectations-remote-team/
[14] M. Mullenweg, “How P2 changed Automattic,” ma.tt. [Online]. Available: https://ma.tt/2009/05/how-p2-changed-automattic/
[15] Automattic, “How we hire,” Automattic.com. [Online]. Available: https://automattic.com/how-we-hire/
[16] Automattic, “How we work,” Automattic.com. [Online]. Available: https://automattic.com/how-we-work