Sharing knowledge in a remote team, across timezones
“True innovation comes an intersection of a cross-pollination of roles and ideas” - Sunil, former-CTO@Buffer
I’ve been working remotely at Buffer for 6 years now. As a software engineer, one of the critical skill I believe we should must have is being able to learn continuously. However, working in a fully distributed team, split accross 10+ timezones. I live in Asia (UTC +8) while most of my teammates live in the US or Europe. That’s up to 15 hours difference. We only meet each other once a year. This remote setup affects how we learn from my team, compared to if I were in a physical office.
With the current COVID-19 crisis, when company suddenly switched to a work from home setup, understanding how the dynamic of knowledge sharing in your team is important. You don’t want the knowledge shared being stopped. I’ll lay down some of our successful experiments, their pros and cons, what I think works for me and our company.
❌🧠 The real miss opportunity in a remote team, knowledge sharing
In a remote team, we don’t have regular random opportunities to come together like we would in a physical office. Conversations will be focused within your current team conversation channel. You won’t be able talk over the watercooler/coffee machine about your current issues with someone else than your core team. You’ll miss opportunities to talk with other teams about their challenges, bring up your expertise, and learn from someone else experiences/advices from an other team. We stop learning as much as we could because we’re not seing each other anymore.
As a remote company, how can you overcome this challenge? How do you optimize knowledge sharing, no matter which timezone? This is where the concept of regular snackchats at Buffer was born 3 years ago, introduced by Sunil.
🍴💬 Snackchats
Snackchats are small talks that everyone can propose in the company. It can be any topics, from code, architecture, management, tips for a tool to side projects. Anything really. We usually ask on slack, and if you there is enough interest, you commit to it and prepare it. Here an example of Tigran asking interest on using Datadog Logs with APM together:
Here a great example of snackchat by Hamish on an “Intro to GitHub Actions”:
Also here some other great ones:
- Federico on git workflow
- Joe on “Get started with Go”
Tips for doing a snackchat
- Keep them short: 10 to 20 minutes, keep interest of your audience
- Record them, people will be able to see them later if they can’t attend
- Your busy teammates will be able to see them at x2 speed
- Have a directory (notion/wiki) for future reference
- Like video call, putting a face, it’s great to have a human touch to something “technical” to see someones smilling, worrying.
The downsides of a Snackchat
The downside of snackchat is that takes quite a bit of energy to prepare. There can also be intimidating to ask if a topic you might want to present won’t get enough interest from your workmates. In a remote setting, people will try to make the best use of their time, and we might most of the time be busy on prioritties. The time you will set might not be the best fit for everyone. I wasn’t able to participate to most of the snackchats because I live in a total different timezone than most of the people in the company. The tip here is to make sure to record your snackchat and repost it for people who couldn’t attend them.
⚡️ Impromptu Knowledge Screencasts
An other format I personally enjoy doing is the “spontaneous” knowlege sharing with a screencast . I’m in the infrastructure team, where product engineers might not necessarly need to understand what happens “behind the scene”, but where the knowledge could be useful to understand more how service bahave, or simply can pick their curiosity for learning purpose.
I especially enjoy the screencast format for few reasons:
- Snackchats requires preparations, and I know I will not be great at “live” presentations
- Being in a timezone where you wake up when others start going to sleep isn’t great for coordinating any live presentation.
- I’m more in the introvert side. It require quite a bit of energy to ask interests, worrying if people shows up. Sharing when I feel like it is easier mentally.
- My envy to create educative content isn’t always consistent. There is some days where I will be more encline to share it and some where I’ll not feel like it.
Tips on making “Impromptu Knowledge Screencasts”
- I like using Loom. They make recording your screen and voice really easy. It also allows you to pause the recording, and aslso has an impressive online editor to trim your blanks.
- Try to keep the video dynamic, go to the point, and avoid the fluff, but keep the jokes
- Keep it short, ideally under 10 minutes
- When I know a video will be valuable on the long term, I try to do some Google slide to structure the video
Here an example where I wanted to show (not the first time) the benefits of using one of our internal librarie to make debuguing faster and easier:
📼 Use GIF to share knowledge
1 picture is worth a thousand words, but 1 GIF worth a lot more. It can save you or your teammates a lot of time, save you some context switching, and save your productivity. When someone has a question, or you want to explain something complicated, a simple GIF of the solution will be more than enough than trying to make on a call and explain it.
I enjoy using cloudapp. For example here what I’ll share when I wanted to share the results after migrating a service from PHP to Golang:
🥇 Make sharing knowledge explicitely valuable
At Buffer, we have an engineerig framework that encourage kowledge sharing. To reach a “Senior Engineer 2”, One of the criteria would be… “educates across domain” or “Reach out to other teams within and beyond Buffer to share knowledge”. I don’t mean that money should be the incentive, but , I’ve personally because it was one of the condition to reach the next step, but then started to enjoy it more and more. I’m now doing it because I see value in it now whe other teamate tells me how valuable are my videos.
An other great way to encourange to continue sharing is to reach people who share that their knowledge were helpful. Here for example Jose telling me he is using my video for a future mongoDB upgrade:
👨🏫 Be a teacher, don’t make asssumptions, over communicate
In a remote team, informations get easily lost. Other team members might not have the same context as you, new hires are recurrent occurence, and won’t dare to ask “stupid questions”.
Extra communication is key, don’t make assumption, the more you say, the better teamates will get more knowledge. I’ve even more for trivial questions, where some fundamental might be missing and where your informations will be be really valuable
One of the favorite people I’ve been working at Buffer is certainly Colin. Since day 1 I’ve joined the company, he’s been relentlessy explaining and giving context if any issues or questions arises. He’s been certainly the go to person when engineers has doubts or need advices. Indirectly, it help to make you look “approachable” for new members, especially in a remote settings where you won’t have much chance to interract. Sharing knowledge is definitely a great mark of leadership.
Additioanlly, It will help creating a great culture in your company where there no stupid question exists, and where your team will feel safe.
❤️ Share and re-share without limits
Sharing links via Slack or email are great, but those content get easily lost. You shouldn’t make assumptions your teammates saw the video or message you’ve shared the other week. I recommend to maintain a directory (in Notion/Paper/Wiki etc…). When you see a question that was answered in one of your video, share it again. A natural snowball effect will happen when your teammates will see more and more people sharing their knowledge.
Keep sharing ❤️
Over to you, what’s your secrets on keeping your team in a remote setup? Comment on Hacker News
📚 Next read: Why you should have a side project
Thanks for reading
As always, hit me up and let’s hang out. I am thinking a lot about AI, Health, Tooling, Hacking and other stuffs. I now focus on TaipeiDev and HackersBait.
If you are in Taipei come hang out.