Delivering Silicon Systems Through AI Disruption, Part 2: The Conductor

Conductor: the person who keeps every section of the orchestra in time without playing an instrument. In this article, it’s your operating model.

In Part 1, I wrote about the score, your designed workflows across the three layers Gene Kim and Steven Spear describe in Wiring the Winning Organization: the technical work, the tools, and the social circuitry. A score is a great start, but it doesn’t play itself.

Picture the violins speeding up while everyone else keeps the same pace. The symphony doesn’t get faster. It falls apart. That’s what happens when AI speeds up one layer of a development flow and the other layers can’t keep up.

Why AI Exposes the Flow

I think part of the reason AI feels so disruptive is that we never designed our development flows the way we design our circuits. On the chip, we margin, simulate, and verify every signal path. The path the work takes from architecture to design to test mostly grew up on its own, one program at a time. Now we’re pushing more work through a system nobody designed, and nobody really knows what’s going to happen.

Karim Lakhani of Harvard Business School said it well in the foreword to Microsoft’s 2026 Work Trend Index: “Agents can accelerate work, but they can also expose brittle processes, unclear decision rights, and weak governance.” AI is shining a light on what should have been better all along, and at the same time it’s creating a future state none of us have run before. Lakhani calls the real shift the emergence of a new operating model. I call it the conductor.

What a Conductor Does

A conductor doesn’t play an instrument. A conductor orchestrates, keeping architecture in tune with design and design at the same tempo as test. In a development flow, that comes down to four things:

Set the tempo: the program cadence and the date we committed to.

Cue each section: clear signals that work is ready, like RTL ready for verification or firmware ready for bring-up.

Balance the sections: where AI, people, compute, and licenses go, so no team drowns out or starves another.

Listen: hear a section drift before the audience does.

Listening has to happen live. Hearing a recording in the car on the way home isn’t the same as sitting in a concert hall. Leaders have to experience the work to understand it. Go into the lab, talk to the people doing it, show up in their regular meetings. That takes time, and in my experience, it’s the first thing that gets squeezed out of a leader’s calendar.

Listening: Inline Monitors

In Part 1, I asked whether AI is helping you hit your date or putting it at risk, and how you would know. This is how you would know. A conductor also needs real-time indicators. Would you drive a car without a gas gauge? A lot of programs do. Milestone reviews are months apart, and they are looking for task completion, not how it went. Between milestones, leaders can’t see the work that’s sitting idle. It’s like captaining a ship without knowing there’s a hole in the hull.

Status updates don’t close that gap. By the time an issue works its way up the org to the program meeting, it’s been sanitized. Nobody wants to get in trouble, and they’re in the middle of a fix that might work, so by the time the status is presented, everything is fine. We’ve all sat in that meeting.

Inline monitors are signals built into the work. They show where work is waiting and whether the date is moving, weeks before a milestone review would tell you. How many times have you rushed to get something done because you had to deliver it the next day, only to find out that the work it feeds is a week late? If you’d known, you might have waited and worked on the higher-priority issue your manager wanted. Now you have to work late on that too. Inline monitors report what’s actually happening, not what somebody decided to say about it. Think control charts on a fab line. A few examples by layer:

Layer 1: bug count, late spec changes.

Layer 2: test time, license and compute wait time.

Layer 3: bug open to bug closed time, milestone checklist status.

This is the step that comes after the three in Part 1. Run the redesigned workflow and measure it against your baseline. Measure the date and the cycle time, not tokens or lines of code.

Owners and Cadence

In a fab, every module has an owner. The etch owner designs the etch process, monitors it, improves it, and speeds it up when they can. Development flows need the same thing: an owner for every workflow who reviews its monitors on a regular cadence and acts on what they show.

Owners also answer the questions most programs leave hanging. Where do you take an issue when you find one? Is there a structure in place, or does it go to whoever yells the loudest? If we change how we work, how do we know we won’t break somebody else’s work?

Cross-functional flows need an owner who can break the tie. Firmware thinks hardware should fix it. Hardware thinks firmware should fix it. So what decides? Seniority? The loudest voice? Whoever is least behind schedule? Somebody has to make sure the right thing happens for the program.

AI adds three more questions, straight from the same Microsoft report: “Who reviews agent performance? Who has the authority to update the workflows that agents run? How does a local win get captured and scaled across the organization?” At SEMICON West, VerifAIX’s Madhulima Tewari came at it from the verification side. The system that generates an artifact can’t be the only one that certifies it. The LLM proposes, and deterministic engines decide. Someone has to own where that line sits.

The Nested Hierarchy

An orchestra is already nested. Each section has a principal who leads it, and the principals follow the conductor. Good code is the same. Functions roll up to modules, modules roll up to the system, and the comments carry the context forward, the same way a documented process carries forward what the team learned.

Development flows should be nested too. Workflows are owned at the block and team level, they roll up to the program, and programs roll up to the portfolio, just like blocks, subsystems, and the SoC. The Director conducts the program. The VP conducts the portfolio. Each level listens to the monitors below it and sets the tempo for it. That’s how a local win on one team becomes the way every team works.

And none of it holds still. Tools change, teams change, and AI is changing the work every week. If nobody is listening at each level, the system can run away from us in ways no one person can see.

A Shepherd for the Lead Lot

Early in my career, our best lead lot through the fab had taken 35 days. The next one had a goal of 25. A principal engineer shepherded that lot the whole way, and I’m still not sure when he slept. He worked with the techs, helped them understand how this lot was different, looked ahead for issues, and made sure every tool was ready before the lot got there. It came out in 22 days.

That first lot needed a shepherd. When I left a year later, 25 days was the average, and nobody was shepherding lots anymore. The way he orchestrated the flow became the way lots ran. That’s what a conductor builds.

Close

Everyone is getting the same AI tools. The teams that keep their commitments through this disruption will be the ones with a score and a conductor.

Also Read:

Delivering Silicon Systems Through AI Disruption, Part 1: Writing the Score

SEMICON West 2026: AI Made the Steps Faster. The Time Between Them Is Next.

The Invisible Bottleneck Is Costing You Time You Can’t Get Back