Weeks 6–8: The wind-down we planned became the practice we kept
Daniel Nikulshyn · CEO & Founder ·
Weeks 6–8: The wind-down we planned became the practice we kept
Six weeks ago I wrote that week 6 would be the close. Exit interviews, a playbook decision, a quiet wind-down. We did the exit interviews. We made the playbook decision. We did not wind down — and the reason we didn't is the most useful thing the whole experiment taught us.
The exit interviews said the quiet part out loud
Every developer, ten minutes, written notes. Three questions: what would you do again, what would you skip, would you recommend this to a friend's team.
Nine for nine on "do it again" is a number you should distrust on sight — people are generous in exit interviews. So I read the "what would you skip" column first, because that's where the honesty hides. The skips were real and specific: drop the leaderboard nobody looked at, cap sessions at ninety minutes, stop scheduling them the day after a release.
But the thing that showed up unprompted in seven of nine notes wasn't about Minecraft at all. It was that the session had become the only hour in the week where engineers talked to each other about the system with no ticket in front of them. The game was incidental. The room was the point.
"I learned more about how the billing service actually works in one build session than in six months of standups." — one of the backend engineers
The number that made the decision for us
I've said since week 2 that the metric I watch is the energy score. Week 2 was 8.4. Week 4 dipped to 7.2. Week 5 recovered to 7.6. Then week 6 came in at 8.1, and weeks 7 and 8 — the first two we ran with no end date hanging over them — landed at 8.3 and 8.5.
That sequence is the whole story. I'd read the week-4 dip as fatigue with the game. It wasn't. It was the fatigue of running anything on a countdown — the low hum of "this is ending soon, make it count." The moment we stopped treating it as a six-week experiment with an expiry date, the energy walked straight back to where it started.
We didn't make the sessions better in week 7. We just stopped telling everyone they were almost over.
What we'd do differently from day one
The team drafted this in a single session, posted it internally, and let it get argued with for a week. It survived, so it ships. The short version:
- Rotate the host from day one, and write the one-line rule early: if you can't stop a session, you're not the host. We learned this the expensive way in week 4 and shouldn't have needed to.
- Don't force state-heavy code into the game. Flows, layouts, and sequences build beautifully. State machines collapse into a tangle of redstone nobody can read. Know that boundary before you burn forty minutes rediscovering it.
- Publish your failures the same week you publish your wins. Three-of-five with a clear hypothesis is something another team can build on. Five-of-five is a marketing post.
The actual news: it stays
So here it is. We're keeping it.
Not as a project with a roadmap and a backlog. As a standing practice — a recurring session whose only job is to put the technical people in the same room, building the same thing, with no ticket attached. It's a fixture on the calendar now, hosted on rotation, optional but expected, the way a team lunch is optional but expected.
The reasoning is unglamorous. We set out to design a better way to get nine engineers to share what's in their heads, and the thing that worked turned out not to be a tool or a process. It was a room with a shared object in the middle of it. The game is just the cheapest, lowest-stakes shared object we could find — a thing people will happily stand around and fiddle with while they say the thing they'd never put in a doc.
You don't wind down the only forum where that happens. You protect it.
"We spent six weeks trying to prove the experiment worked. The proof was that nobody wanted it to end." — note from the week-8 debrief
The playbook
We're publishing it. Positive where the exit interviews were positive, mixed where they were mixed, and explicit about the two preconditions we found the hard way: a team that's willing to be slightly silly together, and a team that's willing to publish its own seams. Without the first, the room stays quiet. Without the second, you only ever learn the flattering half.
If a team has both, this is repeatable. If it has neither, no amount of redstone will fix it.
The numbers, final experiment + first weeks as a practice
🗓️ Days active (cumulative): 56 👥 Developers participating: 9 / 9 💡 Ideas captured: 61 (+12 over weeks 6–8) 🛣️ Ideas promoted to the roadmap: 9 🔁 Architecture proposals from build sessions: 3 (partner onboarding hub, the monitoring-delay fix, and a queue-retry redesign from week 7) 🕐 Average session length: ~1.4 hours 🎙️ Debrief participation rate: 94% — fully self-organizing now 😴 Self-reported energy after sessions: 8.5 / 10 (week 8, an all-time high) ✅ "Would do it again": 9 / 9
Close
Six weeks ago the bet was that this would either work or fail in an interesting way. It did both, in the order you'd want: it failed interestingly in the middle — the state-machine builds, the conflict-averse host, the week-4 dip — and it worked at the end. The boring outcome, the one where it runs fine and teaches you nothing, is the one we managed to avoid.
The experiment is over. The practice starts now. That's not a smaller result than the one I hoped for in week 1. It's the bigger one.