I once landed on a team that had been through so much turnover nobody left could reliably say how our own product worked — or, for some pieces, whether they were even still working. That's a scary place to be responsible for something from. So I made the case for a project to fix it: a focused pass documenting what our ~30 pipelines actually did, why we had them, and what needed attention. It was before agentic coding tools existed, so it meant real people reading real code by hand — something like 1,500 individual jobs, some of which hadn't been understood by anyone in five-plus years. I had to argue hard just to get six to eight weeks of a junior engineer's time to help.

That's the "what." It's a fine story on its own — the project worked, the docs got written, the gaps got found. But it's not why it actually mattered.

What made it land was how we did it. On the technical side, I broke the product into pipeline-sized chunks and built a repeatable way to learn, crystallize, and document one fast — fast enough that at points we were each clearing a full pipeline a day, on systems that had resisted understanding for years. But the bigger shift was the frame around the work: we became adventurers on a quest.

Pixel art avatars. Pipelines as levels on a dungeon-themed progress tracker. Badges for milestones, categories to compete in, a space just for the weird and surprising things we dug up, and a daily share-out of what we'd learned.

Here's the part I'd point to if you asked why any of that mattered: people who weren't assigned to the project started asking if they could join. Nobody volunteers for two months of documentation. They did here. That's the actual signal that "how" was doing something "what" couldn't — the documentation template got adopted company-wide, sure, but the bigger change was the team's relationship to its own product. We went from not understanding what we owned to being genuinely proud of it.

The generalizable version: the deliverable is rarely the thing that changes how people feel about the work. How you run the work is. If you want people to do more than the minimum — to bring energy, to want in when they didn't have to — that has to be designed for on purpose, the same way you'd design the technical approach. It's not about games or team-building exercises bolted onto the side. It's about making the real work itself something worth choosing.