Lenny's PodcastThe GitLab way: Kindness, transparency, and short toes | David DeSanto (CPO)
CHAPTERS
- 0:00 – 0:49
Cold open: GitLab’s radical transparency in the wild
A quick teaser of GitLab’s most unusual practices: publishing internal meetings, maintaining an open handbook, and embracing “short toes.” Lenny and David preview how these ideas connect to community contribution and better remote collaboration.
- •Public YouTube uploads of internal team meetings
- •The GitLab Handbook as an open operating system
- •“Short toes” as a cultural mechanism for reducing conflict
- •Why transparency can invite external contributions
- •Set-up for remote-work and culture discussion
- 0:49 – 4:21
Sponsor break + episode framing: what makes GitLab different
Lenny introduces David DeSanto, GitLab’s scale, and the conversation’s main themes: transparency, kindness, remote execution, and product strategy. This section also includes sponsor messages before the interview begins.
- •David’s role as CPO and GitLab’s remote-first identity
- •GitLab’s expansion from SCM into a full DevSecOps platform
- •What they share publicly vs. what they keep private
- •Upcoming focus areas: remote work, breadth/depth strategy, AI
- •Sponsor reads before the main interview
- 4:21 – 5:29
Beard interlude + why GitLab’s culture draws so much attention
A light opening about David’s beard and online handles quickly turns into why Lenny is fascinated by GitLab’s operating model. The stage is set for a deep dive into transparency as a core differentiator.
- •Beard maintenance and David’s social handles
- •Lenny’s motivation: GitLab’s unique operating system
- •GitLab’s longevity and scale as proof it works
- •Transition into transparency practices
- 5:29 – 9:49
Publishing internal meetings: how GitLab decides what goes public
David explains the practical policy behind “GitLab Unfiltered” and what gets recorded or livestreamed. He shares boundaries (customer data, vulnerabilities, MNPI) and how this changes meeting behavior and accountability.
- •Default posture: share as much as possible
- •Hard constraints: customer data, vulnerabilities, material nonpublic info
- •Examples: product meetings vs. internal KPI deep-dives
- •“GitLab Unfiltered” as a massive public archive
- •Transparency improves meeting quality and engagement
- 9:49 – 11:41
The GitLab Handbook: open-sourcing how the company runs
The conversation shifts to the public GitLab Handbook and why it’s so comprehensive—from onboarding to finance workflows. David highlights how other companies fork and reuse it as a starting point for their own operating systems.
- •Handbook covers everything from values to AP workflows
- •Source-available: companies can fork/clone sections or the whole thing
- •Real-world reuse example: UX orgs cloning GitLab’s UX handbook
- •Handbook as leverage for teams building processes from scratch
- •Public competencies/leveling frameworks as a standout resource
- 11:41 – 14:29
Issue tracker + public strategy: letting the world watch (and shape) the roadmap
David adds two more pillars of transparency: a mostly public issue tracker and unusually detailed public direction/strategy. This creates a feedback loop where customers and community members can comment, vote, and sometimes even contribute code.
- •Most issues are public; customers can comment and influence prioritization
- •External contributors can find problems and submit fixes
- •Public product direction links to epics/issues for traceability
- •Transparency as a competitive advantage: “idea vs. execution”
- •Operational cadence: consistent monthly releases over a decade
- 14:29 – 18:12
How to build transparency (without breaking trust): starting small and learning fast
Lenny presses on what it takes to make transparency work and where it can go wrong. David emphasizes separating truly confidential info from “artificial silos,” accepting occasional mistakes, and rolling out transparency incrementally.
- •Challenge “confidential by default” habits and artificial silos
- •Occasional over-sharing happens; reinforce learning and fix quickly
- •Start internally (company-wide visibility) before going public
- •Use async readouts and recorded meetings to scale transparency
- •Find the right balance for regulated industries
- 18:12 – 21:54
Why transparency pays off: async alignment, less FOMO, faster decisions (and external trust)
David outlines the benefits that outweigh added work and risk: better async participation across time zones, improved alignment, earlier problem discovery, and more informed decisions. Going public also increases external engagement and customer trust.
- •Async consumption enables global teams to stay aligned
- •Reduced fear of missing out; higher engagement across 2,000+ people
- •Earlier detection of issues before releases or go-to-market plans
- •External loop: customer comments + community contributions
- •Transparency can build trust even in regulated industries (selectively)
- 21:54 – 27:41
Kindness and “short toes”: cultural guardrails for remote, async collaboration
Lenny digs into GitLab’s values, focusing on kindness, assuming positive intent, and giving negative feedback one-on-one. David explains “short toes” as separating critique of work from critique of people—especially important when communication is mostly written.
- •Kindness practices: assume positive intent, say thanks/sorry
- •Negative feedback should be delivered one-on-one
- •“Thanks” channel as a reinforcing mechanism
- •“Short toes” = it’s about the work, not your ego
- •Values as prerequisites for transparency at scale
- 27:41 – 32:13
Operating system for execution: results, efficiency, and long-horizon planning
David highlights additional values—results and efficiency—and how GitLab pushes responsibility to the lowest level of the org. He also explains their layered planning: mission/vision/strategy/direction, with examples like the “all-ops platform” ambition and section-stage-group structure.
- •Results-first: solve customer pain points, not internal outputs
- •Efficiency: empower teams; leaders set direction, teams decide how
- •Layered planning horizons (including multi-year strategies)
- •All-ops platform vision: single source of truth for R&D and surrounding teams
- •Org structure: sections → stages → groups mapped to the DevOps toolchain
- 32:13 – 43:52
Remote work at scale: why people don’t fit + how GitLab makes it work
David explains the most common mismatch at GitLab: remote work isn’t for everyone, especially those craving daily in-person connection. He then shares foundational remote-first advice—transparency, outcome focus, overcommunication, and periodic in-person gatherings.
- •Top reason for misfit: missing in-office connection and routine
- •Remote-first fundamentals: transparency + outcomes over hours
- •Overcommunication to close understanding gaps
- •Invest in in-person meetups to strengthen human connection
- •Remote expands hiring pool and improves life flexibility
- 43:52 – 48:25
Remote PM tactics: crisp requirements, no waiting, and the handbook-first workflow
This chapter gets highly tactical for product teams operating remotely. David covers writing clear requirements, GitLab’s “deep dive” interview exercise, and how PMs should proactively unblock engineers via issues, Slack, or quick Zoom calls.
- •Requirements must be written clearly early (async-first)
- •Deep-dive interview simulates remote PM/engineering collaboration
- •Don’t wait for weekly syncs—unblock immediately in the system of record
- •Use issues/merge requests as the collaboration hub; Slack/Zoom when needed
- •Handbook updates via merge requests: document decisions for reuse
- 48:25 – 57:18
Async-by-default logistics: tools, time zones, DRIs, and recorded/optional meetings
David outlines GitLab’s core tooling and time zone practices: GitLab issues as the single source of truth, Slack and Zoom for coordination, and an anti-email bias internally. For time zones, they prioritize asynchronous decisions, DRIs, strong notes, and inclusive meeting norms.
- •Tool stack: GitLab (dogfooding), Slack, Zoom; minimal internal email
- •Decisions move into the handbook so everyone benefits
- •Time zones: async first; key decisions wait for the DRI when needed
- •Meetings are optional, recorded, and supported by strong notes
- •Empowerment model reduces need for painful timezone-overlap meetings
- 57:18 – 1:04:12
Product strategy: when breadth-over-depth wins—and when to pivot to depth
Lenny asks about GitLab’s growth approach: building breadth across the DevSecOps lifecycle, then deliberately shifting to depth in the most differentiating areas. David shares how to decide when to go wide vs. focus, with parallels to other successful platform companies.
- •Early strategy: breadth to build a true DevSecOps platform
- •Later pivot: depth in key areas (SCM, CI/CD, security, governance, planning, AI)
- •Use breadth to find differentiation; use depth to defend and win
- •Selective “good enough” areas supported by deep anchors + integrations
- •Frameworks like Crossing the Chasm guide timing of the pivot
- 1:04:12 – 1:11:52
AI at GitLab (GitLab Duo): principles, privacy, and choosing the right models
David explains GitLab’s AI strategy: assist across the entire SDLC (not just coding), maintain transparency, prioritize privacy, and deliver measurable efficiency gains. He emphasizes a practical lesson for product leaders: match the model to the use case instead of forcing one model everywhere.
- •AI across SDLC: help PMs, QA, ops, and security—not just developers
- •Transparency: disclose models, approaches, and source-available implementation
- •Privacy: don’t train/fine-tune on customer IP; partner only where requirements are met
- •Model selection: multiple models (~16) optimized per task (summarization, vuln resolution, code completion, code generation)
- •Mix of partners (Google/Anthropic), proprietary models, and open source contributions
- 1:11:52 – 1:21:33
Wrap-up + lightning round: books, products, mottos, and how to help GitLab
David closes with a concise overview of GitLab’s end-to-end platform capabilities and where to learn more. The lightning round covers favorite books and shows, interview practices, beloved tools, leadership mottos, and ways listeners can contribute via issues and merge requests.
- •GitLab platform overview across the SDLC (planning → production feedback loop)
- •Lightning round: Crossing the Chasm, Essentialism; favorite shows/movies
- •Interview approach: STAR method + tension/conflict scenarios
- •Favorite products: Artifact (RIP), Superhuman, Arc browser
- •How listeners can help: comment/vote on public issues; contribute to handbook/code
