Demo Days: A Simpler Approach to Engineering Leadership
2025-02-19
Weekly demo days started as an experiment: a regular time when anyone can demo anything to the rest of the team. No slides allowed, no status reports, just a live demo.
The format was straightforward: 3 to 4 engineers would each get up to 15 minutes to demonstrate their work in progress or whatever they like. Attendees can ask questions and the facilitator is responsible for maintaining a respectful and professional atmosphere.
While most demos focused on current work projects, the format was open to anything that might interest the team - a cool new technology, a competitor's product, a side project, or a game someone built over the weekend.
This freedom to share whatever they found exciting kept the sessions fun, engaging and low pressure. Despite how good it worked and felt, demo days gradually faded from our routine as we defaulted back to standard "agile" ceremonies.
Reading Ken Kocienda's "Creative Selection" about Apple's product development process reignited my interest in demo days. His book showed me how this approach could scale beyond small teams. Kocienda describes their process eloquently:
"We always started small, with some inspiration. We made demos. We mixed in feedback. We listened to guidance from smart colleagues. We blended in variations. We honed our vision. We followed the initial demo with another and then another. We improved our demos in incremental steps. We evolved our work by slowly converging on better versions of the vision. Round after round of creative selection moved us step by step from the spark of an idea to a finished product."
Here was one of the world's most successful technology companies using regular demos to drive their product design and as a cornerstone of their engineering culture.
Then I recently learned about Oxide Computer Company's experience with demo days - a team I deeply respect for their engineering excellence. Oxide's journey with demos particularly resonates with me. As they describe it:
"...our weekly Demo Friday, an hour-long unstructured session to demo our work for one another. Demo Friday is such an essential part of Oxide’s culture that it feels like we have always done it, but in fact it took us nearly two years into the company’s life to get there: over the spring and summer of 2021, our colleague Sean Klein had instituted regular demos for the area that he works on (the Oxide control plane), and others around the company — seeing the energy that came from it — asked if they, too, could start regular demos for their domain. But instead of doing it group by group, we instituted it company-wide starting in the fall of 2021: an unstructured hour once a week in which anyone can demo anything."
Currently, I'm transitioning to doing more work as factional CTO for startup companies, and I've become increasingly frustrated with the endless stream of meetings that seem to define modern engineering management. I miss demo days. Demos feel easy and fun, and they produce high quality feedback and questions that help with implementation and help engineers focus on the important stuff.
The benefits I observed went beyond just better code. Engineers started thinking differently about their work when they knew they'd be showing it to their peers. They naturally prioritized getting to working software faster and thought more carefully about their implementation choices.
However, I'm also aware of the potential challenges. Teams might over-optimize for demos at the expense of deeper technical work. Some engineers might feel undue pressure to show progress every week. Without proper facilitation, demo sessions could devolve into critique sessions that harm team morale.
As I prepare to implement this approach again with my consulting clients, I'm particularly interested in hearing from other technical leaders who have experience with demo days. How have you scaled this practice in larger organizations? What challenges did you encounter with distributed teams? How do you balance the demo cadence with other engineering processes?
If you're using demo days in your organization, I'd love to hear about your experience. What's worked? What hasn't? How have you adapted the practice for your specific context?