Aragon One has been a remote team since day one. Even when Jorge and I were working on the very first Aragon prototype, we were flying around.
Something interesting about remote teams is that they are very recent. There isn't much prior knowledge on how to run them.
That makes it equally hard and exciting to run remote teams.
Today, I want to share some advice on things that work for Aragon One.
Trust each other
This an obvious one, but everything is easier if you like your co-workers. Since the very first interaction in the hiring process, we make sure that the candidate's values align with ours.
If values are aligned, creating deep relationships becomes easier.
And once you establish deep relationships, everything becomes enjoyable. You can make inside jokes, talk with your mates about their personality traits, or in general feel like you can trust and be trusted. Trust is so important because we are constantly delegating and being delegated to. If you don't trust the person you delegate to, chances are the work environment will become toxic.
Trust to express freely
Another side effect of trust is that you can freely express yourself.
It's especially important since remote teams die without communication.
Thanks to trust you don't continually oppress yourself thinking that something you may say will offend others. Everyone takes for granted that their mates don't want to confront or hurt them.
We don't want to live in 1984 where you have to measure every word you say to your very own team. Creativity thrives when there's trust, and not fear.
Have a team handbook
A handbook captures how the team works. If there's any doubt, the handbook is the knowledge base you should resort to.
Having a handbook also forces you to write about how the team works. That means establishing processes and thinking about edge cases that you wouldn't think of otherwise.
I have an obsession with tooling. I don't want tools that get the job done, but that is also pleasant and fun to use.
Sometimes the "mainstream" tools just don't cut it. We started using Trello, only to figure out that it was too chaotic for us. Then we switched to Flow, which has all the best from Trello and Asana. Since then we have been using and enjoying Flow more than any other task management tool we have tried.
Invest in learning how to use the tooling
At first, some tooling may seem unnecessary and overwhelming. However, investing in it is paramount. An example is Flow, our project management tool. In the short term, it might not be the easiest for everyone to use it. But the effects of the whole team using the same project management tool and having the same usage etiquette compound over time. There aren't silos, but instead, the entire team is connected by the same tool and usage patterns.
In case of doubt, overcommunicate
Texting can be hard. And everyone texts in their own particular way.
However, text is very powerful, because it is recorded, and that means you can go back to it, edit it, and make it better. I recommend checking out another post I wrote about why writing is so important and how to become good at it.
I want to emphasize this again: Remote teams die without communication. This means that if you believe you are not adequately communicating, you need to overcommunicate until there's no doubt.
That doesn't mean writing more, which usually makes things even harder to understand. It actually means writing better. It means genuinely caring about what you write to other people. We naturally care when talking face to face, and that's why we use body language to supplement our words. In remote teams a lot of that is lost in calls and text, so we need to enhance it by being better narrators.
Differentiate ephemeral from non-ephemeral communication
Chats are not task managers. Repeat with me; chats are not task managers. A message in a conversation gets lost in a second. When I wake up in the morning, I always have more than 50 messages to read.
If everyone had the same volume, that'd be around 1,000 messages for the entire team. Imagine having 1,000 tasks, which are sort of defined, sort of have a due date, and sort of have an owner. That's a lot of "sort of"s. That lowers the probability that something tangible may come out of those 1,000 messages.
Task managers help us create tangible action items that have an owner, a due date, and are well documented.
When someone tells me that I need to do something on a chat, my reply usually is; "Just assign me a task on Flow :)"
People may be offline because of timezones, and you cannot just grab someone in the office and tell them to explain something.
Documentation solves that issue. Even if it's internal documentation, it helps to have a team's knowledge base and the habit of using it.
Have an onboarding project
We have an onboarding project in our task manager, so we can clone it and use it for new team members.
Onboardings are usually hard because new members get into a team with their own culture and way of doing things. A bad onboarding can make a new member unproductive for months. A good one can help the new member reach peak productivity in a month.
The worst onboarding is no onboarding, which surprisingly seems to be the standard out there. We have been told by many team members that Aragon One has the best onboarding they've had and that it helped them get up to speed.
Do an all-hands call
We do a weekly all-hands call in which everyone can add topics.
This is key so that everyone can have a voice. It's also crucial to keep the team multi-disciplinary and make sure different sub-teams know what's going on between them.
We have different kinds of topics:
- Quick updates: 2 min to quickly update the team on important matters
- Demo: 5 min demo to showcase product, designs or ideas
- Lightning talks: 10 min of presenting a topic + 20 min Q&A or discussion
- Discussion: 30 min group discussion about a particular topic
Demos are the best
Demos connect the engineering team with the rest in a very meaningful manner.
Engineers get to showcase what they made themselves. The team gets to know the latest advancements on the product. Engineers get excited to show their most recent work and get team validation for it. The team gets excited because they see it before everyone else.
There have been demos during calls in which the call's chat was just flooded with amazing reactions, and I almost cried during one of them. It's just such a great feeling to see a product or feature coming alive for the very first time.
I'm sure I'm forgetting many other tips on how we organize as a remote team, but I hope this was an excellent first overview. Running remote teams isn't easy, so I hope to open source most of our knowledge over time to help other teams work better.