GitLab's culture of transparency, short toes, and remote work at scale

Executive overview

Most companies treat internal information as a liability to be managed. GitLab treats it as an asset to be shared — posting team meetings publicly, open-sourcing its entire company handbook, and making its product roadmap and issue tracker visible to anyone.

The result: external contributors fix bugs after watching internal meetings, customers vote on roadmap priorities, and companies fork GitLab's handbook to bootstrap their own operations.

The core insight: transparency is cheaper than secrecy — it removes coordination overhead, aligns teams faster, and turns customers and community into co-builders.

What GitLab makes public

• Team meetings streamed or recorded to a public YouTube channel ("GitLab Unfiltered")
• The full company handbook at handbook.gitlab.com — including onboarding, workflows, PM laddering, and accounts payable
• Product roadmap and one-year direction pages linking down to epics and issues
• 72,000+ item public issue tracker; customers can comment and vote
• Exceptions: customer data, material non-public information, security vulnerabilities

Benefits of radical transparency

• Asynchronous teams stay aligned without live meetings
• Customers and open-source contributors find and fix issues unprompted
• External feedback produces a more accurate roadmap
• Handbook forking lets other companies bootstrap operations from GitLab's work
• Removes artificial silos that force program managers to act as information routers

How to start if your company isn't GitLab

• Begin with one team meeting published internally; expand from there
• Publish asynchronous weekly readouts to Slack
• Distinguish what is actually confidential from what is only treated as confidential
• Regulated industries can still publish roadmaps — it builds customer trust
• Expect occasional mistakes (accidental public issues, mis-set recordings); the upside outweighs the risk

GitLab's cultural values in practice

• Kindness: assume positive intent on Slack messages and async communication; default to charitable interpretation
• Short toes: feedback is about the work, not the person; don't take edits or comments personally
• Negative feedback is one-on-one: public channels stay positive; criticism goes to DMs
• Thanks channel: a dedicated Slack channel for public appreciation; in constant use
• Results over hours: measure adoption and outcomes, not features shipped or time logged
• Efficiency: strategy is set at the top; teams decide how to get there

Remote work: what GitLab has learned

• Focus on results, not hours; agree on outcomes and leave the path to the individual
• Over-communicate: assume your message lands at 60–70% fidelity; aim for 150%
• Make in-person time a priority — quarterly team offsites, director-plus gatherings; human connection makes Zoom less transactional
• Async-first means key decisions wait for the directly responsible individual (DRI), even across time zones
• Remote is not for everyone; some people simply need the in-person environment and that's a legitimate fit issue

Product management in a remote environment

• Requirements must be written clearly the first time — you can't rely on a quick hallway clarification
• GitLab's PM interview includes a written requirements deep-dive with a role-playing "engineer" to test async communication ability
• Don't wait for the next check-in if something looks off — comment on the issue or send a Slack message immediately
• Tools: GitLab (issues, epics, MRs as single source of truth), Slack, Zoom for when back-and-forth writing breaks down
• GitLab is anti-internal-email; decisions go into the handbook, work into issues

Breadth-over-depth, then depth-over-breadth

• GitLab started with breadth: build across the full DevSecOps lifecycle to establish platform presence
• After gaining market leadership, pivoted to depth in core areas: SCM, code review, CICD, security and governance, planning, AI
• Depth in key areas creates a rising-tide effect on adjacent features that don't need to be as deep
• Breadth still applies to new investments (e.g. AI); depth applies where differentiation matters
• Signal to pivot: have you found product-market fit? If yes, put all resources behind that arrow

GitLab Duo: AI across the full SDLC

• Premise: developers are only 25% of the software development lifecycle; AI that only helps coders leaves 75% untouched
• Three tenets: (1) AI across the full SDLC, not just code; (2) transparency and privacy — no customer IP used for training; (3) efficiency gains targeting 10x productivity
• Uses ~16 models matched to specific use cases (vulnerability explanation, conversation summarisation, inline completion, code generation)
• Matching model to use case matters: inline completion needs sub-second response; code generation can take 20–30 seconds
• Partners: Google Cloud and Anthropic for commercial models; open-source and proprietary models (via UnReview acquisition) also in the mix
• Customers report 50%+ efficiency gains from GitLab Duo adoption