The Battle I'm Still Fighting

🔥 The Battle I'm Still Fighting

It's 6 months before a lead lot is due, over Christmas, and I've just been told the best we've ever done is 35 days. My fab manager wants 25.

I was a new Fab Product Engineer, newly named NPI Chair, running meetings with teams from lithography, etch, process integration, and metrology — none of whom wanted to be there. They were still fighting fires on the current product; I was asking them to think about the next one. Six months of meetings. Not enough progress. I thought we weren't going to make it.

Then a Lean coach showed up with a whiteboard and some sticky notes and asked for two days.

In those two days, we mapped the entire 25-day flow, and the team started fixing what they found, right there, on the spot. Weeks later, we delivered the lead lot in 22 days. A year later, that number was routine.

What changed wasn't the people. It was that, for the first time, they could see the work, not the status report about the work, the actual work: the handoffs, the waiting, the rework, the places where good people were quietly absorbing a bad system's problems.

I've spent 25 years since then watching the same pattern: roadmaps grow, complexity compounds, dependencies multiply, and when programs slip, the answer is always more pressure, never a hard look at the system. By the time postmortems show up, the team is already late to the next program.

I retired in October of 2024, thinking I was done with that fight. I wasn't. I realized I'm still fighting the same battle; I just don't have a badge anymore.

So I started FlowAccel.

I believe there's a better way, one that doesn't ask leaders to choose between hitting the roadmap commitments and having a life:

💡 Complexity and change emerge where engineers work, not in status meetings.

💡 Heroics can save a milestone. Systems scale roadmaps.

💡 A better-designed system delivers more and costs your people fewer nights and weekends. You don't have to choose.

That whiteboard, 25 years ago, is where I first saw it: make the work visible, and people stop firefighting each other's problems and start fixing the system underneath them. It works the same way in silicon development, no matter which team you're on, whether it's architecture, design, test, validation, or firmware, because it's the nature of the work, not the specific work, that matters. Everything I've built since is the Silicon Systems Development Flow Architecture™, that same idea, grown up.

You may not control the roadmap.

You can still control how the work is designed

Helping silicon systems engineering leaders build capacity faster than complexity grows. So they deliver on roadmap commitments, even as complexity, change, and AI accelerate.