Hello! Happy Monday and start of your week! 👋
This isn’t a standard Hardware FYI issue, and it’s one of the first times we’ve used this space for a more direct announcement. We’re in your inbox this morning because this felt like the right moment to step back and explain what we’re building.
I’ll be upfront: it feels a little strange to write this. But if you’ve ever read an issue and thought, “I wish there was more engineering media like this,” then this note is for you. It’s less about promoting something new, and more about making the implicit direction of the newsletter explicit.
To introduce the conference we’ve been planning, I kept asking myself what the right approach was. And the only honest answer I came to was to start with context: on how Hardware FYI got started, what it’s become over the past two years, and where we’re trying to take it next.
Hardware FYI originally started really as just a way of cataloging my own self-directed learning. At the time, I was working full-time as a mechanical design engineer in consumer products, and building what sounds like a simple product—a smart composting trash can—but was, in reality, a deeply technical system involving grinding mechanics, thermal control, food dehydration, sensors, and manufacturing tradeoffs.
When I wasn’t at work, I was almost always reading about manufacturing & hardware product development. I had a growing sense that a lot of academic framing missed how physical systems actually get built in practice, and that the fastest way to learn was to work at high-growth startups and actually ship to customers—iteratively and with real consequences. I still believe this holds across any industry: whether you’re working on consumer products, standing up manufacturing lines, or building rockets, the learning only really happens when you’re building and shipping the real thing.
(Tangential but assigned reading: 7 reasons not to join a startup and 1 reason to).
Today, Hardware FYI reaches about 20,000 readers, but the first set of issues were really just written for an audience of one. I’m still amazed that what began as a self-directed writing habit has grown into Hardware FYI as it exists today, along with the opportunities and people that came with it.
Hardware FYI has always been written in a particular spirit: less like a publication, and more like an engineer walking you through material at a whiteboard. The focus on clear explanations and direct language is intentional. Writing is arguably the most powerful educational medium because it forces clarity and makes ideas directly explicit.
Once we started hosting events, a similar pattern emerged. Every time we held an in-person gathering—whether it was a small dinner of thirty people or a happy hour with a couple hundred attendees—the conversations ran long, often right up until the venue had to close around us. It didn’t take much reflection to realize that many of the best parts of our writing philosophy were happening in the room. The same ideas resurfaced, but now layered with context from a collective of people drawing on different constraints and firsthand experience.
Over time, it became clear why those conversations felt different from most networking events, and why the newsletter itself grew from an audience of one to many.
Most engineering media fails for the same reason most media fails to deliver real value: it’s built to optimize for scale and revenue. When those are the incentives, depth loses. Content drifts toward market narratives and surface-level commentary, while the details that actually matter are underrepresented or missing entirely.
Hardware FYI works because it runs in the opposite direction. It treats engineering as something to be deeply understood, not just summarized. Once that started working, first in the newsletter and then again in early in-person events, the next question was obvious: what does this look like when you let it evolve naturally?
Writing helped us scale ideas. Kinetic scales conversations.
It’s designed for the people actually designing, manufacturing, and scaling real hardware systems. People who have built and shipped real systems that carry a kind of earned, tacit knowledge; and when you bring them together, that knowledge compounds. This is especially true as tooling, supply chains, and constraints have shifted so quickly in just the last few years.
Our goal with Kinetic is to make it easier for frontier practitioners to share what they’re building and what they’ve learned in the right context. The talks we’re planning are the ones that usually stay trapped inside company walls: the system retrospectives, technical deep dives, the “here’s what broke in production” stories, and case studies from the field. If we can make it easier for people to share those lessons in the right room, everyone builds faster.
Over the next few months, we’ll be announcing new speakers and content tracks. And since many of the people reading this are exactly the kinds of practitioners we’d want on stage, we’re also opening up a call for speakers! If you have a lesson, case study, or experience others could learn from, we’d love to hear from you.
I haven’t felt this energized about a new project since first writing the newsletter. The most fun part of this work is experimenting with things that feel slightly uncomfortable, but that you know should exist. Kinetic feels like the natural next step, and I’m excited to share it with all of you.
That’s all for today. We’ll be back in your inbox tomorrow for our regular scheduled programming.
Benji