I design work like engineers design products

Joel Jorgensen
25 years at Intel: NAND and NOR flash memory design, architect, two patents, two IEEE ISSCC papers, and many years leading development flow work for the NAND Group alongside Steven Spear, author of The High Velocity Edge.
The Battle I'm Still Fighting
Six months before a lead lot was due, over Christmas, I was told our best-ever time was 35 days. My fab manager wanted 25.
I was a new Fab Product Engineer, newly named NPI Chair, running meetings with lithography, etch, process integration, and metrology, none of whom wanted to be there. They were 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.
The people didn't change. What changed is they could finally 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 watching the same pattern since: 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 2024, thinking I was done with that fight. I wasn't. I just don't have a badge anymore.
I spent 25 years at Intel. The first fifteen were hands-on: NAND and NOR flash memory architect, two patents and two IEEE ISSCC papers in flash memory design, and NPI chair. The last eight, I led our development flow work for the NAND Group, working directly with Steven Spear, author of The High Velocity Edge.
That wasn't a slide-deck number. Engineers doing the work identified, conservatively, $400M a year in labor hours they'd get back from changes they discovered themselves. We trained 1,700 people and helped launch 1,250 improvement efforts.
I don't restructure your org chart or tell your engineers how to do their jobs. I work as an engineer, inside the work, with your engineers, not over them, unlike the consulting firms that parachute in, reorg, and leave you with the same problems.
So I started FlowAccel.
There's a better way. One that doesn't force leaders to choose between hitting the roadmap and having a life.
π‘ Complexity and change emerge where engineers work, not in status meetings.
π‘ Heroics 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.
What I Believe
π‘ Most roadmaps grow faster than an organization's ability to deliver them.
π‘ Complexity and change emerge where engineers work.
π‘ Heroics can save a milestone. Systems scale roadmaps.
π‘ Engineering organizations spend enormous effort designing products.
π‘ Exceptional engineering leaders also design the delivery systems used to build them.
I'm Looking for Leaders Who Want to Lead Differently
FlowAccel isn't for every engineering leader.
It's for leaders willing to:
β Challenge assumptions
β Make complexity visible
β Improve how work gets done
β Build better systems
β Create better outcomes for their teams
β Leave organizations better than they found them
I believe the future belongs to leaders who are willing to build something better than what they inherited.
What Better Systems Create
β More predictable execution
β Improved coordination
β Better management of complexity and change
β Faster learning
β Increased organizational capacity
β Reduced dependence on heroics
β Sustainable competitive advantage
β Working fewer nights and weekends
Engineers design silicon systems.
Exceptional engineering leaders also
design the delivery systems used to build them.
Design Your Work Like You Design Your Circuitsβ’
If that sounds like your program, let's talk.
I run a Development Flow Diagnostic that maps where your program's breaking down and hands back a prioritized fix list.
I also write about this regularly in my newsletter, The Development Flow Brief.

