Short Toes
Engineer feedback so it lands on the work, never the person — the async collaboration protocol
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 5
- Confidence
- 95%
'Short toes' is GitLab's named value for making yourself hard to step on: if your toes are long, every adjacent contribution feels like an intrusion; if they're short, contribution is just contribution. Paired with 'assume positive intent', a public thanks channel, and a hard rule that negative feedback is delivered one-on-one, it forms a complete protocol for keeping a text-first, asynchronous org from generating friction that nobody intended.
Origin
A GitLab core value under the collaboration pillar, explained here by CPO David DeSanto. He frames it as the deliberate inverse of Uber's well-known 'toe-stepping' value and of the 'move fast and break things' school.
Core principles
- 01It's about the work, it's not about you — you are not your output.
- 02Assume positive intent: text strips tone, so default to reading the message as a request for help or an attempt to help.
- 03Comment on the work, not the person: 'this could have been better this way', never 'look what you did'.
- 04Negative feedback is one-on-one, always — which is precisely what makes it safe to assume positive intent in public channels.
- 05Gratitude is public and continuous; criticism is private and specific.
- 06Kindness is not softness — it removes the negative headbutting that destroys async throughput.
How to run it
- 1
Name the value explicitly and put it in writing
Publish 'short toes', 'assume positive intent', 'say thanks', 'say sorry', and 'negative feedback is one-on-one' as stated values (GitLab's are at about.gitlab.com/values). A named value can be invoked in the moment; an unnamed norm cannot.
Pro tip A vivid, slightly odd name ('short toes') gets used in conversation. Abstract virtues ('respect') do not.
- 2
Route all negative feedback to a one-on-one
When you notice you need to give critical feedback, take the conscious step of moving it out of the public channel into a direct conversation. This is the mechanism, not the sentiment.
Pro tip Because criticism never appears in public, public messages become unambiguously safe — the positive-intent assumption stops requiring effort.
Watch out One public dressing-down permanently reintroduces threat-scanning into every public message the team reads.
- 3
Create a standing thanks channel
Run a dedicated channel where people post genuine thank-you notes. At GitLab it receives messages constantly and reinforces the collaborative default.
Watch out It has to be genuine gratitude, not a performance quota, or it becomes noise.
- 4
Model receiving feedback badly-received work
Leaders demonstrate short toes by publicly not taking criticism personally. DeSanto posts videos to Slack that are not always well received; his stated response is to ask what would have made the video better next time.
Pro tip Say the reframe out loud in the thread — people learn the value by watching a leader run it live.
- 5
Use the value as licence to over-communicate
Short toes and positive intent are what make frequent check-ins land as help rather than surveillance. Without them, 'the PM is checking in again' reads as distrust; with them, it reads as unblocking.
Pro tip When someone bristles at a check-in, name the value rather than apologising for the check-in.
In the wild
Lenny points out that Uber's stated values encouraged stepping on toes. DeSanto confirms GitLab took the other side of the 'move fast and break things' move on purpose, optimizing instead for community, trust, and everyone hitting the results together.
→ DeSanto, four and a half years in, calls it the happiest he has been in his career — at a company that is simultaneously an ~$11B publicly traded business.
DeSanto records and posts videos to Slack that are sometimes poorly received by the team.
→ Instead of defensiveness, he treats each as an input: what would have made this more valuable? The next iteration improves, and the team sees the value modelled from the top.
Common mistakes
Delivering criticism in a public channel because it's 'efficient'
It is efficient once and expensive forever: it teaches everyone that public channels can hurt them, which reinstates defensive reading of every message and kills the positive-intent default that async work depends on.
Adopting the value without the async culture that needs it
Short toes exists because remote teams cannot read tone, faces, or intent. Co-located teams get most of this for free from body language; imported as a slogan, it becomes empty.
Confusing 'assume positive intent' with 'never push back'
The value governs how you interpret and where you deliver feedback, not whether you give it. DeSanto is explicit that if everyone is a bit annoyed at the PM, the PM is probably doing the job well.
Is it for you?
Best for
Leaders of remote-first or heavily async teams where written feedback in shared channels is the primary mode of collaboration.
Not ideal for
Situations requiring genuinely hard accountability conversations at speed, or cultures where the leadership team will not actually model it — a stated-but-unlived value is worse than none.
From the transcript
“it's about the work it's not about you”
“assume the person is traditionally just asking for help or is trying to be helpful you know have short toes”
“about you know comment on the work not the person it's not look what you did it's like this could have been better this way”
“negative feedback should be one-on-one”
From the episode
The GitLab way: Kindness, transparency, and short toes
David DeSanto (CPO)