Most engineering orgs have some version of the weekly tech demo. Ours is no different — each engineer gets five minutes, there's an audience, and the format rewards polish over depth. It's great for visibility. People get to see what other teams are shipping, leadership stays in the loop, and it keeps work from disappearing into silos.
But five minutes is a constraint. You can show whatyou built, but you can't really explain how or why. And for a lot of engineers — especially juniors who are still building confidence — the performative aspect makes it harder to participate at all.
The Conversation Over Drinks
The idea started at a bar after work. A coworker mentioned something he'd been working on that he wanted to share with the team, but it wasn't the kind of thing that fit into a five-minute slot. So he told us about it over drinks instead — and the conversation was genuinely one of the most useful technical discussions I'd had in weeks.
That got me thinking. A lot of engineers on our team are siloed. They work on their own systems and don't get much exposure to how other parts of the platform work. Our juniors, in particular, don't have many opportunities for mentorship or deep technical conversations. And a lot of engineers are anxious about presenting in the formal demo format — so the people who might benefit the most from sharing their work are the least likely to do it.
I pitched the idea that night: a monthly "speakeasy" demo. After work, last Friday of the month, no time limits, no management, no pressure. Just engineers going deep on whatever they want to talk about. Everyone at the table loved it.
Setting It Up
I created a Discord server and started inviting engineers from different teams. I was deliberate about cross-team representation — the whole point was to break down silos. Within a few days, there were nine engineers and a QA in the server. Everyone was excited about the idea.
I chose monthly cadence intentionally. This is an after-work activity, and I don't want to pressure anyone into working more than they need to. But I do want to give people a space to share knowledge and bond. Once a month felt like the right balance — frequent enough to build momentum, infrequent enough that it doesn't feel like an obligation.
The First Session
Five engineers showed up for the first round: two seniors, two juniors, and a mid-level. Three people brought demos.
I went first, walking through the visitor resolution system I built for our AI product. In the weekly demo I would have shown the feature and moved on. Here, I could take twenty minutes to go deeper — how we read from a Kafka topic, how we compare cookie IDs, how the agent actually works under the hood. The juniors asked questions they never would have asked in the formal setting.
Then one of the other senior engineers took the floor for forty minutes. He walked through how OpenFlow works in our system, then branched into how Kafka works at a lower level. Since I'm the one who originally set up OpenFlow for our org, there was a ton of back-and-forth — I'd correct something, he'd build on it, the juniors would ask follow-up questions. It was collaborative in a way that the formal demos never are. The juniors and mid-level said they found it extremely useful, and the senior who presented loved the format.
The third demo wasn't even engineering-related. One of the engineers walked us through a local storage system he'd been building at home — a RAID setup as an alternative to cloud storage. He explained the product, how he uses it, the tradeoffs. It was interesting, it was fun, and it reinforced something important: this isn't just about work. It's about people sharing what they care about.
What People Said After
The senior engineer told me it was a much better environment for knowledge sharing than anything we had before. But the message that stuck with me came from one of the junior engineers, who texted me afterward:
"I love that you've brought a cluster of coworkers together. It seems to be helping all of us remember that we work with humans."
That's not something I expected to hear from a technical knowledge-sharing session. But it makes sense. When you strip away the time pressure, the audience, and the performance, what you're left with is just people talking to each other about things they find interesting. And that builds something that a five-minute demo can't: trust.
Keeping It Organic
A principal QA and a staff engineer have both expressed interest in joining. I'm letting it grow naturally — no formal invitations, no sign-up sheets, no agenda templates. The format is deliberately unstructured: show up if you want, demo if you want, just listen if you want. No topics are planned for the next session yet, and that's fine.
One thing I'm intentional about is keeping management out of the picture. Not because there's anything to hide, but because the value of the speakeasy is that it's a space where engineers can be candid, ask "dumb" questions, go on tangents, and share things that aren't polished enough for a formal audience. The moment it becomes an official program with stakeholders, it loses what makes it work.
Why This Matters to Me
If there's a thread that runs through my career, it's bringing people together and helping others grow. I see it in my time as a wildland firefighter, where crew cohesion was the difference between a controlled burn and a disaster. I see it in my years as a STEM tutor, where I learned that meeting someone where they are matters more than knowing the answer. I see it in how I approach engineering — not just building systems, but making sure the people around me understand them too.
The speakeasy is a small thing. It's one Friday a month, a Discord server with ten people, and no formal structure. But it's already changing how the engineers in it relate to each other and to their work. And sometimes the small things are the ones that matter most.