Mar 31, 2020

Working 'Remote' after 10 years

This is a quick intro to how I work with new collaborators in remote teams.

This comes from 10 years of experience setting up and running remote organisations:

  • Leancamp ran in 30 cities, each time with a new team of local volunteers, totalling 150+ people
  • Founder Centric was training company with 4 full-time partners, kind of like an A-Team called into various top-tier accelerators and universities over several years.
  • Source Institute was an end-to-end education company with 40+ p/t trainers running high-profile programs across 3 continents. We also designed a bunch of programs, online and in-person.
  • A bunch of smaller projects with remote teams: hackathons, making PPE for hospitals, launching startups, student events

We learned from others who’d already figured it out: remote startups, companies that transitioned to flat structures (Semco, Goretex, Spotify), and chapter-based communities like Barcamp, Kiwanis clubs and biker clubs.

But I also had unique challenges, because the organisations I ran were mainly with part-timers and volunteers.

So The Source Way built up practices to make it easer for new people to start, and easier for larger groups to keep up with a bunch of parallel projects.

What we learned

“Remote” is a totally different way of working.

You can’t just start using Zoom and chatrooms, otherwise they take over your life. There’s actual work to do, and we want to optimise for the people who actually get things done.

With Source collaborations, we have very few meetings, and no video call or chatrooms required. (They always end up horrible, so why make people use them.)

At Source, everyone has mostly uninterrupted days to really get things done. They are in control of their own schedule, and rarely have to work around other people’s timezones or personal routines.

A lot of people can’t imagine remote work without calls and chats, but the switch to this kind of remote work is actually easy! It just needs people to turn their attention to self-awareness, to jump in to new habits, and help each other break our old ones.

The Source Rules Of Remote

How does Source work practically? A few easy rules:

  • Every week or so, write a quick note to update everyone with your current priorities.
  • If you get mentioned on the forum, reply within one business day. (This makes the forum the single source of truth).
  • If a teammate calls, get back to them the same day. (And don’t call if it’s not important enough to require a call back the same day.)
  • If you’re on a squad, commit to be on the weekly standup call, which is voice-only and 20 minutes max. (It’s a great deal, to free your week of all other meetings.)

At the end of the project, everyone attends the retrospective and shares the conclusions on the forum so we all learn from each other.
This way of communicating gives us a lot of control over our schedule, and a lot more free time, but it needs us to rethink our roles and responsibilities.

Choose “Async”

Favour asynchronous communication (like the forum) over synchronous (chat and voice). And specifically - if something’s important, we put it on the forum.

Thoughts on big decisions, teammate updates, etc. - that stuff goes in writing because:

  • it’s inclusive - everyone is in the loop
  • it’s respectful - we can read and respond on own own schedule
  • it promotes thoughtfulness - writing helps us articulate our thinking more clearly from the start

Squads instead of managers

Squads form around projects (with one-time end results) or factories (to produce a similar output repeatedly) Squads are a maximum of 4 people to stay agile. If a squad needs to be bigger than 4 people, we instead designate 2-3 people as squad members (drive the boat) and the rest as water-skiiers (follow and help when pulled in.)

Squad members pick their own tools. The organisation doesn’t force tools on them, but also nobody outside of the squad is expected to use the tools the squad uses.

Each squad member holds themselves accountable. The best thing about no manager is also the worst – there’s nobody there the chase you.

Teams prioritise together

Squads take responsibility for their results and direction, and report that to everyone else.

Squads set their own OKRs but these are usually related to higher-level OKRs set by the organisation leadership.

My squads have a single, mandatory 20-minute agile standup call that happens at the same time each week. No updates or “while I’ve got you” stuff, since those happened already on the forum. We only prioritize the upcoming week’s work together.

Organizing around priorities, not tasks

Everyone communicates their top 3+ priorities (what they’re working on, and their short-term goals) every week or so. This way, everyone knows what’s going on and if they should connect with each other. It also creates a sense of peer accountability and peer support.

Watch out for “ripples”

Teamwork is interconnected, so if someone’s stuck or delayed, it affects others. In remote teams, this is harder to see, so it’s important to speak up if you’re stuck.

If someone is completely stuck, call a “block” so all hands drop what they’re doing and come to their support. Blocks are immediately followed by a 30-minute root cause session, so we can use the opportunity to improve for next time.

Reject urgency

It’s disrupted when someone does something last-minute, and ends up pulling everyone into that last-minuteness. If this becomes a pattern, everyone gets caught up in the urgent instead of the important. But we can break these urgency habits, leaving us all in flow, working calmly while still seeing big results.

Chat is for social stuff only

The worst thing in the universe is having to follow yet another chatroom. We so no to FOMO. Chat is strictly for social, fun and random stuff only. So its optional and you can tune out without worry. (Because if it’s important, it’s on the forum anyway!)

Calls are 1-to-1 and unscheduled

Calls are used sparingly, but sometimes a voice conversation is the right way to go. Things like brainstorms, quick clarifications, or discussions that involve a lot of Q&A back-and-forth - and anything that gets a little emotional – it’s time for a call.

After the call, write a quick note on the forum so everyone’s in the loop and clear.

That’s it. Simple, and its worked great. It just takes some commitment and some getting used to.

What am I up to these days?

I’m a new parent, and prioritising my attention on our new rhythms as a family.

Work-wise, I’m trekking along at a cozy pace, doing stuff that doesn’t require meetings :)

I have a few non-exec/advisory roles for engineering edu programs. I’m also having fun making a few apps, going deep with zero-knowledge cryptography, and have learned to be a pretty good LLM prompt engineer.

In the past, I've designed peer-learning programs for Oxford, UCL, Techstars, Microsoft Ventures, The Royal Academy Of Engineering, and Kernel, careering from startups to humanitech and engineering. I also played a role in starting the Lean Startup methodology, and the European startup ecosystem. You can read about this here.

Contact me

Books & collected practices

  • Peer Learning Is - a broad look at peer learning around the world, and how to design peer learning to outperform traditional education
  • Mentor Impact - researched the practices used by the startup mentors that really make a difference
  • DAOistry - practices and mindsets that work in blockchain communities
  • Decision Hacks - early-stage startup decisions distilled
  • Source Institute - skunkworks I founded with open peer learning formats and ops guides, and our internal guide on decentralised teams