67% of distributed teams struggle with culture. Is this a remote work bug or a feature exposing weak foundations?

General
1

I just came across GitLab’s latest research on distributed teams, and one statistic stopped me cold: 67% of distributed teams struggle with cultural alignment. My immediate reaction? This isn’t a remote work problem—it’s a diagnostic tool exposing organizational debt we’ve been ignoring for years.

Context: Scaling Remote-First at EdTech

I’m currently VP of Engineering at a high-growth EdTech startup, scaling our team from 25 to 80+ engineers—fully remote from day one. We made an intentional choice to build remote-first, not because of COVID, but because we believed it would help us access diverse talent and build a more inclusive organization.

Here’s what I’ve learned: If your culture breaks when you go distributed, it was already broken. You just couldn’t see it through the fog of physical proximity.

The Uncomfortable Truth About “Office Culture”

Let me be direct: most “collaborative office cultures” were actually covering up dysfunctional processes with proximity.

Think about it:

  • Water cooler conversations masked the fact that you had no intentional communication architecture
  • “Just swing by my desk” meant you never documented decisions or created knowledge systems
  • Overhearing discussions compensated for unclear project ownership and poor information sharing
  • Lunch conversations hid the reality that only extroverts or those in the “in-group” actually knew what was happening

Remote work didn’t create these problems. It just made them impossible to ignore.

What the Data Actually Tells Us

GitLab’s research reveals some powerful insights:

Teams with strong documentation practices experienced 67% fewer blocking delays compared to teams relying primarily on synchronous communication. Think about what that means—the issue isn’t remote work. It’s the lack of systems.

Well-structured rituals lead to 76% higher team cohesion and 82% better knowledge retention. Again, this isn’t about being in an office. It’s about intentional design.

Remote onboarding takes 30-50% longer when you don’t have proper processes. But here’s the thing—those processes should have existed regardless of location. We just got away with chaotic onboarding in offices because someone could physically grab a new hire and show them the ropes.

What Successful Remote Teams Do Differently

The teams that thrive remotely aren’t doing anything magical. They’re just doing what every team should have been doing all along:

1. Design Information Architecture

They don’t just pick collaboration tools—they architect how information flows. Who needs to know what? When? In what format? They make these decisions explicit instead of assuming proximity will solve it.

2. Build Trust Through Consistency and Clarity

In co-located teams, trust often came from proximity and informal interactions. In remote teams, trust comes from consistency, clarity, and care. Can team members count on you to respond within agreed timeframes? Are expectations crystal clear? Do you demonstrate genuine care for people’s wellbeing across timezones?

3. Create Intentional Rituals

Instead of relying on spontaneous water cooler moments, successful remote teams design rituals:

  • Regular 1-on-1s with structured agendas
  • Team retrospectives with psychological safety
  • Async brainstorming with clear timeboxes
  • Virtual coffee chats with random pairings across teams

The difference? These are designed not accidental. And designed systems scale better than accidental ones.

The Real Question

Here’s what I keep coming back to: that 67% statistic might actually be revealing something powerful. Maybe distributed work is forcing us to build the kind of explicit, inclusive, scalable culture that we should have had all along.

My question to this community: What processes or practices worked “fine” in your office but completely failed when you went remote? And more importantly—what does that failure tell you about the actual quality of those processes?

I suspect we’ll find that most “culture struggles” in remote teams are actually communication process gaps that physical proximity was masking. And that’s not a bug in remote work—it’s a feature that’s forcing us to level up.

What’s your experience been?

2

@vp_eng_keisha This resonates deeply. I’m currently facing this exact challenge as CTO at our mid-stage SaaS company—scaling from 50 to 120 engineers while building a remote-first culture. Your framing about remote work as a diagnostic tool is spot-on.

Let me add the strategic dimension I’m wrestling with: Remote work doesn’t just expose weak culture—it forces you to design culture explicitly instead of letting it emerge through osmosis.

The Osmosis Trap

In offices, we got lazy. Culture happened accidentally through:

  • Physical proximity creating “knowledge through overhearing”
  • Hallway conversations making decisions feel participatory
  • Seeing people at their desks giving illusion of alignment
  • Shared lunch orders creating sense of community

None of that is designed. It’s just… happening. And we called it culture.

Example: What “Collaborative” Actually Means

Here’s what happened at our company. Pre-remote, we proudly described ourselves as having a “highly collaborative culture.” Everyone nodded along.

Remote forced us to ask: What does collaborative actually mean?

Turns out, our “collaborative culture” meant:

  • People interrupted each other constantly
  • No clear decision-making framework
  • Whoever talked loudest in meetings won
  • Engineers got pinged on Slack 50+ times per day
  • “Collaboration” was code for “everyone has to be involved in everything”

That’s not collaboration. That’s chaos with a positive spin.

Going remote forced us to define:

  • What decisions require synchronous discussion vs async input?
  • How do we make decisions transparent without requiring everyone’s real-time participation?
  • What does “collaborative” mean for someone in a different timezone?
  • How do we balance input-gathering with decision velocity?

The result? We built a decision-making framework:

  • Type 1 decisions (reversible): Owner decides, announces in Slack, 24hr comment period
  • Type 2 decisions (hard to reverse): Written RFC, async feedback, synchronous discussion for conflicts, final call documented
  • Strategic decisions: Leadership alignment first, then team input, then decision with clear rationale

Is this more work upfront? Yes. Does it scale infinitely better than “just talk about it”? Absolutely.

Activity ≠ Culture

Here’s what I’m seeing across our peer companies: Many leaders mistake activity for culture.

  • Seeing people in the office = “good culture”
  • Full Slack channels = “engagement”
  • Lots of meetings = “collaboration”
  • Long hours on-site = “commitment”

Remote reveals the truth: none of that is culture. That’s just visible activity.

Real culture is:

  • Shared values that guide decisions
  • Clear norms about how we work together
  • Explicit processes that embody our principles
  • Trust that comes from consistency, not proximity

The hard part? These things must be codified and communicated when you’re remote. You can’t rely on “you’ll pick it up by being here.”

The Hidden Benefit

The uncomfortable truth that’s actually exciting: Intentional culture scales better than accidental culture.

Our remote-forced cultural design has delivered unexpected benefits:

  • New engineers onboard faster with explicit documentation
  • Async communication creates automatic knowledge base
  • Clear decision frameworks reduce bike-shedding
  • Timezone distribution forces better work-life boundaries
  • Written communication favors thoughtful input over fast talking

We wouldn’t have built any of this if office proximity let us stay lazy.

The Challenge to Leaders

Keisha, your question about what processes failed going remote is perfect. But I want to flip it:

How many processes that we think are “working” in offices are actually just covering up dysfunction with physical proximity?

And more importantly: How many “culture issues” are really just communication process gaps that we’re too lazy to fix?

Because here’s my bet: that 67% struggling with cultural alignment aren’t struggling because they’re remote. They’re struggling because they never actually designed their culture—they just assumed being in the same building was enough.

Remote work didn’t break culture. It just stopped letting us pretend that proximity equals alignment.

3

Both @vp_eng_keisha and @cto_michelle are hitting on something crucial, and I want to add a dimension from my experience leading distributed teams across the US, Latin America, and India: The cultural alignment struggle isn’t just about remote work—it’s about whether we’re building inclusive culture or defaulting to majority culture.

Culture ≠ Location-Based Rituals

Here’s what I’ve learned leading 40+ engineers across three continents in financial services: Most “office cultures” are actually location-based rituals that reinforce majority-culture norms.

Think about what traditional office culture often means:

  • English-only casual conversations that non-native speakers can’t fully participate in
  • “Swing by my desk” culture that favors those comfortable with interruptions (often from dominant cultures)
  • Happy hours and after-work events that exclude people with family responsibilities or cultural/religious reasons not to drink
  • Inside jokes and references that only make sense if you grew up in the US
  • Meeting dynamics where native speakers dominate and international team members stay silent

When companies went remote and “culture struggled,” I wonder: Was the culture actually breaking, or were we finally noticing that only some people had access to it?

Remote Forced Us to Build Inclusive Culture

At our fintech company, going distributed didn’t break our culture—it exposed that we’d never really built one that worked for everyone. Here’s what changed:

Before Remote (Office-Centric “Culture”):

  • Meetings held during US hours (midnight for our India team)
  • Critical decisions made in hallway conversations (US-based team only)
  • Documentation was sparse because “you can just ask someone”
  • English-language speed and fluency determined who got heard
  • Career advancement correlated strongly with who was in HQ

After Remote (Intentional Inclusive Design):

  • Rotating meeting times across timezones—everyone gets inconvenient slots sometimes
  • “No meetings Wednesdays” globally—protects deep work time across all regions
  • Written RFCs for all significant decisions—levels the playing field for non-native English speakers who can edit and refine their input
  • Explicit communication norms—defined expectations for response times, what requires sync vs async, when to escalate
  • Career frameworks documented—removed “tribal knowledge” about advancement

You know what happened? Better ideas started emerging.

Engineers who’d been quiet in real-time meetings because English wasn’t their first language started contributing incredibly thoughtful written proposals. Team members in India and Mexico brought perspectives we’d been missing when US voices dominated. Our decision quality improved because we stopped optimizing for “who talks fastest” and started optimizing for “who thinks deepest.”

The 67% Might Be About Leadership Gaps

I’m starting to suspect that the 67% cultural alignment struggle reflects a different problem: Most engineering leaders lack cross-cultural leadership skills.

We know how to lead people who look, sound, and work like us. But distributed teams require:

  • Designing for multiple work styles (async-first vs sync-preferred)
  • Communication across language and cultural norms
  • Building trust without defaulting to “people like me”
  • Creating belonging across timezones and geographies
  • Recognizing and interrupting bias in how we define “collaboration” and “engagement”

That’s a skill set most of us never developed when everyone sat in the same office.

Practical Wins from Intentional Design

Here are some concrete examples of what changed when we stopped trying to recreate office culture remotely and instead built something new:

Decision-making transparency:
We moved to RFCs for architecture decisions. Result? 30% more participation from international team members, better technical decisions, automatic documentation.

Async-first communication:
We default to Slack threads and documents before scheduling meetings. Result? Engineers in all timezones can contribute meaningfully instead of the US team deciding everything.

Rotation of “inconvenience”:
When we need real-time collaboration, we rotate who takes the late/early meeting. Result? Everyone shares the burden instead of only international team members sacrificing sleep.

Cultural celebration:
We celebrate Diwali, Lunar New Year, Día de los Muertos, and other culturally significant holidays with the same weight as US holidays. Result? Team members feel seen and valued, not tolerated.

The Uncomfortable Question

Michelle asked how many processes we think are working in offices are actually just covering up dysfunction. I want to go further:

Is “culture struggle” in remote teams often code for “we’re no longer able to maintain exclusive, majority-culture norms”?

Because in my experience, the teams struggling most with remote culture are the ones that:

  • Had the strongest “culture fit” hiring (which often meant “people like us”)
  • Relied heavily on informal networks and hallway conversations
  • Never documented anything because “everyone knows”
  • Measured engagement by physical presence and fast verbal responses

Those aren’t hallmarks of strong culture. Those are hallmarks of homogeneous, exclusive culture that only worked for people who matched the majority.

Remote work didn’t break that culture—it just stopped letting us pretend it worked for everyone.

What Success Looks Like

The teams I see thriving in distributed environments are the ones that:

  • Design for diversity from day one
  • Make inclusion a technical problem to solve, not a “nice to have”
  • Build systems that work for people in all timezones, language backgrounds, and work styles
  • Measure culture by outcomes (inclusion, belonging, psychological safety) not inputs (meeting attendance, office presence)

Keisha, you asked what processes failed going remote. For us, the answer was: Every process that assumed cultural homogeneity. And honestly? I’m glad they failed. We built something better.

4

Okay, this conversation is getting real and I need to share something uncomfortable: I’ve lived both sides of this. I ran a startup with what we thought was “amazing office culture”—and watched it completely fall apart when we went remote during COVID. It was painful, embarrassing, and honestly? One of the best learning experiences I’ve had.

The Painful Truth: We Confused Perks with Culture

My failed B2B SaaS startup had all the startup culture trappings:

  • Ping pong table and bean bag chairs
  • Catered lunches three times a week
  • Friday happy hours with craft beer
  • “Flat hierarchy” where anyone could talk to anyone
  • Energetic office vibe with music and collaboration

We were so proud of our culture. Investors loved hearing about it. We put photos on our website. It felt real.

Then COVID hit. We went remote. And within two months, everything fell apart.

What Actually Happened

Here’s what I learned the hard way: We had confused shared physical space with shared purpose.

When the office disappeared, so did the “culture” because it turns out we had:

  • Never defined our actual values beyond generic words like “collaborative” and “innovative”
  • No decision-making process beyond “whoever’s in the room when the decision gets made”
  • Zero documentation because “just ask Maya” or “just ask our tech lead”
  • Informal power structures where only the extroverts who grabbed lunch together actually knew what was happening
  • No onboarding process beyond “shadow someone for a week”

The ping pong table and craft beer weren’t culture. They were just… stuff in a room.

The Design Systems Perspective

Here’s where my design background kicked in: Culture needs a design system.

In design systems, we:

  • Define core principles (like our “design tokens”)
  • Document how those principles apply to different contexts
  • Create reusable patterns based on those principles
  • Test and iterate when patterns don’t work
  • Make the implicit explicit so new designers can contribute

Why weren’t we doing this for culture?

At my current company (design systems lead at an agency), we literally treat culture like a product we’re designing:

Culture Tokens:

  • Values: Not just words on a wall, but definitions with examples
    • “Transparent” = What does this mean for decision-making? For feedback? For project status?
  • Norms: Explicit expectations documented
    • Response time expectations (24hrs for Slack, 3 days for email, immediate for pages)
    • Meeting norms (agenda required, notes shared, action items assigned)
    • Work hours flexibility (core hours 10am-3pm your timezone, async rest of day)

Patterns:

  • Decision-making patterns: Different types, different processes (like Michelle’s Type 1/Type 2 framework)
  • Communication patterns: When to use Slack vs email vs Loom vs doc vs meeting
  • Celebration patterns: How we recognize wins, give feedback, handle failures

Documentation:

  • Everything written down like code documentation
  • New hires can read it and understand how we work
  • We iterate on it based on what’s working/not working

What Percentage Was Just Proximity?

@vp_eng_keisha asked what percentage of “office culture” was just shared physical space. For my startup? Honestly? About 90%.

The 10% that was real:

  • We genuinely cared about solving our customers’ problems
  • We wanted to build something meaningful
  • We respected each other’s skills

But the other 90% was just:

  • Being in the same room
  • Eating the same catered food
  • Playing ping pong together
  • Drinking at happy hour

None of that is culture. That’s just proximity creating a false sense of connection.

The Contrast: Intentional Design Works

My current company is fully remote and has been from day one. Our culture is stronger than my in-office startup ever was. Why?

Because it was designed, not assumed.

  • New team members know exactly how we work because it’s documented
  • Decisions are transparent because they’re written
  • Remote designers in Colombia contribute as much as designers in Austin because async communication is the default
  • We celebrate wins in public Slack channels with clear criteria for what’s worth celebrating
  • Feedback happens through structured 1-on-1s and documented performance frameworks

I thought this would feel sterile or corporate. Instead it feels… freeing? Like everyone knows the rules of engagement and can show up authentically within that structure.

Culture Needs a System

Here’s my take: Most teams approach culture like I approach my personal design projects—organically, intuitively, “we’ll figure it out as we go.”

That works for side projects. It doesn’t work for teams.

Culture at scale needs:

  • Principles: What do we actually value? (With definitions and examples)
  • Tokens: The smallest units of culture that can be reused (norms, rituals, language)
  • Components: Patterns built from those tokens (meeting formats, decision frameworks, communication templates)
  • Documentation: Everything explicit so it can be learned, not absorbed through osmosis
  • Versioning: Recognition that culture evolves, so we iterate and update

This isn’t bureaucratic. It’s honest. It’s saying: “Here’s how we actually work. If that fits you, great. If not, that’s okay too.”

My Answer to Keisha’s Question

What processes worked in my office but failed remotely? Every single one that relied on:

  • Physical presence as a proxy for engagement
  • Informal networks as decision-making channels
  • Extroverts dominating conversations
  • “You’ll pick it up” as onboarding
  • Seeing people = knowing people

Those didn’t fail because remote broke them. They failed because they were never actually working—they were just hiding dysfunction behind the comfort of proximity.

And honestly? I’m grateful they failed. Because it forced me to build something real.

Remote work is the design constraint that makes you build actual culture instead of just vibes and free food.

5

This thread is :fire: and I need to jump in with the product lens because @maya_builds just said something that clicked for me: culture needs a design system.

As VP Product, I’d go further: Culture has product-market fit—or it doesn’t.

Treating Culture Like a Product

Here’s how I think about it using product frameworks:

Market = Your Actual Team

  • Distributed across timezones? Diverse backgrounds? Mix of introverts and extroverts?
  • That’s your market. That’s who your “culture product” needs to serve.

Product = Your Cultural Practices

  • Decision-making processes, communication norms, rituals, values
  • These are the features of your culture product

Fit = Does Culture Serve Team Needs?

  • Does your culture help people do their best work?
  • Does it create belonging and psychological safety?
  • Does it scale as you grow?

Most companies designed their culture for a 2010 co-located team. Then the market shifted to 2026 distributed reality. Product-market fit broke.

The 67% Are Experiencing Culture-Market Mismatch

I’d bet that statistic isn’t measuring “remote work failure.” It’s measuring teams whose culture was designed for one context (co-located, synchronous, homogeneous) trying to force-fit it into another context (distributed, async, diverse).

That’s not a culture problem. That’s a product-market fit problem.

When your SaaS product stops serving customer needs, you don’t blame the customers. You evolve the product or you die. Same with culture.

Product Thinking Applied to Culture

At our Series B fintech startup, we literally treat culture like we treat our product roadmap:

Discovery Phase

  • User research: What do team members actually need from culture?
    • Quarterly culture surveys (not engagement surveys—culture fit surveys)
    • Exit interviews to understand culture mismatches
    • 1-on-1s asking: “What cultural practices help you? Which ones hurt?”

Define Jobs to Be Done

Culture needs to solve specific jobs for team members:

  • Job 1: “Help me make decisions quickly without getting blocked”
  • Job 2: “Help me know what’s happening without being in every meeting”
  • Job 3: “Help me feel connected to teammates I’ve never met in person”
  • Job 4: “Help me balance async work with real-time collaboration”

Does your current culture solve these jobs? If not, iterate.

Build → Measure → Learn

We treat cultural practices like features:

Example: Weekly all-hands

  • Hypothesis: Team wants CEO updates in real-time
  • Test: Host all-hands at 9am PT
  • Result: 40% attendance, mostly US team, international team watching recording days later
  • Learning: Job isn’t “hear CEO in real-time”—it’s “know company direction”
  • New approach: CEO posts written update + AMA in Slack. Engagement jumped to 85%, better questions, automatic archive

Example: “Collaboration culture”

  • Old way: “Be responsive on Slack” (undefined what that means)
  • Team feedback: Getting pinged 50+ times/day, can’t do deep work
  • New approach: Defined response time SLAs (24hrs normal, 2hrs urgent, immediate for pages)
  • Result: Deep work time increased 3hrs/week, satisfaction up

We sunset practices that don’t serve the team and double down on what works.

Competitive Analysis

@eng_director_luis mentioned teams struggling most had “strong culture fit hiring.” In product terms, that’s designing for your current users and ignoring market expansion.

If your culture only works for:

  • People in HQ timezone
  • Native English speakers
  • Extroverts who thrive in meetings
  • People without caregiving responsibilities

…then you’ve designed a niche product that can’t scale. You’ve limited your addressable market to a narrow segment.

Successful products expand to serve broader markets. Same with culture.

The Product-Market Fit Test for Culture

Here’s my framework for checking if your culture has PMF:

1. Would 40%+ of your team be “very disappointed” if these cultural practices went away?

(This is the Sean Ellis PMF test applied to culture)

If people would shrug at losing your rituals, you don’t have strong culture. You have going-through-the-motions.

2. Do new hires onboard faster or slower than in-office baseline?

  • Faster = culture is well-documented and designed
  • Slower = culture relies on osmosis

3. Do underrepresented groups report belonging as high as majority groups?

  • If not, your culture isn’t inclusive—it’s exclusive to dominant groups
  • That’s a product serving only part of your market

4. Can you explain the “why” behind every cultural practice?

  • If the answer is “we’ve always done it this way,” that’s tech debt
  • Every feature should have a clear job it solves

Culture Retros

Here’s what we do quarterly that I wish every team did:

Culture Retrospective

  • What cultural practices are serving us well? (Keep)
  • What’s creating friction? (Fix)
  • What’s no longer relevant? (Sunset)
  • What new needs have emerged? (Build)

We literally use a product roadmap:

  • Now: Shipping new async decision framework
  • Next: Improving cross-timezone collaboration ritual
  • Later: Rethinking how we celebrate wins remotely
  • Sunset: Friday happy hours (only 15% attendance, not serving job)

This isn’t bureaucratic. It’s product management applied to culture.

When to Pivot vs Iterate

Sometimes culture-market mismatch requires iteration (fix current culture). Sometimes it requires pivot (build new culture).

Iterate when:

  • Core values still resonate
  • Practices just need refinement
  • Team fundamentally likes the direction

Pivot when:

  • Culture was designed for different team composition
  • Market (your team) has fundamentally shifted
  • Old culture creates systematic exclusion

Most teams in that 67% need a pivot, not iteration. Their culture product was designed for a market that no longer exists.

My Answer to @vp_eng_keisha

When did we last do a “culture retro” to check product-market fit?

For most teams: Never. They designed culture once (if at all) and assumed it would work forever.

No product manager would ship a feature and never check if it’s working. Why do we do this with culture?

The Uncomfortable Opportunity

Remote work is the forcing function that breaks culture-market fit for teams that were coasting on proximity.

That 67% statistic? Those are teams getting market feedback: “Your culture doesn’t serve us anymore.”

You can ignore that feedback and blame remote work. Or you can do what good product teams do: listen to your users (team members) and evolve your product (culture) to serve them better.

The teams that thrive remotely aren’t lucky. They’re doing product discovery and iteration on their culture instead of assuming it’s finished.

Culture isn’t something you have. It’s something you build, measure, and improve—continuously.