David DeSanto (CPO)14 April 2024

The GitLab way: Kindness, transparency, and short toes

8Frameworks

15Insights

Episode overview

Lenny Rachitsky interviews GitLab CPO David DeSanto about how GitLab operationalizes radical transparency through public meetings, its handbook, issue tracker, and product direction. DeSanto connects GitLab’s kindness, positive-intent, and “short toes” values to effective asynchronous remote work, emphasizing clear written requirements, outcome-based management, and empowered teams. They also examine GitLab’s shift from breadth to depth in product strategy and its privacy-conscious, use-case-specific approach to AI through GitLab Duo.

Key ideas

Transparency is a default at GitLab, with customer data, vulnerabilities, and material non-public information treated as explicit exceptions.
Public meetings, issues, strategy, and handbook pages invite contributions and create feedback loops with customers and the open-source community.
Kindness, assuming positive intent, private negative feedback, and having “short toes” reduce interpersonal friction in asynchronous work.
Remote teams should prioritize clear written requirements, overcommunication, recorded optional meetings, asynchronous decisions, and occasional in-person gatherings.
Teams should be measured by customer outcomes and adoption rather than hours worked or the number of features shipped.
GitLab initially pursued breadth across the software-development lifecycle, then shifted toward depth in strategically important areas once the platform matured.
GitLab selects different AI models for different use cases while emphasizing transparency, privacy, and not training on customer intellectual property.

Transcript available · source text is retained privately and is not published

Frameworks in this episode

Strategy6 steps

Breadth-Then-Depth Platform Strategy

Go wide to discover your niche, then put all your wood behind the few arrows that lift the rest

Read →

Productivity5 steps

Celebrate Adoption, Not Shipping

Replace hours and feature counts with customer-adoption outcomes teams can actually steer toward

Read →

Leadership5 steps

Handbook-as-Code

Treat how the company operates as a versioned repo anyone can submit a merge request against

Read →

Innovation6 steps

Right Model for the Right Use Case

Route each AI feature to a model chosen for that job, not one popular LLM stretched over everything

Read →

Communication5 steps

Short Toes

Engineer feedback so it lands on the work, never the person — the async collaboration protocol

Read →

Leadership5 steps

The Deep Dive PM Interview

Make candidates write real async requirements and defend them — a two-way test for remote PM fit

Read →

Leadership5 steps

The Remote-First Operating Stack

Five mechanisms that make an all-remote company across 60+ countries actually work

Read →

Leadership5 steps

The Transparency Ramp

Default everything to public except three named exceptions, then ramp until it feels uncomfortable

Read →

People & resources mentioned

Attributed to the moment in the episode. Timestamps are approximate.

People · 9

David DeSantoMentionsDavid is the chief product officer at GitLab.
“today my guest is David D Santo David is the chief product officer at gitlab”
▶ Watch at ~0:30approx.
Lenny RachitskyMentionstoday we've got another very special compilation episode something I've been pulling on more and more with the podcast and the newsletter
“David thank you so much for being here welcome to the podcast”
▶ Watch at ~4:00approx.
Marty CaganMentionsMarty has been helping product teams and product managers improve their craft processes and careers for over 20 years
“they're talking about a book club of Marty kagan's recent book”
▶ Watch at ~6:00approx.
Sid SijbrandijMentionsGitLab co-founder and CEO.
“I actually asked Sid our co-founder and CEO a similar question”
▶ Watch at ~13:00approx.
Hila QuMentionsToday, my guest is Hila Chee.
“I asked a previous guest who worked with you heila Chu who was head of growth”
▶ Watch at ~57:00approx.
Dharmesh ShahMentionsone of the attendees there is darmesh founder of hubspot and very thoughtful person
“my last interview that I did was with the co-founder of HubSpot daresh”
▶ Watch at ~1:01:30approx.
Geoffrey A. MooreMentionsmentioned
“the two that I probably recommend the most are crossing the Chasm by Jeffrey Moore”
▶ Watch at ~1:15:00approx.
Josh MillerMentionstoday my guest is Josh Miller Josh is the CEO and co-founder of a company called the browser company
“the Josh Miller was on the podcast talking about how they operate”
▶ Watch at ~1:18:00approx.
Tim GunnMentionsmentioned
“people who are listening to your podcast might realize that a Tim gun saying from Project Runway”
▶ Watch at ~1:18:30approx.

Resources · 33

YouTubeUseswebsite · Google
“you post videos of your team meetings on YouTube”
▶ Watch at ~0:00approx.
GitLabMentionscompany · GitLab
“David is the chief product officer at gitlab which is an incredibly unique company”
▶ Watch at ~0:30approx.
GitHubMentionssoftware · GitHub
“a source code management business competing with GitHub”
▶ Watch at ~1:00approx.
Lenny's PodcastMentionspodcast · Lenny Rachitsky
“if you enjoy this podcast don't forget to subscribe and follow it in your favorite podcasting app”
▶ Watch at ~1:30approx.
OrbRecommendscompany · Orb
“use orb to ship product faster stop worrying about billing and evolve pricing with ease and control”
▶ Watch at ~2:30approx.
EppoRecommendssoftware · Eppo
“check out EPO at geo.com Lenny and 10x your experiment velocity”
▶ Watch at ~4:00approx.
ThreadsUsessoftware · Meta Platforms
“I just started trying to use threads”
▶ Watch at ~5:00approx.
GitLab UnfilteredMentionswebsite · GitLab
“you can search for GLE filtered on YouTube and there's more content there than a human being could watch”
▶ Watch at ~7:00approx.
GitLab HandbookMentionswebsite · GitLab
“you also have this handbook the gitlab handbook which is handbook. gitlab.com”
▶ Watch at ~9:30approx.
GitLab HandbookRecommendswebsite · GitLab
“if you can Leverage What gitlab has done that's amazing”
▶ Watch at ~10:30approx.
ParagonRecommendssoftware · Brandon Foo
“Paragon enables your engineering team to ship Integrations seven times faster than building a house”
▶ Watch at ~41:00approx.
SlackUsessoftware · Slack Technologies
“we use slack it's like reach out on slack or comment on the git lab issue”
▶ Watch at ~47:00approx.
ZoomUsessoftware · Zoom Video Communications
“we also encourage people to use zoom if you have too many back and forth”
▶ Watch at ~49:00approx.
Google WorkspaceUsessoftware · Google
“we use Google workspace”
▶ Watch at ~50:00approx.
GitLab DedicatedMentionssoftware · GitLab
“our SAS platforms which are gitlab.com and gitlab dedicated”
▶ Watch at ~54:00approx.
LinkedInUseswebsite · LinkedIn
“I think it's how I stay in touch with former colleagues”
▶ Watch at ~57:30approx.
GartnerMentionscompany
“analysts like Gardner and Forester are calling that out”
▶ Watch at ~1:00:00approx.
ForresterMentionscompany
“analysts like Gardner and Forester are calling that out”
▶ Watch at ~1:00:00approx.
HubSpotMentionscompany · HubSpot
“my last interview that I did was with the co-founder of HubSpot daresh”
▶ Watch at ~1:01:30approx.
GitLab DuoMentionssoftware · GitLab
“around 16 models we use today to make gitlab have its AI Suite which is called gitlab Duo”
▶ Watch at ~1:07:00approx.
AnthropicUsescompany
“today we've partnered with both Google and anthropic”
▶ Watch at ~1:08:30approx.
UnReviewMentionscompany
“we actually acquired a company at the beginning of 2021 or 2022 named un review”
▶ Watch at ~1:08:30approx.
Google CloudUsesproduct · Google
“both Google as in Google cloud and anthropic were able to meet the Privacy requirements we had”
▶ Watch at ~1:09:30approx.
Crossing the ChasmRecommendsbook · Geoffrey Moore
“the two that I probably recommend the most are crossing the Chasm by Jeffrey Moore”
▶ Watch at ~1:15:00approx.
EssentialismRecommendsbook · Greg McKeown
“the other one is essentialism and that is really about saying no to the right things”
▶ Watch at ~1:15:00approx.
Core and Context FrameworkRecommendsother · Geoffrey A. Moore
“there's the critical core context framework and if you've read both of those books it really helps you frame”
▶ Watch at ~1:15:00approx.
Zone to WinMentionsbook · Geoffrey A. Moore
“does he talk about that in zone to win”
▶ Watch at ~1:15:30approx.
Glass Onion: A Knives Out MysteryRecommendsfilm · Rian Johnson
“my wife and I just watched The Glass Onion really liked it”
▶ Watch at ~1:16:00approx.
The Devil's HourRecommendstv show
“the most recent TV show I really like the devil's hour”
▶ Watch at ~1:16:00approx.
Taylor Swift: The Eras TourRecommendsfilm · Sam Wrench
“we watched the erors tour when it came available to watch and also was phenomenal”
▶ Watch at ~1:16:00approx.
ArcUsessoftware · The Browser Company
“I just started using the arc browser from the browser company and I think it's fantastic”
▶ Watch at ~1:17:30approx.
Project RunwayMentionstv show
“a Tim gun saying from Project Runway”
▶ Watch at ~1:18:30approx.
BlueskyUsessoftware · Bluesky Social
“I'm also trying to make blue sky a thing for me”
▶ Watch at ~1:19:30approx.

Spot an error or want something removed? Request a correction or removal.

Insights & moments

The myth-busts, hot takes, explainers, and tools worth keeping.

Hot Take· 2

Hot Take13:00

Transparency Is Execution, Not the Idea

Lenny notes anyone could copy GitLab's open playbook but nobody replicates it — it's the execution that separates them. David traces his own early fear of sharing roadmaps (ideas getting stolen) to CEO Sid's reframing: product's job is ambition, engineering's job is to meet it. Framed that way, publishing plans stops being scary.

David feared shared roadmaps because a great idea could be built by others first
Sid's reframe: product is ambitious, engineering meets that ambition
The collaboration between the two makes putting information out less scary
It's not the idea, it's the execution that competitors can't copy

“he basically said you know it's product's job to be ambitious it's engineering's job to meet that ambition and if you think of it that…”
David DeSanto · 13:30

#transparency#leadership#product#strategy

Hot Take42:00

If Everyone's Annoyed, You're Doing Your Job Well

David is blunt that product isn't the rockstar role people imagine. As the hub of the wheel connecting engineering, marketing, sales and legal, a good PM pushes boundaries — and if everyone around you is a little annoyed and questioning the workload, you're probably doing it right. Don't be an order-taker; work out what all the requests together really mean.

Product is the hub of the wheel; the spokes are engineering, marketing, sales, legal
If everyone's a little annoyed, you're probably doing your job well
Don't be an 'order taker' or deli-counter worker filling requests
Figure out what all the requests together mean, then do that

“if everyone's really annoyed you're probably actually doing your job well right product is the like the Hub in the middle of the wheel”
David DeSanto · 42:00

#product#career#leadership#hot-take

Explainer· 6

Explainer06:30

Why GitLab Posts Its Team Meetings on YouTube

GitLab records and sometimes live-streams internal meetings to a public YouTube channel called GitLab Unfiltered. The default is maximum transparency: anything that isn't customer data or vulnerability information can go public. A surprising payoff is that outside developers watch, spot issues, and contribute code fixes on their own.

Policy is 'be as transparent as possible' unless it's customer data or vulnerability info
Search 'GitLab Unfiltered' on YouTube for more meeting content than one person could watch in a day
Whether to post is up to the individual and their team
Community and open-source members watch, find bugs in the public issue tracker, and commit fixes

“our policy is like be as transparent as possible so if it's not customer data it's not vulnerability information we heavily encourage team to put…”
David DeSanto · 06:30

“we've had you know customers open source community members go oh I can go build that I know what that is and they will just…”
David DeSanto · 08:00

#transparency#remote-work#open-source#culture

Explainer18:00

How Transparency Kills FOMO in a Global Team

David's top benefit of working openly is focus on results plus letting a 2,000-person global company consume what happened while they were offline. It raises engagement and removes the fear of missing out. Second-order benefits: better alignment and catching problems earlier instead of at the end of a release.

People asynchronously consume what happened while offline, reducing FOMO
Raises both engagement and alignment across a 2,000+ person global team
Teams catch issues earlier rather than at the end of a release or campaign
Being transparent can end up less work than tracking who heard what

“it allows people to asynchronously consume what happened while they were offline and it gives them both more engagement as well as that lack of…”
David DeSanto · 18:30

#transparency#async#remote-work#alignment

Explainer22:00

Kindness Means Assuming Positive Intent

In an all-remote culture you can't read tone in a Slack message, so GitLab's kindness value operationalizes as 'assume positive intent' — the other person is asking for help or trying to help. David says treating each other this way removes a lot of the negative headbutting that plagues async teams, and that GitLab actually lives its values from the CEO down.

You can't read intent or emotion in a Slack message when fully remote
Assume the person is asking for help or trying to be helpful
Kindness plus positive intent removes negative headbutting in async cultures
Values are lived from Sid down to a new grad, not just posted

“we say assume positive intent assume the person is traditionally just asking for help or is trying to be helpful”
David DeSanto · 22:30

#culture#kindness#remote-work#values

Explainer25:00

Short Toes: It's About the Work, Not You

GitLab's 'short toes' value means feedback on your work is someone helping make it better, not a judgment of you as a person. With long toes you feel people stepping on you when they contribute in your space; with short toes it's about the work. David notes it's the exact opposite of Uber's 'step on toes' value — the other side of move fast and break things.

Comment on the work, not the person — 'this could have been better this way,' not 'look what you did'
With long toes you feel people are stepping on you; short toes makes contribution welcome
David posts videos that aren't always well-received and doesn't take it personally
The exact opposite of Uber's toe-stepping value

“the short toes is you know it's really about the it's about the work it's not about you”
David DeSanto · 25:00

“it's the exact opposite of uber whose one of their values I think was encouraging toe stepping step on toes don't worry about it long…”
Lenny Rachitsky · 26:30

#culture#feedback#values#short-toes

Explainer58:00

Breadth First, Then Depth: GitLab's Product Bet

GitLab deliberately went broad first to build out the full DevOps platform, touching every part of the software lifecycle. Last year they consciously pivoted to depth over breadth in key areas — source code management, code review, CI/CD, security, planning and AI — betting a rising tide from those deep areas lifts the shallower ones around them.

Went breadth-first to cover the whole DevOps / SDLC as a platform play
Pivoted to depth-over-breadth once the platform was broad
Deep-investment areas: SCM, code review, IDE/remote dev, CI/CD, security & governance, planning, AI
Deep areas create a 'rising tide' that lifts the less-deep areas around them

“last year we made the conscious decision to start to Pivot to depth over breath and that's because we have a very broad platform today”
David DeSanto · 58:30

#strategy#product#platform#breadth-vs-depth

Explainer66:30

Don't Force One AI Model to Do Everything

David's core AI lesson: people grab one popular LLM and make everything fit it, which reduces feature quality. GitLab runs around 16 models across its GitLab Duo suite, matching each to a use case — one for explaining vulnerabilities, one for summarizing, and different models for inline code completion versus generating whole code blocks, which can take 20–30 seconds.

Forcing one model onto every use case reduces the quality users experience
GitLab uses ~16 models across its GitLab Duo AI suite
Match model to task: vulnerability explanation, conversation summarization, code generation
Inline completion and full block generation need different models — block generation can take 20–30 seconds

“we have around 16 models we use today to make gitlab have its AI Suite which is called gitlab Duo”
David DeSanto · 67:00

#ai#llm#product#gitlab-duo

Story· 3

Story09:30

Companies Fork GitLab's Public Handbook

The GitLab handbook publishes how the company operates: mission, strategy, onboarding, even how accounts payable works. Because it's source-available, other companies and startups clone whole sections as their own baseline. David sees this as leverage — you skip the uplift of building a department's operating model from scratch.

The handbook is source-available; you can view source at the bottom of any page
A company cloned GitLab's UX handbook as the baseline for its own UX department, then became a customer
Startups have cloned the entire handbook to start operating
PM competency levels and ladders are among the most-copied parts

“we'll have companies who will Fork the handbook because it's just Source available too at the bottom of the page you can clect view view…”
David DeSanto · 10:00

#handbook#transparency#operations#culture

Story14:00

149 On-Time Releases Over 12 Years

GitLab ships 12 releases a year, every month, and has for over a decade. They moved the release date from the 22nd to the third Thursday so nobody has to work weekends. As of the interview they'd hit 149 consecutive monthly releases.

12 releases a year, essentially every month, for over 12 years
Release date moved from the 22nd to the third Thursday to avoid weekend work
149 releases shipped as of recording

“we still ship 12 releases a year it used to be on the 22nd of every month it's now the third Thursday so we don't…”
David DeSanto · 14:00

#shipping#cadence#engineering#operations

Story44:30

The 'Deep Dive' PM Interview

GitLab's PM hiring includes a deep-dive interview where a candidate writes real requirements and role-plays with someone from product acting as the engineer. One candidate chose bicycles: define the epic, the first milestone, the minimum viable change, then iterate as questions come in on the issue. David thought it was a weird step going in and called it the best interview experience he'd had.

Candidates write requirements and refine them through a role-play with a product person playing engineer
It tests whether someone can write clear requirements for a remote environment
Example prompt: ship a new bicycle — define the epic, first milestone, and minimum viable change
Some candidates realize the remote PM role isn't for them; David called it the best interview process he'd had

“as part of the interview process of G lab we do what's called a deep dive interview where we have the person try that out…”
David DeSanto · 44:30

#hiring#product#remote-work#interviews

Q&A· 1

Q&A16:30

When Transparency Goes Too Far

Asked about the downsides, David admits GitLab has occasionally been over-transparent — an issue made public that shouldn't have been, or a recording accidentally set to public. He treats these as pain points to learn from and reinforce, and argues the risk is far below the value of pushing yourself to be open.

Issues have gone public that shouldn't have; recordings have been accidentally set public
Treat each slip as a learning and reinforce it across the team so it isn't repeated
The risk of occasional mistakes is well below the value of being transparent

“I think the risk of that occasionally happening is way below the value of actually pushing yourself to do it”
David DeSanto · 17:00

#transparency#risk#culture#lessons

Takeaway· 3

Takeaway23:30

Negative Feedback Is Always One-on-One

GitLab pairs a public 'thanks' channel with a hard rule that negative feedback happens one-on-one. Public praise reinforces collaboration and positive intent, while keeping criticism private prevents someone taking a public message the wrong way.

A public 'thanks' channel constantly reinforces positive engagement
Negative feedback should always be delivered one-on-one
Keeping criticism private stops people reading a public message the wrong way

“the negative is one-on-one that you mentioned L like that one's actually really important to me because you don't want someone to take a public…”
David DeSanto · 24:00

#feedback#culture#management#values

Takeaway38:00

Celebrate Adoption, Not Shipping

Remote leaders are told to focus on outcomes over hours, but David explains how: don't frame goals as 'ship 20 features,' frame them as measurable adoption like getting 60% of customers using part of the portfolio. Fixing a bug is a deliverable, not a business outcome — the shift is from bits and bytes to the use case and pain point.

Set outcomes like '60% of customers using this part of the portfolio,' not feature counts
A bug fix is a deliverable, not a business outcome
Shipping fast isn't how customers measure value — solved pain points are
Sometimes the outcome comes from making a feature more usable, not shipping a new one

“celebrate the adoption not the the shipping”
David DeSanto · 38:30

#product#outcomes#remote-work#metrics

Takeaway35:30

Aim to Communicate at 150%

David's executive coach told him that if you think you're communicating 100% accurately, the other person is probably receiving 60–70%. So in a remote environment you should aim for 150%. Overcommunication is one of his core pieces of advice for remote-first teams alongside transparency, outcomes over hours, and in-person events.

Thinking you communicate 100% usually lands as 60–70% for the other person
Shoot for 150% communication to close the gap
Overcommunication is a key remote-work discipline

“if you think you're communicating 100% accurately that's probably 60 or 70% for the other person and shoot for like 150%”
David DeSanto · 36:00

#communication#remote-work#leadership

Key ideas

Frameworks in this episode

Breadth-Then-Depth Platform Strategy

Celebrate Adoption, Not Shipping

Handbook-as-Code

Right Model for the Right Use Case

Short Toes

The Deep Dive PM Interview

The Remote-First Operating Stack

The Transparency Ramp

People & resources mentioned

People · 9

Resources · 33

Insights & moments

◆Hot Take· 2

Transparency Is Execution, Not the Idea

If Everyone's Annoyed, You're Doing Your Job Well

✶Explainer· 6

Why GitLab Posts Its Team Meetings on YouTube

How Transparency Kills FOMO in a Global Team

Kindness Means Assuming Positive Intent

Short Toes: It's About the Work, Not You

Breadth First, Then Depth: GitLab's Product Bet

Don't Force One AI Model to Do Everything

❝Story· 3

Companies Fork GitLab's Public Handbook

149 On-Time Releases Over 12 Years

The 'Deep Dive' PM Interview

?Q&A· 1

When Transparency Goes Too Far

▲Takeaway· 3

Negative Feedback Is Always One-on-One

Celebrate Adoption, Not Shipping

Aim to Communicate at 150%

Hot Take· 2

Explainer· 6

Story· 3

Q&A· 1

Takeaway· 3