Embracing Remote Culture

Remote work stopped being novel some time ago, which means the interesting question is no longer whether it works but why it works well for some teams and badly for others running apparently the same setup.

In our experience the difference is rarely tooling. It is whether the team changed how it operates or simply moved its existing operating model onto video.

The default failure mode

A team that worked in an office moves to remote. Everything is preserved: the daily standup, the planning meeting, the ad hoc conversations, the decisions made among whoever was nearby.

Each of those transfers badly.

• The standup was thirty seconds standing up. It becomes a scheduled interruption in the middle of the morning that fragments everyone’s focus.
• The ad hoc conversation was a two-minute exchange at a desk. It becomes a calendar invitation, or it does not happen at all.
• The decision among whoever was nearby was already exclusionary. Remote makes it invisible as well.
• The corridor context that new joiners absorbed passively simply stops transmitting.

The team concludes that remote work is harder. What is actually harder is a co-located operating model executed without co-location.

Writing is the core skill

The single largest adjustment. In a distributed team, information that is not written down does not propagate. A decision made in a call exists only for the people on it, and unevenly even for them.

What this means in practice:

Decisions get recorded

Every non-trivial decision gets a short written record: what was decided, what alternatives were considered, why, and who decided. Architecture decision records are the well-known form and the pattern generalises well beyond architecture.

This is not bureaucracy. It is what stops the same debate recurring every four months, and it is what lets someone who joins in a year understand why the system is shaped as it is instead of assuming it was an accident.

Proposals precede discussion

Rather than convening a meeting to think, write the proposal first and circulate it. People read and comment in their own time and time zone. The meeting, if one is still needed, resolves genuine disagreement rather than establishing context.

This is slower to start and much faster to finish. It also produces better decisions, because writing something down exposes the reasoning gaps that speaking past them conceals.

Status is readable, not reported

If the standup exists so people know what others are doing, make that visible in the tools instead. A well-maintained board and clear pull request descriptions tell you more than a round of verbal updates, and they are available at any hour.

Async by default, sync on purpose

The goal is not to eliminate synchronous time. It is to spend it on the things it is uniquely good for.

Worth doing synchronously: genuine disagreement that has not resolved in writing; anything with emotional weight, including difficult feedback; early creative work where fast iteration matters; and relationship building, which does not happen in a document.

Better asynchronously: status; code review; proposals and design documents; most decisions; and anything one person needs to think carefully about before responding.

The mechanics that make async work:

• Clear response expectations. Distinguish urgent from same-day from this-week, and mean it. Without this, everyone treats everything as urgent and nobody gets uninterrupted time.
• Recorded walkthroughs. A five-minute screen recording often communicates better than a long message and costs the recipient nothing in scheduling.
• Meeting notes always, published where everyone can read them. A meeting whose outcome is not written down excluded everyone who was not in it.
• Protected overlap hours, a few per day where synchronous contact is possible, with the rest genuinely free.

Trust has to be structural

In an office, managers use presence as a proxy for productivity. It was never a good proxy and remote removes it entirely, which is why some organisations reach for monitoring software.

Monitoring is a mistake with predictable consequences: it measures activity rather than output, it signals distrust unambiguously, and the people most damaged by that signal are the ones you least want to lose.

The alternative is structural: make output visible instead of activity.

• Work in small, shippable increments so progress is continuously observable.
• Set clear outcomes for a period and evaluate against them.
• Review the work itself — pull requests, documents, shipped features — rather than the hours around it.
• Notice absence of output early and address it as a conversation about obstacles, not attendance.

Onboarding is where it breaks first

An established remote team can coast on relationships formed earlier. New joiners have none of that, and onboarding is where a weak remote culture reveals itself.

What has to become deliberate:

• A written first-month plan with specific outcomes, so the new person always knows what good looks like this week.
• An onboarding buddy with explicitly allocated time, whose job includes answering questions that feel too small to ask a manager.
• A meaningful task in week one. Shipping something small and real does more for confidence and context than two weeks of reading.
• Documentation the new person updates as they go, because they are the only people who can see what is missing.
• Scheduled introductions across the team. The relationships that form incidentally in an office have to be arranged.

Connection needs designing too

Isolation is the most commonly reported downside of remote work and it is a real risk, particularly for people early in their careers or living alone.

What we have seen work, and what we have seen fail:

Works: optional non-work channels; occasional in-person gatherings, which are worth substantial budget because they recharge relationships that then sustain months of remote work; pairing sessions, which build connection and share knowledge simultaneously; and managers noticing withdrawal early.

Does not work: mandatory virtual social events, which reliably produce the opposite of connection; always-on video, which is surveillance wearing a friendly interface; and treating a chat tool as a substitute for genuine relationships.

Boolean Solutions experience with remote

We work as a distributed team and we build with distributed client teams, and the pattern that predicts how well an engagement will go is almost always the same one: whether decisions get written down.

Teams that write have context available to everyone, onboard new people quickly, and lose comparatively little when someone leaves. Teams that do not are constantly reconstructing reasoning from memory, and every absence is a gap.

It is not glamorous advice and it is the highest-leverage change available to most distributed teams. If you are working through how to operate a distributed engineering team, we are happy to talk about what has worked for us.

Further reading

• GitLab’s remote work guide — the most thorough public documentation of an all-remote operating model
• Remote: Office Not Required — Basecamp; short, opinionated, and largely borne out
• Architecture Decision Records — the format, and a good argument for why it matters
• Notes on written culture — practical writing on documentation practice in engineering teams