Embedded Development Is Broken. Here's the Strategy I'm Betting My Company On.

A client called us last year in the kind of panic that has become familiar in this industry. Their connected device was eight months late. The firmware team had shipped a release, watched it brick a chunk of field units, and was staring down a CRA compliance deadline with a backlog of CVEs they hadn't triaged in six weeks. The CTO asked me, more or less, how a team of smart engineers ended up here.

The honest answer is that they didn't do anything wrong. They were running a 2015 development model against a 2026 problem. Most embedded teams I talk to are in some version of the same bind.

I've started calling this the embedded complexity crisis. After running a firmware services company through the last several years of it, I've come to believe it's the defining business problem of our decade. The good news is that it's solvable. The less good news is that most teams are reaching for the wrong tools.

The gap that actually matters

The industry loves to talk about software complexity growing. That's true, but on its own it doesn't tell you much. The useful frame is the gap between how fast complexity is compounding and how fast developer productivity is keeping up. McKinsey has put the numbers at roughly 4x complexity growth per decade against 1.5x productivity growth. Those numbers understate what it feels like on the ground, because they don't account for the regulatory overhead that's shown up in the last three years.

The EU Cyber Resilience Act is the obvious example, but it's a symptom of a larger shift. Embedded products now carry a post-ship obligation that used to end at the warranty period. You ship a connected device in 2026 and you've signed up for years of vulnerability monitoring, SBOM maintenance, disclosure workflows, and patch discipline. That work has to come from somewhere. In most companies, it comes out of the same engineering hours that used to go toward the next product.

So when I say embedded development is broken, I don't mean the code is bad or the engineers are slow. I mean the operating model. The tools, the pipelines, the assumption that a firmware release is a finish line. None of that matches the physics of the business anymore.

What I got wrong before I got it right

When I started Dojo Five's DevOps platform work, I assumed the answer was tooling. Better CI, better HIL infrastructure, better SBOM automation. Build the pipes, and productivity would follow.

I was half right. Tooling matters. But I watched teams with excellent tooling still miss their deadlines, because the real bottleneck was strategic. They hadn't decided what to stop doing. They were hand-rolling auth stacks when a standard would do. They were patching security in at the end of projects. They were using AI for the parts of development that were already easy, and avoiding it for the parts where it would actually move the needle.

The pattern I kept seeing, in our own work and in our clients', is that the teams pulling ahead weren't always the best-tooled. They were paying attention to three things that a lot of other teams weren't. Three things that, conveniently, all start with the same letter sound. So I've been calling this covering your A.S.S., which is half a joke and half a reminder that the stakes really are that high.

A is for AI, used where it's actually hard

Most embedded teams I see are using AI wrong. They're letting it generate boilerplate they could have written themselves. They're avoiding it for the work where it would be transformative.

The transformative use cases are the ones that used to require a senior engineer and a free afternoon. Reasoning across a large legacy codebase to find the three places a shared resource gets touched. Explaining why a race condition only appears under specific RTOS scheduler configurations. Sanity-checking whether a vendor's claim about their crypto implementation matches what's in the datasheet. These are the tasks that eat expert time, and they're exactly where current models earn their keep.

The failure mode is treating AI as a junior developer with infinite confidence. That's how you ship subtle bugs with well-formatted comments. The discipline is to use AI against problems where you can verify the answer, and to treat unverified output as a hypothesis rather than a conclusion.

Here's my prediction. Within two years, the embedded teams that haven't figured out how to integrate AI into code review, test generation, and architectural analysis will be structurally uncompetitive. Not because AI replaces engineers, but because it replaces a lot of the meetings where engineers explain code to each other.

S is for Security, designed in from hour one

The CRA didn't invent security as a requirement. It made it impossible to ignore. What changed is that "we'll bolt on security before launch" stopped being a viable strategy. It's now a direct path to a product you can't legally sell in the EU and can't responsibly sell anywhere else.

The shift I'm asking teams to make is architectural. Secure boot chains, key provisioning, SBOM generation, CVE monitoring, and disclosure workflows aren't features. They're preconditions. A team that treats them as preconditions designs a very different system than one that treats them as a Q3 ticket. The first team ships on time. The second team ships a liability.

Let me say the quiet part out loud, because vendor blogs usually won't. Doing this right is expensive up front. Your first prototype takes longer. Some of your best engineers spend weeks on infrastructure that doesn't produce a demo-able feature. Every CEO reading this has felt the temptation to defer that work. I've felt it. The teams that give in pay for it later, with interest, during the post-ship years when the CRA clock is running and nobody on the original team is still on the project.

S is for Standards, understood and applied up front

I saved this one for last because it's the one that gets handled worst, and it's the most expensive to get wrong.

When I say standards here, I mean the ones that govern whether your product is allowed to exist. IEC 62304 if you're building medical device software. ISO 26262 if you're in automotive. IEC 61508 for industrial functional safety. DO-178C for airborne systems. The CRA's forthcoming harmonized standards for connected consumer products. The specifics vary by market, but the pattern is the same. These aren't style guides. They're the conditions of sale in your target market.

The mistake I see most often is treating them as a compliance exercise you do at the end. A team spends eighteen months building a product the way they've always built products, then hands it to a consultant six months before launch to "get it compliant." What they get back is a report telling them their architecture is wrong, their testing evidence doesn't exist, their traceability is missing, and the retrofit will cost more than the original development.

The teams that get this right do the opposite. They read the relevant standard in month one. They make architectural choices that map to it. They set up their V&V process, their requirements traceability, their risk management file, and their configuration management so that compliance evidence is a byproduct of how they work, not a document generated in a panic at the end. When the audit comes, they hand over artifacts they were already producing.

There is no shortcut here, and I'd be skeptical of anyone selling you one. But there is a massive difference between a team that understands 62304 as an input to their architecture and a team that discovers it as a blocker to their ship date. The first team ships. The second team does it twice.

What to do this quarter

If you run an embedded team, I'd like you to do one uncomfortable thing this quarter. Pick the single place where your current process is most clearly out of step with the complexity you're dealing with, and change it. Not all three letters at once. One.

For some of you it'll be AI. Specifically, getting your best engineers to stop reflexively avoiding it. For others it'll be security, which usually means confronting the reality that your first ship date should be three months later than your current roadmap says. For others it'll be standards, which usually means picking up the copy of 62304 or 26262 or whichever one governs your market, and letting what it says actually change how you're building.

I'll be covering all of this in practical detail at the 2026 Embedded Online Conference, May 11-15. If you're wrestling with any of this in your own organization, come to the session, and come find me afterward. The conversations I have with attendees are usually more useful than the talks themselves.

Cover your A.S.S. I'd rather you win.

Sign in