GitLab’s Public-by-Default Playbook: Short Toes, Clear Outcomes, and a Platform Built to Ship

David DeSanto explains that GitLab’s policy is to be as transparent as possible: teams are encouraged to record and sometimes livestream meetings to the company’s YouTube channel, provided the material is not customer data or vulnerability information. His biweekly product meeting is an example, covering work in progress, excitement, troubles, and ways to collaborate better. The move to publish this much content in 2019 also changed meeting behavior: on his first day he realized he had to engage on camera rather than glance around the room as he might on an audio-only call. The result is a public record that customers and open-source contributors can act on.

The external feedback loop is not theoretical. DeSanto says open-source community members watch meetings, learn about an issue, find it in the public issue tracker, and submit code to fix it; customers also comment on videos or social media with their own experiences. GitLab still keeps some reviews internal: performance-indicator and key reviews stopped being public because they discuss affected customers or material nonpublic information. The high-level product division meeting remains public, while the nitty-gritty recording stays internal.

The handbook extends the same philosophy beyond meetings. It is source-available—readers can click “view source”—and GitLab has seen companies fork it, clone sections such as the UX handbook, and use it as a baseline; some startups have cloned the entire handbook. GitLab also publishes product-manager competencies and leveling, which many product teams struggle to build. DeSanto frames this as leverage: instead of rebuilding from scratch when you are the first person in a department, you can start from what GitLab has already documented.

GitLab’s public issue tracker and direction pages are the other major transparency surfaces. Most issues are public and open for comment, and DeSanto tells customers and conference audiences to vote up what they like or comment on what they want changed. The one-year direction is detailed and links into the issue tracker so outsiders can see what GitLab plans to build and roughly when. DeSanto argues that these practices together make GitLab “the most transparent publicly traded company in the world.”

Lenny observes that GitLab shares what most companies keep secret, yet the differentiator is execution rather than the idea. DeSanto recalls asking co-founder and CEO Sid in 2019 why GitLab would share more than a few weeks of roadmap with customers and sales, given his prior fear that a good idea would be copied. Sid’s answer was that product’s job is to be ambitious and engineering’s job is to meet that ambition, which makes sharing less frightening. That framing turns transparency into a collaboration mechanism rather than a leak.

The credibility comes from shipping. DeSanto says GitLab still ships 12 releases a year, now on the third Thursday of each month rather than the 22nd so people do not have to work over a weekend. The most recent release was number 149, meaning GitLab has shipped essentially monthly for more than 12 years. That cadence is the proof behind the transparency: the public can see both the plans and the regular delivery.

DeSanto does not pretend transparency is all upside. GitLab has accidentally made an issue public that should have stayed private and has had recordings set to public when they should have been private; the response is to reinforce the learning across the team so the same mistake is not repeated. He argues the occasional risk is far below the value of pushing the organization to be more open. He recommends starting small: publish one team meeting, then weekly async readouts in Slack, and let others copy the behavior until transparency becomes normal.

The benefits are both operational and cultural. Asynchronous consumption lets a global workforce catch up without FOMO, teams feel better aligned, and problems surface before the end of a release or the start of a go-to-market campaign. Externally, the public issue tracker and roadmap create a community feedback loop that can improve retention and expansion; DeSanto cites a prior employer that shared open feature requests externally and got a more focused roadmap, better customer engagement, and higher retention. He says transparency can even be easier than secrecy because no one has to track who heard what.

GitLab’s collaboration value includes kindness because remote work removes much of the in-person context that helps people read intent. DeSanto says employees are asked to assume positive intent, treat a Slack message as a request for help or an attempt to be helpful, and avoid reading hostility into text. The “short toes” value reinforces this: if the work is the point, feedback is about the work rather than a personal attack. In an asynchronous culture, those norms reduce the negative headbutting that can otherwise accumulate.

The practices are concrete. GitLab has a thanks channel where people post appreciation, which continuously reinforces collaborative behavior. Negative feedback is supposed to be one-on-one so no one is embarrassed or misreads a public message; that norm also makes public channels safer because people can assume positive intent more easily. DeSanto says the values are lived from the CEO down to a new college hire, which is why he describes GitLab as the happiest he has been in his career.

“Short toes” means you are not your work. If someone gives feedback on a video, a document, or a product decision, the goal is to ask what would make it better rather than to feel stepped on. DeSanto contrasts this with an environment where people have “long toes” and feel invaded whenever someone touches their area. The point is contribution and improvement, not ownership of turf.

DeSanto also points to results and efficiency as core values. Results means focusing on customer outcomes—helping customers ship software faster, make it more secure, and get better visibility into usage—which in turn supports empathy for customers and the broader community. Efficiency means pushing responsibility down to the lowest level: leadership sets a three-year and seven-year strategy, but teams decide how to get there. That structure lets GitLab ship something good, get customer feedback, and iterate rather than waiting for perfection.

DeSanto says the most common reason people do not fit at GitLab is not skill but the remote experience. Some people miss the daily office feeling or the energy of being around colleagues, and even strong performers can struggle if they do not feel connected. He admits he found the transition jarring himself: he joined a few months before the pandemic, had met only a slice of the company at sales kickoff, and did not meet many colleagues in person until GitLab’s first company-wide gathering in March. Remote work is an adjustment to how the day flows and how people engage.

His advice for remote-first leaders starts with transparency and a focus on results rather than hours. Managers should ask whether an agreed outcome was achieved, not whether someone worked a full 40 hours or more. He cites an executive coach’s rule: if you think you are communicating 100% accurately, the other person probably receives 60–70%, so aim for 150%. Finally, make time for in-person events; DeSanto brings his leadership team together quarterly and the broader director group every other quarter, and he got all 140 people in the product division together across two cities over a month.

Outcomes need to be business outcomes, not deliverables. Fixing a bug is a deliverable; a better outcome might be getting 60% of the customer base to use a part of the portfolio. That framing lets teams scope the work, measure adoption, and celebrate the customer result rather than the number of features shipped. DeSanto says this is the hardest shift for people moving into product: stop thinking in bits and bytes and start with the use case and pain point, because sometimes the answer is making an existing feature more usable rather than shipping a new one.

The questions DeSanto gets from other leaders tend to cluster around three themes: how he moved from software development and security research into product, how GitLab’s transparent handbook and “GitLab unfiltered” channel came to exist, and whether remote development is right for a given person. On the last point he shares his own early anxiety about remote work and the advice to listen to family and partners who may see the fit more clearly. He also notes that product is not the glamorous role people imagine, and that PMs should think beyond taking orders.

For PMs in a remote world, DeSanto’s first rule is that requirements must be clear in writing. When there is no hallway conversation or daily stand-up to clarify, the PM has to get the issue refined before expecting engineering to act. GitLab tests this in a “deep dive” interview: candidates get an hour-long call with a product person playing the engineering counterpart, then write an epic, a first milestone, and an MVC for a topic such as shipping a new bicycle. The exercise is not free work; it lets both sides see whether the candidate can operate in a remote, written-first environment.

His second rule is not to wait for the next scheduled check-in. If a PM is worried that something is off track, or just wants to know whether it is on track, the right move is to comment on the issue or merge request or send a Slack message immediately. Leaving a developer or engineering manager blocked for 24, 48, or 72 hours is far worse than asking a question early. The old “tap someone on the shoulder” behavior has to become digital, and the kindness and positive-intent norms make that easier.

GitLab uses its own product for this workflow: if you have an idea, open an issue and tag the team, then convert it into an epic or engineering issue when it becomes work. Slack and Zoom are the other main tools: too much back-and-forth in writing should trigger a Zoom call, and decisions should be written back into an issue or handbook page so everyone can benefit. GitLab is intentionally anti-email internally; email is mostly for external communication. The handbook is treated like a product, and employees are encouraged—even during onboarding—to open merge requests for typos, unclear wording, or bigger process changes.

Time zones are handled with asynchronous communication first. If a key decision involves someone who is offline, GitLab waits for the directly responsible individual to return; meetings are optional, recorded, and accompanied by good notes so people in other zones can consume them later. Leaders model this: the leader of the SaaS platform portfolio lives in Germany while much of the team is in the US, and a former leader in Tel Aviv had only a half-hour overlap with DeSanto in the central US but ran a highly effective dispersed team. With people in more than 60 countries, GitLab tries to empower local leaders to take calls at times that would be inconvenient for others.

Lenny relays Hila Qu’s observation that GitLab has been unusually good at a breadth-over-depth strategy. DeSanto agrees: when Hila joined in 2019, GitLab was deliberately broad so it could become a true DevSecOps platform and touch the different parts of the software development lifecycle. A platform strategy required coverage, not just one excellent point solution. That breadth helped GitLab build the surface area needed to be a single platform for how teams deliver software.

Last year, GitLab made a conscious pivot to depth over breadth. The platform is now broad enough to cover business continuity planning, OKRs, enterprise agile planning, coding, deploying, securing, and monitoring; the next step is to be really deep in areas that accelerate software delivery. DeSanto names source code management, code review, IDE experience, remote development, CI/CD, security and governance, planning, and AI as the core areas for depth. Other areas can benefit from the rising tide rather than receiving equal investment.

The broader lesson is that wide and deep are phases, not permanent identities. DeSanto says going wide is useful when you are trying to find your niche and understand where you can differentiate; once you find fit, you put your wood behind that arrow. GitLab still uses breadth-first thinking when it enters new areas or expands its SAM, but it now knows which areas must lead the market. He points to MLOps: GitLab added ModelOps functionality in 2020 and focused on depth in MLOps, while relying on integrations for DataOps rather than building every adjacent capability.

Lenny compares this with HubSpot, which also pursued breadth over depth and transparency; DeSanto says there are universal product frameworks behind such choices. Founders ask him when to pivot, and his answer is to ask whether you have found product-market fit, invoking Geoffrey Moore’s Crossing the Chasm. Once you have found it, you can put all your wood behind the arrow and build differentiation and market presence. GitLab still returns to breadth over depth when it looks at new investments, including parts of its AI strategy.

DeSanto argues that GitLab’s DevSecOps position gives it a different AI lens from developer-tool competitors. If only about 25% of the software development lifecycle is writing code, then helping the developer alone will not make the whole organization effective; GitLab wants AI to help product managers, QA, ops, and security teams too. He says making one developer 100 times more effective can simply break everything around them if the surrounding roles are not helped. That is why GitLab set out to apply AI across the entire software development lifecycle.

The second principle is transparency and privacy. GitLab tells customers which models it uses, is source-available so people can see how the models are used, and explains how they are trained. DeSanto says GitLab does not train or fine-tune models on customers’ intellectual property; its models are trained on data that is not the customer’s, which gives customers more safety. That matters because GitLab says more than 50% of the Fortune 100 trust it with intellectual property, so AI had to meet the same bar.

The third principle is efficiency. GitLab Ultimate, the top tier, has shown a 7X productivity boost in customer data analysis, and DeSanto wants to take that to 10X. The way to get there is not to force every feature through one popular model. He says teams often pick a popular commercial or open-source LLM and then make every use case fit it, which reduces quality; GitLab instead finds the right model for the right use case.

GitLab currently uses around 16 models in its GitLab Duo AI suite. Vulnerability explanation and resolution may use one model, conversation and planning summaries another, and inline code completion must be much faster than code generation, which can take 20–30 seconds for a block of code. The models include commercial partners such as Google and Anthropic, GitLab proprietary models from the UnReview acquisition in 2021 or 2022, and open-source models; an AI model validation team helps choose among them. GitLab publishes the model choices in its documentation and says partners must meet its privacy requirements.

DeSanto uses humor as a leadership tool in high-stakes conversations. He learned early that tension can kill productivity and morale, and a little levity can disarm a topic so people can move forward. He admits not every joke lands and says the skill requires reading the room and the nuance, but he treats it as part of his tool belt rather than a personality quirk. Hila Qu, who worked with him at GitLab, described him as a leader with a great sense of humor in executive negotiations.

When asked what listeners should know about GitLab, DeSanto gives a broad product tour. GitLab covers the software development lifecycle, with particular strength in source code management and code review, CI/CD, security and compliance, and monitoring and analytics; it is adding observability and service management. It also offers enterprise planning, remote development, and GitLab Duo, which customers say has produced efficiency boosts of 50% and above. DeSanto’s pride is that customers who once assembled 75 point tools can adopt GitLab and find more effective collaboration.

In the lightning round, DeSanto recommends Crossing the Chasm and Essentialism, and cites Geoffrey Moore’s critical core context framework for deciding what is critical, what is core, and what can be said no to with low risk. He names The Devil’s Hour, Glass Onion, and the Eras Tour as recent viewing, and Superhuman and Arc as products he loves. His leadership mottos are that the team owns its accomplishments but the leader owns failures and misses, “just make it work,” and “it’s just software so anything’s possible.”

For listeners who want to help, DeSanto asks them to comment on GitLab’s public issues and tasks, vote things up, and send feedback. People can also open a merge request to improve the handbook or contribute code, from small bug fixes to new features; because companies fork the handbook, improving it helps more than GitLab. He points people to GitLab on social media and to his own accounts, including LinkedIn, X, Threads, and Bluesky, under variants of David DeSanto or David the Beard.