I've worked at a fully remote company again for almost a year now, after nearly a decade at companies that allowed remote work but were never properly set up for it.
In that time, I've noticed something that runs against what most people assume. Moving deliberately doesn't make a team slower. Neither does giving a decision the time it actually needs instead of forcing it into a live conversation.
The teams I've been part of that think carefully before committing to something don't necessarily get it right on the first try. But they end up with fewer gaps and a lot less back and forth than teams that race ahead and course correct three sprints later. Mindful and async isn't a trade-off against speed. Often, it's where speed actually comes from.
The tools haven't caught up
What surprised me is what hasn't caught up to that realization: the tools. We still run almost everything through chat. Slack, in my case, though it could be any of them. Tools like Slack don't fit how an async, thoughtful team actually works. They're built for presence. They assume someone is there, maybe not this second but relatively soon, ready to respond.
Async work assumes the opposite. You should be able to pick up a decision hours after it started, with enough context to actually contribute, without anyone having waited on you.
Almost all of us use chat anyway. Not because it fits, but because there's genuinely nothing else. I don't think that's a small gap. I think it's one of the more expensive blind spots in how distributed teams operate today.
Here's the shape of the problem as I've come to see it. Chat is real-time and unstructured by design. That's exactly what makes it good for a quick question or a moment of connection.
It's also exactly what makes it a bad container for the things that actually make up "real work": a decision that needs to be reasoned through, a status update someone will want to find again in three months, a technical debate with real trade-offs, a scheduling back and forth.
The cost of multiple tools
That's what we end up using other tools for. Issue trackers like Linear or Jira are excellent at state: they show who owns what, what's blocking or blocked by something else, what's been shipped already.
With enough discipline, you could also move the discussions that need a decision to Linear using documents, project updates or the comments section.
But then, where does this information live long-term? Teams usually end up picking yet another tool: a knowledge base like Notion.
What gets lost
The result is that in between the tools, information gets lost. Who remembers to move a discussion that happened ad hoc in a Slack thread to a Linear discussion? Once a decision has been made, who remembers to find and update the Notion page that contains information about the feature?
The thing async teams depend on most is being able to share knowledge and context in enough detail that anyone can find it and act on it later — without having to ask.
But this, right now, happens by accident. It's scattered across threads in different tools and docs that go stale because nothing points back to them. And the memory of whoever happened to be in the room becomes far more important than it should.
We've all quietly accepted this. I don't think we should have to.
What I've been sketching
On and off for a while now, I've been trying to picture what a real alternative could look like. It's less a rewritten chat app and more a rethink of what the default surface for "getting things decided and done" should be.
I see this product as a merge of Linear and Notion with the collaborative aspect of Slack and a big emphasis on autonomy for every single teammate.
A wiki as the source of truth
Here's the starting point. A company's knowledge — what the company builds, how things work, how people work, why decisions were made, what's true right now — all of that should live in one place that's actually organized, not scattered across a thousand threads in many different tools.
That place is a wiki or knowledge base. Not a graveyard of stale onboarding docs, but the living, current record of how the company actually works and what it is about. One that you can always trust to be up to date.
Projects born from gaps
In this model, work exists to serve that record. You don't start a project because it's Tuesday and there's an empty slot open in the current sprint.
You start one because you noticed a gap: a section of the wiki that's stale, a piece of product feedback that came in or just a new feature idea that fits well with the current state of the product.
The project exists to close that gap. It has a destination before it has a plan.
The resolvable question
Inside a project, the actual unit of work isn't a chat thread or a number of tickets.
It's something closer to a resolvable question: what needs to be true to close this gap? That gives a project a definition of done from the start. It might change along the way, but everyone involved begins with a clear goal.
People work through these however they need to. Async, over hours or days, picking up whatever's unblocked.
When a project finishes, it's resolved by filling the gap in the wiki that the project was aimed at. The knowledge goes live the moment the thinking and execution are done, not whenever someone gets around to writing it up.
That one shift, collapsing "we discussed it" and "it's now documented" into a single moment, is the part I keep coming back to. It removes the step where good thinking quietly evaporates.
Where this actually stands
Right now, this is just an idea I keep circling back to, sketched out further than I probably needed to for something I haven't committed to building.
One day, I want to create a new team again and work on projects like Maxout. And if I do, this is the kind of tool I'd want to use before the first thread ever got started.
I don't know yet whether it becomes a real product or whether I'll just find a different workaround.
What I do know is that the friction I described at the start isn't something I'm imagining. Thoughtful async work is genuinely good. Chat is a genuinely bad home for it.
I hear some version of this from almost everyone I talk to who works this way. We've all just accepted it as the cost of not being co-located, instead of asking whether it has to be.
An open question
I don't have a clean answer yet for what this looks like fully built, or whether I'm the one who should build it. But I wanted to write this down and put a stake in the ground. Mostly because I suspect I'm not the only one who's felt this particular itch and hasn't said so out loud. If that's you too, I'd genuinely like to hear how you've been thinking about it.
Photo by Austin Distel on Unsplash