Here's an uncomfortable thing to admit: we built SyncTeam because we kept running into remote collaboration problems we couldn't solve with existing tools. And then, in the first year of building it, we ran into remote collaboration problems we couldn't solve with our own product.
We were a small team, fully remote from the start. We had strong opinions about async work. We were building the tools we wanted to exist. And we still got a lot of it wrong. This is the honest version of what those mistakes were and what we changed.
Mistake #1: Assuming async was the same as asynchronous-by-default
Early on, we said we were an async team. What we actually were was a team that had mostly async workflows with a few synchronous habits that we hadn't examined. We had a daily standup call. "It's only fifteen minutes" was the justification. But fifteen minutes every day is over an hour a week, and that's before accounting for the context-switching cost of breaking up a working morning for a meeting that produced nothing a shared async update couldn't have provided.
More importantly, we had a culture of "quick calls" that didn't feel like meetings but functioned like meetings. "Can we jump on for a few minutes?" was a constant presence. These calls were usually fine individually, but they added up to a scattered, interrupted day that looked nothing like the deep-work environment we were supposedly building.
The fix was specific: we named the quick call habit explicitly and decided that anything that had previously triggered a "quick call" needed to go through a stated preference. Is this something I need to discuss right now, or can I put the question in the workspace and get an answer in a few hours? Most of the time, the answer was the second one. Once we named the pattern, we could make a deliberate choice instead of defaulting to the path of least resistance.
Mistake #2: Documentation was something we'd do later
We were a small team and we moved fast. Documenting things felt like slowing down to record history that everyone already knew. We'd write it up properly later, once the dust settled.
The dust never settled. Things kept moving. And the "we'll write it up later" documentation never got written, which meant everything that happened lived in the heads of the people who were there. When a new person joined, they'd ask a question and one of us would spend twenty minutes reconstructing the reasoning for a decision made eight months ago from memory.
We started treating the act of deciding as the trigger for the act of documenting. Not a full write-up, just a quick note: what did we decide, why, what did we not choose and why. This felt like overhead at first. Six months later it had materially reduced the number of times we were reconstructing history from memory and the number of times we reversed decisions we'd already made because we'd forgotten we'd made them.
Mistake #3: Context lived in the person, not in the project
For a long time, if you wanted to understand the state of a project, you had to ask whoever was running it. Not because the information was secret — just because it was never written down anywhere that someone else could find it. The status existed in someone's head, or scattered across a chat thread, or in notes on their local machine.
This made work surprisingly fragile. If someone was sick or on leave, the project stalled because the context wasn't portable. When someone new joined a project mid-stream, the onboarding was an hour-long call with the person who knew the most, which meant that person couldn't work for an hour and the new person had to reconstruct a lot from memory anyway.
We built the habit of writing project context into the workspace itself. Not a formal status report — more like a running project log that someone could read to get current in ten minutes. "Here's where we are. Here's what's blocked. Here's what was decided last week and why. Here's what's next." It takes less time to write than you'd expect when it becomes a habit instead of a special task.
Mistake #4: Treating all communication as equally urgent
In the early days, everything went into Slack and everything was implicitly urgent because it was in the main channel and someone might be waiting. This created a pressure to respond quickly that made everyone anxious when they were in deep work and created the habit of checking messages constantly.
The fix was adding explicit priority levels to communications. Urgent means I actually need a response in the next few hours and here's why. Normal means sometime today or tomorrow is fine. FYI means no response needed. Sounds simple. Changed the texture of the day significantly. Most things turned out to be FYI or normal. The sense of constant pressure to respond immediately was mostly manufactured by the absence of these distinctions.
Mistake #5: Not being honest about what was hard
This one was less visible and took longer to see. We were building a product about remote collaboration, which meant we had some investment in remote collaboration being good. When it was hard, we were slow to name it. When the communication was frustrating, when someone felt isolated, when coordination was breaking down, there was a tendency to work around it individually rather than surface it as a team problem.
The thing that changed this was a monthly honest retro. Not about what shipped or what metrics moved. Specifically: what was hard about working together this month? What felt off? What would you change? It's a simple question but it required permission to answer honestly, and for a while the answers were too polished.
When it started working, the issues that surfaced were fixable: a pattern of meetings that shouldn't have been meetings, a workspace that had gotten too messy to find things in, a feeling among two people on the team that they weren't sure what each other was working on. None of it was catastrophic. All of it was better addressed directly than left to fester.
What we'd tell a team starting out
The things that made the biggest practical difference: decide explicitly how you communicate before the patterns form. Document decisions at the time of making them. Make context portable so it lives in workspaces, not in people's heads. Be specific about urgency. And give the team permission to say when something isn't working.
None of this requires perfect tooling. It requires habits and norms, and the willingness to be honest when the current approach isn't working. We learned most of this by getting it wrong first. You don't have to.