The Transparency Ramp
Default everything to public except three named exceptions, then ramp until it feels uncomfortable
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 95%
GitLab inverts the normal confidentiality default: instead of asking 'should we share this?', they ask 'is there a concrete reason we can't?'. Only three categories are automatically withheld (customer data, vulnerability information, material non-public information); everything else — team meeting recordings, the issue tracker, strategy, the handbook — goes public. Rather than flipping the switch org-wide, DeSanto prescribes a graduated ramp starting with a single team meeting.
Origin
Developed at GitLab under co-founder/CEO Sid Sijbrandij and articulated here by David DeSanto, GitLab's Chief Product Officer, who joined in 2019 from a security background where roadmaps were shared no more than four to six weeks out. Sijbrandij's reframe to him — that it is product's job to be ambitious and engineering's job to meet that ambition — is what made publishing the roadmap feel non-threatening.
Core principles
- 01The default is public; confidentiality must be justified, not assumed.
- 02Only three things are automatically private: customer data, vulnerability information, and material non-public information.
- 03Artificial silos, not competitors, are the main cost of secrecy — they force program managers to act as routers between teams.
- 04Being transparent is eventually less work than not being transparent, because you stop tracking who heard what.
- 05The occasional over-share is cheaper than the permanent cost of opacity.
- 06It's not the idea, it's the execution — publishing your roadmap does not hand anyone your company.
How to run it
- 1
Name your true exception list
Write down the categories that genuinely cannot be public. At GitLab that is customer data, vulnerability information, and material non-public information (e.g. the granular performance-indicator and key reviews, which are recorded but kept internal). Everything not on the list is publishable by default.
Pro tip Force each proposed exception to be defended out loud. Most 'confidential' items turn out to be habit, not risk.
Watch out If your exception list is long or vague, you have rebuilt secrecy with extra paperwork.
- 2
Publish one team meeting internally
Start with a single recurring team meeting recorded and made available to everyone in the company. This is the lowest-risk unit of transparency and requires no new tooling.
Pro tip Expect people to be worse on camera at first — DeSanto describes looking around the room on his first recorded meeting because he was used to audio-only calls. Recording itself upgrades meeting behaviour.
- 3
Ramp to weekly meetings and async readouts
Extend from one meeting to weekly meetings, then to written asynchronous readouts posted where everyone can read them ('here's everything that happened this week to the team'). Transparency becomes contagious — once one team does it, others copy.
Pro tip Async written readouts carry most of the benefit of recorded meetings at a fraction of the consumption cost.
- 4
Push until it feels uncomfortable
The check that you have actually reached transparency, rather than performative openness, is discomfort. DeSanto: you have to push yourself and it almost has to be uncomfortable before you are truly transparent.
Watch out Discomfort is the signal, not the goal — don't push into the exception list to prove a point.
- 5
Go external where your industry allows
Open the parts customers and community can act on: the issue tracker (voting and commenting), the public roadmap/direction, and the handbook. Regulated industries can rarely open the issue tracker, but almost all can publish more of the roadmap than they do.
Pro tip Tell customers explicitly to go vote and comment on issues at every call and conference talk — external transparency only pays if people know it exists.
Watch out Accidents happen: an issue set public that shouldn't be, a recording mis-flagged. Treat each as a learning to reinforce, not a reason to retreat.
In the wild
GitLab live-streams and posts team meetings to its 'GitLab Unfiltered' YouTube channel. Open-source contributors and customers watch, see a problem discussed, cross-reference the public issue tracker, and simply build the fix themselves.
→ Code commits and merge requests arrive from outside the company; DeSanto says some of GitLab's favourite features were contributed by external people. Feedback also arrives from people who hit the same problem and want to compare solutions.
Before GitLab, DeSanto's team began sharing their list of open feature requests more externally instead of holding a four-to-six-week roadmap window.
→ A more customer-shaped roadmap, better customer engagement, a higher retention rate, and better expansion numbers.
Common mistakes
Flipping everything public at once
Companies hear 'radical transparency' and try to open all meetings, docs and trackers simultaneously. DeSanto's prescription is explicitly incremental: one project, one meeting, then expand only if it doesn't feel like additional work.
Treating an accidental over-share as proof it doesn't work
GitLab has had issues public that shouldn't have been and recordings mis-set to public. The correct response is reinforcing the learning across the team; retreating to secrecy costs far more than the occasional leak.
Assuming transparency only works for open-source developer tools
DeSanto argues even Salesforce-type companies would get more customer engagement from a public roadmap, and that heavily regulated industries are already publishing more roadmap externally to build trust. The question is where the right balance sits, not whether you're in the right column.
Is it for you?
Best for
Leaders of technical or product organizations, especially remote/distributed ones, who suspect their information silos are slowing execution and want a low-risk way to test radical openness.
Not ideal for
Companies whose core defensibility genuinely is a secret (unreleased hardware, M&A, regulated financial data), or teams without the psychological-safety values to survive their work being visible.
From the transcript
“be as transparent as possible so if it's not customer data it's not vulnerability information”
“start as simple as publishing a team meeting and making that available for everyone in the company”
“you just have to push yourself and it almost has to be uncomfortable and then you realize you're you're starting to really truly be transparent”
“it's actually a lot easier to be transparent than it is to not be transparent”
From the episode
The GitLab way: Kindness, transparency, and short toes
David DeSanto (CPO)