Leading a Distributed Remote Team Pt. 1
Two years ago I had the opportunity to work with Paybook as Head of Product. The whole company worked distributed and remote.
When I joined, the core product was an API for developers to connect users with their bank accounts. Now, there’s a finance management frontend — Mobile & Desktop. Connecting banks from +3 countries, convert in +100 fiat currencies. Including, blockchain wallets, ERC20 tokens and digital wallets like Binance, Bitso, and Coinbase.
We did it all remote. Looking back I still think how did that happen?
Working remotely was a first-timer. I was used to being in an office, so a lot of my behavior had to change during this journey. For example, I felt that I need to be always available, reply ASAP on Slack, or even appear online. I was mirroring “office” habits in the online/remote work.
So I realized the challenges and opportunities of working with a remote team, and I want to share them with you. Part one of this post series tries to explain:
What is Distributed & Remote work?
My biases, mistakes, and learnings
Which successful companies have scaled?
On Part Two:
Pros and Cons including the processes I implemented; and
Resources: Podcasts, articles, and more stuff about distributed teams.
*How to live and work remotely, my individual experience will be for another post.
Few important words
Synchronous: If I call you, and we chat that is synchronous. At the office, if I ask you something and you respond immediately. That’s synchronous communication.
Asynchronous: If I leave you a Slack message, send you an email, or a document. You will read it at your own time, and then you’ll get back to me. Then I’ll read it on my own time, now we are communicating an asynchronous way.
Timezones Abbreviations: GMT = London Time, EST = New York, CST = Mexico/Austin, PST = San Francisco.
The difference between Distributed vs Remote Teams?
From my point of view, there’s a distinction between distributed and remote.
A team can be distributed but not remote for example:
> HQ is in London, Engineering in Estonia & Product in New York.
There’s a cross-over between stakeholders:
> Marketing Manager in London, tech lead in Estonia, product and design in New York.
With this approach the challenge is different time zones. You’ll want to work around synced and overlapped times.
1 location, 1 office will be online during a period of time. Such availability will crossover when the next location becomes online. Besides, a distributed team can be in a synchronous location, meaning in the same time zone.
Being distributed not only applies to geography. Wordpress Founder, Matt Mullenweg mentions:
> “Every company over 100 people is already distributed, they just pretend they’re not.”
That’s true. If you work at the Apple Campus with a 12K staff, then you are at the same place, but scattered and distributed.
Switching gears, a remote team will always be distributed. There are two styles that I’ve seen:
Locally Remote: You hire remote in one timezone. Everyone works around let’s say EST. The process is you must be online on specific hours.
This is how InVision works. Despite the differences in time zones, the company still maintains official office hours between 10 a.m. and 6 p.m. ET.
Globally Remote: You hire remote doesn’t matter the time zone.
1 member in Mexico City, another one in Austin, another one in London, and the list goes one.
Your work on the outcome, not working hours.
Challenges: Availability, response times, and early birds vs night owls.
NOTE: I’m omitting trust and reliability. You tackle that at the hiring stage. It’s important to mention that remote work is not for everyone.
How do you solve reliability?
Each company needs a process depending on their culture and execution.
Locally Remote can work between synchronous and asynchronous, whereas Globally you depend a lot of text, wikis, and documentation.
Different goals, different processes.
My biases, mistakes, and learnings.
There’s a caveat, when I joined there wasn’t an explicit process on how we should work as a team. Meaning, what’s the expectation? how are we measuring everything? We learned on the go.
My goal is to help you anticipate such challenges if you decided to build a remote team. Address them by agreeing on the expectations you have with the team.
For context, the team at Paybook is around 30+, all remote in different time zones. Due to my role, I interacted with approx. 20 people between engineering, product, and marketing.
Also, I worked half a year in CMT, then EST time and then another year in GMT time. Most of the team is on EST & CST, around 5–6 hours difference from London (GMT).
My mistakes, notes and, learnings:
Online all the time: I thought that being online on Slack was equal of going to an office. You must be “seen” available. This depends on what process and the company’s culture has.
Moving asynchronously: One morning I was training a new product manager in GMT time. I asked, “why haven’t you sent the documents (to EST)?” Because I don’t want to bother or wake them up. — The same thing happened to me when I joined.
Updating Wiki or Documentation: Documentation needs to be always up to date. This affects product development and onboarding new employees. Multiple times, I had to onboard new hires through meetings. Wasting a lot of time.
Implicit process instead of an explicit one: When I joined there was a spoken process but nothing established. To scale, you must define the expectations, and the process to get there.
Your habits vs your teams: I wake up early and get things done early, but most the team waked up late getting online around 12 pm. So I’d be getting Slack messages at 1 am in the morning.
Video Conference tools suck: Current tools don’t allow introverts or people who are shy to speak up. The louder someone is; Hangout would shift the microphone and camera. Also, I would try to put my camera to increase team engagement, but no one would put their video at all.
You connect through text There’s a weird magic feeling of getting to know someone through Slack.
Creative Planning: I couldn’t find a tool that gives you the same effect as being in an office and jump into the whiteboard. The flow is different.
Catching up: More about onboarding New Hires: Most of the “social” bonding happens on Slack, most of the discussions too. Is hard to keep up, and there’s no “summary” of past informal conversations.
No one understands you: My mom or any friends would think I wasn’t working because I’m in the house. They measure work in a different way.
Distractions everywhere: The distractions are offline.
Motivations and being loneliness…
And the list could continue around the individual challenges: distractions, how to keep yourself motivated, and being lonely. I’ll work on a different post around this subject.
My advice to founders.
One big recommendation to founders is:
Either go 100% remote, or 50% on location, and 50% remote.
If you have eight people in an office and 2 remote. Your process needs to serve both needs, creating extra effort as a founder.
Clark Valberg, InVision CEO says:
“If you have an office and yet a bunch of people work remote, it can be problematic, because the work experience of the people who work remote is often impoverished compared to the people working from the office.”
That happened to me working on GetNoble. 4 team members were in an office, I was the only person remote. Is hard to be up to date if all the information isn’t available.
Successful Distributed Companies
In part 2 I’ll add more resources but I wanted to share the companies I admire, so you can learn more from them.
Automattic: They are the people behind Wordpress.com, with over 850 employees, in 69 countries. You can learn more about their culture here, and here Matt Mullenweg is writing a book about remote work, which is exciting.
Gitlab: Git-repository manager with 350+ employees, in 45 countries, having a $1B valuation. I admire their transparency, you can learn how they run the company in their handbook You can learn more about Gitlab’s remote culture here,here and here.
Basecamp: I look up to Jason Fried, Basecamp co-founder, and CEO, he is a genius, he co-authored a book called: Remote, the podcast episode Tim Ferris is great, but you can check more about their culture: Here and here.
This is Pt. 1 the next post will be about the processes, tools, and solutions for leading a distribute remote team.
Subscribe to get notified, for part 2, and for product and growth.