LLenny's Podcast
← All episodes
David DeSanto (CPO)14 April 2024

The GitLab way: Kindness, transparency, and short toes

8Frameworks
15Insights

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 →

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