I expected distance to make communication harder. I did not expect our strongest process to become a problem. At Cino, we spent eight months trying to handle everything asynchronously, then had to relearn when a conversation was the only sensible tool.
I am Elena Churilova, co-founder of Cino OÜ. Elena is in Tallinn. Mikael is in Helsinki. Our small team also works across three more time zones.
Async was the right early decision
In year one, async-by-default gave us room to build. We could write down a question before sending it, respond when the work allowed, and leave a visible trail behind decisions. For a small Angel-backed team, that reduced interruptions and made distance manageable. It also suited how we actually worked: independently, across several places and schedules.
We did not need a meeting for every choice. A written proposal often exposed missing details earlier than a live discussion. It gave Mikael and me time to think, and let the rest of the team catch up without being pulled into the moment.
Async also made ownership easier to see. A task had a person, a note had a place, and an unanswered question stayed visible instead of disappearing after a call. Early on, this felt like a useful discipline. We were building habits that matched a distributed company rather than copying an office routine.
We pushed async further than it could go
The trouble began when "write it down" became our answer to everything. We added comments and messages when we needed a shared conversation. Decisions slowed because nobody wanted to call a meeting.
We had to unlearn the idea that synchronous work was a failure of process. A thirty-minute call could resolve a knot that would otherwise occupy a channel for two days. It could also reveal uncertainty that no one had thought to document. The goal was not to defend async work at any cost. It was to choose the format that helped the team understand the problem.
That change was uncomfortable because async had served us well. We were not abandoning written communication, and we still wanted decisions recorded. We were learning to use a call for exploration, disagreement, and clarification, then put the result somewhere people could find it. In year two, that distinction became part of how we worked.
Building Cino changed how we see meetings
Cino extracts committed actions from meetings and creates tracked tasks automatically. Building that tool forced us to notice how much meaning lives between a decision and the words used to describe it.
Consider the difference between "we need to sort out the billing integration" and "Mikael will have the billing integration connected to the staging environment by Thursday". The first sounds like progress, but it has no clear owner or finish line. The second gives us something to track. In our own meetings, we found that people often believed they had agreed on an action while holding different versions of what would happen next.
A meeting can feel productive while leaving behind work nobody owns. We began listening for commitments, not just conclusions. Who is doing what? By when? What does done mean? Those questions shaped the product because they were questions we kept needing to answer ourselves.
The cost of missing context
Documentation solved one problem and created another. We could capture the decision, but not always the reasoning that made it sensible at the time. Later, a teammate might see a short task and reasonably ask why we had chosen that path. The answer was often in a meeting, a thread, or someone's memory, rather than beside the decision.
"We chose X" is a record. "We chose X because Y was too slow and Z had the dependency problem we identified in the March planning call" is institutional memory. Without the second version, a later reader may reopen an old debate or repeat the same investigation. The words matter because context tells people whether a decision is still current.
We are still balancing context. Too little leaves archaeology; too much hides the decision. Capture the action without losing its reason.
What hiring did not reveal
Hiring our first ten people showed us that strong async writing does not guarantee distributed teamwork. We needed judgment, follow-through, and visible work.
Our hiring process was good at checking skills and experience. It was weaker at showing how someone handled ambiguity when nobody was nearby. A candidate could describe excellent collaboration and still struggle to signal progress, ask for help, or close a loop in writing. Those gaps appeared only after real work began.
We underestimated silence. When struggling contractors went quiet for two days, we could not tell whether work was blocked, misunderstood, or stalled. Without hallway conversations, that uncertainty spread quickly.
We now look for clear ownership, early signals, and healthy remote work habits, not constant availability or solo output. The lesson is still unfinished.
What still does not work
We are still a small, Angel-backed team, and our systems are not finished. Some meetings produce clear tasks but weak context. Some written discussions run too long. We still miss moments when a quick conversation would have prevented a day of scattered messages.
We do not have the answer to how much communication a distributed team should keep synchronous. We have a better habit of noticing the question. We try to record decisions, name owners, and preserve enough reasoning for someone who was not in the room. That helps, but it does not remove judgment.
Remote-first culture keeps changing as the team changes. A process that worked for four people may need adjustment when a new person joins or a new time zone enters the week. We still find ourselves deciding whether the next issue belongs in a document, a task, or a call.