Embodied Algorithm Offsite
Make the team physically become the system so nobody can leave without understanding it
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 4
- Confidence
- 90%
A deliberate technique for getting an entire team to internalise a complex change, rather than letting two or three people race ahead while the rest nod along. Schottenstein physically constructed the system in the room — engineers as nodes, rope as edges — and walked the new algorithm through step by step, slowly, with everyone holding a role. The design constraint is the point: you cannot copy-paste the algorithm, and you cannot leave the exercise without knowing exactly what is going on, because your participation is load-bearing.
Origin
Julia Schottenstein, inspired by a scene in Douglas Hofstadter's Gödel, Escher, Bach in which an ant colony bands together to do the work of a computer, flipping bits from zero to one to solve logic gates. She adapted it for a dbt Labs team offsite about a year before the interview.
Core principles
- 01Ownership requires internalisation, and internalisation requires participation
- 02If a few people run way ahead of the pack, the design will not survive its edge cases
- 03Physically embodying a system prevents the copy-paste illusion of understanding
- 04Deliberately create memorable moments centred on the mission
- 05Going extremely slowly is the mechanism, not a concession
How to run it
- 1
Diagnose the comprehension gap
Use this when you are doing a big zero-to-one project with a genuinely new algorithm or architecture, and you notice a few people understand it deeply while everyone else is following along. The tell is that the team could not anticipate the edge cases on their own.
Watch out Do not use this for changes people can simply read a doc to understand. The overhead only pays off for genuinely novel, structurally complex work.
- 2
Map the system onto people and physical objects
Assign every structural element of the system to a person or a physical prop, so that the whole thing exists only if everyone participates. Schottenstein made each engineer a node of the graph and used rope as the edges connecting them, with sticky notes for state.
Pro tip Choose a mapping where every single person has a role — the whole point is that nobody can spectate.
Watch out Expect the team to look at you like you have two heads. Do it anyway.
- 3
Walk the algorithm through extremely slowly, step by step
Execute the new algorithm by hand across the human system, one step at a time. The slowness is what surfaces the edge cases and forces every participant to reason about their own role rather than trusting someone else's.
Pro tip Because you cannot copy-paste the algorithm when it is made of people and rope, the exercise structurally prevents fake comprehension.
- 4
Hand over ownership
The purpose is not the lesson but the ownership: once everyone has held a role in the system, they own the project and can anticipate its edge cases, making the design more durable. Frame the exercise as a memorable moment centred on the team's mission.
Pro tip These moments compound — a leader who reliably creates them builds a team that expects to own things rather than receive them.
In the wild
About a year before the interview, dbt Labs was doing a big zero-to-one project: changing the algorithm for how customers' data transformation graphs were built — flipping the way DAGs run from an imperative model (run things left to right as data arrives in the warehouse) to a declarative one (work backwards from what would need to happen for your data SLAs to be materialised in time). Schottenstein needed the whole team, not just the fast few, to internalise it and own it. She turned up to a team offsite with a spool of rope and sticky notes and started tying people together — engineers as graph nodes, rope as edges — then walked the new algorithm through extremely slowly, step by step.
→ Everyone had a role to play, so nobody could leave the exercise without knowing exactly what was going on. She describes it as perhaps an overly creative or kooky way to spend the day, but really successful — the team went along for the journey together rather than a few people running ahead.
Common mistakes
Letting the fast few run ahead
When a small group understands a new system and the rest do not, the team cannot anticipate edge cases and the resulting design is less durable.
Mistaking a walkthrough for internalisation
A presentation lets people copy-paste comprehension. Embodying the system removes that escape hatch because participation is required to make the system exist at all.
Rushing the walkthrough
The value comes from moving through the algorithm extremely slowly. Speeding it up returns you to a normal meeting with props.
Is it for you?
Best for
Engineering and product leaders on a zero-to-one project with a genuinely novel algorithm or architecture, where whole-team ownership matters more than speed of rollout
Not ideal for
Incremental changes, distributed teams that cannot get in a room, or work that a written design doc adequately conveys
From the transcript
“one of my favorite books on logic is called girdle eer Bach and in this book there's a fun scene where there's an ant farm…”
“so I showed up to a team offsite with uh spool of rope and uh sticky notes and I think my team looked at me…”
“it was a way that you couldn't leave that exercise without knowing exactly what was going on because everyone had a role to play”
“I think a lot of times when you're starting something new you get into a situation where a few people really understand it and they're…”
From the episode
M&A, competition, pricing, and investing
Julia Schottenstein (dbt Labs)