How to Create a Great Remote Team 🧰
An extensive guide that builds on three years of articles and conversations.
Over the years I have written tens of articles about remote work, each usually from a specific angle: how to reduce meetings, improve communication, create better relationships, and more.
Today I am going to weave everything together in a full guide about how to create a good remote workflow: for your team, and for yourself.
I write one of such Guides every month — this will be the November one. Guides are longer, more in-depth and more researched articles than usual, that act as primers about some topic.
Guides are also usually exclusive for paid subscribers, but today I am making an exception, because this is such an important topic. So, if you are a free subscriber, consider this like a sneak peek into what the full plan gives you!
So, going into this article, you may wonder whether the whole idea of a “remote workflow” makes sense: should remote teams work any differently than co-located ones?
Yes and no.
Many principles for collaboration are universal and work for everybody, but remote work has also specific challenges you need to account for.
Based on my own work experience, and conversations I had with countless tech leaders, here are the four main factors you should consider:
🧠 Mindset — how remote shifts the mindset and the culture of your team.
📣 Communication — how to bring clarity, reduce meetings, and make async effective.
📑 Documentation — how to make people write and use docs for real.
❤️ Relationships — how to nurture relationships in a remote team.
Let’s dive in and look at each of them!
🧠 Mindset / Culture
Those of you who transitioned from an office to remote may have noticed this: remote work is unforgiving and exposes all the flaws in your processes.
That’s because remote makes communication more expensive.
Calls are less effective and more draining than meetings
I have found that, in-person, you can have good or bad meetings.
In good meetings you can feed off other people’s energy, get into a state of flow together, and create something great by taking advantage of the incredible bandwidth of being in the same room together.
It’s basically impossible to recreate this in a call. Energy is not there, and non verbal communication falls of a cliff, so most calls are just miserable.
Of course, there are bad meetings in real life, too — probably most of them, to be fair — and these, translated into calls, become even more unbearable.
Casual interactions are harder
Most communication inside a team doesn’t happen in meetings. It happens in casual, 1:1 chats, which are also made worse by remote.
Writing a DM on Slack is not like peeking over somebody’s shoulder. You can’t expect to get an immediate answer, so you have to adjust to a workflow where people are just less available around you.
Remotely, people spend less time around others, and processes need to adapt to enable people do just as good as a work, with less direct communication.
Fortunately, that’s where some magic happens.
Empowering crafters
Good teams figure out that, by restricting communication, people work better.
By reducing meetings, improving written docs, and favour async comms, you naturally lose some bandwidth, but you also remove a ton of lazy / inefficient habits — and the benefits of the latter more than compensate for the former.
So, remote can act as a forcing function for better communication.
As we discussed with Kaz Nejatian, COO of Shopify, a couple of months ago, building a remote team means building a team around crafters, and the act of crafting.
Engineers are crafters of tech, while managers are crafters of processes and systems.
If your team workflow is a system, then the need for a meeting is like a missing API. Managers should continuously improve such a workflow so that less and less unstructured communication is required.
So let’s see how you can do that.
📣 Communication
Work communication has three main goals:
📃 Sharing info — e.g. for status update, or to answer a request for help. In meetings, examples are sprint reviews, or when you demo new features to stakeholders.
🎲 Making decisions — for when you need to decide how to move forward. E.g. in a planning meeting when you prioritize stuff and decide what to work on next week.
🧱 Creating stuff — brainstormings, design sessions, problem solving, and anything where something gets created through the collaboration of the participants.
These goals live on an ideal line that goes from mostly passive/unidirectional communication, to mostly active/multidirectional.
More simply, it goes from status to action.
There is at least a fourth kind of meeting, that is about team bonding: celebrations, mob programming, watercoolers, and more. These are extremely valuable, but I pit them in a different category as they focus on relationships rather than actual output. We will cover them later in the article.
Status vs Action
Back to status vs action, I have two strong beliefs that come from this:
🪚 Meetings should be unbundled — most meetings do not belong to a single type: they are a mix of many, because they need to suit different stakeholders. Rather than removing a meeting altogether, you can remove some parts (and some attendees), to make the rest shorter and more cohesive, so that nobody thinks they are wasting their time.
🏃 You should use meetings for action — meetings have high bandwidth. The best use of such bandwidth is for creating things and solving problems, rather than sharing information. The latter can be usually done asynchronously just as well.
So, the best way to reduce meetings is to 1) split them into parts, and 2) remove / make async those about status.
I have written a full article about this with practical examples and tactics, so if you are interested in this thread you can continue it below.
People’s roles
A takeaway of this mental model is that you can improve communication by being intentional about what you want to achieve. If you are well aware of what people need from a meeting, you can make the meeting better, split it, and sometimes replace it with something else altogether.
To achieve this, I find it useful to reflect on people’s roles by means of the RACI chain. I know that many despise it and find it overly theoretical, but when stick to the core ideas, it is simple and useful.
RACI pits people who participate in any project (or meeting), into four roles:
🔨 Responsible — those who actually do the job.
👑 Accountable — those who ultimately sign off on the job and are answerable for it.
🤝 Consulted — those whose opinions are sought but do not work directly on the job.
📣 Informed — those who are kept up-to-date on the status of the job.
If you think about them as meeting attendees, it’s easy to see that each role is interested in different things:
📣 Informed people are interested in status. They don’t make decisions nor participate in doing stuff.
👑 Accountable people make decisions and need status to do so. But they don’t join the creation process.
🔨 Responsible people don’t need info (they provide it to others). They usually join in the decision making, and also build stuff themselves.
🤝 Consulted people don’t need info and don’t participate in the decision making, but may be involved in the building part as domain experts.
By being aware of what everybody needs to know and do, you can create communication that is effective for everybody, with the right mix of sync / async, instead of e.g. putting everybody in the same meeting room for 2 hours.
More ideas also in this previous piece 👇
Structuring communication
Written communication only goes so far if what you write isn’t clear, exhaustive, or understandable enough.
We tend to take this for granted but I have found there is a lot we can do intentionally to make our communication better from a content point of view.
I have written a full article about this that you can explore 👇
Among the tactics that I covered, the most popular one is The Pyramid Principle, by Barbara Minto.
In her book, she introduces the SCQA framework for presenting ideas in a way that captures the recipient’s attention and increases the chances they understand them. Each idea should be organized into four sections:
1️⃣ Situation — the context, or the status quo. E.g. we need to deliver the product in six months.
2️⃣ Complication — a change or a problem in the current situation which makes this communication necessary. E.g. current requirements are unclear, so we are not sure about what we can deliver in six months.
3️⃣ Question — the main problem statement. E.g. we want to agree with you on the process we should adopt to minimize risks and deliver the best possible solution over these six months.
4️⃣ Answer — your best answer to the posed question, or the process to put in place to get such answer. E.g. we define a core subset of the design to be delivered in 4 months, while keeping 2 months of buffer for learnings, improvements, and setbacks. We will ship working software every week and keep stakeholders posted so we can steer the development fast if we realize we are going in the wrong direction.
At this point, you typically need to support your proposed answer with arguments and ideas. Minto proposes to apply The Pyramid Principle to do it effectively 👇
The principle advocates that ideas in writing should always form a pyramid under a single thought. In this case, such a thought is the answer you propose. Below that, you should summarize and group the next level of supporting arguments. Then, for each argument, you may break it further into more ideas, to form a pyramid.
The Pyramid Principle is based on three key concepts:
Start with the answer first — most people think better in a top-down fashion. Start with the answer and present supporting ideas later.
Summarize and group supporting arguments — force yourself to limit the number of arguments you propose, by grouping them and focusing on the main ones. Minto suggests the Rule of Three.
Logically order your supporting ideas — make sure that the ideas you bring together under each group actually belong together, are at the same level of importance, and follow some logical structure.
📑 Documentation
The best remote companies are usually extremely good at replacing meetings with written stuff, which leads us to: documentation!
It is no coincidence that some of the most glorious company docs you will ever see are written by 100% remote companies. Like the GitLab Handbook, or the Almanac one.
For these folks, docs are a matter of life or death.
I have written a lot about docs on Refactoring — in fact, I have already written a full guide about it. Feel free to check it out.
So, for remote teams, here are my three best pieces of advice:
1) Attach docs to processes 🔄
The best way to be consistent at writing documents is to attach them to existing processes. This turns writing into a habit, so that people do it naturally — like brushing their teeth.
For example, you can enforce agendas for meetings, or design docs for new initiatives. For larger projects, you can use checklists that detail everything that needs to be done, including writing down stuff. Or you can also use your onboarding process as an opportunity to update old docs.
A good practice we established, especially for higher-level technical documentation, is to assign every new hire the task of updating and filling in any gaps as part of the onboarding process.
— Nicola Ballotta • Director of Cloud at Namecheap
Also, you can create templates for any type of document that needs to be written. This is a low hanging fruit that 1) reduces the friction of writing, and 2) improves the overall quality.
So, for any doc you need to write, ask yourself:
What process can I attach this to?
Can I create templates to make this easier?
2) Write design docs ✏️
Another question you may ask is: ok, but what docs should I write? If you don’t know where to start, the answer is design docs.
Design docs are the MVP of all docs, where in their case "MV" stands both for Minimum Viable, and Most Valuable.
A design doc illustrates the tech design and implementation strategy for a given initiative. It is meant to be created before you start writing code, and to be shared with other stakeholders to converge on the solution.
You write it for several reasons:
💭 Help your reasoning — writing is thinking. Going through the process of writing a formal document helps solidify your reasoning and come up with a better solution.
🤝 Create consensus — align with stakeholders about what should be built, make sure important technical decisions are participated, and people feel invested in them.
🔨 Find the best technical solution — improve the original design through the contribution of others. Like a code review, but for the design.
📓 Record the decision — for posterity and documentation. That includes the trade-offs you evaluated, alternative solutions you discarded, open questions, and more.
In that respect, a design doc is useful throughout the whole lifecycle of a project:
⬅️ Before release — it drives the process that makes people converge on a good solution.
➡️ After release — it acts as a record of the decision, which is often more useful than pure tech specs.
3) Create a simple workspace that people understand 🗂
Meetings often become the default, as opposed to docs, because they are easier to summon.
If you want to make async the new default, you should design such a workflow to be as effortless and reliable as meetings.
So, ask yourself a few questions:
📑 Docs — If you want to create a doc about some specs/information, how easy is it to do? Do you know where to put it? How confident you are that it will be found by other people and used in the future?
🖋️ Decisions — if you need to converge with others on something, do you have a reliable place to do it in written form? Do you trust this place not to get lost and to be referenced in the future?
For company workspaces, one of my favorite ways to organize docs is in projects and areas:
🔨 Project docs — stuff you need to deliver a project. A project is an initiative that has a beginning and an end, and potentially involves multiple areas (cross-functional). Likewise, projects may need a diverse set of docs, including e.g. product requirements, design docs, rollout plans, and more.
🎨 Area docs — long-lived documentation about a specific area. An area is anything for which you need to maintain a standard, and that stays relevant for indefinite time (as opposed to projects, that have an end). Engineering onboarding, database schemas, company org charts are all examples of docs that may not belong to a specific project, but rather to a long-lived area.
Most action happens in project docs, while area docs are more useful for future reference. This separation, though, is not static: after a project is delivered, you may archive most of its material, and move some of it into the respective areas, where it will stay useful for longer.
For example, you may move the database migration specs into the general database docs, or the PRD into the product area.
If your system supports it, you may tag content rather than actually moving it. E.g. I am a fan of using Notion for company docs because it allows you to be flexible and define areas and projects through relations and tags, rather than folders. But you can implement this in any system, like Confluence, or Google Docs.
❤️ Relationships
When I talk with people about the switch to remote, the #1 drawback they mention is the lack of human connection with co-workers.
Creating meaningful relationships at work is important. Relationships make us happier, create a sense of belonging, and, ultimately, make us more productive too.
The best managers I know design processes to help people create better relationships with their co-workers. They are intentional about it, just like they are about productivity and company goals.
Still, these people are a rare breed.
Structure and permission
I suspect the reason why intentional work on remote relationships is so rare, is that it is counter-intuitive. Back at the office, everything seemed so effortless, right? You didn’t design for personal moments — they were just serendipitous.
Or were they?
Think of the coffee machine in that corner — beside the sofa, maybe. Someone intentionally decided to put a coffee machine, and a sofa, there, so you could have coffee breaks with others. And do you have a space for lunch? With some appliances maybe, and a few tables? This is by design, too.
The coffee machine, the microwave, the sofa, the ping-pong table — they all create structure for certain things to happen. This structure in turn signals to people that they have permission to do these things. The ping-pong table makes people know they are allowed to play ping-pong at work. Otherwise, of course, they wouldn’t know.
This kind of judgment seems trivial in the physical world — either there is a ping-pong table, or there isn’t — but it is trickier when you work remotely.
Are you allowed to play a quick online game with a co-worker? Did the company make this game available to you, just like it did with the ping-pong table? Are you allowed to talk about puppies at work if there isn’t a Slack channel to talk about puppies?
So, you can be intentional about all these things, and you should do so at every level:
☀️ Every day — you can embed human connection in your processes. You can encourage pair programming, schedule watercooler meetings, or create a structure for interest clubs.
📅 Every week — you can design dedicated, recurring spaces for fun and bonding. You can get together for mob programming on an interesting challenge (even unrelated from work), or you can do an online game with your team.
🗓️ Every quarter — you can avoid staleness with infrequent initiatives like retreats and team rotations. A good retreat does wonders to your relationships and energy.
I wrote about all these ideas (and more!) in detail in a full article about designing good remote relationships:
📚 Related articles
And that’s it for today! You will find this guide featured as the primer of the Communication & Remote topic in the Library.
If you want to learn more, here is a recap of the other articles I have written about this topic — which I have already linked throughout this guide:
See you next week!
Sincerely,
Luca
Lots of interesting concepts. Thank you for the knowledge sharing. I am surprised that a daily video call to discuss what everyone is working on is not included.