I’ve lived through five major technology shifts: mainframe to Windows in the early ‘90s, internet computing in the late ‘90s and early 2000s, Agile in the mid-2000s, cloud through the 2010s, and now AI.

You learn things by surviving that many. You learn that vendors oversell. That leadership wants results yesterday. That the breathless predictions almost never land on the calendar that everyone promised. So you learn to discount the hype.

And that reflex, the one thing that five shifts trained into me, is the thing I’d warn other veterans about right now.

The hype curve lies in both directions. Everyone knows it inflates expectations early. What we forget is that it deflates them later, right around the time the technology actually starts to matter. The people who got burned chasing the last four shifts are the ones primed to under-react to this one. The engineer who lost a year to a premature cloud migration is the same engineer waving off agentic coding today. Same scar, wrong lesson.

The easy advice is “don’t chase the hype.” The harder discipline is catching the moment your own hard-won skepticism quietly turns into an excuse to stand still.

You Can’t Measure Improvement Without a Baseline

This is where teams get tripped up every single time. A team adopts AI coding tools, productivity looks like it jumps, and leadership declares victory. Victory compared to what?

If you didn’t measure cycle time, throughput, defect rates, and developer satisfaction before the change, you’re not reporting results. You’re telling a story you can’t prove. And that story comes back to bite you the first time someone asks for the math.

Before any significant transition, nail down your current state with actual data. Those numbers become your reference point for every evaluation conversation that follows. Without them, you’re flying blind and hoping nobody notices. This matters more with AI than with anything before it, because the productivity claims are louder and the temptation to believe them is stronger.

Evaluate Like an Engineer, Not a Marketer

Every tool that shows up during a shift comes with a vendor narrative. The narrative is always compelling. It’s seldom the whole picture.

Run structured pilots. Keep them small and time-boxed. Four to six weeks is usually enough to learn something real without sinking meaningful capacity. Define what success looks like before you start, not after the fact when you’re already emotionally invested. Measure against your baseline. Be honest about what you find, even when the results are inconvenient.

The teams that got burned hardest during the cloud shift bought the pitch first and validated second. Don’t make that mistake with AI. And don’t make the opposite one either, where you run a half-hearted pilot, get a mediocre result, and use it to justify sitting out for two years.

Protect Delivery While You Experiment

This part is non-negotiable. The business still expects you to ship. The new platform doesn’t care about your roadmap commitments.

The answer isn’t to pause delivery for transformation. It’s to ring-fence your experiments. Designate specific teams or specific sprints as the proving ground. Keep that work clearly separated from your core delivery commitments. When a pilot goes sideways, and it will, it doesn’t take a production release down with it.

This also sends the right signal to the team: we take innovation seriously, and we take delivery seriously. Those aren’t competing priorities.

Narrate the Transition, and Reset It Early When Reality Changes

Nothing creates more chaos than unclear expectations. Engineers don’t know if they’re supposed to be experts in the new thing yet. Product managers don’t know whether to plan around the new capability or the old one. Leadership fills the vacuum with assumptions.

Your job is to narrate the transition out loud. What are we experimenting with and why? What does the on-ramp look like? When do we expect real results? Spell it out. Then, and this is the part most leaders miss, when reality diverges from the plan, say so early and recalibrate. The leaders who get in trouble during transitions are usually the ones who stayed optimistic too long.

AI Is a Mentality Change, Not Just a Process Change

This is where AI breaks the pattern, and it’s the part of the playbook veterans need to hear.

Cloud was a change in where your software lived. Agile was a change in how you organized the work. Those were process shifts. You could adopt them with a migration plan and a new ceremony or two. AI is different. It changes who you hire, what you train for, and how your engineers spend their day. It pushes teams away from narrow specialists and toward generalists who can frame a problem, write a clear prompt, judge an AI’s output, and own the outcome.

You can’t ring-fence your way through a mentality change the way you can a platform migration. The disciplines above still hold. Baseline it, pilot it, protect delivery, communicate. But the goal isn’t just “did we adopt the tool.” It’s “did the way our people think about building software actually change.” That’s a longer game, and it’s the reason discounting AI as just another overhyped cycle is the expensive mistake this time.

Technology is going to keep shifting. Something will come after AI, the way AI came after cloud. The leaders who navigate these transitions well aren’t the ones who picked the right tool. They’re the ones who stayed clear-headed about baselines, disciplined about evaluation, honest with their teams, and relentless about protecting delivery. That part of the playbook has worked through every shift I’ve seen.

The new line I’d add, five shifts in: trust your skepticism, but check it. The hype curve lies in both directions, and the lie that costs veterans the most is the quiet one at the bottom of the curve.

Summing It Up

Don’t chase the hype. Establish baselines before you change anything. Run disciplined pilots with pre-defined success criteria. Protect your core delivery commitments while you experiment. Communicate clearly and reset expectations early when reality diverges from the plan. And build for sustainable velocity, not the numbers that look good in week three. The fundamentals that got your team here will get them through this shift, too, if you let them.

Share.
Leave A Reply