We Went Distributed and It Was a Disaster (Here’s What We Learned)
Our entire team quit in my head the day I realized we were the worst distributed company ever.
Not literally quit. But the signals were all there. People weren’t replying to Slack messages. Decisions that should take hours took days. Someone shipped a feature that contradicted what another team member thought we decided. A contractor in Eastern Europe did work nobody asked for because they misunderstood the written instructions.
It was chaos. And I’d done it all intentionally.
We decided to go distributed six months earlier because it made sense on paper. We hired a designer in Mexico. An engineer in Poland. A customer success person in the Philippines. On spreadsheets, we saved $200K annually in salary costs. In reality, we created a company that was fracturing in real time.
The worst part? Nobody was doing anything wrong. Everyone was working hard. We just had no idea how to actually manage people across time zones, across continents, across different working styles and communication norms.
I spent a weekend reading everything I could about distributed teams. What we were doing was completely wrong.
The Problems Nobody Warned Us About
We Thought async Communication Would Be Easy
We assumed “just write things down” would replace meetings. We set up Slack. We documented processes. We’re doing distributed work now, right?
Wrong.
Writing things down didn’t create clarity. It created confusion. Someone would ask a question in Slack. By the time they got a response (hours later, when someone in a different timezone checked), they’d already solved it differently. Then a different person solved it a third way. Now we have three different approaches to the same problem.
Async communication without structure isn’t communication. It’s just people talking past each other on a delay.
We Had No Time Zone Boundaries
I scheduled a meeting at 2 PM my time (California) without thinking. That’s 6 AM for the Poland team. 10 PM for the Philippines team. We did this constantly.
After a month, the Philippines team was exhausted. The Poland team was showing up late or not showing up. I couldn’t figure out why people seemed disengaged until I finally checked what time our meetings actually were for them.
I felt terrible. And stupid. Of course people are disengaged when you’re asking them to meet at 10 PM.
Nobody Understood What We Actually Decided
Meetings would end and everyone would walk away with different understandings of what was decided.
We’d have a discussion about product direction. I thought we decided one thing. The engineer thought we decided something else. The designer thought we decided a third thing. Since we were all async and in different timezones, by the time we realized the misalignment, the engineer had already started building in the wrong direction.
The Company Didn’t Feel Like a Company
People felt isolated. They weren’t part of a team. They were individuals on a Slack channel with the same company name.
One of our contractors told me later that he sometimes went days without talking to anyone on the team. He’d finish work, submit it, get async feedback, and repeat. It felt like freelancing, not working at a real company.
The kicker? He wanted to be part of a team. He wanted connection. He just didn’t know how to ask for it.
Communication Overhead Increased, Not Decreased
I thought going distributed would reduce meetings. We’d write things down instead of talking.
Reality: We had MORE meetings (because written communication wasn’t working), AND we still needed to write things down AND people still felt confused.
We were working harder, not smarter.
What We Actually Did To Fix It
Around month four, I reached the point where I had to make a choice: declare distributed teams impossible, or figure out how to actually do them right.
I chose to fix it.
We Created Written Decision Frameworks
Instead of just documenting our processes, we documented how we actually make decisions.
“Here’s how we decide whether to build something new: we use this framework, we consider these factors, these people have input, here’s the decision-maker, here’s when we decide.”
Once people understood the framework, async communication worked because everyone knew what they were working toward.
We Scheduled Overlap Time Ruthlessly
We figured out that we needed overlap with every person. Not all-day overlap. Just one hour per day where everyone was awake.
That meant 7 AM for the California team. That meant midnight for the Philippines… wait, that didn’t work.
So we hired someone in Eastern Europe instead. One hour of overlap where everyone could have synchronous meetings. Everything else was async.
That one hour changed everything. We made decisions in real time when needed. We built connection. We clarified misunderstandings immediately instead of over multiple Slack threads.
Get Gaurav Verma’s stories in your inbox
Join Medium for free to get updates from this writer.
We Established Communication Norms
“Slack is for quick questions that need answers within 24 hours. Email is for important decisions or detailed explanations. Loom videos are for complex things that need visual explanation. Meetings are for strategic decisions or working through disagreement.”
Before, we were using Slack for everything. Asking strategy questions. Making product decisions. Writing RFCs that should have been documents.
Once we had norms, people knew what channel to use and what response time to expect.
We Built Actual Rituals
Weekly all-hands where we share wins and updates. Recorded so people in different timezones can watch async.
Monthly virtual lunch where we just talk (no work). We hire someone to run an online game or activity. People actually connect.
Quarterly in-person week where the whole team gets together (we make it a company expense, mandatory). We do strategic planning, we bond, we remember that we’re actually a team.
These rituals feel expensive and time-consuming. But they’re what made people feel like part of something instead of isolated individuals.
We Hired for Async-First Communication
When we hired people, we stopped looking just at skills. We looked at whether they actually knew how to work async.
Can they write clearly? Do they ask clarifying questions? Can they work independently without constant hand-holding? Have they successfully worked remote before?
We started rejecting candidates who needed real-time collaboration or constant check-ins. They wouldn’t be successful anyway.
We Got Ruthless About Documentation
Not just “here’s the handbook.” But obsessive documentation.
Why do we do things this way? What’s the history? What approaches did we try before? What’s the decision framework? If this changes, here’s how to update the documentation.
Documentation became the source of truth. New people could onboard themselves because everything was written down.
The Results (Three Months Later)
After implementing these changes, something shifted.
People started actually engaging. Our Philippines team member started contributing ideas in Slack (at their own working hours). The Poland team was showing up to the one meeting we scheduled in their timezone. The designer was on-time with work and the quality improved.
We weren’t having the “everything is a disaster” conversations anymore.
Was it perfect? No. We still had miscommunications. We still had time zone friction. But we had systems to catch problems early instead of discovering them months later.
More importantly, people felt connected. Our contractor from the Philippines told me the company actually felt like a company now. The Poland engineer said she finally understood what we were building and why it mattered.
That’s worth everything.
The Thing Nobody Tells You About Distributed Teams
Distributed teams aren’t hard because remote work is inherently chaotic. They’re hard because most companies don’t actually build systems for them. They just put people on video calls across time zones and hope it works.
The companies that succeed aren’t smarter than you. They’ve just made intentional choices about communication, overlap, documentation, and culture.
They treat distributed team building as a completely different skill than in-office management. Because it is.
Once you accept that and actually build systems for it, distributed teams work beautifully. You get access to amazing talent worldwide. You have a resilient business that doesn’t depend on one city. You build a culture that’s intentional instead of accidental.
But you have to actually do the work.
If You’re Thinking About Going Distributed
Before you hire someone in Eastern Europe and throw them in a Slack channel, consider:
Do you have clear communication norms? Will meetings respect time zones? Do you actually know how to write decisions down? Are you building rituals that create connection? Have you documented your processes?
If you answered no to any of those, you’re not ready. Spend the time getting systems in place first.
If you’re already distributed and things feel broken, that’s actually good news. It means it’s fixable. You don’t need new people. You need new systems.
There’s a comprehensive guide here that walks through the full picture of building distributed teams that actually work. It covers infrastructure, compliance, culture — everything we had to figure out the hard way.
Read it before you hire someone. It’ll save you six months of the chaos we went through.
The biggest lesson we learned: distributed teams aren’t about location. They’re about intention.
Build systems. Set norms. Create connection. Document obsessively.
Do that and you build something special. A team that’s spread across the world but genuinely aligned. That feels rare but actually becomes possible when you stop treating distributed like a cost-cutting hack and start treating it like a strategic advantage.
That’s where we are now. And I can’t imagine going back.
