GitLab’s Radical Transparency Meets High-Context Cultures: A Culture Map Case Study

When a company built on Dutch-style directness scales to 2,000 employees across 65 countries, the friction is not a bug. It is a cultural physics problem -- and Erin Meyer gave us the equations to predict it.

By late 2022, GitLab had a problem it could not solve with a merge request.

The company -- fully remote since its founding in 2014 by Dutch CEO Sid Sijbrandij and Ukrainian co-founder Dmitriy Zaporozhets -- had grown to roughly 2,000 team members distributed across more than 65 countries. It had pulled off what most organizational theorists would have called impossible: a $11 billion IPO on NASDAQ in October 2021 with no headquarters, no offices, and a culture governed almost entirely by a single public document. GitLab's handbook -- over 2,000 pages of policies, processes, values, and behavioral expectations, published on the open internet for anyone to read -- was not a reference guide. It was the company's operating system.

The handbook encoded six values under the acronym CREDIT: Collaboration, Results, Efficiency, Diversity, Inclusion & Belonging, Iteration, and Transparency. These were not poster slogans. They were enforced norms. Compensation was calculated by a public formula. Feedback was delivered in public merge requests. Meetings were recorded and transcribed. If it was not in the handbook, it did not count as a decision.

This system worked brilliantly for the Northern European and North American employees who made up the majority of the company. It reflected the cultural instincts they already carried: be explicit, be direct, write it down, challenge the idea not the person.

But in Tokyo, a small team of engineers had gone quiet. Not quiet as in "heads down shipping code" -- quiet as in pull requests without comments, meetings with cameras off, and a steady trickle of resignations that HR was tracking but not yet diagnosing. In Bangalore, a growing cohort of talented engineers praised GitLab's flexibility and compensation on Glassdoor but flagged "the culture rewards a very specific personality type." In Paris, a senior engineer had written an internal post questioning whether GitLab's iteration-first approach was "intellectually shallow" -- and the response, a direct public rebuttal from a colleague in San Francisco, had confirmed every concern she was trying to articulate.

GitLab had not done anything malicious. It had done something much more common and much harder to fix: it had built a genuinely excellent culture on a set of assumptions that were invisible to the people who shared them and deeply visible to everyone who did not.

Erin Meyer's Culture Map framework -- published the same year GitLab was founded -- predicted every one of these friction points. Almost perfectly.

Erin Meyer is a professor at INSEAD who spent over a decade studying how national culture shapes the way people communicate, give feedback, make decisions, and build trust in professional settings. In 2014, she published The Culture Map: Breaking Through the Invisible Boundaries of Global Business, which maps countries along eight behavioral scales.

Each scale is a spectrum, not a binary. And the insight that makes the framework powerful is not where any single country falls, but the relative distance between two countries on a given scale. Two cultures that are both moderately direct will have little friction. Two cultures at opposite ends of the Communicating scale will misunderstand each other constantly -- and both will believe the other person is the problem.

Here are the eight dimensions, with their endpoints:

Meyer is careful to note that these are cultural tendencies, not individual predictions. A Japanese person can be direct; a Dutch person can be indirect. But when you design a system -- a company culture, a set of norms, a 2,000-page handbook -- you are designing for aggregate behavior. And aggregate behavior follows cultural patterns with remarkable consistency.

On Communicating, the Netherlands sits near the extreme low-context end of the spectrum. The United States is also low-context, though slightly less so. Japan is at the far high-context end. South Korea, India, and China cluster near Japan. France sits in the middle but leans high-context relative to Anglo-Saxon and Northern European norms. Brazil leans high-context and expressive.

On Evaluating (how people give negative feedback), a crucial subtlety emerges. The Netherlands, Russia, and Israel are among the most direct negative feedback cultures on earth -- the Dutch will tell you your work has problems and consider it a sign of respect. Japan, Thailand, and Indonesia are among the most indirect. But here is where it gets interesting: the United States is low-context in communication but relatively indirect in negative feedback compared to the Dutch. Americans soften criticism with "great job, but..." sandwiches. The Dutch just say the "but" part. GitLab's culture, shaped by its Dutch founder, was more direct on negative feedback than even most American companies -- a fact that surprised American employees and alarmed Japanese ones.

On Leading, the Netherlands and Denmark are the most egalitarian cultures Meyer maps. India, Japan, South Korea, China, and Nigeria are strongly hierarchical. This is not a minor stylistic difference. It shapes who speaks in meetings, who feels authorized to challenge a decision, and whether "everyone can contribute" is experienced as an invitation or an anxiety-producing demand.

These three dimensions -- Communicating, Evaluating, and Leading -- are where GitLab's cultural operating system created its sharpest collisions. The handbook was a low-context artifact operating in a high-context world. The feedback culture was Dutch-direct being applied to face-saving cultures. The flat hierarchy was Scandinavian egalitarianism being exported to Confucian and post-colonial hierarchies.

GitLab's engineering team in Japan was small but strategically important. Japan represents one of the largest DevOps markets in Asia, and having Japanese-speaking team members contributed to localization, customer support, and market credibility.

But the handbook-first culture created a specific and predictable problem.

In Japanese business communication, context carries as much meaning as content. A manager who says "this is an interesting approach, and I wonder if we might explore some alternatives" is delivering a clear signal to anyone operating within Japanese norms: this approach has significant problems. The listener is expected to decode the message, reflect, and revise without the speaker having to state the criticism explicitly. This protects both parties' mentsu (face) and maintains the relational harmony (wa) that Japanese organizational culture treats as foundational -- not optional, foundational.

GitLab's merge request culture inverted every piece of this. Feedback was written, public, explicit, and attached to your name. A comment saying "This approach won't scale because of X, Y, and Z -- here's an alternative" was, by GitLab norms, a model of good collaboration: specific, actionable, constructive. By Japanese norms, it was a public loss of face delivered without any of the relational buffering that makes criticism safe.

The result was not confrontation. It was withdrawal. Japanese team members stopped commenting on merge requests. They submitted clean, cautious code that avoided risk -- because risk meant potential public critique. They stopped raising concerns in async channels. In Meyer's terms, they moved from "silence as agreement" (the American reading) to "silence as self-protection" (the high-context reading). And because GitLab's communication system was designed by and for low-context communicators, the system read their silence as engagement rather than alarm.

This is what Meyer calls the "low-context trap": when your system is built on explicit communication, the absence of explicit complaints looks like the absence of problems.

India represented one of GitLab's largest single-country talent pools. India's deep bench of engineering talent, combined with favorable time zone coverage for async work and competitive compensation dynamics, made it a natural hiring focus. By the early 2020s, India-based team members constituted a significant portion of GitLab's non-US workforce.

Meyer's framework places India on the hierarchical end of the Leading scale. Indian corporate culture carries the legacy of both traditional social structures and British colonial organizational models. Dowling, Festing, and Engle describe in International Human Resource Management (8th ed.) how Indian workplaces typically feature defined reporting lines, deference to seniority, and an expectation that consequential decisions flow through the hierarchy rather than around it. This does not mean Indian professionals lack initiative. It means they exercise initiative within a framework of understood authority relationships.

GitLab's "short toes" principle -- an explicit encouragement to step into others' areas of responsibility and contribute where you see opportunity -- was designed to foster collaboration. For team members from egalitarian cultures, this felt liberating. For team members from hierarchical cultures, it created a double bind.

If you are a junior engineer in Bangalore and your skip-level manager in Amsterdam posts a proposal, GitLab's culture says you should comment publicly with your honest assessment. But your cultural operating system -- reinforced by every professional experience you have had before GitLab -- says that publicly challenging a senior leader is disrespectful, risky, and likely to damage a relationship you depend on for career advancement. You face two losing options: follow your cultural instincts and be rated as "not collaborative enough" by GitLab standards, or override your instincts and potentially damage a relationship that your culture treats as essential to professional survival.

Glassdoor reviews from GitLab's India-based employees from 2022 through 2025 reflect this pattern with striking consistency. Positive themes: mission, flexibility, compensation, intellectual challenge. Negative themes: "culture rewards specific personality types," "hard to be heard if you are not the loudest voice," "the way feedback works assumes everyone is comfortable with conflict."

The double bind was not created by malicious intent. It was created by universalizing a set of norms that feel natural to people from one cultural position and feel like a personality test to people from another.

France presents a different kind of friction -- one that Meyer's framework predicts through the Persuading dimension rather than the Communicating or Leading dimensions.

French business culture is strongly principles-first. Before accepting a proposed course of action, French professionals want to understand the intellectual framework behind it. Why does this approach make sense? What is the underlying logic? How does this fit into a coherent theoretical model? Only after the conceptual architecture is established does the French professional feel comfortable moving to implementation details. This is not pedantry. It is a deeply held belief that action without theory is reckless -- that you must understand why something works before you can trust that it works.

GitLab's culture is aggressively applications-first. The "Iteration" value is explicit: ship the minimum viable change. Learn from it. Iterate. A proposal that begins with three paragraphs of theoretical justification before describing the actual change would receive feedback to "get to the point." The "boring solutions" sub-value actively discourages elegant, theoretically grounded approaches in favor of practical, incremental ones.

For French team members, this felt like being told that rigor was a liability. Former French employees have described the experience of submitting carefully reasoned proposals -- grounded in first principles, structured as logical arguments -- only to receive feedback that they were "over-thinking it" or "not iterating fast enough." The Blackwell Handbook of Cross-Cultural Management documents that principles-first cultures produce more robust long-term decisions when given time to build theoretical foundations. Applications-first cultures produce faster iteration cycles. Neither is superior. But a system that only rewards one will systematically undervalue the other.

Meyer makes a subtle but critical observation about France that applies directly here: French culture is also moderately confrontational on the Disagreeing scale. French professionals are comfortable with intellectual debate -- in fact, they enjoy it. But the type of debate matters. French disagreement tends to be theoretical and dialectical, not personal or blunt. When a French engineer pushed back on a proposal in a GitLab issue thread using a principles-first argument, and received a reply from a Dutch or American colleague that dismissed the theory and jumped to "here's what we should do instead," the French engineer experienced it as anti-intellectual rather than efficient.

Across all of these collisions, one dimension operated as an invisible multiplier: the Trusting scale.

GitLab's async-first, documentation-heavy, deliverables-measured culture is a textbook task-based trust system. You earn trust by shipping good code, writing clear documentation, meeting your commitments, and contributing to merge requests. The quality of your output is the basis of your professional reputation.

This works naturally for cultures that share this orientation: the US, the Netherlands, Germany, the UK, the Nordic countries, Australia. In these cultures, you can work with someone for years, never meet them in person, and trust them completely based on their track record.

But in relationship-based trust cultures -- Brazil, India, China, Japan, Nigeria, Mexico, Saudi Arabia, most of Latin America and Southeast Asia -- trust is built through personal knowledge. Shared meals. Conversations about family. Time spent in the same physical space. You trust someone because you know them, not because their last commit was clean.

GitLab's async model systematically reduced the opportunities for relationship-based trust building. The company introduced "coffee chats" -- randomly paired 25-minute video calls -- as a countermeasure. This was a genuine effort. But a structured 25-minute video call is itself a task-based solution to a relationship-based problem. For team members from relationship-based cultures, it often felt like networking rather than connection.

The trust gap had downstream effects. Team members who could not build trust through relationships had to rely entirely on output trust -- which meant they were under constant pressure to perform visibly, in a communication medium that was not designed for them, in a culture whose norms felt foreign. The cognitive overhead was real and cumulative.

The distribution is the quiet part of the story. Approximately 60-65% of GitLab's workforce came from cultures that align closely with the company's communication norms. The remaining 35-40% were operating in a cultural system designed by and for someone else.

Six handbook practices carry outsized cultural implications:

• "Say why, not just what" -- Requires explicit reasoning. Disadvantages high-context communicators who embed reasoning in context rather than stating it directly.
• "Disagree, commit, and disagree" -- Requires open disagreement before decisions. Directly challenges non-confrontational cultures where dissent flows through private channels.
• "No ego" -- Reframes direct criticism as "egoless." This can inadvertently invalidate the emotional experience of team members from face-saving cultures: telling someone their discomfort with public critique is an "ego problem" adds a moral judgment to an already difficult cultural adjustment.
• "Write things down" -- Privileges written communication fluency and comfort with explicit, low-context documentation. A second-language penalty compounds the cultural one.
• "Short toes" -- Encourages stepping into others' areas of responsibility. Can register as a boundary violation in cultures where professional domains and hierarchies are clearly delineated.
• "Boring solutions" -- Values incremental, practical approaches. Can frustrate principles-first thinkers who want to build elegant, theoretically grounded systems.

• Glassdoor ratings (2022-2025): Fluctuated between 3.4 and 3.8 out of 5 -- solid but below the ~4.0 average for comparable-stage tech companies.
• Recurring themes from non-US/non-European reviewers: "Very American/Dutch culture," "great if you're extroverted and direct," "async is isolating," "hard to build real relationships."
• Diversity, Inclusion & Belonging reports: GitLab published annual reports tracking regional representation. "Belonging" scores -- the feeling that one's authentic self is welcome -- consistently lagged behind "diversity" numbers, particularly for team members outside North America and Western Europe.
• Regional attrition: While GitLab does not publish attrition data by country, anecdotal evidence from former employees and industry analysis suggests voluntary turnover in APAC roles ran above the company average during 2022-2023, distinct from the structured February 2023 layoff.

Job van der Voort, who served as VP of Product at GitLab from 2015 to 2019, left to co-found Remote.com -- an Employer of Record platform designed to help companies hire internationally. The timing and concept are not coincidental. Van der Voort experienced firsthand both the potential and the friction of GitLab's model for global employment. Remote.com's pitch -- simplifying the legal, compliance, and payroll complexity of hiring across borders -- directly addresses the infrastructure challenges that companies like GitLab navigate when scaling across 65+ countries. It is worth noting that the people who saw GitLab's global model from the inside chose to build tools that help other companies do it differently.

An honest analysis must include what worked. GitLab made genuine efforts:

1. Translated handbook sections into multiple languages and explicitly acknowledged that English-first documentation creates access barriers.
2. Created regional Slack channels to foster local community and connection.
3. Implemented coffee chats as structured informal relationship-building -- imperfect but real.
4. Published inclusive language guidelines acknowledging cultural differences in directness.
5. Hired People Business Partners with regional cultural expertise to support managers in specific geographies.
6. Documented "low-context communication" as a skill to develop -- explicitly acknowledging that their norms required adaptation. (Though framing a cultural difference as a "skill gap" is itself a culturally loaded choice.)
7. Conducted annual "Contribute" gatherings -- in-person events that brought distributed teams together, providing precious face time for relationship-based trust builders.

These adaptations were genuine. They were also, by Meyer's framework, predictably insufficient -- because they were add-ons to a system whose foundations remained unchanged.

Meyer's Culture Map provides the diagnostic lens. GitLab provides the data on what happens when that lens is ignored during cultural design. The following adapted framework synthesizes both into a system any company can use.

Before you hire your first international team member, audit your company's default behaviors against Meyer's dimensions. Be ruthlessly honest. You are not mapping what your values page says. You are mapping what actually happens when someone does not meet a deadline, pushes back on a leader, or delivers criticism.

The "Who Designed This?" column is the most important. Most company cultures are designed by the founding team, which is usually culturally homogeneous. GitLab's culture was designed by a Dutch CEO and a predominantly Northern European / North American early team. That is not a criticism. It is a diagnosis. You cannot adapt what you have not identified.

GitLab's mistake was not having a strong culture. It was treating all elements of that culture as equally non-negotiable. The adapted framework distinguishes three tiers:

• Integrity, ethical conduct, legal compliance
• Respect for people (the principle, not a specific expression of it)
• Quality standards and accountability
• Documentation as a source of truth (the practice of writing things down, not the specific communication style required)

• Feedback delivery: The substance is non-negotiable (people receive honest assessments). The format flexes: private 1:1s in high-context cultures, public comments in low-context ones. Pre-review channels for those who want private feedback before public posting.
• Decision participation: The principle of broad input is standardized. The mechanism flexes: anonymous input channels for hierarchical cultures, open debate forums for egalitarian ones.
• Persuasion format: Accept both principles-first and applications-first proposals. Create templates that invite the "why" as well as the "what."
• Performance assessment: Standardize the criteria. Flex the delivery: written 360 reviews for some cultures, private manager conversations for others, with the same substance communicated through different channels.

• Meeting norms (who speaks first, how silence is interpreted, how disagreement surfaces)
• Onboarding experience (how new hires learn the culture -- mentorship-heavy in relationship cultures, documentation-heavy in task cultures)
• Informal relationship-building (team dinners in Tokyo, coffee chats in Amsterdam, group outings in Sao Paulo)
• Recognition practices (public praise in individualist cultures, private acknowledgment in collectivist ones, team recognition in group-oriented cultures)
• Career development conversations (direct "here's what you need to do" in low-context cultures, guided self-assessment in high-context ones)

This is the part most companies skip. A cultural translation layer is a set of mechanisms that allow people from different cultural positions to interact with the same system in different ways -- without either party needing to fully adopt the other's style.

• Offer private pre-review channels where work can be discussed before public submission
• Train managers to treat silence as a data point, not as consent
• Create structured 1:1s where concerns can surface privately before escalation
• Pair new hires from high-context cultures with mentors who can decode the system's implicit expectations

• Have senior leaders explicitly and repeatedly model receiving public critique -- not once in an onboarding video, but regularly and visibly
• Create anonymous feedback mechanisms alongside open ones
• Recognize that "permission to disagree" must come from someone with hierarchical authority to grant it -- a handbook entry is not enough

• Fund regional in-person gatherings at least biannually -- this is not a perk, it is infrastructure
• Allow more synchronous communication for teams where relationship-building requires real-time interaction
• Extend onboarding periods to include relationship-building time that would happen naturally in an office

• Add a "Rationale" section to proposal templates that explicitly invites theoretical grounding
• Do not penalize thoroughness. A longer, more reasoned proposal is not a slower one -- it may be a more durable one.
• Value the intellectual rigor that principles-first thinkers bring, even when the iteration cadence feels slower

You have seen the framework. You have seen what happened when one of the most deliberately designed company cultures in history collided with 65 national cultures' worth of invisible assumptions. Here is what you do about it this week.

Print the audit table from Part A. Fill it in as a team. Do not discuss what your values page says -- discuss what actually happens when someone misses a deadline, gives blunt feedback, or stays silent in a meeting. You will discover that your "universal" culture is more culturally specific than you thought. This is the starting diagnosis. Everything else follows from it.

Pick five team members from your top non-headquarters countries. Schedule private, 1:1, video-on calls. Ask one question: "What about how we work feels unnatural to you?" Then stop talking. If they say "everything is fine," do not take that at face value -- in many cultures, that is the signal that things are not fine but the trust level is insufficient for candor. If you hear real feedback, write it down. You now have data, not assumptions.

Take your employee handbook or culture document and highlight every behavioral expectation. For each one, ask: "Is this a value or is this a culturally specific practice that expresses a value?" "We value honest feedback" is a value. "We give honest feedback in public Slack channels" is a practice. Values are non-negotiable. Practices can flex. Most companies have confused the two, and the confusion costs them talent in every market where the practice does not match the local cultural grain.

If you have team members in relationship-based trust cultures (most of Asia, Latin America, Africa, and the Middle East), async tools and coffee chats are not enough. Budget for at least biannual regional in-person gatherings. Do not categorize this as "team building" in your budget. Categorize it as "cultural infrastructure" -- because that is what it is. For relationship-based trust builders, the in-person gathering is not a nice-to-have. It is the mechanism through which trust becomes possible.

If your onboarding process for international hires is primarily "here's how we do things" -- meaning "here's how to communicate, give feedback, and participate in decisions the way our founding culture does" -- you are running an assimilation program, not an onboarding program. Flip the investment. Spend equal or greater resources training your HQ-culture managers to interpret and accommodate different styles. Teach them Meyer's framework. Give them the language to recognize when a conflict is cultural rather than personal. The burden of translation should not fall entirely on the person who did not design the system.

GitLab is not a cautionary tale. It is a case study in the difficulty of doing something that very few companies have ever attempted: building a coherent organizational culture across 65 national cultures without a single shared physical space. They shipped real innovations in organizational design -- the public handbook, async-first communication, transparent compensation, the merge-request-as-governance-tool. Much of what they built will influence how remote companies operate for decades.

But the GitLab case confirms what Meyer's framework predicts and what Dowling, Festing, and Engle describe in their analysis of international staffing approaches: the culture you build will always reflect the culture you come from. When Dutch directness becomes the global standard for collaboration, it does not become culturally neutral. It becomes the dominant culture into which everyone else must translate themselves. And that translation carries a cost -- in cognitive load, in emotional labor, in the quiet departure of talented people who could not bring their full professional selves to a system that was not built for them.

Dowling's framework identifies three approaches to international organizational culture: ethnocentric (HQ culture dominates), polycentric (local cultures dominate), and geocentric (a genuine hybrid emerges from integrating multiple cultural inputs). GitLab started ethnocentric -- with good intentions and a better handbook than anyone else has ever written. The question for every company expanding internationally is whether it can make the journey toward geocentric before the cost of ethnocentrism accumulates beyond what good intentions can repair.

Meyer gives you the map. GitLab gives you the terrain. The adapted framework gives you a path. The rest is leadership -- and the willingness to see your own culture as one option among many, rather than the default.