The Engineer-cation
Leaders clear 3-4 days, join a team as an IC, ship one small feature to production, and log the friction.
- Difficulty
- Moderate
- Time to result
- ~days to results
- Steps
- 6
- Confidence
- 95%
An engineer-cation is a portmanteau of engineer and vacation: a leader clears their calendar for several consecutive days, joins a team, picks up a small task, and ships it end-to-end to production using exactly the tools and processes the team uses every day. It is the antidote to leaders making trade-off calls about developer productivity from slideware. The output is a written friction log of the experience, shared with the team.
Origin
David Singleton's personal practice as CTO of Stripe, which he has since institutionalised: he advises every Stripe engineering manager to run one in their first quarter-to-six-months, then annually. He had done something similar before joining Stripe.
Core principles
- 01Managers are the editors-in-chief of their team's plans, which requires ground-truth about what the work actually feels like.
- 02Doing IC work every day is damaging for a leader; doing it on a deliberate cadence is high-leverage.
- 03The credibility cost of being visibly bad at the team's stack is far smaller than the cost of not knowing.
- 04Treat it like a vacation: the world goes on without you, so decline everything and take a maker schedule.
- 05The context you buy funds years of downstream prioritisation conversations.
How to run it
- 1
Clear three to four consecutive days
Decline every meeting for the block, exactly as you would for a vacation. Singleton names finding and defending this time as the single hardest part of the practice.
Pro tip Frame it internally as a vacation, not a work block — people respect a vacation boundary in a way they don't respect a 'focus day'.
Watch out A day here and a day there does not work; you need a maker schedule long enough to get a change all the way to production.
- 2
Pick a team and a genuinely small feature
Choose a task small enough that it can realistically get from start to finish and into production inside the block. The point is to traverse the whole pipeline, not to ship something impressive.
Watch out Picking an ambitious task means you never reach deployment — which is where most of the friction lives.
- 3
Get assigned a buddy on the team
Identify someone on the team to onboard you and unblock you. Singleton had never written a line of Ruby before joining Stripe; his buddy Akshay taught him during the three days.
Pro tip Being visibly a beginner is the point. Singleton was afraid of losing credibility; the team ripped him a little and ultimately appreciated that he'd done it.
- 4
Go through the exact experience the team has
Use their dev tools, their build infrastructure, their review process, their docs. Notice how long you wait to see your change live and how long the feedback loop actually takes.
Pro tip Tell the reviewer of your pull request explicitly: 'this is an important part of the process, please don't treat me any different to anyone else.'
- 5
Keep a friction log throughout
Write up the experience as an aide-mémoire for yourself and as a shared artefact for the team. Singleton rereads his reports periodically; the context feeds years of subsequent trade-off and prioritisation conversations.
Pro tip Sharing the log with the team is what proves you actually understand what their week feels like — it converts the exercise from a stunt into a mandate.
- 6
Set the no-immediate-action expectation up front
Explicitly tell the team you are not going to demand instant changes to anything you dislike. This is a longitudinal input to prioritisation, not a review.
Watch out Without this expectation, an executive dropping into a team turns every offhand observation into an emergency, and the team performs for you instead of working normally.
In the wild
Stripe's core product infrastructure is mostly Ruby. When Singleton joined as CTO he had never written a line of Ruby, and was genuinely scared of the credibility hit from showing up unable to write it. He did the engineer-cation anyway with a buddy, Akshay, who taught him Ruby over three days.
→ He shipped the change, took some good-natured ribbing, and gained lasting credibility plus years of usable context; he now advises every Stripe EM to do the same in their first six months.
During an engineer-cation, Singleton found parts of the development process where teams were working hard to help each other synchronously — 'come talk to this other team if you want to use this thing' — which quietly penalised anyone in a different time zone.
→ The finding drove a conversation about documenting and automating those steps and making consultation available asynchronously instead.
Common mistakes
Doing IC work continuously instead of periodically
Singleton is explicit that it would be damaging for him to do IC engineering every day — it doesn't ladder up to guiding the team. The value comes from the cadence, not the volume.
Not actually clearing the calendar
A half-attended engineer-cation reproduces the fragmented schedule you already have and never reaches production, so you learn nothing about the deploy loop — the part that matters most.
Turning findings into immediate directives
A leader who ships one feature and then mandates changes based on three days of exposure destroys the trust that makes the next engineer-cation possible.
Is it for you?
Best for
Engineering leaders and CTOs at companies large enough that they no longer touch the codebase, who need direct evidence about developer productivity rather than dashboards.
Not ideal for
Small startups where leaders already write code daily, or leaders who cannot credibly commit to not intervening on what they find.
From the transcript
“I'll clear several days in a row, three or four days, actually join a team, pick up a small task”
“While one does that, uh, it's really valuable and important to keep a friction log because”
“advise engineering managers at Stripe that they should do an engineer-cation sometime in their first quarter to six months at the company”
“you have to set the expectation that you're not going to like take immediate action if something isn't exactly the way you want it to…”
From the episode
Building a culture of excellence
David Singleton (CTO of Stripe)