When work stops staying aligned
At some point, things just start to feel off inside a program.
More meetings.
More updates.
More people pulled into every decision.
And still—the work isn’t moving the way it should.
I saw this play out on a program where yield came in lower than expected.
That one change triggered everything:
- manufacturing projections kept shifting
- engineering demand changed daily
- stakeholders needed updates constantly
Teams were working hard.
Really hard.
But the system wasn’t holding.
The supply team was rerunning their model multiple times a day.
Engineering was adjusting plans in real time.
Leaders were asking for updates from every direction.
Everything became urgent; it was a fire drill
But what was actually happening was simpler: work wasn’t staying aligned as it moved across teams
That showed up as:
- conflicting updates
- work coming back late
- constant plan changes
- pressure going up without real progress
When things start to feel like this, the instinct is to push harder:
- more meetings
- faster updates
- more data
But that usually makes things worse.
Because activity goes up, while alignment continues to drift.
What changed
We didn’t start by redesigning everything.
We started by looking at how the work was actually moving.
Where it was getting delayed.
Where it was coming back.
Where teams were no longer aligned.
A few things stood out right away:
- teams weren’t working on the same cadence
- decisions weren’t holding from one step to the next
The biggest driver was how often the system was being updated.
Every new data point triggered another round of:
- updates
- meetings
- decisions
>> more information was creating more instability
So we changed the focus.
Not “how do we update faster?”
But: how do we keep work aligned across teams?
Stabilizing how the work moved
That led to a few simple shifts:
- we developed a weekly cadence
- we put structure and discipline into decisions
- clearer ownership around three types of escalations: quality, customers, and current revenue
We also realized what looked like one escalation problem was actually three:
- customer impact: # of samples they would receive
- supply trade-offs: NPI (development material) vs. HVM (customer material)
- development constraints: units for testing to deliver to our milestone metrics for quality
Each needed different inputs.
Different decisions.
Different ownership.
Until that was clear, alignment wasn’t possible.
What changed (and what didn’t)
The constraints didn’t change.
Yield still had to ramp.
Supply was still tight.
But the system changed.
- fewer conflicting updates
- fewer rework loops
- fewer late surprises
And most importantly: work started staying aligned again
Once that happened, things became predictable again.
Why this shows up so often
This is how most execution problems actually begin.
Not as one big failure.
But as:
- alignment slowly breaking down
- activity increasing to compensate
- problems showing up later than they should, we knew the yield was late
I’ve seen this pattern across many programs.
Where AI fits (and where it doesn’t)
A lot of teams are now trying to address this with AI.
The idea is straightforward:
move faster
react faster
analyze faster
But if execution isn’t stable:
- AI doesn’t fix it
- It just accelerates the breakdown
More updates
More decisions
More change
-
faster misalignment
The pattern that actually works
What works is simpler than most people expect.
Stabilize execution first
Make sure work:
- stays aligned across teams
- holds from step to step
- doesn’t come back late
Then: apply AI where it actually improves delivery
Final thought
Most of what drives outcomes doesn’t show up in the plan.
It shows up in how work actually moves.
If work isn’t staying aligned, that’s where to start
