Building a Culture of Deep Work in a Remote-First Company
Team and Culture5 min read

On this page
Remote work came with a promise that most teams only half received.
The promise was flexibility. Autonomy. No commute, no open office, no someone tapping you on the shoulder mid-thought. The freedom to do your best work from wherever you worked best.
What came with it, quietly and almost immediately, was something else entirely. A Slack notification at 8am. A message marked urgent at 9. A meeting that could have been an email, followed by an email that could have been a document, followed by a document nobody read because there was another meeting. Remote work did not remove the interruptions. It just moved them online and made them available twenty-four hours a day.
For our engineering team, the result was a calendar full of flexibility and a workday full of noise. We had the autonomy to work from anywhere. We just could not find more than twenty minutes in a row to actually think.
What We Were Getting Wrong
The assumption we had been operating under was that presence equaled productivity. If someone was online, responding to messages, visible in channels, they were working. And in a remote environment where you cannot see people at their desks, that visibility felt important.
What we discovered when we started paying closer attention was that our most valuable work, the thinking, the designing, the problem solving that actually moved things forward, was not happening in that visible, responsive state. It was happening in the rare, accidental pockets of quiet that people carved out between meetings. And those pockets were getting smaller every week.
The meetings were not malicious. Nobody was scheduling things carelessly. But every single meeting, however short, however well intentioned, had a cost that did not show up on the calendar. The cost was the time before and after, the wind-up and wind-down that deep work requires. A thirty-minute meeting in the middle of the morning does not cost thirty minutes. It can cost the entire morning.
How We Rebuilt the Day

The first decision was to stop treating meetings as the default format for communication.
Most things that were happening in meetings did not need to happen in meetings. Status updates, progress checks, decisions on questions that had already been thoroughly discussed, all of it could live in writing. So we moved it there. Standing meetings became written updates. Decisions that previously required a call started ending with a one-paragraph summary posted to a shared channel with a named owner and a clear next action.
This did not happen overnight and it did not happen without resistance. Writing is slower than talking in the moment, which made it feel less efficient even when it was more effective. We had to make the case repeatedly that the goal was not to eliminate communication but to make it asynchronous by default so that synchronous time became genuinely valuable when we used it.
The second decision was to protect focus time structurally, not just culturally.
Culture changes are slow. Policies are faster. We blocked two focus windows on the team calendar every day, one in the morning and one in the afternoon, during which no meetings could be scheduled. We called them maker hours and we enforced them. Not rigidly, not with disciplinary weight, but with genuine team commitment. If something was important enough to interrupt a maker hour, it had to clear a real bar.
The third decision was to define response time expectations by channel rather than assuming everything needed an immediate answer. Urgent issues had a channel with a fifteen-minute response expectation. General questions had a four-hour window. Non-urgent requests could wait until the next day. Having those norms written down and agreed on meant that not responding immediately stopped feeling like negligence and started feeling like the system working as designed.
What Actually Changed
Six months after we began, meeting hours across the team had dropped by sixty percent. The remaining meetings were shorter, more focused, and more decisive because they were reserved for things that genuinely required real-time conversation.
What we got back was not just time. It was quality. Engineers started commenting that they were solving problems in hours that had previously taken days, not because they were working faster but because they were finally able to think without interruption long enough to actually get somewhere. Design work improved. Code review became more thoughtful. The work that required depth started getting depth.
The less visible change was in energy. The particular exhaustion that comes from a day spent context switching, never fully in one thing, never fully out of another, started to lift. People were tired at the end of the day in the good way, the way that comes from having done something substantial, rather than the hollow, scattered tiredness of a day spent putting out small fires.
Starting Smaller Than You Think You Need To

If you are building a remote team and trying to create space for deep work, the instinct is to redesign everything at once. New meeting norms, new communication tools, new response-time policies, new everything.
The instinct is understandable and it usually fails. Culture does not shift because a new policy gets announced in a company all-hands. It shifts because one team tries something, it visibly works, and other teams start asking questions.
Start with one team. Protect two hours a day. Measure meeting hours before and after, and share what you find. That is enough to begin. The rest follows from the evidence.
The deep work your team is capable of is already there. It is just waiting for the noise to stop long enough to get out.
Build the kind of clarity your team deserves. Start with SaneHQ

Continue reading

The Hidden Cost of Context Switching (And How to Minimize It)
We did not remove urgency. Urgent things still got handled urgently. We did not make the team less responsive. We made the team more deliberately responsive, which turned out to be more useful than reflexively responsive had ever been.

Why We Killed Our Daily Stand-ups (And What We Did Instead)
The original purpose of a daily standup is legitimate. You want the team to be aligned. You want blockers surfaced quickly. You want people to know what their colleagues are working on so work does not get duplicated or fall through gaps.

The Art of Saying No: How We Shipped 40% Faster
We made our roadmap visible to everyone inside and outside the company. Not just what we were building but why, what outcome each initiative was aimed at, what evidence supported the decision, and what would change our minds. That transparency did something unexpected: it reduced the pressure to say yes to things. When people could see our reasoning, they stopped lobbying as hard. They understood the constraints. Sometimes they even helped us refine the criteria.