The Stack Overflow Developer Survey 2024 reported that, six years after the pandemic-driven shift, sixty-six percent of professional developers were working in fully remote or hybrid arrangements, and that the proportion was higher in Western European engineering organisations than in any other geography surveyed.1 The shift is durable. The discourse around it is mostly noise. Most of what is published about "hybrid" concerns where people physically sit, which is the part of the problem that matters least.
The part that matters is decision latency. When an architect in Geneva makes a call at 16:00 and the senior engineer in Porto finds out the next morning through a Slack message with no context — that is where things break. Not because people are remote. Because information moved poorly. The problem is structural and well-documented; the solutions are, by now, also well-documented and disappointingly under-applied.
The real problem is not where people sit
Every CTO in Romandy now operates some version of the same setup: a core team in Geneva or Lausanne, several engineers in Berlin, Lisbon, Sofia, or Bangalore, perhaps a squad in a nearshore partner's office in Porto or Belgrade. Everyone calls it "hybrid." Almost no two organisations mean the same thing by it.
The location model is largely a distraction. The DORA Accelerate State of DevOps research programme, in its 2023 and 2024 reports, has repeatedly found that team-level practices — psychological safety, learning culture, documentation discipline, decision-making transparency — correlate far more strongly with delivery performance than physical-presence arrangements do.2 GitLab, the canonical remote-first software company, has codified its operating model into a public handbook of approximately 3,000 pages, the central organising principle of which is that handbook-first communication replaces ambient context.3
The problem is not remote work. The problem is operating distributed teams with co-located habits.
Decisions need a protocol, not a policy
In co-located teams, decisions happen in hallways. People overhear things. Course corrections happen in real time. Distributed teams have no ambient awareness, and no quantity of Slack channels recreates it. What works instead is being explicit about how decisions get made and recorded — not in a heavy governance way, in a we write things down way.
The lightest viable artefact for this is the Architecture Decision Record. Michael Nygard described the pattern in 2011: a one-page document per non-trivial technical decision, recording title, context, options considered, decision, status, and consequences.4 The pattern is now ubiquitous in well-run engineering organisations and effectively absent in poorly-run ones. The ADR is not architecturally important because it documents the answer. It is important because it documents the question the decision was answering — which is the piece of context that allows a new engineer, or a remote engineer, or the same engineer twelve months later, to evaluate whether the answer still holds.
Once an organisation has ADRs, two further practices compound their value. A decision scribe in any meeting where remote participants are absent — typically a rotating responsibility — converts whiteboard conclusions into written ADRs before the day ends. And a decision log that is searchable, version-controlled, and linked from project channels makes the record discoverable rather than archaeological.
The discipline is unglamorous. The effect is large. Organisations that have adopted it consistently report that onboarding compresses, that senior engineers spend less time relitigating past choices, and that CTOs stop being decision bottlenecks because the reasoning behind prior calls is visible.
Async-first is a stance, not a tooling choice
Declaring an organisation "async-first" and then scheduling six hours of video calls per day is lying with extra steps. The DORA research and the engineering-leadership literature have converged on a more honest framing: async-first means designing work so that the default communication path is written and asynchronous, with meetings reserved for the genuinely-synchronous-only — debate, alignment under tension, sensitive feedback, things text genuinely cannot carry.
The CTO's own behaviour is the lever. If a CTO responds to every Slack message within minutes, the team learns that synchronous communication is the expected default. If a CTO demands video calls "to stay aligned," the implicit message is that written communication is not trusted. The pattern that works, observable across the strongest distributed engineering organisations, is roughly: written check-ins replace status meetings; deep-work blocks are calendar-protected at organisational level, not individual level; meetings are scheduled when async is genuinely insufficient and end with a written summary that becomes the record. Atlassian's 2024 State of Developer Experience research found that engineers in organisations with this pattern reported substantially lower context-switching cost and higher self-rated focus quality.5
The intuition that "async work is slower" is, in the controlled-comparison literature, generally false. Async work is slower in the first ninety days as the habits and artefacts are built; thereafter it is faster, because the cost of interrupting deep work and the cost of re-explaining context to absent participants are both removed from the daily budget.
The office is not dead — but its purpose changed
There is real value in being together physically. The value is no longer "this is where work happens." The value is relationship density: trust-building, onboarding, the early stages of architectural design where whiteboarding still genuinely outperforms collaborative software, retrospective conversations that benefit from non-verbal signal, and the social glue that makes the rest of the operating model survive disagreement.
Use office days for the things that are demonstrably better in person. Onboarding a new engineer. Running team retrospectives. Working through the first sketches of a major architectural change. Mentoring sessions between staff engineers and senior engineers. Team meals. Stop using office days for status meetings that could be a Loom video or a written check-in.
The failure mode to actively audit is two-tier culture. The 2023 and 2024 studies of post-pandemic hybrid work — including the Microsoft Work Trend Index series and the Atlassian research — both found that office-present engineers frequently receive faster access to context, decisions, and informal sponsorship for promotions, and that this gap, if unaddressed, drives attrition among remote engineers within twelve to eighteen months.6 The audit is not difficult. Examine who gets pulled into design discussions. Examine who is credited in performance reviews. Examine which engineers leadership names spontaneously when asked about high-performers. If a proximity bias is visible in any of these, the remote engineers will leave, and the audit will become an exit-interview pattern rather than a preventable one.
Code review is the secret alignment tool
In a distributed engineering organisation, pull requests are the most honest communication channel available. They are timestamped, written, contextually anchored to the work itself, and inherently asynchronous. The DORA research has shown for over a decade that high-performing engineering organisations are distinguished by small, frequent, well-reviewed pull requests rather than by any specific tooling choice.2 A team that invests seriously in its code review culture — substantive review comments, response-time expectations, explicit norms about when to LGTM-without-reading versus when to ask a clarifying question — gets two things at once: better code, and a parallel-async communication channel that compounds team trust without any meeting overhead.
The teams that get this right treat PR review as a coaching surface. Reviews become the conversation in which staff engineers transfer the architectural taste that, in co-located teams, transfers through whiteboard sessions and shoulder-surfing. The teams that get this wrong treat reviews as a formality, and discover, eighteen months in, that their senior engineers are siloed and their juniors are isolated.
What this means operationally
Technical leadership in distributed teams is not principally about tools or policies. It is about reducing the time between a decision being made and everyone needing to act on it understanding why. Five practices, in order of leverage: write decisions down in lightweight ADRs, kept searchable and versioned; default to asynchronous communication and protect the default with the CTO's own behaviour; reserve meetings for the genuinely-synchronous-only and end them with written summaries; use office days for relationship-dense work, not for status; and ruthlessly audit whether co-located habits are creating invisible promotion or context advantages for the engineers who happen to be near leadership.
The teams that get this right ship faster — not despite being distributed, but because the discipline of explicit decision capture and asynchronous communication makes them sharper than co-located teams that operate on ambient context and informal authority. The teams that do not get it right do not fail dramatically. They lose their best remote engineers over twelve to twenty-four months, attribute the attrition to "the remote work didn't work for them," and rebuild the same operating model with new people who will, on average, encounter the same problems.
The model is unromantic. The differentiation it produces is durable.