Week 3–4: When Other Teams Joined the Server
Daniel Nikulshyn · CEO & Founder ·
Two weeks, two experiments
Week 2 closed with two open questions: what would happen if we let other teams onto the server, and could we use the game itself as a thinking tool for our own product. Three weeks in, both got tested. Neither played out the way I expected.
## Cross-role night: when designers walked into engineering's playground
We invited our design and PM teams for a single Tuesday session. Three designers, two PMs, eight developers — fifteen people on a server that, until then, had been engineering's after-hours space.
I worried it would feel like a school visit. It didn't. Within twenty minutes the design team had hijacked one corner of the world to build a "user journey village" — literal villages connected by paths sized to mimic flow priority. The PMs spent the night standing back and watching, then asked sharper roadmap questions in the next morning's planning than they had all month.
What surprised me most: developers stopped explaining once design was in-game. The space did the explaining. "Here's why this onboarding step is heavy" became a five-second walk through three rooms instead of a fifteen-minute Zoom with screenshots.
"I've reviewed this flow ten times in Figma. Walking through it in Minecraft is the first time I felt the weight of it." —
one of our designers, midway through the session
## The structured build challenge
The other experiment was harder. We picked one feature from our actual product — the partner application + onboarding flow, which we know is too long — and gave the team a single instruction: recreate it inside the game so anyone can walk through it.
We split into three groups, two hours each. The output was three different builds of the same flow, and the moment we walked between them was the moment that made this experiment worth running.
Group A built it as a long corridor with locked doors. Linear, mechanical, exactly how the product feels today.
Group B built it as a sequence of small rooms, each with a self-contained task and a door at the end. Felt better but produced a sneaky problem: each room had no context on what the previous room did, and "applicants" got disoriented.
Group C built it as a central hub with optional side rooms — apply for the things you care about first, return for the rest. The hub-and-spokes shape didn't exist in our product. It felt obviously better. Three days later it was a real architecture proposal in our .tasks/ folder.
We didn't ship the hub-and-spokes design that week. But the proposal exists, the conversation around it is sharp, and the alternative we never would have considered without the build challenge is now on the table.
## What went sideways
Two things bit us in week 4 that we should be honest about:
- Burnout signal. Two developers told me they were tired of optional evening sessions feeling slightly less optional. We
- Server drama. A long-running griefing prank between two engineers who normally don't interact much escalated and
responded by capping participation expectations at one session per week and explicitly removing it from any informal performance signal. The damage was small but real, and the lesson stuck.
needed a private conversation to clear. The flatness of in-game hierarchy is a feature; the absence of HR-grade conflict containment is a feature too — until it isn't. We added a second line to our internal guidelines: the server has hosts on rotation, and they have authority to call a session if it's heading sideways.
## The numbers so far
🗓️ Days active (cumulative): 28 👥 Developers participating: 9 / 9 — plus 5 designers/PMs in the cross-role session 💡 Project-related ideas captured: 41 (cumulative) 🛣️ Ideas promoted to the roadmap: 6 🔁 Architecture proposals from the build challenge: 1 🕐 Average session length: ~1.6 hours (continuing to drop — focus tightening) 🎙️ Debrief participation rate: 88% 😴 Self-reported energy after sessions: 7.2 / 10 (down from 8.4 in week 2)
## Is it replicable?
This is the real question we've been sitting with since the cross-role night, and I don't have a confident answer.
What I'm fairly sure of: the patterns we keep seeing — flatter hierarchy, ideas surfacing from physical metaphors, debriefs that work because they're bounded — aren't unique to our team. They're characteristics of any small group given a shared low-stakes space and a habit of reflecting briefly afterwards.
What I'm less sure of: whether it would survive a different team. Our team has a high tolerance for play. Some teams don't, and forcing it would be the worst possible move. The real precondition isn't "do you like Minecraft" — it's "do you trust each other enough to be slightly silly together."
If the answer is no, no game is going to fix that.
## What's next
We're closing out the experiment officially at the end of week 6 — which gives us two more weeks to test:
- A retrospective build. Recreating one of our recent incidents inside the game, with the people who lived through it.
- An "explain it to me" challenge. Each engineer picks a piece of code they own and builds an in-game model of it.
The hypothesis: walking the timeline physically will surface causes the post-mortem missed.
Whoever's watching has to articulate what it does without being told. If those two work, we'll publish the playbook. If they don't, we'll publish what we learned from them not working, which is probably the more useful post anyway.
The pattern continues to compound. The question of whether anyone else can copy it is the harder, more honest follow-up.