The Operating Model Playbook for Distributed, Multi-Product Companies

Being distributed is one coordination problem. Running multiple products is a second, separate one. Companies that are both at once — a remote team operating a portfolio of products, the shape covered in our multi-product SaaS portfolio guide— face a compounded version of each: not just “how do we communicate without a shared office,” and not just “how do we structure teams around several products,” but both simultaneously, where getting either one wrong makes the other one worse.

This guide covers how real, well-documented distributed companies actually solve the communication half of that problem — GitLab's handbook-first culture chief among them — the organizational science, dating back to a 1968 paper, that explains why team structure and product structure inevitably end up mirroring each other, the real research on whether remote and hybrid work actually perform, and the moment the industry's most prominent public advocate for async-only culture stood up and said, in public, that he'd overstated the case.

This is also, deliberately, a guide about operating practice rather than organizational structure. Our multi-product SaaS portfolio guide already covers the decision of whether and how to build a portfolio of products at all — the organic multi-hub, independent-portfolio, studio, and holding-company structures. This guide assumes that decision is made and asks the next, more operational question: once you have more than one product and a team that doesn't share a physical office, how do you actually run the thing day to day without either the products or the team quietly drifting into dysfunction neither problem alone would have caused.

Why This Is a Compounding Problem

A single-product, distributed company only has to solve for time zones and asynchronous communication. A co-located, multi-product company only has to solve for how work gets divided across products. A distributed, multi-product company has to solve both at once, and the two problems interact: a communication practice that works fine for one product team can break down the moment two product teams need to coordinate on shared infrastructure across a nine-hour time difference, and an organizational structure that makes sense on a whiteboard can quietly fail the moment it's implemented by people who rarely see each other in real time.

The interaction runs in both directions, which is what makes it a genuinely compounding problem rather than just two separate problems to solve in parallel. Poor product organization makes distributed communication worse, because unclear ownership over which team is responsible for what turns every cross-team question into an ambiguous, slow, asynchronous negotiation about who should even be answering it. And poor distributed-communication practice makes product organization worse in turn, because a team structure that assumes people can quickly clarify ambiguity in a hallway conversation will silently accumulate confusion when that hallway doesn't exist — confusion that shows up, eventually, as exactly the kind of tangled, unintentional architecture Conway's Law predicts. Solving only one side of this problem well is a genuinely common failure mode: a company can have an excellent, well-documented product structure and still struggle, or excellent communication practices layered on top of a genuinely confused product organization, and neither partial fix resolves the underlying compounding effect.

What the Research Actually Shows

Before getting into practices, it's worth grounding this in the strongest available research on remote and hybrid work itself, rather than opinion. Stanford economist Nicholas Bloom's highly-cited randomized controlled trial at the Chinese travel company Ctrip found that employees working from home saw a 13% performance increase, driven mostly by working more minutes per shift and taking fewer breaks and sick days — though those same employees were promoted at half the rate of their office-based peers, a finding that shaped how the company (and much of the subsequent remote-work conversation) thought about the trade-off between output and career visibility (Bloom, Liang, Roberts & Ying, NBER Working Paper No. 18871, 2013). A follow-up randomized trial by Bloom and colleagues at Trip.com, testing hybrid work specifically (two days a week from home rather than fully remote), found hybrid arrangements did not damage performance and meaningfully improved retention, particularly for non-managers and women (Bloom, Han & Liang, NBER Working Paper No. 30292, 2022).

Gallup's own May 2025 workplace survey, covering only the roughly half of U.S. jobs it classifies as “remote-capable,” found 51% working hybrid and 21% fully on-site — a share that had drifted only slightly (down from 55% hybrid two quarters earlier) rather than showing any dramatic return-to-office collapse (Gallup, “Hybrid Work in Retreat? Barely,” Ryan Pendell, 2025). Buffer's 2023 State of Remote Work survey, based on responses from 3,000 remote workers, found 82% working from home specifically (as opposed to co-working spaces or other locations), and, notably, 98% saying they'd like to work remotely at least some of the time for the rest of their careers (Buffer, State of Remote Work, 2023). Read together, this is not a fringe experiment — it's a durable, well-studied, and generally effective way of working, with real, documented trade-offs rather than either the utopian or catastrophic framing either side of the debate tends to favor.

The specific trade-off worth taking seriously from Bloom's own research is the promotion gap observed in the original Ctrip study — remote workers performed better but advanced more slowly, a finding that predates the wave of hybrid-specific research and helps explain why so many companies eventually settled on hybrid rather than fully remote arrangements once given the choice. For a distributed, multi-product company specifically, this has a direct practical implication: if visibility and advancement quietly depend on who happens to be most present in informal conversations with leadership, a distributed team will reproduce the same promotion gap Bloom's research found — which is exactly why the deliberate, engineered informal-connection practices covered later in this guide matter as more than a nice-to-have. They're a direct answer to a specific, documented risk of the model, not just a culture-building exercise.

Buffer's own survey data adds a useful counterweight to any narrative that remote work is purely a cost-saving or productivity play divorced from what employees themselves actually want. The 98% figure — nearly every surveyed remote worker wanting to keep working remotely at least some of the time for the rest of their career — suggests the arrangement isn't merely tolerated as a second-best compromise, which matters for a founder weighing whether a distributed model will help or hurt hiring and retention. Combined with Gallup's finding that the hybrid share of remote-capable jobs has held roughly steady rather than collapsing back toward full-time office work, the overall picture is one of a genuinely settled, durable preference on the employee side, not a temporary pandemic-era anomaly that companies are still waiting to fully unwind.

Async by Default

GitLab's handbook states the philosophy directly: “GitLab is intentional about documenting in a manner that creates a single source of truth. It operates handbook-first... we write things down first, and communicate that…This way there is no need for documentation after the communication, a step that is frequently skipped” ( GitLab Team Handbook, “Handbook-First Approach to Communication”). The company reinforces this structurally, not just culturally — GitLab's Slack messages are retained for only 90 days, a deliberate forcing function that makes chat unsuitable as a place to store anything that actually needs to be found later, pushing real decisions back into the handbook where they belong.

GitLab's own async communication guidance is specific about what this means day to day: asynchronous communication “is the art of communicating and moving projects forward without the need for additional stakeholders to be available at the same time” — concretely, this means defaulting to merge requests and issues over live meetings, and explicitly stating that there is “no expectation to respond to messages outside of your planned working hours” ( GitLab Team Handbook, “Communication”). This matters more, not less, once a company runs multiple products: with several product teams each operating on their own cadence, an assumption that everyone will be online at the same time to receive an announcement breaks down fastest exactly where coordination matters most.

There's a specific multi-product wrinkle worth naming explicitly: handbook-first documentation works best when it's organized by the actual question someone is trying to answer, not by which team happens to own the answer. A support engineer on Product B who needs to understand a shared authentication system Product A's team maintains shouldn't have to know, in advance, which team's section of the handbook to search — the documentation itself needs to be structured around shared systems and cross-cutting concerns, not just mirrored one-to-one against the org chart. This is a subtle but real failure mode: a company can be genuinely handbook-first and still make information hard to find across product boundaries, simply because the handbook's own structure was designed around a single-product mental model.

Engineering Informal Connection

The obvious risk of an async-first culture is that it strips out the informal, unplanned interaction that builds trust and relationships in a physical office — the hallway conversation, the coffee run. GitLab's own answer to this isn't to ignore the problem, but to engineer informal connection deliberately rather than leave it to chance. Co-founder Sid Sijbrandij has described the practice directly: “every person who joins GitLab has to schedule at least 5 coffee chats during their onboarding” alongside “Ask Me Anything meetings with senior leaders” and over 15 other structured ways to build relationships that don't depend on shared physical space (GitLab Team Handbook, “Informal Communication in an All-Remote Environment”).

“If you do all-remote, do it early, do it completely, and change your work methods to accommodate it. Be intentional about informal communication. All-remote forces you to do the things you should be doing anyway, earlier.”

— Sid Sijbrandij, GitLab co-founder

Sijbrandij's framing is worth taking seriously beyond the specific coffee-chat mechanic: his argument is that distributed work doesn't introduce a new problem so much as it removes the excuse to leave an existing one to chance. A co-located team can coast on accidental hallway relationship-building for years without anyone noticing it's happening. A distributed team notices the absence immediately, which forces the practice to become deliberate — a forcing function GitLab treats as a genuine advantage of the model, not just a workaround for its downside.

For a multi-product company specifically, this deliberateness needs to extend across product boundaries, not just within a single team. It's easy for a coffee-chat program to accidentally reproduce the same silos a functional org chart already tends to create — new hires connecting mostly with people on their own product team, and rarely with anyone building something else under the same parent company. A distributed multi-product company that wants the cross-pollination benefits of a shared parent — the retention and knowledge-sharing advantages covered in our portfolio guide — needs to design its informal-connection programs to deliberately cross those product boundaries, not just deliberately cross the geographic ones GitLab's own practice was originally built to solve.

Conway's Law and Team Structure

Conway's original paper, published in Datamation in April 1968 after being rejected by the Harvard Business Review the year before, made an observation that has held up remarkably well across more than five decades of software organizations (Melvin E. Conway, “How Do Committees Invent?,” Datamation, April 1968). For a multi-product company, the implication is direct: if your engineering team is organized as one undifferentiated pool working across every product interchangeably, your products will tend to develop tangled, interdependent architecture that mirrors that lack of separation — regardless of how cleanly you intended the products to be separated on a roadmap. If, instead, distinct teams own distinct products with clear boundaries, the products themselves tend to end up more cleanly separated, because the communication structure that produced them was cleanly separated too.

A specific application of Conway's Law, generally referred to as the “Inverse Conway Maneuver” — commonly attributed to Jonny LeRoy and Matt Simons, writing in Cutter IT Journal in December 2010 — flips the observation into a deliberate strategy: instead of letting your architecture passively mirror whatever team structure you happen to have, you can deliberately restructure your teams first, to match the software architecture you actually want to end up with. For a distributed multi-product company deciding how to organize engineers across products, this is the single most actionable piece of organizational theory available: don't ask “how should we organize our teams,” ask “what architecture do we want, and what team structure would naturally produce it.”

Amazon's well-known “two-pizza team” concept, attributed to Jeff Bezos and documented in journalist Brad Stone's book The Everything Store (2013) and corroborated by Amazon's own AWS materials, is a related, practical instance of the same idea: keep a team small enough to be fed by two pizzas, give it ownership of a specific, bounded piece of the system, and let Conway's Law work in your favor rather than against you — a small, clearly-scoped team naturally tends to produce a small, clearly-scoped piece of software.

Conway's Law bites hardest on a distributed team specifically because the communication structure it describes is harder to observe from the outside than it would be in a shared office. In a co-located company, you can often see the informal, undocumented communication patterns forming — who eats lunch together, whose desks are near each other — and correct for them before they calcify into architecture. On a distributed team, those informal patterns still form, just less visibly: which engineers happen to overlap in working hours, who's active in the same Slack channels, who naturally jumps on the same calls. Those invisible patterns shape the architecture exactly as strongly as visible office proximity would, which means a distributed company needs to be more deliberate, not less, about designing its communication structure on purpose rather than discovering it after the fact in the shape of a tangled codebase.

Organizing Around Products, Not Functions

The classic organizational alternative to product-based teams is a functional structure — one engineering team, one design team, one support team, each serving every product on request. This is a real, legitimate structure, formally studied under the banner of matrix organization design by Jay R. Galbraith, whose book Designing Matrix Organizations That Actually Work (2009) remains the standard reference for the trade-offs involved in organizing simultaneously along more than one dimension — product, function, and geography all at once.

For most distributed, multi-product companies below a certain scale, a pure product-based structure — the Inverse Conway Maneuver applied directly — tends to be the easiest to operate well, precisely because a distributed team already has less bandwidth for resolving the ambiguity a matrix structure introduces than a co-located team would. Matrix structures work, per Galbraith's own research, but they demand more explicit, better-documented conflict-resolution processes than most companies build until they're forced to by scale — which is exactly the kind of explicit, written-down process GitLab's handbook-first culture is built to support.

The functional structure's coordination cost is easy to underestimate until it's experienced directly: a single, shared design team serving five products isn't five times more coordination overhead than serving one product, it's worse than that, because every request now has to be prioritized against every other product's requests, and that prioritization negotiation itself becomes a recurring, ongoing cost every product team pays indefinitely. A dedicated product team, by contrast, pays a one-time cost to duplicate some shared capability, in exchange for never having to negotiate priority with anyone outside the team again. For a distributed company specifically — where every negotiation is slower by default, since it can't be resolved in a two-minute hallway conversation — that recurring negotiation cost compounds faster than it would for a co-located functional team, which is the specific reason product-based structure tends to be the more forgiving default for a distributed multi-product company.

Managing Time Zone Spread

Doist, the company behind Twist and Todoist, publishes its own practical guidance on this specific problem: capping recurring synchronous meetings to roughly once a week per meeting type (team meeting, project meeting, one-on-one), setting a maximum expected response time of 24 hours for asynchronous messages, and rotating meeting times across time zones rather than fixing them permanently to favor whichever region happens to be easiest to schedule around (Twist (Doist), “Remote Team Communication”). The rotation detail is worth calling out specifically: a fixed meeting time technically works for everyone on paper, but in practice it consistently disadvantages whichever time zone draws the short straw, week after week, in a way that quietly erodes morale on a distributed team even when nobody formally complains about it.

A multi-product company adds a specific wrinkle to time-zone planning that a single-product company doesn't face: cross-product coordination meetings — the ones that genuinely need real-time discussion, like resolving a conflict over shared infrastructure between two product teams — tend to involve more people across more time zones than a single product team's own internal meetings do, simply because more teams are in the room. This is exactly the kind of meeting Doist's own guidance would flag as the rare, justified exception to a general no-synchronous-meetings default, precisely because the coordination problem it's solving is genuinely hard to resolve asynchronously — but it's also exactly the kind of meeting most likely to quietly become a recurring weekly habit if nobody deliberately caps it, since it involves enough people that no single team feels ownership over questioning whether it still needs to exist.

1. 1

   Cap recurring synchronous meetings, don’t default to them

   Doist’s own guidance caps each meeting type at roughly once a week — treat a synchronous meeting as an exception that needs justifying, not the default mode of coordination.

2. 2

   Set an explicit, reasonable async response-time expectation

   A stated 24-hour response window, per Doist’s guidance, removes the ambiguity that otherwise makes people feel obligated to be always-available.

3. 3

   Rotate meeting times across time zones

   No single region should permanently draw the early-morning or late-night slot — rotate the burden explicitly rather than defaulting to whichever zone is most convenient for leadership.

4. 4

   Document decisions in a single, shared, versioned handbook

   GitLab’s handbook-first model exists specifically so a decision made at 2am in one time zone is fully available, in writing, to someone starting their day 12 hours later.

How Portfolio Operators Run Multiple Businesses

The multi-product operators covered in our portfolio guide offer real, if differently-documented, models for the operating question specifically. Tiny, Andrew Wilkinson's holding company, states its operating philosophy directly on its own site: “Leave People Alone”, explained as leaving decisions to “the people who built the business” because they “know it better than we ever will,” and “Avoid Synergy,” on the grounds that “‘synergy’ is usually code for meddling” ( Tiny, About). Constellation Software follows a broadly similar pattern at much larger scale, reportedly running a lean central head office focused narrowly on capital allocation and legal/tax matters, while leaving sales, product, and hiring decisions fully decentralized to each operating group — a structure that only works, for either company, because of exactly the kind of clear, written operating boundaries Conway's Law and the Inverse Conway Maneuver would predict a company needs when it deliberately avoids centralizing coordination.

The throughline across both companies' stated philosophies is a specific kind of restraint: the parent company's job is to set clear boundaries and then genuinely stay out of day-to-day operating decisions, rather than nominally decentralizing while still second-guessing every call from the center. For a distributed team specifically, this restraint matters even more than it would for a co-located parent company, because the natural tendency to informally check in — a hallway conversation, a drop-by — simply isn't available as a backdoor around the stated boundaries. Distributed operation, in this sense, forces the discipline these portfolio operators describe rather than merely permitting it.

It's worth being precise about what “Avoid Synergy” actually rules out, since it's easy to over-read as a blanket argument against any shared infrastructure at all. Tiny's framing targets forced, top-down coordination — a parent company insisting two businesses collaborate because it looks efficient on paper, regardless of whether either business actually benefits. It doesn't rule out voluntary, bottom-up sharing, where one product team chooses to reuse another team's authentication system or design components because it genuinely saves them real work. The distinction matters for a distributed multi-product company deciding how much shared infrastructure to build centrally: the failure mode isn't sharing itself, it's sharing imposed from above onto teams who didn't ask for it and don't actually benefit from it.

When Async-Only Culture Fails

It's worth taking seriously the strongest available critique of the exact model this guide has largely been describing — and the most credible version of that critique comes from inside the movement itself. Amir Salihefendić, Doist's own CEO and one of the most prominent public advocates for async and remote work over the past decade, posted publicly in January 2024 that his company was “moving away from promoting remote or async work” as the primary explanation for good results: “We will continue being remote and async first, but they aren't the core reasons we do great work. It's a mirage to believe that remote or async work is the primary solution.”

“It's a mirage to believe that remote or async work is the primary solution.”

— Amir Salihefendić, Doist CEO, January 2024

This is a genuinely important corrective, coming from someone with every incentive to keep promoting the model rather than complicate it publicly. The implicit argument is that async and remote practices are enabling conditions, not causal ones — a company can adopt every practice in this guide and still fail, if the underlying product, team quality, and clarity of purpose aren't there, and conversely a company with excellent fundamentals can succeed despite imperfect async discipline. Basecamp's own long-running remote practice, documented in founders Jason Fried and David Heinemeier Hansson's book Remote: Office Not Required (2013), makes a compatible point from a different angle: remote work removes a set of excuses and distractions, but it doesn't substitute for the harder work of building a good product with good people, which was always the actual point.

The practical takeaway for a distributed multi-product company isn't to abandon async-first practices — Salihefendić himself said Doist would remain remote and async-first even after the correction. It's to hold the practices and the outcomes as separate things to evaluate separately. If a product team is struggling, the first diagnostic question shouldn't automatically be “are we async enough” — it might be a genuinely weak product idea, an unclear mandate, or the wrong people on the team, none of which more documentation or fewer meetings will fix. Treating every organizational problem as a communication-practice problem is its own kind of category error, just as much as ignoring communication practice would be.

Building Your Operating Model

Combining the practices above into a working operating model for a distributed, multi-product company looks like this, in sequence:

None of these steps substitutes for the others, and Salihefendić's own reversal is the reminder worth keeping closest at hand: this operating model makes good execution possible, it doesn't replace the need for it.

Sequencing matters here more than it might first appear. A company that tries to go handbook-first before it has organized teams around clear product boundaries ends up documenting confusion rather than clarity — a beautifully written handbook describing an org chart that doesn't actually map to how the products are structured just makes the underlying confusion easier to find, not easier to fix. Structure has to come first, or close to it, because every other practice in this list assumes there's a clear answer to “whose decision is this” before it can be written down, communicated asynchronously, or respected by a restrained parent company. Get the structure roughly right early, and the remaining four practices become steadily easier to implement well as the company grows; get it wrong, and no amount of documentation discipline fully compensates.

Mistakes to Avoid

Most of the mistakes below share a common shape: adopting the visible surface of a practice without the underlying discipline that made it work for the company it was borrowed from. A handbook with no one actually enforcing the “write it down first” norm, a coffee-chat program nobody actually attends, a product-team structure drawn on an org chart but not respected in practice — each looks identical to the real thing from the outside, while producing none of its benefit.

• Treating chat as documentation. GitLab's deliberate 90-day Slack retention exists specifically to prevent this — a decision that only lives in a chat thread is a decision that will be re-litigated the next time someone in a different time zone needs it and can't find it.
• Letting informal connection happen by accident. A distributed team that assumes relationships will form the way they do in an office will simply not form them — Sijbrandij's framing is specific: this has to be engineered, not hoped for.
• Organizing teams without considering Conway's Law. An engineering org that doesn't map cleanly onto the products it's building will produce architecture that doesn't map cleanly either, regardless of how the roadmap is drawn.
• Fixing meeting times to favor one time zone permanently. This quietly and consistently disadvantages the same people every time, which corrodes morale even when nobody formally objects.
• Believing async and remote practices are themselves the source of good results. Salihefendić's own correction is the clearest warning available: these are enabling conditions, not a substitute for building a genuinely good product with genuinely good people.
• Letting cross-product coordination meetings become an unquestioned recurring habit. These meetings are the legitimate exception to a no-synchronous-meetings default, but their size and shared ownership make them the easiest kind of meeting to let persist long after the coordination problem they were solving is resolved.
• Imposing shared infrastructure on product teams that didn't ask for it. Tiny's own “Avoid Synergy” principle targets exactly this pattern — voluntary, bottom-up sharing between teams is different from top-down mandated coordination that looks efficient on paper but serves no team's actual needs.

Frequently Asked Questions

It's worth returning, one last time, to the specific companies this guide draws on, because they're instructive as a set, not just individually. GitLab, Doist, Tiny, Constellation Software, and Basecamp are structurally quite different businesses — a public dev-tools company, a small productivity-software maker, a diversified internet holding company, a serial acquirer of vertical software businesses, and a privately-held project-management company — and yet each one arrived, independently, at some version of the same core discipline: write things down, give people real ownership over a bounded piece of the business, and resist the urge to impose coordination that isn't actually needed. That convergence, across companies with almost nothing else in common, is itself a form of evidence — not proof that any single practice is mandatory, but a strong signal that the underlying discipline behind all of them is solving a real, recurring problem rather than reflecting one company's particular culture or personality.

The through-line across GitLab's handbook, Conway's fifty-year-old paper, Bloom's randomized trials, and Salihefendić's own public reversal is the same one running through this entire guide: distributed, multi-product operation is a real, well-studied, and genuinely workable model — but it's a set of enabling practices, not a strategy in itself. Getting the operating model right removes the excuses. It doesn't remove the need to build something worth operating in the first place.