Shipping Atoms and Bits: What Building Physical Products Taught Me About Better Engineering Decisions

Most tech talks assume your product lives in the cloud. Mine ships in a box.

I lead engineering at a small professional audio/video company where software, firmware, and hardware all have to work together on day one. Our products range from Bluetooth Auracast audio devices to AI-powered real-time translation, and all of them have to ship on time with a small team and a real budget. A hardware mistake means a costly respin, not a quick patch. That changes how you think about every decision.

In this session I'll share things that building physical products taught me that I think apply to anyone making engineering decisions:

• Coordinating teams that move at completely different speeds. Hardware timelines don't bend to your sprint cadence. How we blend structured milestones with agile sprints so firmware, software, and hardware teams stay aligned without slowing each other down.
• Rolling out AI tools when you don't have an AI team. Our actual strategy for adopting AI tools across the entire company, what stuck, what flopped, and how it's changed what we can take on.
• Your team isn't generic, so why is your tooling? Enterprise software is either too expensive or too bloated for a small team, and the spreadsheet you've been nursing along is one pivot table away from collapse. I used Claude Code to build a custom resource planning tool in a week. No dev team, no six-figure license. I'll make the case that building your own tools is now a real option for any small company.
• Saying no to good ideas. How constraints on time, people, and budget force better prioritization than any framework.

Whether you're an engineer thinking about leadership, a founder wearing every hat, or a developer curious how the "other side" builds products, there's something here for you.

• All levels
• Development
• AI/ML
• Product
• Careers