In my last blog post, I talked about the cadence of product planning and delivery at Honeycomb. Tucked away in there was a mention of “demo day”—and I’m back to tell you all about that because it’s a pretty big deal around here, and I want to encourage you to give it a try as a way to see progress on new feature development and get folks excited about what’s on the horizon.
What’s demo day?
Every Friday afternoon, everyone in the entire company is invited to gather on Zoom for internal demos of various projects teams have been working on. While this tradition was founded in the R&D org (that’s Engineering, Design, and Product), anyone at Honeycomb is welcome to demo.
Our demos are a lighthearted but powerful way to share progress and celebrate our wins as a team. They also make our work visible in a way that status reporting cannot and help colleagues who are not part of day-to-day product development feel included. They are the heartbeat of our work that we radiate to everyone in the company.
Because nothing says fun more than RULES, we established these strict bylaws of demo day, a couple of which I have been known to personally violate from time to time:
- No demo shaming. If a team or team member has nothing to demo this week, they will be back and sharing again soon enough.
- No slide decks. This is a showcase for what we are building, and unless your actual work is creation of a slide deck, please don’t bring them here.
- No dev box demos (mostly). Whenever possible, demos should be run from dogfood (our integration environment) or production.
- No selling. Our demos are not enablement—they are for internal consumption. Things that are shown there may not be available in the product for customers (now or possibly ever).
Why demo days are awesome
Demo days have become an institution at Honeycomb. They’re well attended by folks from all different parts of the org (in our company of ~100 people, usually at least 60 show up), and even for roles not directly associated with product development, we’ve added “go to a demo day” to our onboarding plans for new hires.
Whenever possible, I’ll invite candidates who are interviewing for a role on my team to join a demo day. There’s a Slack channel (naturally) where we share humorous GIFs to go along with the demos. Recordings are posted there as well, in case anyone can’t make it and wants to catch up later. And the chat is off the hook:
Our team is incredibly supportive of one another, and demo days give us a reason to fire up that atmosphere of celebration and excitement every Friday. Some teams even start their Monday syncs by asking, “What do we want to demo this week?” and giving themselves a natural, unforced end-of-week target to aim for.
Seems easy … right? Welllllll … yes and no. I picked up the demo day tradition during my time at Chef Software, where founder Adam Jacob got it started. It worked beautifully there, and we often had so many signups that we would have to pin some demos for the following week.
When I moved to $LASTJOB, I started chatting with the (also new) VP of Engineering right away about introducing demo days there. He was into it, and off we went—but we changed the formula a bit and the demo days were not a success. Where did we go wrong? <sobs>
The main problem, and this has been validated through talking with folks in other orgs that have tried to do it, was how demo day was scheduled. Rather than weekly like at Chef and now at Honeycomb, we made it monthly. I think we had good intentions; this is a new thing, let’s not freak people out. The throughput of the product development team at that time was Not Great, so we also thought if we held it weekly, nobody would have anything to share. We made the event one hour long and divided it up into four 15-minute slots. We canceled month after month for lack of signups, probably only holding the event about once a quarter.
We had inadvertently made the stakes too high, and it was too easy for engineers and other demo-ers to forget what they had worked on since the last demo day a month earlier. So I learned this is a sure way to kill demo day.
Demo and chill
Let’s look at this “high bar” problem. By scheduling the meeting monthly and with these mondo 15-minute slots, we were signaling YOUR DEMO HAD BETTER BE THE SHIT. For contrast, here’s how we describe what makes a good demo at Honeycomb:
A demo walks the team through something that is recently completed or is a work in progress. Feature work, bug fixes, performance improvements, instrumentation, integrations, prototypes, and refactors are all great things to share. A demo should not exceed 5 minutes and should include the following:
- A short framing of what the work is, why it matters, and who it benefits (e.g., our users, our business, our own team)
- A working example of the thing itself; i.e., not a code walkthrough
- Sometimes, a before and after (in case of an improvement)
- A summary of what’s coming next for the thing
Yes, bug fixes and performance improvements. Instrumentation that improves our own observability. Prototypes, including design mocks. I cheer rabidly when people demo this stuff.
And did you notice that 5-minute limit thing? Demos are best when they are short, live, and rapid fire—our meeting is 30 minutes long and we can cram in up to 8 demo slots. This practically guarantees that demo-ers are sharing incremental progress, the bite-sized steps they completed that week as they work toward some larger goal. It’s super fun to see how a new product feature develops, week over week, like devouring that next episode of Game of Thrones to see how the story will unfold.
Punch it, Chewie
I’d really encourage you to try this with your teams. You’ll bring your own flair and create your own delightful variations. Make it fun, make it punchy, do it every week you can. Pick a regular host or set up a rotation, whatever works.
I’d love to hear how it goes for you, or answer any questions you have about making your own demo day a success. Hit me up on Twitter or find me in our Pollinators Slack.
