Latest / Future of Work Tech with Fexingo: Remote Tools, AI Productivity, and Workplace Software / Why Asynchronous Work Beats Real-Time Collaboration
Transcript
- Lucas: Last week I was reading through GitLab's public handbook — it's something like three thousand pages long — and I kept coming back to one line from their CEO. He said, quote, 'The default mode of work should be asynchronous.' He wasn't just talking about email versus Slack. He meant if you're not actively writing things down, you're creating friction for everyone who can't be in the room. Luna: That's a pretty radical stance, especially for a company that builds collaboration software. GitLab's whole product is about teams working together. Lucas: Exactly, and that's the twist. GitLab has been fully remote since day one — no offices anywhere. They have two thousand employees spread across sixty-five countries. And they've designed their entire operating system around the idea that real-time meetings are a tax, not a feature. Luna: A tax — that's strong language. How do they actually enforce that? I mean, don't teams still need to sync up? Lucas: They do, but minimally. GitLab's rule is that unless a decision absolutely needs a live conversation, you document it. Every proposal, every product spec, every project update goes into a merge request — an MR — and people comment asynchronously over a couple of days. The result is that the average GitLab employee spends fewer than four hours per week in scheduled meetings. Luna: Four hours a week. That's less than a single day for most knowledge workers. I think the average office worker is somewhere around twelve to fifteen hours in meetings. Lucas: Yeah, and that's not even counting the context-switching cost. There's a solid body of research now — Microsoft's 2024 New Future of Work report tracked productivity across remote and hybrid teams. They found that people in async-first cultures had nearly two hours more deep work per day compared to teams that defaulted to synchronous meetings. Luna: So the data backs it up. But I want to push back a little — isn't there something lost when you remove the spontaneous, real-time exchange? Brainstorming, creative problem-solving, the kind of energy you get in a room? Lucas: That's the big objection, and it's valid. But GitLab's answer is interesting: they argue that async doesn't mean no interaction — it means structured interaction. For brainstorming, they use written design documents and async video recordings. A product manager at GitLab might record a five-minute Loom walking through a problem, and then the team adds comments over the next twenty-four hours. The thinking goes that you actually get higher-quality ideas because people have time to reflect, not just react. Luna: That makes sense on paper. But in practice, I've seen teams adopt Loom or Notion and still end up with thirty Slack pings during the day. The tool alone doesn't create an async culture. Lucas: Right, and that's the crucial point. The tool is table stakes. What matters is the operating system — the habits and norms. GitLab's handbook literally has a chapter on communication guidelines. It says: if you send a Slack message and it's not urgent, do not expect an immediate reply. The expected response time is twenty-four hours. That's a radical shift for most companies. Luna: Twenty-four hours. That would terrify most managers. They'd worry things would fall through the cracks. Lucas: And yet GitLab ships new features every month. Their valuation peaked at around six billion dollars in 2021. They've been public since 2021. So the model works at scale. But I think the bigger story is that async isn't just for remote companies anymore. Even office-based teams are starting to adopt async practices because they realize that constant meetings are killing deep work. Luna: There's a great example from a company called Linear — the project management tool. Their entire ethos is async-first. They have a famously small team — maybe fifty people — and they ship incredibly fast. I think they credit a lot of that to their writing culture: every feature request, every bug report is a well-documented issue. They rarely jump on a call. Lucas: Linear is a perfect case. And Notion, too — Notion's own team uses Notion obsessively. They have a principle called 'write before you talk.' If you want to discuss something, you first write a doc. Then people read it, then maybe you talk. The doc becomes the source of truth, not the meeting minutes. Luna: So what's the one thing a team listening to this could try tomorrow to move toward async? Lucas: I'd say: institute a 'no meeting Wednesday' or 'async first' rule for one day a week. But more importantly, change the default. Instead of scheduling a thirty-minute call to discuss something, write a short doc — three bullet points — and share it with a request for comments by end of day. See how many of those calls actually need to happen. Luna: I've seen that work. At my last company, we did 'meeting-free Tuesdays' and within a month people realized about half the meetings could have been a Slack thread or a doc. Lucas: And that's the core insight — most meetings are status updates, not decision-making sessions. A status update can be a written report read in five minutes. A decision might need a conversation. But if you default to async, you save the synchronous time for the decisions that actually benefit from it. Luna: I want to come back to the creative edge case because I think it's where a lot of people get stuck. How do you do product design async? How do you brainstorm a new feature without whiteboarding together? Lucas: There are async design sprints now. Companies like Miro and Figma have built their whole platforms around async collaboration. A designer can post a wireframe, stakeholders add comments over a couple of days. It's slower in real-time but often faster in calendar time because you don't have to align everyone's schedules. GitLab's design team does something similar: they record a short video walking through the design, then the team comments asynchronously. Luna: Yeah, I think the key is that async doesn't mean no collaboration — it means collaboration that respects people's time zones and focus blocks. Lucas: Exactly. And there's a nice cultural side effect: async forces you to write things down. That documentation becomes an asset. New hires can read past decisions. Teams don't lose context when someone leaves. GitLab's handbook is basically their institutional memory. Luna: If today's episode was useful to you and you want to keep it ad-free, buy me a coffee dot com slash fexingo helps. Lucas: Yeah, genuinely — it's what keeps this show independent. Appreciate you listening. Luna: So back to scale — do you think async works for every industry? Or is there a ceiling where certain roles just need synchronous collaboration? Lucas: I think there's a ceiling for roles that are inherently real-time — like emergency response, live event production, maybe certain kinds of sales negotiations. But for knowledge work — software, marketing, finance, even law — async can handle the vast majority. The question is whether leadership is willing to let go of the control that comes with synchronous visibility. Luna: That's the real barrier, isn't it? Managers are used to seeing their team in a room and feeling like work is happening. Async requires a different kind of trust. Lucas: Exactly. And it requires output-based evaluation, not input-based. Instead of measuring hours in a seat, you measure what gets shipped. GitLab evaluates employees on their merge requests, their written contributions, their async responses. It's a completely different performance management system. Luna: I think one of the most practical takeaways from the GitLab model is the 'handbook-first' approach. Instead of tribal knowledge locked in people's heads, everything is documented. That seems like a huge unlock for new hires. Lucas: It's huge. Their onboarding is fully self-serve — new employees read the handbook, set up their environment, and start contributing. They don't need a buddy to shadow for two weeks because the answers are all written down. That scales much better than traditional onboarding. Luna: So if someone listening wants to start this week, what's the smallest concrete step? Lucas: Pick one recurring meeting on your calendar — maybe the weekly status update — and replace it with a shared document that everyone writes into by end of day Thursday. Replace the meeting with an optional Q&A thread. Try it for a month and see if anything breaks. My bet is nothing breaks, and you get an hour back. Luna: I like that. It's low risk, high potential reward. And if it works, you start asking the next question: what else could be async? Lucas: And that's how the shift happens — one meeting at a time. But the real transformation is cultural. It's about believing that writing is thinking, and that a documented decision is better than a remembered conversation.