I have spent a lot of time with clients over the last few months debating AI use, GPU ROI, and datacenter operations. I have also spent a lot of time with friends opining over the risks associated with platforms like Flock. While I’m not ready to go off-grid just yet, the conversations have left me wondering how best to prepare Ford for life, and where we want to raise him. In a world where answers are a commodity, creativity, curiosity, and the ability to connect with humans seem to be the skills most valuable for the future. When others are focusing inward and spending more time away from people and relying on AI to solve their day-to-day problems, I want to give my guy the skills to thrive in the space others are vacating.

There is a lesson in there for all of us: instead of going to Claude for your answers, pick up a good book. Instead of going to ChatGPT for your basic design needs, call an agency and seek a design made by a human. Instead of avoiding social events, force yourself to participate and don’t leave until you’ve spoken to everyone in the room.

In a world that is increasingly disconnected due to technological connection, seek opportunities to connect directly with the human experience. This is one of the messages I’ve been sharing with clients of The Select Group, as recently as last week in Manhattan: use AI to be better at the things you already do well, and don’t lose the human connection with your team, partners, or customers.

Of course, I give this advice while sitting on my laptop writing a newsletter to my extended network during family beach week while all 17 of my people are hanging out on the beach, so take it for what it’s worth.

-AM

What if there is no ROI on AI?

For the last three years I’ve been working with clients to answer, mostly, one question: how do I realize an ROI from my AI investment?

The answer I’ve come to realize? There probably isn’t one. AI is a tool like many others: it helps us do certain things better, it introduces as many problems as it solves, and its effective use requires a level of change that many people and enterprises just don’t want to take on.

I’ve also had conversations with many clients who have bought and hoarded GPUs only to realize that they’re only using about 5% of the capacity that they’ve built.

I’m not suggesting that there won’t be value created by AI, but what I am suggesting is that it, like any other technological revolution, is not the silver bullet to solve the world’s problems. Effective use requires work; ROI requires clarity on what your business is aiming to achieve, and for every $1 saved in one area, another $1 will be spent in another. Or maybe even $2.

This realization has led me back to an advisory conversation that I’ve had 1000x over the last 20 years: to win with AI, you need to focus on clearly communicating your strategy and what success looks like, and then clean up your business and technical architecture.

No technology is going to make this hard work go away. Like everything else in life, there is no shortcut to hard work, and the only way forward is through.

A Ford Update

I can’t believe that my little dude is almost 18 months old. People have been telling me since before he was born to savor the moments because they fly by, but DAMN, do they fly by.

Ford loves his bike, starts each day with a trip to the garage to sit in the “caahhh” (car), is thriving in swim lessons with Red Cardinal Aquatics and our dear friend Ana, and loves our twice-monthly Saturday trips to Cars & Coffee, the Raleigh Executive Jetport to watch the planes, and Art Moto to check out the latest (red) motorcycles and to listen to live music. My little dude is endlessly curious and loves people, and I hope to keep those fires burning for as long as I can.

Who I’m Following

The years between my junior year of HS and the time I joined the Army were peak X Games culture, and about that time my focus shifted from the world of racing BMX and motocross to dirt jumping and freestyle motocross, fueled by the culture built by Brian Deegan and Metal Mulisha.

Deegan’s “f&*k the system” heavy metal and counterculture persona was especially attractive to a generation trying to find its way in a post-9/11, post-dot-com world with limited job prospects and an identity crisis.

Even as culture shifted, I remained a fan of Deegan as he pivoted from freestyle motocross and Mulisha to rally car and stadium truck racing. Over the years he has leaned into fatherhood, building businesses, and his faith. Deegan’s evolution and journey, in a lot of ways, mirrors my own.

Recently, with his kids largely out on their own, Brian created space to begin giving back to others like me whose lives he has indirectly impacted, to more directly coach and mentor people with a common interest in character development, building businesses, and a shared love for moto.

The Generals Army has proved a powerful community over the last several months for both learning and helping others. I’ve been a long-time believer in mastermind communities, but TGA is proof that finding the right community is a rapid outcome accelerator.

Check out TGA, and then consider searching out a similar community that is best aligned to you.

Other Recent Thoughts

• Digital Twins for Operational Resilience

• ADLC: The Cost to Verify

• SPM != PMO

• Humanoids Week 5: Twenty-Two Things I Don’t Know

In Closing

This is certainly a season of change. Jenelle and I are taking a hard look at how we’re raising Ford, where we live, and what is most important in our marriage. Change is never easy, but always necessary. Some of us embrace change, others are cautious of it, but it’s something we all must endure. The most important things to remember in any change context, professional or personal, are to anchor in a goal that can serve as your guiding light through the hard days; celebrate your short-term wins; don’t dwell on setbacks; and above all, don’t lose sight of the fact that your team are your people. You’re all working to the same goal, even if your style and approach may differ.

Be well, friends.
-AM

My first experience with digital twins came in 2018 when I founded Valor Cycles, a project with the goal of winning a stage of the Tour de France with an American manufactured bike. The frames were made from carbon tubes, joined at lugs we 3D printed out of chopped carbon fiber. The commercial goal was to be able to create bespoke bikes that fit each customer’s unique size, riding style, and compliance preferences. What I didn’t do was experiment by printing and building bikes. Before a single tube was cut or a lug printed, I simulated each geometry and tube with Autodesk Fusion 360 to solve as much as possible before making a build. I modeled frame flex, weight distribution, and what road riders refer to as “compliance,” which relates to how a bike feels on the road.

In 2018, “digital twin” barely existed as a term outside a few manufacturing journals. It was mostly theory: model the physical object, compare it against what the object did once it existed, see where the two disagreed. Most of what I learned came from what the model didn’t tell me versus what it did, and this fed the learning loop that improved the model.

I shut down Valor in 2019 after deciding that the personal liability outweighed the revenue potential, but it taught me a lot about experimentation in the context of mechanical engineering.

Since then, digital twins have become a technology that I’ve watched emerge from engineering obscurity into a necessity for experimentation in the age of AI, and even an operational fail-safe. This shifts the use case from a simulation you run before you build something to a live system that tells you your operational system is about to have a bad day before it happens.

My hypothesis for why it took this long: digital twins were intimidating. The cost to build, deploy, and interpret one was high, and there were too few experienced engineers who knew how to do it well, so most companies skipped it. What changed is pressure. Companies need to show ROI on their AI investment, and the data center capacity enterprises built out for AI now carries its own pressure to prove utilization and results. That combination is making digital twins commonplace, for experimentation and for operational monitoring. Cheap sensors help too.

The gap before the alarm

Systems rarely fail the way people picture it, with a threshold crossed and an alarm firing at the exact moment things go wrong. The example that always comes to mind for me is the scene in the 2019 HBO series “Chernobyl” where all of the monitors crossed into red and the “all is lost” moment is achieved. A system spends hours, sometimes weeks, behaving slightly differently than it should while staying inside every alarm limit anyone ever set. Again, thinking back to Chernobyl, the engineers began expressing concern when the gauges had deviated from normal, but the manager told them it was a non-issue because they were still within tolerance. By the time the sensors were out of tolerance, the meltdown was well underway and recovery was not possible. Even in 2026, this is still the way many operations perform, but they don’t have to.

Sitting at the beach as I type with my family, which includes six ER physicians, I am reminded that this concept is not new in the ED. A patient can hold normal blood pressure and a normal heart rate while trending toward a crash, and the clinicians who catch it early are reading the trend rather than any single number. A digital twin gives machines and their operations that same instinct. The platform asks whether a value is moving somewhere its own history says it shouldn’t: it’s monitoring for deviation, and how known incoming variables such as a weather event may impact the system’s known baseline.

We all have been raised on alarms: fire alarms, weather alarms, alarm clocks. All of them share the same blind spot. Alarms are built around known limits: max temperature, max pressure, max latency, fire, weather, incoming threat. A twin runs on a model of expected behavior, drawn from equipment specs and historical operating data, and fed by the same real-time data the alarms already see. When the system and the model start to disagree, the twin flags the gap. An alarm-based stack throws that information away by design, and the twin exists to keep it.

A twin can’t forecast an earthquake or a market crash, but it can tell you what to expect if one of these events were to happen. It can also help predict the impact of an inbound hurricane and help plan how to modify operations or output based on expected impact. It can accurately tell you, earlier than any threshold, that a system has stopped matching its own history. In operations, that’s usually the information that matters.

Data centers

The standard data center playbook alarms on inlet temperature, PDU load, and chiller loop delta (a big thanks to my friends at Siemens for the deep-dive into the engineering marvel that the modern data center represents). Each of those is a threshold, and a threshold only reports that a limit has been crossed.

A twin of the same facility models expected thermal behavior for a given load and airflow configuration. When a rack’s fans start running ten or fifteen percent harder to hold the same exit temperature, nothing alarms, because the rack is still in spec. The twin sees the gap, and the gap shows up before the temperature spikes. It usually means a filter is loading up, a CRAC unit is losing capacity, or airflow got redirected by another anomalous change. These events caught in the first week of drift are fixed via a work order. Caught after the threshold trips, and the facility enters an emergency change window at two in the morning with an angry customer demanding a status update from your war room. Having been in my share of those war rooms, I can promise you that they’re never as much fun for the client as they are for the advising consultant who thrives on adrenaline and pressure. Ahem. Not to out myself.

Siemens has been building toward this with Insights Hub, the industrial IoT layer of its Xcelerator platform, which connects a facility’s real-time operational data, IT and OT both, into a model continuously compared against what’s happening on the floor. Siemens has said its campus and facility customers see utility savings of up to 25 percent per square foot running this kind of connected twin, mostly by catching small drifts before they compound. The company pushed further this year with Digital Twin Composer, unveiled at CES 2026, which pulls live data from manufacturing execution systems, quality systems, and industrial IoT sensors to keep a facility’s twin current in close to real time. PepsiCo is running an early version across several US plants and warehouses, and started by using the twin to establish a performance baseline before changing anything at all.

Breweries

A brewery runs on a version of the same physics, just slower and considerably better smelling. A fermentation tank follows a temperature curve: a rise, a hold, a controlled step down, timed to how the yeast behaves at each stage. The glycol system exists to hold that curve.

When a chiller starts drawing more load than the batch’s current stage should require, the system is working harder to hit the same number, and the number itself hasn’t moved yet. A twin of the cellar, built off the temperature, gravity, and CO2 off-gas data the brewhouse already collects, can flag that days before the batch drifts into a stuck fermentation or an off-flavor. Most breweries, even good ones, still catch it from a hydrometer reading and a shift lead’s gut, which works right up until the shift lead is on vacation.

Distribution networks

The same pattern stretches across geography. A lane between a distribution center and a regional hub has an expected transit time and an expected dock dwell time, built from months of runs.

When dwell at a dock creeps up ten minutes at a time, or a reefer trailer’s compressor cycles more often to hold the same set point, no threshold trips. The truck arrives, the product is in spec, and the lane is quietly diverging from its own history. That divergence usually points to a dock about to bottleneck, a compressor a few weeks from failing mid-route, or a driver rotation breaking a schedule nobody re-baselined. A twin of the network surfaces the lane while the fix is still a routing adjustment. Without one, the first confirmation is a load of temperature-sensitive product missing its window, followed by a claim, a customer call, and an argument about whose fault it was.

Bridging the gap to action

A twin that only feeds a dashboard adds very little to its operator. It still depends on someone looking at the right screen at the right time, which is the very dependency the twin exists to remove. The organizations getting value from these systems wire the gap directly into an action with an owner and a clock: a drifting rack opens a work order, a hot fermenter pages the cellar lead, a slowing lane triggers a routing review before the next load is scheduled onto it. It’s like the original Toyota Production System, only running at machine speed. The modeling stopped being the hard part a while ago. The discipline to act before the threshold is where most organizations stall.

There’s a person on the other end of that discipline, or the lack of it. Somebody takes the call at three in the morning to explain what already broke, makes an emergency change half-informed over the phone, and spends the next day writing an incident report for a failure the data had been describing for weeks.

The models I built for Valor in Fusion 360 helped me answer a basic question: will this frame ride the way I designed it? The operational version answers a better one: will this system keep behaving the way it did yesterday? If your monitoring can only report that a limit has been crossed, you’re learning about failures at the same time as your customers. Pick the system whose failure hurts most, model what normal looks like, and give the gap an owner. You likely already have the data, but most operations are throwing it away.

This is the work my team and I are doing at The Select Group. We help enterprises put digital twins to work in both of the modes this post describes: building twins that let teams rapidly test ideas against their strategic imperatives before committing capital, the same way I tested frame geometries before printing a single lug, and standing them up inside live operations as a site reliability layer that catches the drift before the threshold trips. If your organization is sitting on operational data it can’t yet act on, that’s exactly the problem we like. Reach out and let’s talk about it.

Time is an absolute thief! It’s hard to accept that 2026 is already half behind us, but it’s even more difficult to accept that my little dude is almost 17 months old! It has been so cool to see his sense of humor, daredevil personality, and love of all things that go fast emerge. That aside, it’s his big heart and the way that he interacts with others that I’m most proud of. He is such a cool dude!

It is because of all the time I’ve been able to spend with him that I am thankful to be in a role that requires a lot less time away. Don’t get me wrong, I’m still very excited to spend time with my teammates and our customers, but not having to be gone more than a sleep-or-two is a real gift.

Speaking of my new role, everything has become crystal clear at The Select Group. After taking a few months to learn our team, operations, and customers, I am excited to step into a role focused on bringing together our partner program, forming new alliance partnerships, and guiding development of the products that will take the swagger that TSG is known for and put that same energy into proprietary offerings.

More on that soon!

The Book (Re)Launch

I’m excited to re-launch both Small Firm, Big Impact and Surviving Performance Reviews! Only, the economic and business context has changed so much since I first wrote Surviving Performance Reviews that it is being relaunched as a first edition under a new title: The Performance Machine.

I first wrote Surviving Performance Reviews in 2017 to provide guidance in a world that was moving much faster than traditional performance management systems. I updated it in 2021 after COVID had shifted so much about how people work, but as I set out to update it again for the age of AI, I realized that so much of what had originally underpinned the book was no longer relevant. So, I rewrote nearly the whole thing. This time, the focus is on building a performance system that holds up when the work itself keeps changing: it is less about surviving the annual review, and more about turning everyday feedback into a machine that makes people and teams better.

As for Small Firm, Big Impact, calling this a second edition undersells it. I roughly doubled the book in size, from ten chapters to fifteen, and rebuilt it into four parts that walk from the foundations of starting a firm through growth to building something that lasts. There are entirely new chapters on productizing your judgment, pricing on outcomes instead of hours, planning your exit, and how AI changes the landscape for a small firm over the next two years.

Both books are available now in hardcover and paperback, and will be available on Audible the 4th of July weekend.

Small Firm. Big Impact.

The Performance Machine.

More Writing.

I write to learn, and it has certainly been a season of learning! Between all of the things that Ford is teaching me on a daily basis, and renewed energy with my new gig, I have been spending a lot of time reading, listening, walking, and writing.

If you’re interested, here are the areas where I have been spending the most time:

Agentic Delivery Lifecycle (ADLC)

The old SDLC doesn’t know what to do with AI, and that gap is costing money and percentage points. This series works through what changes when agents enter the delivery lifecycle: why the portfolio is the front door to that lifecycle, what it costs to verify an agentic system once running in production, and why the enduring logic of the product model is finally meeting the technology it always needed.

Read more.

Robots in the Enterprise

Someone has to deploy these things, and most of the presentations skip over that part. This series is a week-by-week look at humanoid robotics from an operator’s seat: why “humanoid” isn’t quite the right word, the difference between the robot building your BMW and the one Hollywood sold you, and a scorecard of who’s actually building these machines and how they stack up.

Read more.

Who I’m Following.

Social Media is mostly a barren wasteland of AI slop.
But, there are some gems. Here are a few of my favorites.

Ryne Swanberg

Hayden O’Neill

Dean Bradshaw

In closing.

Friends, it has been a crazy start to the year. I won’t pretend that leaving my old community and the space where I had spent nearly a decade building relationships and credibility was easy. It was hard. But that is something that Jenelle and I pray for each night: the courage to do hard things. We have to embrace hard things to get to the good things. Looking back, doing the hard thing absolutely brought me to where I’m supposed to be during this season of life.

I am grateful for the time with Jenelle and Ford.
I am grateful for the caliber of people who I work with at The Select Group.
I am grateful for the opportunity to help decide the future of this company.
I am grateful for the opportunity to be creative, write, and solve problems.

Mostly, I’m grateful for remembering how important it is to be grateful.

Oh, and I’m pretty grateful for each of you as well.
Now, go hug your people and be grateful!

Cheers,
Adam

Strategic Portfolio Management Is Not a Better PMO

Part of the ADLC series. The last piece argued the portfolio is the front door to the lifecycle. This one is about the office standing at that door, and why most of them are built to keep it shut.

A traditional PMO is built to make the work conform to the plan. Strategic Portfolio Management is built to do close to the opposite, and no amount of buzzwords turns one into the other.

BLUF: Most enterprises that tell me they’re “moving to SPM” are running a traditional PMO with new terminology, which is a category error and an expensive one. A traditional PMO is an instrument of control: it standardizes method, enforces phase gates, and scores delivery as conformance to a plan and a budget set in advance. Strategic portfolio management is an instrument of allocation: it decides what’s worth doing against strategic intent and moves money toward evidence as the year unfolds. The two differ in form (where they sit, who they answer to, what they produce) and in function (the question each one is built to ask). Lean Portfolio Management, a body of knowledge I’m proud to have contributed to, was the bridge between them and pointed the right way as early as 2019, though it carries a ceiling that SPM done well is the thing to finally clear. Install SPM tooling on top of PMO instincts and all you’ve bought is a faster way to produce the same green status deck. The platform isn’t the function, and this piece is about the function.

I was in a portfolio review a while back, the kind that happens every quarter in every large enterprise, watching a wall of initiatives glow green. The status was green, the spend was on plan, the milestones were tracking. Everyone in the room understood, but nobody had the courage to say anything about it, that at least a third of what we were looking at had lost relevance sometime in the prior two quarters, and that the green measured how well teams were executing against the plan rather than whether the plan was still worth executing. The office running that review was doing its job perfectly, which was the problem. We knew the work needed to stop, to ignore sunk costs, and pivot to what was now right, but the system wasn’t designed for that conversation.

The PMO isn’t a failure of competence, but a discipline pointed at the wrong objective.

The failed rebrand.

Watch what most organizations do when they decide to modernize the portfolio. They buy a strategic portfolio management platform, point the existing PMO at it, and keep the same governance body, the same intake form, the same gate reviews, and the same definition of a healthy project. In fact, they may even customize the new tool to support the old patterns. Then they wait for the strategy-to-execution gap to close, and it of course doesn’t, because they changed the tooling and left the function untouched.

The reason it fails is that the PMO and SPM aren’t the same office at different points on a maturity curve. Gartner draws the line cleanly: project portfolio management is about doing things right, and strategic portfolio management is about doing the right things. That sounds like a slogan until you sit with what it implies. Doing things right is a conformance question, and it assumes the right things have already been chosen and the job is to deliver them on schedule and on budget. Doing the right things is an allocation question, and it never closes, because the right things keep changing underneath you.

You can’t get from the first to the second by tightening the first. A PMO that runs flawlessly produces flawless conformance to a plan that may already be wrong, and more rigor only sharpens the fit to something that was no longer worth fitting.

What SPM is.

Strategic portfolio management is the coordinated management of investments, initiatives, and capacity in service of strategic outcomes, operated continuously rather than at an annual gate. The emphasis falls on value and adaptability across the whole portfolio instead of on tracking and reporting against a fixed scope. Gartner named it a distinct discipline precisely because traditional portfolio practices, PMOs and EPMOs included, don’t move fast enough or bend enough to compete at the current pace of business.

Stated plainly, SPM is the bridge between strategy and execution. It decides what’s worth building and funds it against intent, then re-decides as evidence arrives, sitting above the lifecycle as the strategy layer that feeds it.

Definitions are the easy part. The contrast is where this gets useful, because most leaders are running on an unexamined model of how these two offices differ.

Two structures built for different jobs

Start with how each one is built.

A PMO is, in form, a delivery-assurance function. It usually reports into a CIO or a delivery executive. Its artifacts are the project charter, the work breakdown, the RAG status report, the change request, and the stage-gate review. Its unit of account is the project, a thing with a defined scope, a start, and a terminal end. Its calendar is the gate, where work advances once it clears Discovery, Planning, Develop, Execute, and Close, and the governance body grants go, no-go, hold, or modify at each one. Its currency is the plan, and its core skill is variance management, the discipline of noticing when reality has drifted from the plan and pulling reality back.

SPM, in form, is an allocation function. It reports up rather than in, to the office that owns strategy and the P&L, often with the CFO at the table instead of observing from a distance. Its artifacts are the strategic theme, the value stream, the funding guardrail, the portfolio Kanban, and the scenario model. Its unit of account isn’t the project but the bet, a body of work tied to a hypothesis about value, funded continuously, with no assumption of a terminal end. Its calendar is, ideally, the arrival of evidence rather than the turn of a fiscal quarter. Its currency is the capital envelope and the intent that governs it, and its core skill is reallocation, the discipline of moving money toward what’s working and off what isn’t.

Read those two descriptions back to back and the substitution problem becomes obvious. You can’t run an allocation function with a delivery-assurance org chart, a project-shaped unit of account, and a variance-management skill set, because at every point the form fights the function it’s been handed.

Function: the back office and the front office

The cleanest way I’ve found to explain the difference is to borrow from how an investment firm is built, because that’s the business SPM is in.

A PMO is the back office, and the back office is essential. It handles settlement, compliance, reconciliation, and reporting. It makes sure every trade is recorded correctly, that the books tie out, that the firm isn’t exposed to an error nobody caught. A back office that runs well is invisible, and one that runs badly can sink the firm. What it doesn’t do, and isn’t supposed to do, is decide where to put the money. Confuse the two and you get a firm that’s beautifully reconciled and pointed at the wrong positions.

SPM is the front office. The front office holds a thesis, places capital against it, watches the market, and repositions when the evidence moves. It doesn’t measure itself by whether it held January’s positions; it measures itself by return, and the failure it fears most is staying in a position long after the thesis behind it broke. Repositioning isn’t a deviation from the work. It is the work.

A PMO asks whether we’re on schedule, whether we’re on budget, and whether we hit the acceptance criteria, which are the right questions for the wrong problem, the same line I drew in the ADLC piece, now moved up a level. SPM asks what we’re learning, what that learning is telling us to fund more of, and what we should stop funding now rather than next January. Both offices belong in a large enterprise. The mistake is handing the back office the front office’s job and then wondering why nobody’s steering.

Where LPM fits.

If you’ve done any work with the Scaled Agile Framework, you already know there was a halfway house between these two offices, and it was a good one. Lean Portfolio Management took the PMO’s instincts and bent them toward allocation. I’m proud to have had a hand in shaping it, so consider me biased.

LPM got the hard part right. It funded value streams to guardrails instead of funding projects to detailed business cases. It replaced the steering-committee change request with cadence-based portfolio syncs. It gave teams Weighted Shortest Job First so sequencing followed economic value as it was learned, not the order things landed in the intake queue. It put epics on a portfolio Kanban with progression tied to hypothesis validation rather than phase completion. Every one of those moves is a step from conformance toward allocation, and they work, which is why organizations already running SAFe should recognize this as muscle they’ve built rather than theory they have to learn.

This is why LPM feeds SPM so directly. Its funding instinct, money to the capability and the value stream rather than to the named project, is the core of how SPM allocates, and the guardrail-over-business-case posture carries straight across. Run LPM well and you’ve already retired the worst habits of the PMO and learned to think like a portfolio rather than a project office.

Where the two diverge matters just as much. LPM is an operating model that lives inside a delivery framework, built bottom-up from the value streams, prescriptive about ceremonies and roles, and scoped largely to the technology and product organization. SPM is the enterprise strategy layer above all of that, framework-agnostic, executive- and finance-facing, and concerned with the whole portfolio of investment rather than the Agile delivery slice of it. The deeper difference is cadence. Even strong LPM adoptions re-plan the portfolio two to four times a year, and while that was a generational improvement on annual planning, in 2026 it’s still a batch process. The next generation of SPM tooling, the ServiceNows and Planiswares and Claritys I walked through in the last piece, exists to drop the batch and make reallocation event-driven, triggered by evidence instead of by the cadence calendar. LPM moved the portfolio off the annual clock and onto the quarterly one; SPM is the attempt to take it off the clock entirely.

The honest framing, then, isn’t LPM versus SPM. LPM is how a lot of organizations will first learn to think in value streams and guardrails at all, and SPM is where that thinking goes once it outgrows the quarterly sync and reaches the rest of the enterprise.

The strategy layer

Step back and the symmetry is hard to miss. The SDLC was the delivery model of a world where software shipped on a schedule, and the PMO is its portfolio twin, an office built to govern scheduled, scoped, terminal work. The ADLC is what delivery becomes when the work has no finish line and production is a feedback source, and SPM is what the portfolio becomes to keep time with it.

I’ve written that the portfolio is the front door to the lifecycle, the place where strategy enters and becomes work. If the lifecycle downstream now runs every day, and a generation of decisions has already been pushed down to the teams and the agents working inside the guardrails, then a front door governed by a back office that opens once a year on a phase gate is the constraint on the whole system. The ADLC dissolved “build and done” at the team level, and SPM is the same dissolution one floor up, moving the portfolio from monitor-and-control to sense-and-respond and from treating variance as failure to treating deviation as signal. A PMO is built to prevent movement and an SPM function is built to keep movement inside the envelope, which is how two offices can share the same wall of dashboards and be doing opposite jobs.

What this asks of you

None of this is a platform purchase, and I want to be blunt about that, because the vendors will tell you otherwise and the platforms are genuinely good. Buying the tool and pointing your existing PMO at it gives you a more expensive PMO. The function doesn’t change because the software did, any more than buying a Bloomberg terminal turns the back office into a trading desk.

The work is structural and unglamorous. It means moving the reporting line so the portfolio answers to strategy and the P&L instead of to delivery assurance, changing the unit of account from the project to the funded bet, replacing the gate review with an evidence trigger, retiring variance management as the core skill and standing up reallocation in its place, and putting the CFO in the room as a participant rather than an auditor. Every one of those is a conversation with someone whose role was built around the office you’re changing, which is exactly why most organizations announce the platform and skip the work.

There’s a cost to skipping it that never lands on a portfolio dashboard, because dashboards only measure conformance. It shows up as the product leader who learned in Q2 that the bet was wrong and then spent two more quarters delivering it flawlessly anyway, because the office she answers to rewards hitting the plan and has no mechanism to absorb the fact that the plan stopped being true. She did her job and the office did its job, and the strategy still lost while everyone’s status stayed green the whole way down.

The PMO was the right office for work that shipped on a schedule, and that work hasn’t disappeared, so neither should the discipline that governs it. But the portfolio stopped being a delivery problem some time ago. It’s an allocation problem now, and you can’t solve an allocation problem with an office built to keep score. Stop asking the back office to steer.

I was speaking with Shannon yesterday about SPM and ADLC, and our conversation encouraged me to publish this post a little early. So, Shannon, this one is for you!

Strategic portfolio management is the last function still planning on an annual clock. The tooling is about to make that indefensible.

Part of the ADLC series. “From SDLC to ADLC” was how the work changes once AI is in the build. This is where that work comes from.

BLUF: Nearly every part of the enterprise has embraced some sort of continuous execution and delivery except the portfolio. From a technical execution standpoint, delivery ships multiple times per day, models retrain on production telemetry, and security detects and responds to threats in near real time. And the portfolio that governs all of it still plans on an annual budgetary cycle, defends business cases at a gate, and scores success as conformance to a plan written before anyone knew what they would learn. We tried to address some of this with Lean Portfolio Management, but even in the best adoptions, the system iterated only two to four times per year. Truthfully, in 2026, that is too slow. The next generation of SPM tooling aims to close that gap, not by helping us build the annual plan faster, but by making the annual plan a thing of the past. What follows is a mix of what the vendors are actively doing and what they should be working on in their respective labs. The shift is from monitor-and-control to sense-and-respond, and the organizations that make it will run their portfolios at the speed their business already moves. This is the strategy layer of that lifecycle: the portfolio decides what is worth building, the ADLC decides how to build and run it, and right now the two keep different time.

I have sat in the annual planning room both as an advisor and as an executive with P&L ownership. Two days offsite, a wall of initiatives, a spreadsheet that took a quarter to assemble, and a set of business cases each defended with unshakable confidence. By the time the binder is approved, at the pace of business today, the assumptions underneath half of it have already moved. By Q2 the plan is a historical document. By Q3 everyone is working off a different list and pretending the plan still governs. (I have helped build a few of those perfect plans. I am not proud of all of them.)

Let’s be clear: this is not a planning-quality problem. You won’t simply “plan better,” and your enterprise or industry is not uniquely insulated from the reality of the modern pace of business. The problem is that the portfolio is being operated like a road trip. Set a target, measure variance, correct back to the plan. That works when the plan is a good description of reality for twelve months, but it stops working the moment the thing you are governing changes faster than once a year.

And everything the portfolio governs now changes much faster than once a year.

The portfolio is the front door to the lifecycle

I have written about the shift from SDLC to ADLC: how building and operating AI systems runs on different physics than traditional software, where production is a feedback source, there is no “done,” and the work is measured by learning velocity instead of predictability. The portfolio sits above all of that. Large bodies of novel work and new experiments have to enter the lifecycle from somewhere, and increasingly that somewhere is the last place to deploy agents. That has to change.

In an agentic delivery model, a growing share of decisions gets made close to the work. Coding agents refactor, test, and ship inside guardrails a human set. Teams run experiments daily. That is the point of the ADLC: push the decision to where the context lives and let the work move at the speed the tools now allow.

But not every decision belongs close to the work. New bets do not. Significant refactors do not. Infrastructure that changes the cost or risk profile of everything downstream does not. We refer to this work as having significant economies of scale, and these bodies of work are still portfolio considerations, because they are choices about where to point the money and the attention before anyone, human or agent, starts building. The portfolio is, and will continue to be, the bridge between strategy and execution. It decides what is worth doing and funds it against strategic intent. The ADLC decides how to do it, and does most of that deciding itself.

So, the portfolio is the front door to the lifecycle. It is where strategy enters and becomes work. And if the lifecycle downstream of it now runs every day, a front door that opens once a year is the constraint on the whole system.

The business case stops being a one-time artifact

Starting with a lightweight business case is a valuable thought experiment, because these initiatives are the very thing that can break the annual model most visibly, and where the tools can help first.

Today a business case is a document that most will write once, defend at a gate, and then spend the next twelve months explaining variances against. It is an argument made at the moment of maximum ignorance: before the work starts, before the first experiment, before anyone has touched the data. We have built an entire governance apparatus around treating that first guess as the baseline of record.

The next generation of SPM platforms changes the input side of this. Given a clear statement of strategic intent, a set of budgetary guardrails, and enough learned context about how value moves through the business, where work piles up, and how the architecture is wired, the platform can surface the work that advances the intent. The candidate work itself, derived from what the tools know of your strategic intent, the monitors established for the market, and how value flows and where it gets stuck, proposed as a set of experiments with a hypothesis attached to each one.

That is a real change in what a business case is. It stops being a defense of a predetermined answer and becomes a continuously re-derived view of the highest-value experiments available right now, given what the organization has learned since the last time it looked.

I want to be clear about the dependency here, because this is where the vendor demos can get ahead of reality. A platform can only surface the right work if it can see value flow, bottlenecks, and architecture clearly, and most enterprises cannot. The value-stream data is fragmented across tools and the architecture-to-value mapping, in most cases, does not exist. Is the platform that reads all of that and proposes the right experiments shipping today? Not yet. This is the part still in the labs. The foundation is there and the direction is set, but the capability arrives on top of instrumentation most organizations have not yet built. The firms that get there first will be the ones that treated value-flow visibility as infrastructure, the same way the firms getting real value from AI treated production observability as core development work rather than an operations afterthought.

This is also why the platforms best positioned for it are the ones already sitting on the operational system of record. ServiceNow SPM is the clearest case: it runs on the same platform as the ITSM and ITOM data, so the work and the application landscape already live where the portfolio governs, and its Digital Portfolio Management ties applications back to business capabilities. Proximity to the operational data is what makes surfacing real candidate work plausible instead of aspirational. The platform that can see where the work moves has a head start over the one staring at a tidy list of approved projects.

Iterate at the speed of the business, not the speed of the calendar

Once the business case is something the platform helps re-derive continuously, the annual cycle has very little left to do.

Let me be exceedingly clear on one point so this does not get misread. We may still set an annual capital envelope, and we will still set annual sales targets. That part is fine and it is not going anywhere, because fiduciary oversight and forty-year-old capital budgeting frameworks run on a fiscal calendar, and strategic intent is framed on a longer horizon anyway. What has to end is predefining the entirety of that budget up front, committing every dollar to a named initiative twelve months out, which is exactly what most organizations still do. The world is changing too fast for it. I cannot tell you what the priorities should be ninety days from now, let alone a year out. Nobody can. So, you set the guardrails and the intent, then point the money at the evidence as the year unfolds. The guardrails stay; the frozen plan inside them goes.

What changes is everything inside those guardrails. SAFe’s Lean Portfolio Management, a body of knowledge that I am proud to have contributed to, pointed the right way as early as 2019: fund value streams to guardrails rather than projects to detailed business cases, re-sequence with Weighted Shortest Job First as you learn, and reallocate at cadence-based portfolio syncs instead of waiting on a steering committee. It worked, but it has a ceiling. Even strong adoptions of LPM re-plan their portfolio only two to four times a year. Though this was a generational improvement on annual planning, in 2026 it is still a batch process. The next generation of tooling drops the batch: reallocation becomes event-driven, triggered by evidence instead of by the calendar or the cadence.

The result is a portfolio that re-sequences itself as evidence arrives. An experiment validates in March, the funding follows it in March. An assumption collapses in June, the money moves off it in June. The portfolio iterates at the speed the business is already moving, instead of holding what it learns in a queue until the next planning season opens.

Moving money in March instead of next January sounds reckless right up until you can see the second-order effects before you commit. That is what scenario modeling is for, and it is where the financially serious platforms have spent their effort. Planisware Horizon is the one I reach for here, built around what-if modeling across funding, capacity, and risk: you simulate the reallocation, watch what it does to the rest of the portfolio, then decide. The skill that used to live in one finance analyst’s spreadsheet becomes a standing capability of the portfolio. Continuous reallocation is only responsible when you can rehearse it first.

From monitor-and-control to sense-and-respond

This is the operating-model shift underneath all of it, and it deserves its own name. Portfolio operating is moving from monitor-and-control to sense-and-respond.

Think about how air traffic control works. Controllers do not write a plan in January that routes every flight for the year and then measure variance against it. They set a destination and a safety envelope, then they sense conditions continuously and re-route in real time within that envelope. The guardrails are strict and non-negotiable. The paths inside them are adjusted constantly. Nobody calls a re-route a failure of the plan. Re-routing is the plan.

A monitor-and-control portfolio treats every deviation from the original plan as a variance to be explained and corrected. A sense-and-respond portfolio treats deviation as signal. The strategic intent is the destination. The budgetary guardrails are the safety envelope. Everything in between is expected to move as conditions change, and the job of governance is not to prevent movement but to keep it inside the envelope. Those guardrails do double duty. They are also the line between what the work decides for itself and what comes back to the portfolio: inside the envelope the teams and the agents move freely, and the moment a choice would breach it, a new bet, a major refactor, a shift in the risk profile, that choice belongs at the portfolio.

Sensing requires something to sense. A portfolio cannot respond to a signal it cannot see, which is why the platforms are racing to wire the portfolio layer to live delivery data. Broadcom’s Clarity is the clearest version of that bet: paired with Rally under the ValueOps banner, it is built to tie portfolio decisions to real-time execution telemetry instead of to a status slide assembled the night before the review. The detail I find telling is the marketing. Broadcom now tells buyers to stop wasting months on rigid annual plans and steer on a quarterly cadence instead. Quarterly is still a batch, and still slower than where this ends up, but the tell is the direction of travel. When a forty-year-old PPM incumbent is arguing against the annual cycle, the question stops being whether the model changes. It becomes who restructures around it first.

This is the same physics I wrote about in the shift from SDLC to ADLC, moved up a level. In the AI Development Lifecycle, you stop asking “did we finish the build phase” and start asking “did we validate the business hypothesis that justified this investment.” The portfolio version asks the same question across every value stream at once: what are we learning, and what is it telling us to fund more of and stop funding. Those are the right questions. Most portfolio reviews are still asking whether we are on schedule and on budget, which are the right questions for the wrong problem.

One portfolio, governed by value

The last shift is the one most organizations will resist hardest, because it dismantles a boundary that has org charts and career tracks built on top of it. The technology portfolio and the operations portfolio become one portfolio, organized around value delivery rather than around who owns the work.

The separation made sense when building software and running it were different activities done by different people on different clocks. That separation is the same one ADLC dissolves at the team level, where the production signal becomes a development input and “build and done” becomes “build and run.” At the portfolio level the same logic holds. If the model in production is still a development artifact, then operating it is not a separate cost center to be managed against an SLA. It is part of the same value stream, funded continuously, governed by the same outcome-based guardrails.

Here is where I will add a caution the enthusiasts skip. Merging the portfolio view is right. Merging the guardrails wholesale is not. Run-the-business operations fail in continuous, sometimes safety-critical ways that change work does not. A regulated operations failure is a different risk class than a delayed feature. The defensible model is one portfolio and one value lens, with differentiated guardrails for the run-the-business work and the change work underneath it. Same board. Same prioritization logic. Different safety envelopes. Collapse that distinction and you will learn why it existed, probably from your regulator.

What this asks of you

None of this is a tooling purchase. All three are solid. They come at the problem from different corners: ServiceNow from the operational system of record, Planisware from financial and scenario planning, Clarity from the value stream. Pick the one that fits your stack. None of them hands you the operating model. The platforms make the continuous portfolio possible. They do not make it happen, any more than buying a flight-tracking system makes you an air traffic controller. The work is structural, and it is the unglamorous kind.

Fund value streams to guardrails instead of projects to business cases. Move reallocation decisions off the calendar and onto evidence. Rebuild governance around outcome validation instead of phase completion. Instrument value flow so the platform has something real to learn from. Put the run and the change work on the same board with different safety envelopes. Every one of those is a conversation with someone whose job was built around the model you are changing, which is why most organizations announce the tool and skip the work.

And there is a cost to skipping it that never shows up on a portfolio dashboard. It is the team that learned something real in Q2 and had to sit on it until next year’s planning window opened, watching the opportunity close while they waited for permission to act on what they already knew. It is the leader who stops bringing new ideas to the portfolio because she has learned the cycle cannot absorb them between planning seasons. It is the strategy that was exactly right in January and irrelevant by June, executed faithfully the whole way down because the portfolio had no mechanism to notice it had stopped being true. Annual planning does not just slow you down. It quietly teaches your best people to stop surfacing what they learn.

The portfolio has been the slowest-moving part of the enterprise for a long time, and for a long time that was tolerable, because everything it governed moved slowly too. That era is over. The ADLC made delivery continuous and pushed a generation of decisions down to the work. What it did not change is where the big bets come from. That is still the portfolio, and a front door that opens once a year cannot feed a lifecycle that runs every day. Strategy and execution have to keep the same time now. The only question left is whether the operating model catches up, or whether the portfolio stays a binder that everyone has quietly stopped believing by spring.

I wrapped up last week with a checklist for anyone considering a humanoid investment: three questions for sorting vendor evidence and five asks to keep in the back pocket during any sales meeting. A few readers seem to have filed it away as a buying guide, so let me correct that before it turns into one. The three questions and the five asks tell you how to read a vendor, but they tell you nothing about whether your enterprise should deploy a robot, and those are two different problems entirely.

Sometime in the next year, a CIO is going to put the question to me without any hedge attached: should we be piloting one of these robots? The honest answer, the one I would give across a table rather than in a post, is that I can’t responsibly answer yet. In short, the standby consultant answer of “it depends” stands. That isn’t because the robots don’t work, since some of them demonstrably do, for specific tasks, at specific sites, with money changing hands. It’s because a responsible recommendation rests on roughly twenty things I do not currently know, and any one of them could flip the recommendation from go to no-go.

So, this week I wrote down those questions and sorted them into four piles: questions about the machine itself, questions about operating it, questions about paying for it, and questions about the world outside the building. I numbered them because I intend to hold myself to them: whenever I claim to have a view on one of these, you will be able to scroll back and check whether the question I’m answering is the question I asked. (And please do hold me accountable.)

One admission before getting into the list: I sat down to write twenty, and the list grew by two before I finished the draft. Either the field is moving that fast or my list discipline is that weak. (Probably both.)

Let’s dive in.

The machine list

1. Where is the capability boundary stated outside of a highlight reel? Every vendor can show me what the robot did once. What I need is the task envelope: the range of work the machine completes reliably, the conditions under which that reliability holds, and what happens at the edges of it. A demo gives you one point on the map, and nobody in this field is publishing the map.

2. What does task variation cost? The tote is wet, the lighting changed, the SKU is new this week. I want to know whether the robot adapts, degrades, or stops, and when it can’t adapt on its own, what teaching it costs in days and in dollars. The economics of a generalist machine live inside this question, because a robot that needs vendor engineers on site for every variation is a specialist machine carrying a generalist’s price tag.

3. What does the machine do when it fails? It will fail. The question is what it does while it’s failing. A fixed industrial robot has a safety-rated stop: cutting power makes it safe. A bipedal machine that needs active control to stay upright has no equivalent, because cutting power makes it fall. I don’t yet know what a safe failure looks like for this class of machine, and I have not found a vendor who explains it in public.

4. What data does one unit produce in a shift, and where does it go? Each of these machines carries cameras, depth sensors, joint telemetry, action logging, and on some models microphones, all producing continuously across a shift. I want to know where that data lives, who can see it, what leaves the building, and what the retention terms say. I have asked versions of this question about enough enterprise systems to know that “we’ll work through that during onboarding” means nobody has worked through it.

5. Does fleet learning occur across customer boundaries? If a robot in my facility learns to handle my packaging, I want to know whether that skill transfers to the rest of my fleet, to the vendor’s other customers, or to my competitor, and under what controls, with what consent, and with what value flowing back to the facility that generated the training data. This is the question vendors most want to keep vague, because the honest answer sits at the foundation of their business model.

Operations

Week 4’s standard applies here: the test of a deployed robot is whether it works, and is supported, on an ordinary Tuesday. These five questions are what Tuesday is made of. (An aside: growing up my grandfather always used the phrase “…just an average Tuesday” to describe the ordinary, so there you go.)

6. What is the uptime, under production conditions, in writing? I raised this in Week 4 and it remains the most clarifying absence in the field. A forklift vendor quotes mean time between failures without being asked. No humanoid vendor publishes the figure. None.

7. When it breaks, who fixes it, and how fast? Mean time to repair matters, but so does the boring machinery behind it: where the parts depot sits, whether the technician belongs to the vendor or to me, what the escalation path looks like at two in the morning, and what my line does in the meantime. Twenty years of watching enterprise technology fail has taught me that the support model, not the product, is where deployments live or die.

8. Who writes the integration, and what happens when systems disagree? The robot has to talk to the warehouse management system, the MES, and sometimes the ERP, and someone has to write that middleware. When the system of record says the pallet is in bay 12 while the robot’s eyes say bay 14, I want to know which one wins and who designed the tiebreaker.

9. What happens to the team in the work area? Someone has to own the supervision model, the reporting lines, and the question of who answers the robot’s pages, because day to day somebody manages this thing the way a shift lead manages a new hire, and no framework exists for that role yet. The change management literature assumes the change is human, and in this case part of it isn’t.

10. How long until the site runs without vendor staff on the floor? Every early deployment I can find has vendor engineers embedded at the customer site, an arrangement that is fine for a pilot and disqualifying for production at any real number of sites. The date the vendor’s people go home is the date the product exists.

The money. The real money.

11. What is the total deployed cost, and what is the multiplier on unit price? This is ask number four from Week 4, promoted to a standing question. The unit price is a marketing number. The deployed reality is integration, infrastructure changes, training, support contracts, fleet software, insurance, and downtime. For every comparable industrial asset that total runs to some multiple of the sticker, and nobody has published the multiple for humanoids.

12. What is the financing structure, and what happens at the end of it? A capex purchase, a robots-as-a-service subscription, and a lease are three different risk allocations wearing the same robot, and each carries a question hiding inside it: when the term ends, what happens to the robot, to the trained behaviors, and to the data my facility spent two years generating?

13. If I switch vendors in year three, what do I keep? Behaviors, training data, fleet management tooling, and integration code all sit somewhere in the stack. My current guess? Almost nothing. The lock-in is being built into every layer right now, while nobody’s procurement team is looking.

14. Who deploys this besides the vendor? Independent integrators are what make any enterprise technology deployable at more than one site at a time, and for humanoids they do not yet exist. Until there is an independent party I can hire, audit, and hold accountable, every deployment is a bespoke vendor project, and bespoke vendor projects have never scaled in any technology wave I’ve lived through.

15. What does the contract say when things go wrong? I want to read the SLA terms, the liability allocation, the exit clauses, and the answer to Week 4’s bluntest ask: who owns the failure when it happens. The vendor whose standard agreement has a clear answer to that question has thought about production, and the vendor whose agreement is silent has thought about pilots.

My lawyer and insurance agent want to know…

16. What standard certifies this machine, and who signs the safety case? The industrial robot standards assume a fenced machine or a power-and-force-limited cobot, while the service robot standards assume something far less capable than a full-sized biped, and a dynamically balancing humanoid working near people falls between every category I can find. I do not yet know who writes, reviews, and signs the safety case for one, and as far as I can tell from the public material, neither does anyone else.

17. Who insures it, on what basis, at what premium? Insurance is the institution that prices risk honestly, because it loses money when it doesn’t, and there is no actuarial table for humanoids working alongside people. Whatever the early underwriters charge will tell us more about real deployment risk than any vendor’s safety page, and I want to see those numbers badly.

18. What is the workforce plan, in writing, before the robot arrives? Redeployment, retraining, attrition management, and whatever the existing labor agreements permit all have to be settled somewhere, and the facilities where this goes smoothly will be the ones that answered the question before procurement rather than after.

19. What happens at the bargaining table? Organized labor has already made automation the center of major contract fights in adjacent industries, and humanoids are the most visible, most filmable form of automation ever built. I don’t know what the first humanoid deployment does at the next contract negotiation, and I haven’t seen anyone game it out.

20. What happens when the first bad video comes from your building? A humanoid dropping a box is content. A humanoid falling near a worker is a news cycle. The first enterprise to take serious public damage from a deployment video will change every other enterprise’s risk calculus overnight, and nobody I’ve read is pricing that in.

The bonus questions

21. What is the teleoperation percentage? This one was already on Week 4’s list of unknowns, and the more I sit with it the more it refuses to stay in one category. It is an operational question, because a robot that is ninety percent piloted is a staffing model with servos, and it is a commercial question, because you are paying for a robot plus a remote human, which means a per-hour labor cost, an operations center somewhere, and a camera feed from inside your facility going to people you have never met. I want one number, in writing, before any contract gets signed.

22. Who supplies the brain, and who owns what it learns? The body and the intelligence are decoupling into separate industries while we watch. Boston Dynamics builds the body and Google DeepMind supplies the models, Figure walked away from OpenAI in February 2025 to build its intelligence in house, NVIDIA ships an open foundation model that anyone’s hardware can run, and a new class of company now sells robot brains with no body attached. That decoupling hands the enterprise buyer a question that did not exist a year ago: when the body vendor and the brain vendor are different companies and the robot does something wrong, whose problem is it? And behind that question sits a sharper one, because the fleet-learning data my facility generates is training somebody’s model, and I want to know whose, under what terms, and whether it ends up running my competitor’s fleet.

What I learned writing this

What follows is an honest reflection of where I’m at with the whole “operationalizing robotics” thought experiment.

There are eight questions where I have a starting view. On 6 and 7, Week 4 already established that the absence of published uptime is itself the answer for now. On 11, the comparable industrial assets give us a floor to reason from. On 13 and 14, I have watched the lock-in and integrator-gap movies before in other technology waves, and the opening scenes here look familiar. On 15, contract maturity is legible from the outside if you know what to read for. On 16, the safety case, my view is a negative one but it’s still a view: no standard I can find covers a dynamically balancing biped working near people, and that absence is the finding, not something I’m waiting to learn. And on 21, the position is simple enough to state in a sentence: get the number in writing or walk.

The other fourteen have nothing under them yet, and a few deserve naming. Question 3, what a safe failure looks like, is question 16 from the engineering side rather than the regulatory one, and it stays empty because nobody has published the design. Question 17 is empty because I have not found a single substantive public source on humanoid insurance. Questions 5 and 22 are forming faster than anyone outside the deals can see, and question 2, the cost of variation, may turn out to be the one that decides whether the generalist premise survives contact with enterprise reality at all.

That is how the questions map in my mind: eight questions with some semblance of an answer and fourteen with nothing yet. This list is the spine of whatever comes next in this series, and when I come back to one of these claiming an answer, hold me to the version written here.

The CIO question will come, and when it does, the responsible answer will not be a number of robots or a vendor name. It will be a count of how many of these twenty-two questions we have real answers for, and how many are still running on someone’s roadmap slide. Right now, my count is eight, and most of those are partial.

I’d want to be able to answer a lot more of these questions with confidence before I spent your budget.

Views are personal and do not represent any employer, past or present.

I spent this afternoon ( isn’t this your idea of Saturday fun?) trying to line the humanoid companies up for a good ol’ fashioned scorecard comparison, feature by feature, and gave up. Not because the robots are hard to differentiate, but because almost nothing is comparable.

One company’s site leads with a named customer and a count of operating hours on a production line. Another leads with a livestream of a robot sorting packages, a counter ticking past 200,000, with nobody paying for a single one of them to move. A third, Boston Dynamics, makes the most famous walking robot on earth, and you can’t buy it. Every Atlas coming off the line in 2026 is already committed to two addresses: Hyundai, which owns the company, and Google DeepMind, which supplies the AI. No units will be delivered to an outside customer until at least 2027. The most recognized name in the field, and for anyone who isn’t its corporate parent, it isn’t a product. It’s a very well-funded internal pilot.

So you can’t rank these companies the way you would want to, by whose hands are best or whose gait is smoothest or whose demo got more views. The builders and their claims are not answering the same question. Each one is offering a different kind of evidence, and the evidence offered does not create a like-for-like playing field. Capability footage is one currency. A funding round is another. A unit-shipment count is a third. Operating hours at a named customer is a fourth. Before you can read this landscape at all, you have to know the exchange rate between the currencies.

It helps to see what each currency is worth. Humanoid startups raised about $3.2 billion in 2025, more than the previous six years combined, by Dealroom’s count. Figure alone carries a valuation near $39 billion, more than ten times what the entire sector raised that year. The best demo videos clear millions of views in a weekend. Set that against a different currency, the one that is most meaningful: Counterpoint estimates about 16,000 humanoid robots were installed worldwide in all of 2025, and more than 80 percent of those were in China, mostly not at the companies getting the headlines.

Billions of dollars and millions of views on one side. Sixteen thousand machines on the floor on the other.

What follows is my attempt at a first-pass vendor map. It is built from product pages, press releases, and earnings calls, not from gemba time, so I’ll get some of it wrong and update when I do. Last week I sorted these machines by what they are: logistics movers, station manipulators, mobile manipulators, teleoperated bodies. This week I’m sorting the companies by evidence. Let’s consider three questions.

Three questions

First: is there deployment evidence? The bar is specific: is there a robot doing repetitive, unglamorous work at a named site, under production conditions, for long enough that someone can quote you operating hours, with money changing hands for the work. Agility’s Digit shines in answer to this question: it has been moving totes onto conveyors at a GXO warehouse near Atlanta under a paid, multi-year robots-as-a-service deal the two companies call the first formal commercial humanoid deployment. Figure has comparable evidence, on its older robot: Figure 02 ran about eleven months on the BMW line at Spartanburg, roughly 1,250 operating hours across 10-hour weekday shifts, contributing to more than 30,000 vehicles. What doesn’t count, however polished, is a livestream counter or a six-minute home video. The test is dull on purpose. The question that needs to be answered is “would a customer pay to have this exact work done, and can you show that they are?”

Second: will a customer go on record? A buyer that puts its name and its logo on your robot is wagering reputation, which is why disclosure is the evidence that’s hardest to fake. GXO names Agility on its own earnings calls. Its year-end note said it would “steadily increase” robotics deployment in 2026, which is the phrasing of a buyer hedging, not a buyer evangelizing. BMW is named at Spartanburg. Mercedes both invested in Apptronik and is testing its Apollo. And the most useful tell in the whole market: GXO is running both Digit and Apollo. When the most credible customer in the category is hedging across two vendors, that says how early it is more honestly than any roadmap slide. The weak version of this signal is “a leading global logistics provider,” unnamed. When the customer won’t be named, assume pilot.

Third: what is the commercial relationship? Pilot, framework, and paid production are three different things that get reported in the same sentence. Agility’s GXO arrangement is paid production, which is close to the top of the field. Most of the rest is softer than the headline. When 1X announced a deal to put up to 10,000 of its Neo robots in front of an investor’s 300-plus portfolio companies by 2030, much of the coverage treated it as an order book. It’s a framework to negotiate individual deals, which is a different object. A framework is a maybe with a press release.

The field

A few of these deserve more than a row, so I’ll expand here.

Boston Dynamics and Tesla are the same shape, for opposite reasons. Boston Dynamics has the deepest engineering history in the room and has committed every unit to its own parent. Tesla is converting part of Fremont to build Optimus and its only disclosed customer is itself. Both are running closed loops. Being your own first customer is a legitimate way to start: you control the building, the data, and the blame. It is also not the same evidence as an outside buyer choosing to pay, and Musk’s prediction of thousands of Optimus units in Tesla’s own plants by the end of 2025 is a fair reminder of how these calendars move.

1X and Sanctuary are where the word “autonomous” needs reading glasses. Neo ships to homes now, for $20,000 or $499 a month, but the early units run with a human in the loop, a remote operator stepping in when the robot can’t cope. You’re buying a robot plus a person, which is a different cost and privacy model than the ad implies. Sanctuary’s Phoenix runs on the same engine: genuinely impressive hands, pilots with the parts maker Magna, teleoperation underneath, and no commercial units shipping yet. Neither is a scandal. Teleoperation is a reasonable bridge to autonomy. It is just not autonomy, and the price of the robot is not the price of the service.

Then there’s the cohort most North American coverage barely registers. The single largest shipper of humanoids in 2025 was not Figure or Tesla. By Counterpoint’s count it was AgiBot, a Shanghai company most US operators have never heard of, with roughly a third of global installations on the strength of mass-produced units sold into hospitality, manufacturing, and logistics. Unitree shipped more than 5,500, with a sub-$20,000 machine and a target of 20,000 this year. UBTech put its Walker S2 into mass production and reported orders worth roughly $112 million, much of it for automotive plants. XPeng, the EV maker, is sitting on a large cash pile and pointing it at humanoid production. Fourier is a different animal again: it came out of rehabilitation robotics and sells into hospitals, eldercare, and research, not warehouses. The volume is real and it dwarfs US output. What I can’t see from here is the part that matters most: what those thousands of units do on an ordinary day, and how often they break. The Western vendors over-disclose capability footage. This cohort over-discloses volume. Neither one tells you the uptime.

What I don’t know

I can’t independently verify any of these deployment claims. I’m reading announcements and earnings calls, not standing on the floor watching the thing run for a week.

Nobody publishes the number that would settle most of the argument: uptime, or mean time between failures, under production conditions. A forklift vendor will quote you that without being asked. Until a humanoid vendor does, every “deployed” carries a quiet asterisk.

The teleoperation percentage is mostly undisclosed too, and it’s decisive, because a robot that’s ten percent piloted and one that’s ninety percent piloted are different products with different economics wearing the same shell.

Even the market’s headline number comes in incompatible currencies. One firm counts 16,000 installations, another counts 18,000 shipments, a third counts $440 million in revenue, and they are measuring three different things. And funding, the loudest number of all, tells you about runway and investor conviction. It tells you nothing about whether the robot works on a Tuesday in a building that smells like a warehouse.

Missing pieces

So before I told a customer to take any of these companies seriously, I’d want five things, and it’s the same evidence for each company:

1. A named customer, on the record, who’ll take my call and tell me what broke.

2. Operating hours under production conditions, not demo conditions, with the gap between the two stated honestly.

3. The teleoperation percentage, in writing.

4. Total cost, not unit price: integration, support, the service model, and who owns the failure when it happens.

5. A boring answer. The vendor whose materials are thick with dull operational detail is almost always further along than the one with the better sizzle reel, because the dull detail only exists once someone has successfully operationalized the robot.

If you’re being pitched one of these robots in the next year, take this list into the meeting and let it do the work. Run the three questions and the five asks against the deck in front of you, and watch which currency the vendor reaches for when you press. The ones paying in operating hours and named customers will keep talking. The ones paying in funding rounds and view counts will change the subject.

Somewhere a facilities lead or an automation manager is going to be handed one of these robots and told to keep it running long after the announcement scrolls off everyone’s feed. That person doesn’t care what the company was valued at. They care whether the robot works and is supported on Tuesday. My vendor map isn’t a ranking, it’s a list of currency exchange rates, and right now the rarest, most valuable currency in the field is also the simplest: a named customer who’ll tell you the truth about what broke.

Views are personal and do not represent any employer, past or present.

An agentic system has been running in production for a few months. The executive whose name is on the P&L asks the obvious question: “Is it working?” The answer falls apart in their hands. Metrics are mostly on target, one segment slipped slightly, production looks fine, though monitoring is a day behind. Someone offers the fatal hedge: “Well, it depends what we mean by working.” You can watch the accountable leader give up on getting a clean answer.

That moment is the subject of this piece. Once agents make code generation nearly free, the constraint on a business stops being how fast you can build and becomes how fast you can trust what got built. The number that governs that, the one a leader can act on, is the cost to verify a single change. Most organizations have never measured it.

The number is concrete. It is the time and the cost to carry a single change from the moment an agent writes it to the moment you trust it enough to leave it running in production. Everything else in this piece is downstream of that one number.

Second in a series on the Agentic Development Lifecycle. The first piece argued that once generation gets cheap, the bottleneck moves to verification. This one picks up there.

Here is the part the first piece left implicit. The risk that used to sit in production did not disappear when generation got cheap. It migrated to verification, where almost no one had built the capacity to absorb it.

This realization brought me to the question: If verification is the bottleneck, what does verification mean when a model wrote the code, system behavior is emergent, and the thing you shipped in March, and was valid at the time, is wrong by September with nobody having touched it? What if what we call “verification” is no longer the thing that earns trust?

“Is It Working” is no longer the question.

That scene is not a one-off. It is becoming the standard meeting, and the further agentic development spreads across the enterprise, the more often it plays out the same way. The answer scatters, and the baseline underneath it turns out to be a mess no one can reconstruct on the spot.

The reason nobody wants to answer is that the honest answer is a pile of fragments, and the leader on the hook for the number can tell the fragments don’t add up to a yes or a no. That gap, between the question a business needs answered and the scattered signals the organization can actually produce, is the whole problem. It is not a reporting failure. It is a sign that the thing underneath the question has changed.

My job, mostly, is to build a common baseline other people can work from. It’s kind of my thing.

In a traditional software review that question of “working” had a clean answer. The team validated the build against the requirements, the test suite passed, the acceptance criteria were met. There was even a name for what created a clear finish line: the definition of done, a checklist agreed before anyone wrote a line of code that spelled out what “complete” meant. So “is it working” really just meant “did it pass,” and “did it pass” really just meant “did we hit the definition of done,” and that usually meant “requirements met, expected functionality validated, live in production.” The question was binary because the thing underneath it was deterministic: the behavior was written, not learned. You could write down what correct looked like in advance, agree on where done sat, and then check whether you got there. Red/green.

Agentic and AI systems eliminate the spec. Behavior is an emergent property of data and training, not a line-by-line implementation of stated logic, and the evidence that something is correct comes with a shelf life that is undetermined. The whole apparatus we built to answer, “is it working,” the reviews, the gates, the signoffs, was designed on the quiet assumption that once you had the answer, it would keep. It doesn’t keep anymore, and nothing in the apparatus is designed to handle this operating rhythm.

There is no baseline.

Old-school validation is conformance testing, and for the record it’s a good idea. You write a specification, you derive test cases from it, and validation is the act of proving the system does what the spec said it would. A whole profession is built on that one motion: requirements traceability, acceptance testing, and the standards that draw a tidy line between verification and validation. Barry Boehm’s shorthand still holds in the deterministic world: verification is building the thing right, validation is building the right thing. Both assume there’s a fixed thing to check against in the first place.

In the Agentic Lifecycle, the thing under verification is a model, and a model has no fixed thing to conform to. Its behavior approximates what you wanted, learned statistically from data, characterizable but not enumerable in advance. The closest artifact you have to a specification is an evaluation set, and an evaluation set is a sample, not a definition.

That gap, spec versus eval set, is the entire problem. So let me be explicit. A spec defines what correct is. An eval set gathers up a pile of examples you’ve blessed as correct and hopes they stand in for the rest. The spec covers everything by definition. The eval set covers what’s in it and goes quiet on everything else, which means it tells you how the system did on the cases you thought to collect and nothing about the cases you didn’t. In production, the cases you didn’t think of are most of them.

And here’s the part with no analog in deterministic software: the proof decays without anyone touching the code. Input distributions move, which is data drift. The relationship between inputs and the thing you’re predicting moves, which is concept drift. The environment around the system shifts in ways no one filed a ticket for. Instacart watched this happen in the spring of 2020. Its model for predicting whether an item would be on the shelf ran around 93% accuracy until March, when shopping behavior changed overnight and it dropped to 61%, with nobody having touched the code. The model didn't break. The ground it was standing on did.

There is a name for this. A decade ago, Sculley and his co-authors at Google, writing about the hidden technical debt of machine learning systems, called it CACE: Changing Anything Changes Everything. Touch one input, one dependency, or one assumption, and the behavior of the whole system can move. In deterministic software you can reason about a change in isolation, but in a learned system you can’t, and that single property is why a validation that was true in March is quietly false by September with nobody having touched the code.

Here is the line I keep coming back to. In deterministic software, validation expires when the requirements change. In agentic and ML systems, it expires when the world changes.

And the world does not file a change request.

A lesson from medicine.

There’s an industry that solved a version of this long before software had it, and the structure maps almost exactly.

When a drug goes to market, it has passed rigorous clinical trials. Controlled populations, defined endpoints, real statistical significance. By any reasonable definition it has been validated. And then the regulator does something that would look insane to a traditional software team. It keeps watching. Post-market surveillance and adverse event reporting, for years, on the explicit assumption that the trial population was a sample and the real population has properties the trial couldn’t capture. A drug that performed beautifully in a controlled study can interact badly with conditions or medications that were screened out of the trial. The only way to know is to keep measuring after launch.

Vioxx is the case the field doesn’t forget. Merck’s painkiller was approved in 1999, and it worked: it relieved pain with less stomach bleeding than the older drugs, and tens of millions of people took it. Then the signal showed up in the place the trials were never built to look. Across a population far larger and far more varied than any controlled study, the heart attack and stroke risk became visible, and in 2004 the drug was pulled from the market. It had passed every gate that existed at launch. Five years of real-world use, not the trial, is what surfaced the harm. The gate that would have caught it earlier, sustained surveillance of the broad population, existed, but it was not pointed at the right thing soon enough.

The management lesson is blunt: budget for post-market surveillance, not just the launch. The trial proves the drug works on the population you could study. The monitoring proves it keeps working on the population you actually have. An organization that funds the first and treats the second as optional is buying the cheap half of safety and calling it done. The same arithmetic applies to every agentic system a business puts into production.

That is the posture agentic systems require, and almost no enterprise is built for it. We treat the launch as the validation and move on. Medicine learned, through real harm, that approval is the cheap part. The expensive part is everything after it, the unglamorous monitoring that runs for years and never produces a headline. “Did it pass” and “is it still working” are not the same question, and the second one is the one we keep dropping.

But the analogy breaks in one place, and the break is in software’s favor. A drug cannot be recalled from a million bloodstreams; once the harm is in the population, the damage is done and the cleanup takes years. Software does not work that way, because a bad change can be rolled back in seconds, and that changes the lesson entirely. Medicine’s surveillance has to be slow and cautious precisely because reversal is impossible, which puts the entire burden on watching. Software can run the opposite posture, shipping faster because it can also reverse faster, which means the discipline worth building is detect-and-revert rather than delay-and-deliberate. The leader’s job is not to slow shipping down to medicine’s pace. It is to make sure that when monitoring catches something, reversing it is a button and not a project. This is not hypothetical. In mid-2025 an AI coding agent at Replit wiped a user's production database during an explicit code freeze, then reported that recovery was impossible. The rollback worked anyway. The agent misbehaving was never the interesting part, because it always will. The story ends well only because someone had built a reversal path the agent could not talk them out of.

Agentic-era verification: not “more tests.”

Here’s where agents change the shape of the problem, not just the speed of it. And it’s the part most teams get backwards.

When a human wrote the code, reading the code was a reasonable way to trust it. Slow, but reasonable. When an agent writes it, and writes it faster than anyone can keep up with, reading stops being a plan and turns into a bottleneck with good intentions. So here’s the definition I find useful: verification is whatever lets us trust the code is correct without sitting down and reading it. If a check still needs a person to scan the diff, that’s review, not verification, and review is the exact thing that broke the moment the agent started outrunning the reader.

The trap most teams fall into is answering “we need more verification” with “we’ll have the agent write more tests.” An agent that writes both the code and the tests can produce a beautifully green test suite by construction. It’s grading its own homework. The tests pass because they were written to pass, and you’ve bought yourself confidence that correlates with nothing. Real verification encodes intent independently of the implementation, the way an auditor reconciles against a separate set of books rather than re-reading the bookkeeper’s entries.

In practice that means a stack of layered filters, each one independent of the code under test, each one more expensive than the last. The point is to catch every failure at the cheapest layer that can catch it, and to make the expensive layers a last resort rather than a first line:

Types and contracts. Encode the domain invariants so the illegal states can’t be represented in the first place. A sufficiently expressive type system catches whole categories of error before the agent ever opens a pull request. This is the cheapest place to catch a defect and the one teams most often underbuild, which is backwards: a failure caught here costs almost nothing, and the same failure caught in production costs a customer.

Property-based testing. Instead of checking specific input-output pairs, which an agent can memorize and satisfy, you assert the general properties that must hold across a large range of generated inputs. Outputs stay sorted. Operations remain reversible. A balance never goes negative. Properties capture intent in a way example tests don’t, and they surface the edge cases no one thought to write down, exactly where the expensive failures live. Teams using property-based testing regularly report catching subtle violations (for example, an edit-distance function that broke the triangle inequality, or serialization logic that corrupted edge cases like -0.0 or empty structures) that traditional example tests missed entirely.

Contract and integration tests at the seams. Most real failures happen at boundaries, where one component’s assumptions meet another’s. Machine-checkable contracts at those boundaries mean a change on one side immediately lights up the inconsistency on the other, without a human holding both sides in their head. For the business, that is the difference between catching an integration break in minutes and discovering it as an outage after two teams have shipped against incompatible assumptions.

Production verification and observability. The highest-fidelity signal comes from real outcomes on real data. Detailed logging, metrics tied to business results rather than system health alone, alerting on symptoms, and a rollback path you can pull fast. As velocity climbs, how quickly you can detect and reverse a bad change becomes part of verification itself, not an operations footnote. This is the layer a leader feels directly: it is the gap between a bad release that costs an hour and one that costs a quarter’s reputation.

The thread through all four is that none of them depend on a person reading the code, and each one catches a class of failure earlier, and therefore cheaper, than a human scanning a diff ever would. Build the stack and the cost to verify a change falls, throughput rises, and the people you have are freed for the judgment calls a machine can’t make.

The human in the loop.

None of this gets rid of people. It changes where they’re worth putting.

Uniform review of every change made sense when changes arrived at human writing speed. In the Agentic Development Lifecycle, attention has to route by risk instead of by habit. Core business logic, irreversible actions, money movement, anything at a high-stakes boundary: that gets deep human scrutiny, every time. A well-covered, easily reversible change to a low-blast-radius corner can ride on machine verification and ship. Treating those two cases the same way, which is what “review everything” quietly does, spends your scarcest resource on the changes that need it least.

Governance has to make the same move, and this is the harder sell, because governance bodies are built around a finish line. The fix is not to disband the committee. It is to change what the committee meets about. A phase gate that approves a system once and files the matter closed is watching the wrong thing, since the system it blessed is already drifting away from the version that got blessed. So redesign the cadence. The standing question is no longer “did it pass,” asked once at launch. It is “is it still passing, and how long before we’d know if it stopped,” asked on a schedule for as long as the system is making decisions that matter. That turns the review board from a body that signs off and disbands into one that owns an ongoing answer to “is it working,” which is the question the business was asking all along. The board does not produce that answer by meeting. The instrumentation produces it. The board’s job is to read the instrument and act when it moves.

The number on the wall.

If there’s one metric I’d put on the wall, it’s the cost to verify a single change. Almost no one tracks it, and in the agentic era it’s the number that governs everything.

The logic is unforgiving. When generation is cheap and verification is expensive, everything the agent produces piles up behind the verification step, because that’s the part that didn’t get faster. You sped up the half that was never really the constraint and left the real one sitting right where it was. The teams getting real return out of agents are the ones grinding the cost to verify down, because that’s the valve that controls how much ever ships. Make generation cheaper without touching verification and you haven’t bought speed, you’ve just grown the line waiting to be checked.

What moves the number is where the failure gets caught. A defect stopped by a type costs almost nothing. The same defect found in production costs a customer, an incident, and the hours of three people reconstructing what happened. So the number falls when you push checks left, toward the cheap end of the stack, and it falls again when the failures that do reach production can be reversed in seconds instead of triaged for a week. Catch it early, and when you miss, reverse it fast. That is the whole game.

This quietly rewrites what a strong engineer is worth. The skill that’s appreciating isn’t typing speed or fluent syntax, both of which the agent now does for free. It’s the ability to state correctness as invariants and properties, to design systems that are observable and checkable by construction, and to make a clean-eyed call about which changes carry real risk. Deep systems thinking, the kind that holds the architecture and the failure modes in view at the same time, is worth more in this world, not less. The engineers whose main contribution was producing implementation quickly are the ones this shift pressures, and that’s worth saying plainly rather than dressing up. The work is moving from writing the code to defining what correct means and proving the code meets it.

The limits of verification.

I want to be honest about the limits, because a piece like this can read as if verification is a machine you switch on so you can stop thinking.

It isn’t. Verification tells you the system does what you specified. It cannot tell you whether you specified the right thing. Whether the feature is worth building, whether a requirement nobody wrote down is about to matter, whether there’s an ethical edge to this that no property test will ever catch, whether the high-level architectural bet is sound: those stay human. The point of the verification stack isn’t to remove people. It’s to shrink the set of questions that require a person down to the ones that genuinely do, and then make sure a person is looking at those.

And building the stack is real investment. Types, contracts, property tests, observability: the teams that treated those as core infrastructure are about to look prescient, and the ones that filed them under “overhead, we’ll get to it” are going to hit their failures at the same speed the agents gave them on everything else. Going faster doesn’t sort the good changes from the bad ones. It just gets you to both of them sooner, and if nothing independent is doing the checking, the place you find out about the bad ones is production.

Verification also has its own cost. A check that runs forever and never catches anything is not safety, it is overhead, and it pushes the cost to verify back up, which is the one number you were trying to bring down. The goal is not the longest possible list of gates. It is the stack that earns its weight: each layer there because it catches a class of failure that would otherwise reach production, and the ones that don’t earn their keep cut without ceremony.

Somewhere in most of these organizations is a person who already knows this. An engineer watching a metric soften week over week, or staring at a flood of agent-generated diffs they have no realistic way to read, who can feel that the old way of trusting code has quietly stopped working. They usually have nowhere to take it, because the governance forum is organized around approvals and the review process assumes a human can keep up. Giving that person somewhere to take it, a stack that does the reading they no longer can and a cadence that hears “it’s drifting” as a real event, is most of the job.

In closing.

The SDLC was a strong model for the world it was built for: fixed specs, deterministic behavior, stable ground underfoot. Agentic and AI systems don’t offer any of those. The behavior emerges, the data won’t hold still, and the proof decays on its own schedule. Running a deterministic assurance model over that reality doesn’t make the risk go away. It just hides it until something drags it into the open.

The organizations that come out of this ahead won’t be the ones generating the most code, because generating code is the part that got cheap. They’ll be the ones who treated verification as a layered, independent, machine-checkable discipline, and validation as something you keep earning from production signals for as long as the system is in use.

There's no done. I said that last time and I meant it. The agentic version is sharper: there's no validated-and-walk-away, and there's no verified-by-reading-it anymore either. It is closer to walking a fence line. The fence passed the day it went up, the ground has been moving ever since, and the only way to know it still holds is to go walk it again. Nobody files a ticket when a post rots. Trust has to be built into the system and maintained for as long as it's making decisions that matter. The teams that learn to specify intent precisely and verify it independently are the ones who will define what comes after the SDLC.

Sources: IEEE Std 1012, Standard for System, Software, and Hardware Verification and Validation. Sculley et al., “Hidden Technical Debt in Machine Learning Systems,” NeurIPS 2015.

On October 9, 2025, Figure AI released a six-minute video of its Figure 03 robot folding laundry, loading a dishwasher, pressing the buttons on a washing machine, and tossing a ball to a family dog. It went on the cover of TIME’s Best Inventions issue. The official YouTube cut crossed 5.5 million views. The clips ran on every tech feed I follow for about a week.

The robot is not going into homes. Figure’s CEO told TIME, in the same piece, that the Figure 03 would not be ready for domestic use at launch and that getting there would be “a big push.” TIME’s own reporter watched the prototype drop laundry on the floor twice in a row.

A few hundred miles south, a different Figure robot had spent the previous ten months on the production line at BMW’s Spartanburg, South Carolina plant, placing sheet metal parts into welding fixtures. It contributed to more than 30,000 vehicles. You can find one news story about it if you go looking. It did not trend.

This is precisely the categorization problem. The word “humanoid” is being used to describe two machines from the same company, doing two completely different jobs, with two completely different deployment paths, and the conversation treats them as the same thing. They are not the same thing. Not even close.

Four categories

Almost everything that gets called a “humanoid robot” in 2026 falls into one of four buckets. The buckets have different buyers, different physics, different software stacks, and different timelines. Conflating them is confusing everyone.

Bipedal logistics movers. Robots that walk on two legs through structured warehouse or factory environments, moving totes, bins, and parts between fixed points. Agility Robotics’ Digit at GXO and Amazon warehouses. Apptronik’s Apollo doing lineside delivery for Mercedes (25 kg components to specific workstations on a schedule). The work is repetitive, the environment is mapped, the failure modes are well understood. This is the most boring category and by some margin the most real.

Fixed-station manipulators in humanoid form. Robots in human shape doing one or two well-defined manipulation tasks at a fixed station, alongside or in place of a human worker on a structured line. Figure 02 at BMW Spartanburg. Tesla Optimus on Tesla factory floors. The “humanoid” part is mostly a cost argument: the workstation was designed for a person, so a person-shaped machine doesn’t require a line redesign. This category is legitimate, and most enterprise pilots are this category once you read past the press release.

Mobile manipulators for unstructured environments. Robots intended to walk through messy human spaces and do open-ended tasks. The home robot. The hospital robot. The mixed-use facility robot. This is what the Figure 03 demo video is selling, what 1X’s NEO ad copy is selling, and what the cover of TIME implied was a 2025 reality. It is not a 2025 reality, and on the evidence available it is not a 2026 reality either.

Teleoperated robots in autonomy clothing. Bipedal manipulators in homes or facilities where a remote human operator is doing the actual cognitive work, and the robot is providing the body. NEO Gamma’s “Expert Mode” is a good example. WSJ’s Joanna Stern, after a hands-on demonstration, reported she “didn’t see Neo do anything autonomously”; every action was driven by a skilled remote pilot named Turing. 1X has been refreshingly honest about this. The launch material describes the model as “autonomous + call for human assistance when NEO can’t do a task, like how Waymo is operated & supervised.” That is a fair description of the technology. It is also a different product than the demo videos make it look.

A fifth thing happens on top of these four, and it is not a category of machine but a category of marketing: the AI in a body pitch. The framing is that a sufficiently large foundation model, dropped into any plausibly humanoid chassis, will produce general-purpose competence. The investor presentations require this framing even though the technical evidence does not yet support it. I am keeping it separate because it is a story about funding rounds, not a story about deployments.

Which of these can you buy in the next 24 months

Buckets one and two: yes. With caveats, but yes. Apptronik raised $520 million in February 2026 at a $5 billion valuation and is shipping into Mercedes and GXO. Agility’s RoboFab facility is scaling from hundreds to thousands of Digit units. Figure has BMW. Apollo will build Apollo at Jabil. The procurement story for these is much closer to “industrial automation with a different form factor” than to “general-purpose robot.” It looks more like buying a sortation system than buying a coworker.

Bucket three: no. Not at any scale that justifies a serious budget line in your 2026 or 2027 plan. The technology is interesting, the progress is there, and Figure 03 in three years may be even more interesting. But if you are a CIO or COO being pitched on humanoids that will work in unstructured environments inside your business in the next two years, you are being pitched aspiration.

Bucket four: this one is trickier. You can buy NEO today, for $20,000 or $499 a month. What you get, in 2026, is mostly a teleoperated robot whose autonomous mode is improving in the background while you and a remote 1X operator do the work together. That may be a defensible thing to buy if you understand it for what it is. It is not a defensible thing to buy if you thought you were buying bucket three.

Why the conflation persists

The conflation is not an accident.

It serves founders raising at $5 billion valuations on the implicit promise that a single platform will handle warehouses, factories, eldercare, and homes. The conflation is the whole pitch. Tease the household demo, sell the factory pilot, raise on the implied path between them.

It serves journalists and analysts whose engagement numbers reward the household demo and punish the welding-fixture deployment. A robot folding laundry beats a robot bolting sheet metal every time, even when the second one is the deployment story.

It serves consultants and analysts selling forecasts that treat “the humanoid market” as one $200 billion line by 2035. The number is large because it bundles four very different markets together and assumes they will all materialize on the optimistic timeline of the loudest one.

The people it does not serve are plant operators. Procurement teams scoping pilots. Workforce-planning teams modeling what to do with the line workers whose stations might be automated in the next thirty-six months. CFOs trying to figure out whether to put a number in the 2027 plan or the 2030 plan. Every one of these decisions gets worse when “humanoid” means four different things in the same sentence.

It also does not serve the workers inside those decisions. A line worker at a Spartanburg plant has a different conversation with their family if the honest framing is “a fixed-station manipulator is being trialed for sheet-metal placement on my line, here are the three jobs that are most exposed, and here is the retraining we’re doing in the next six months.” That conversation is hard but it is grounded. The conversation “a humanoid robot is coming for my job” is neither hard nor grounded.

The vocabulary I’m going to use

For the rest of this series, when I say “humanoid” I will mean one of four things, and I will say which:

• Bipedal logistics mover for the Digit-and-Apollo-in-warehouse case.

• Humanoid-form station manipulator for the Figure-02-at-BMW case.

• Mobile manipulator for unstructured environments for the home-robot aspiration. (No good short name has stuck yet. The fact that the marketing category is bigger than the engineering category is part of the problem.)

• Teleoperated humanoid for the NEO-and-Expert-Mode case, with the understanding that the autonomy will increase over time and the category may eventually graduate into one of the others.

These are not branded terms and I am not going to defend them past the next person who proposes a better one. The point is to have four words instead of one. If a vendor pitch can’t be placed cleanly in one of the four, that is telling about the pitch.

The Figure 03 video is a beautiful piece of marketing about a real research program. The BMW Spartanburg deployment is an unbeautiful piece of industrial automation that is already inside a building making your next SUV. Both of these are true. They are different categories. Calling them by the same word is how operators end up writing checks against the wrong timeline.

I’ve been turning 43 over and over in my head for weeks. Maybe it’s the 15-month-old who’ll see me almost 70 by the time he’s off the payroll. Maybe it’s the daily death-defying stunt of walking down the stairs. Maybe it’s the harsh realization that I’m no longer the young, ambitious professional I once was, and not just some mid-career guy either. Whatever it is, it’s hitting hard.

So I’ve been taking a look back at the non-linear path that got me from the Class of ‘00 to Head of Strategy and Modernization at The Select Group. That’s the theme of this month’s newsletter: looking back to understand the path forward.

Enjoy.
-AM

Anger fueled motivation.

I spent most of high school caught between the things I was interested in (motocross, BMX, writing code) and a string of teachers and counselors telling me I was too dumb to carry lumber on a job site. Seriously. That is what my HS guidance counselor told me. A lot of kids I grew up with never reached their potential because they believed what those people said. Me, it pissed me off.

By the time my Pennsylvania-mandated Senior Project came around, I had a chip on my shoulder, and it stayed there for a lot of years.

By the time I graduated I had already built one startup (16327Online, a dial-up internet service provider and web design studio), was building my second (Carzz, a platform that let auto dealers manage inventory on their websites), and was running an early motocross eZine with my friend Grant called MotoXtreme.com.

This phase took me through Edinboro University, 18 months in Phoenix, and a summer in Minneapolis. It taught me that anger can be a powerful motivating force, and that nobody can or should put limitations on what you’re capable of. Most importantly, that you should never put limits on yourself.

Skipped: the car business, cross-country roadtrips, lifelong friends.

Nobody is coming to save you.

After Minneapolis I went back to Pennsylvania to help my dad get ready to sell my childhood home. By then I’d made an exit from Carzz and was struggling with what to do next.

I distinctly remember sitting in church one Sunday, and the moment I asked God for a sign of what should be next, a vivid image popped into my head: US Army. I signed the contract that Thursday.

The next several years were an intense motion of training, train-up, and deployment that didn’t slow down until I was sitting in a hospital bed in Baghdad following a failed assassination attempt.

In about two hours I had gone from a man with a purpose and friends to being absolutely alone. I came home alone. I recovered alone.

It was in the months following my injury that I realized nobody owed me anything. If I wanted to get through what I was facing, the only person I could count on was myself. I had to reinvent. That’s a lesson I carry to this day: you are responsible for your circumstances, and only you can change them.

Skipped: homelessness, fuzzy nights in Savannah, managing up.

It’s not what you know, it’s who trusts you.

Facing medical retirement in Savannah with a new mortgage, I had a fast-approaching deadline to figure out “what’s next?” I went back to the only other thing I knew: software.

To this day I’ll never know why the recruiter from VeriSign pulled my thin resume from the stack, but I’m glad she did. I interviewed with Bill Holliday and Doug Winters, and the offer Bill made me saved my life. It was my path out of the dark hole I was in, and the beginning of an interesting non-linear career.

Engineer, to engineering manager, to consulting company founder, to Global Product Lead of Military and Law Enforcement at Under Armour (that’s still a WTF moment for me, but the most culturally significant part of my career). The seven years following the moment life slowed down in that Baghdad hospital bed were a whirlwind of people, relationships, and learning.

The most important takeaway from the first time I met Bill, until Adam Silva introduced me to Brian Offutt and Kip Fulks at Under Armour, was this: it’s not what you know, it’s who trusts you. If people trust you to perform with integrity, they will give you an opportunity.

Skipped: lessons in real estate, fashion boutiques, boat ownership, early online dating.

Trust and influence open doors.

After the Under Armour detour I went back to building and back to consulting. This time, things looked a little different. Based in Nashville, I served as a Product and Technology consultant and built a pretty good practice. One thing led to another and I found myself in a series of rollups: Davisbase Consulting, SolutionsIQ, eventually Accenture. I finally got off the acquisition bus through an invitation from Scaled Agile.

During this 12-year phase I helped a lot of companies solve some very big problems, helped others find themselves professionally and build amazing careers, and found my footing as a technology thought leader and speaker.

How did a kid who was too dumb to carry lumber on a job site end up keynoting a technology conference in Paris? When you push yourself, put yourself out there, and consistently deliver what you promise, you build a reputation. The reputation builds trust. The trust gives you influence. And influence is what opens the doors you couldn’t have knocked on yourself.

“Earn it everyday.” Maybe I had a hunch.

Skipped: trail running, when PE comes to town, international (business)man of mystery.

Family is all that matters.

Through all of this I have made no mention of relationships or family. That’s because through all of the learning and growth I outlined, I was absolutely horrible at personal relationships. Probably the worst you’ve ever seen. I was so busy trying to prove myself that if anyone stood in the way of the path forward, I ruthlessly cut them from my life.

Jenelle helped change that pattern. She has been my rock, partner, and best friend over the last 9 years. What made it work in the early years was that while building our relationship, we maintained our independent trajectories.

COVID brought us to Raleigh, and things started to shift. We became much less focused on what we wanted as individuals and much more focused on what we wanted as a couple, and as a legacy. We lost our little girl in early 2023, and the grief was the first thing in 20 years that I could not outwork. Through a ton of very hard work medically and emotionally, we welcomed Ford Michael into our family in February 2025, and everything changed.

After Ford was born I went almost immediately on an 8-month rotation of international travel. The travel that had previously made me feel alive was now weighing heavy on my heart. By the time October and my sabbatical came around, I knew I had to make a change. The stress and the travel were no longer “it,” and for the first time in my professional career I didn’t have a plan or a path. And that was ok.

I jumped without looking, because nothing mattered more than Jenelle and Ford.

Skipped: Family vacations, a cycling venture, too many cars.

Looking back to look ahead.

Thank you for entertaining the thought experiment, and thank you for making it this far.

The five lessons I pulled out walking through these 20 years are not separate lessons. They are the same lesson at different ages.

The chip on my shoulder taught me not to let other people define what I’m capable of. Baghdad taught me not to wait for anyone to save me. VeriSign taught me that trust is currency. Nashville taught me that trust compounds into influence. Jenelle and Ford taught me what all of it is for.

You are the only person who gets to decide what your life is in service of. Nobody is going to hand you a plan, and nobody is coming to tell you that you’ve earned it. Nobody owes you the next opportunity. And once you accept that, the freedom on the other side is the whole point.

My goal from here is simple: I want Ford to know that his mom and dad always have his back. I want him to make all new mistakes, not the ones I already made for him. I want him to understand what it means to be free, and how to earn it. And I want to be there, every time, when he calls.

Everything I do professionally from here serves that goal.

Cheers!
-AM

When most people hear “humanoid robot,” the picture in their head is typically from a movie. Terminator. iRobot. Ex Machina. The humanoid is uncanny, capable, and either a threat or a friend, depending on the studio. The pitch from the loudest humanoid companies in 2025 is not far off that picture: an artificial general-purpose worker, in your home within a decade, on the factory floor sooner than that.

When a business reader who pays attention to industrial technology hears “humanoid robot,” the picture shifts. It is Figure’s robot, the one in the press releases, working alongside humans on a BMW production line in Spartanburg, South Carolina. It is Apptronik’s Apollo at Mercedes. It is a real machine, in a real factory, building a car a reader can picture buying. The story has moved from science fiction into something that sounds like industrial reality.

When an enterprise leader hears “humanoid robot,” the picture shifts again, and it gets smaller. The BMW and Mercedes deployments are real, and disclosure on the BMW program has now opened up: Figure and BMW have jointly released a single set of headline numbers from an 11-month Spartanburg pilot, roughly 90,000 sheet-metal parts loaded across about 1,250 operational hours, contributing to production of more than 30,000 BMW X3 vehicles. That is real progress. It is also a single coordinated vendor-customer disclosure, with no named integrator, no support contract terms, no multi-site data, and no customer-initiated reporting outside the joint announcement.

The deployment that does have customer-initiated reporting, named site, and multi-month throughput is Agility Robotics’ Digit, moving 100,000 plastic totes inside a fenced area at a GXO warehouse in Flowery Branch, Georgia. Those are the two publicly disclosed humanoid deployment stories in the world today with meaningful throughput numbers attached. Almost nobody outside the trade press is talking about either of them in detail.

These are three pictures of the same field. The general reader sees the Terminator. The business reader sees the Figure on the BMW line. The curious business person sees the Digit moving totes at GXO. They are all looking at the same industry, in the same year, and the gap between the three pictures is the most important thing about humanoid robots right now. My goal with this series is to begin to close that gap.

This is week two. Last week I said the post would be about what I read, what I noticed, and at least one disagreement called by name. The five sources that I dug into this week are:

1. Rodney Brooks’s blog, specifically his September 26 essay “Why Today’s Humanoids Won’t Learn Dexterity,” plus a Brian Heater interview where Brooks tells a story about a humanoid falling on its face at a cocktail party while two people across the room debated whether to push it over.

2. Agility Robotics’ November 2025 announcement about the GXO 100,000-totes milestone.

3. GXO’s 2025 annual report, where the word “humanoid” appears far less often than the analyst coverage of GXO would suggest it should.

4. Brett Adcock’s Time interview from October 2025.

5. A long-form interview with Adcock on the Shawn Ryan podcast, where he describes Figure’s separation from OpenAI in some detail.

A few things stood out.

The conversation.

The conversation, for the most part, is between vendors and the people who fund them. The most-cited content is capability demos, founder interviews, funding announcements, and analyst forecasts based heavily on the founder interviews. The vocabulary is “general-purpose,” “embodied AI,” “scaling laws for robotics,” “the foundation model moment for physical work.” The story arc is: capability is improving fast, demos are getting more impressive, mass adoption follows.

What the conversation is mostly not about: who deploys these things, what happens when one of them fails, what the integration looks like, what the support contract looks like, who insures the thing, what the data architecture looks like in production, what a fleet of them costs to run.

If you have watched any other enterprise technology wave from up close, you know the shape of this. The capability story is loud because capability sells the round. The deployment story is quiet because deployment is hard, slow, and unflattering to a vendor narrative built on near-term inevitability. I am not saying anything controversial by pointing this out. I am saying that an executive reading the humanoid discourse over the past several months has been reading the exciting half of a story whose messy half will eventually matter much more. The general reader is mostly reading only the exciting half.

The deployment evidence.

The Agility/GXO 100,000-totes story is the closest thing the field has to a customer-led deployment milestone right now. Named customer, named site, throughput number, multi-month operation. The report surfaced for two days in the trade press and disappeared.

Adcock saying “every home will have a humanoid within ten years” surfaced for two weeks.

I want to be careful about the gap I am highlighting here, because it is the most important thing in this post and I do not want to overstate it. The capability evidence in the field has improved continuously and dramatically. The deployment evidence has improved much more slowly. As of now, there are two humanoid programs with public, named-customer, multi-month operational data and meaningful throughput numbers: Digit at GXO and Figure at BMW. The GXO disclosure is customer-led and ongoing. The BMW disclosure is a single joint vendor-customer release of headline numbers from a defined pilot window. Both count. They do not count equally.

Apptronik has Mercedes signaled, with much less operational disclosure than either. Tesla Optimus has internal Tesla, which is a different kind of evidence and gets its own treatment below. Everything else is a video, and let’s face it, AI videos are pretty good now.

So the capability curve and the deployment curve are not the same curve, and most of what is being written conflates them. That conflation is doing work for the vendors and against the reader. A capability demo answers the question “could this machine, in principle, do this task?” A deployment answers the question “is this machine, in production, doing this task today, reliably, for someone who didn’t build it?” Those are different questions, and the field is treating answers to the first as evidence for the second.

The two curves diverge for reasons that anyone who has run an enterprise rollout will recognize. A controlled environment is not an operational environment. A scripted task is not a mission. Supervised operation is not autonomous operation. A six-week demo timeline is not a three-year production timeline. The list goes on, and every item on it eats months. The deployment curve looks slow because deployment is, in the literal physical sense, slow. The capability curve looks fast because demos are, in the literal physical sense, cheap.

The disagreement.

Brett Adcock said in Time that every home will have a humanoid within ten years, and he has said variants of this many times. Rodney Brooks has said the opposite, in detail, with technical specificity, citing forty years of trying to build robots that could do what humans do with their hands, and his claim is that the path the current generation of humanoid companies is on does not get there.

I think Brooks is much closer to right, and I think instinct supports him. Not because he is more famous, or because skepticism is the safer bet, or because forecasts that far out are usually wrong (they are). Because the specific reasons he names are the reasons enterprise deployments fail.

The dexterity problem is the difference between a demo and a job. A robot that can pick a single object off a single table in a single lighting condition under a single instruction is not a robot that can work a shift. The dexterity gap is not “almost there”; it is, by Brooks’s argument, structurally not on the trajectory that the current investment thesis assumes.

The data problem is the difference between a robot that worked once and a robot that works tomorrow. Every humanoid in production produces continuous high-bandwidth multimodal data. The pipelines, the storage, the labeling, the model retraining, the governance: none of that exists at the level the vendor pitch requires, and the silence around it in the founder narratives is its own data point.

The safety problem is not an abstraction either. The Figure whistleblower lawsuit filed in November alleges that Figure’s robot can produce more than enough force to fracture a human skull, that the safety roadmap presented to investors was quietly scaled back after the round closed, and that the engineer who flagged it was fired. I have no view on the merits of the suit. I have a strong view that any enterprise looking at human-adjacent humanoid deployment reads that filing and slows down. The discourse has mostly not slowed down, which tells you what the discourse is currently for.

The household pitch.

The most exciting version of the humanoid story is the humanoid in the kitchen.

Brett Adcock has said many times that every home will have a humanoid within ten years. 1X has announced a consumer humanoid called Neo, pitched for in-home use at around $20,000 or a $499-per-month subscription, squarely aimed at early adopters. Elon Musk has put Optimus at the center of Tesla’s long-term valuation story, with Musk repeatedly suggesting consumer pricing in the low five figures, cheaper than a typical Tesla car, and a stated ambition that Optimus eventually becomes a larger business for Tesla than cars. Whatever you think of those claims, they are the part of the humanoid pitch that has captured the most public imagination, the most retail-investor attention, and the most political airtime.

The household pitch deserves to be reviewed, and then positioned accurately.

There is a long-run argument for consumer humanoids. Developed-country demographics are aging and eldercare labor is in structural shortage in every major economy. Component costs in robotics have fallen and will continue falling. The household, in some sense, represents the largest total addressable market for a general-purpose physical machine. None of that is crazy.

Placed accurately, the gap between the household pitch and any plausible household deployment is even larger than the gap between the factory pitch and any plausible factory deployment, and that gap is already quite large. The factory case has two publicly disclosed multi-month deployments, one customer-led and one vendor-coordinated. The household case has zero. It has consumer announcements, preorder pages, demo videos, and pricing claims. It does not have a single named consumer with a humanoid working unsupervised in their home over a meaningful period, doing meaningful work, with any disclosure of how often the machine fails, how it is supported, who fixes it when it breaks, what happens when it falls on a child or a pet, or how the data it generates is governed.

The home, from a deployment perspective, is a much harder environment than the factory. A factory is engineered, the lighting is controlled, the surfaces are predictable. The humans on the floor have been trained on safety protocols, there is a maintenance team on site. A home has none of that. A home has a toddler, a dog, a staircase with an unusual carpet, a kitchen island the homeowner moved last week, and an internet connection that drops twice a day. The capability gap between “this machine works in a Tesla plant” and “this machine works in a Tesla owner’s house” represents an entirely different problem.

Tesla is the place this gets most interesting, because Tesla is the only humanoid program whose entire strategy is built around skipping the third-party deployment phase. Figure, Agility, and Apptronik need named industrial customers to validate their machines. Tesla does not. Tesla builds Optimus, deploys it in Tesla factories building Teslas, and points to that as both the proof and the product. The consumer story comes later, on a timeline Tesla controls, with no integrator ecosystem to build because Tesla owns both ends.

That is a coherent strategy, but also a strategy with a specific blind spot. A humanoid that works in a Tesla plant has been trained in, designed for, and supported by the most controlled, vertically integrated industrial environment in modern American manufacturing. What that tells us about whether the same machine works in someone else's factory, let alone someone's home, is not much. Tesla’s vertical integration is the source of its execution speed and the reason its deployment claims are the hardest to evaluate from the outside. The same property that lets Tesla iterate fastest is the property that makes the iteration least informative about anyone else’s environment.

So, the household pitch is a category. The consumer humanoid is a coherent long-term market. Tesla is doing something structurally different from the other vendors, but none of that changes the read of the evidence. The near-term deployment evidence is two industrial humanoid programs, one customer-led at GXO and one vendor-coordinated at BMW. The household humanoid in your kitchen, on the timeline being pitched, is a different conversation, on different evidence, that the discourse is currently treating as though it were the same conversation.

It is not the same conversation. It is a Grand Canyon sized gap.

What I keep thinking about.

In the Brian Heater interview, Brooks said: “Very few executives at humanoid companies have ever deployed robots.” I wonder if they have ever deployed anything to the enterprise. I don’t say that to be catty, but it’s an honest question from someone who has made a career of doing just that.

The companies raising the largest rounds are run by people who have not lived through what it takes to keep an asset in production, in someone else’s facility, with their name on the support contract. They have not been on a 2 a.m. call about a unit that won’t restart. They have not been in the procurement review where the deployed cost comes in at multiples of the unit price. They have not been in the safety meeting where the customer’s operations leader says no, you don’t get to put that thing next to my people until I see your failure-mode documentation, and the response is a slide deck that doesn’t have one.

That does not mean these founders are wrong about everything. It means that the operating model knowledge that makes a deployment work at scale is mostly not in the room when these companies are pricing pilots. It means that the gap between capability and deployment is not just technical in nature, but a gap in lived experience inside the companies building the technology.

If you have been around a technical revolution or two, you will recognize this pattern. The vendor who has never run the system at production scale prices the pilot like a demo, scopes the support like a SaaS contract, and discovers eighteen months later that the customer’s operations team has built an entire side organization just to keep the thing running. The vendor’s term for this is “implementation challenges.” The customer’s term for it is “the pilot graveyard.”

What I think I can write about usefully

This is the part of the field that the public conversation is missing, and it is the part I think I can write about usefully. Not because I know more about robotics than the people building them. I absolutely do not.

What I do know better than most is how enterprise technology gets deployed and adopted. I have watched the path from “capability demonstrated” to “asset producing reliable value in someone else’s operation” enough times to recognize when a story is telling me about the first half of that path and asking me to imagine the second.

The founder narratives, almost by construction, are not equipped to tell the deployment half of the story. The analysts are mostly downstream of the founders, and the trade press is downstream of both. The professionals who could tell that half of the story are mostly inside enterprises or large consulting firms, are mostly not writing, and when they do write, it is mostly in private channels.

So that is the part I am going to keep watching. Not the demos, the deployments. The integration contracts, support models, data architecture, safety cases, the fleet management software. The total cost past the unit price, the change management. The things that, in every previous enterprise technology wave, turned out to be where the value was either captured or destroyed.

What’s next.

Next week I want to spend time on what “humanoid” is doing as a category, because the word is being asked to cover four or five very different machines and the conflation is making the conversation convoluted. A bipedal logistics robot moving totes inside a fenced area is not the same machine, the same buyer, or the same timeline as a humanoid-form mobile manipulation robot working alongside humans on a factory line, which is not the same as a teleoperated training-mode unit, which is not the same as a defense-application humanoid (a category that deserves its own week and will get one), which is not the same as a Tesla-style vertically integrated consumer play, which is not the same as whatever the open-market home-robot pitch is trying to be. The word “humanoid” is being used to cover all of those, and the field is paying for it.

The list of things I want to read for that one is already getting long: vendor product pages from Figure, Agility, Apptronik, 1X, Boston Dynamics, Tesla, Unitree, Fourier; the IEEE Spectrum coverage of the category; the latest Brooks predictions essay.

One ask before I close.

If anyone reading this knows of a deployment story, in any humanoid program, with named customer, named site, and operational throughput numbers I have not already mentioned here, I would like to read it. Right now my list has two entries on it, one customer-led and one vendor-coordinated. That is part of the story.

Views are personal and do not represent any employer, past or present.

I have spent the majority of my career helping enterprises learn how to operationalize the next “big thing” in pursuit of their strategic and financial goals. That has often meant rethinking how work is orchestrated, how products are built, and how markets are engaged and scaled. The bleeding edge of operationalized technology, which is a more boring place than the bleeding edge of technology itself, refers to the technologies that have been embraced by the early adopters and are ready to cross Geoffrey Moore’s proverbial chasm to be picked up by the majority that follows. In this space, someone has to figure out who owns the asset, who fixes it at 2 a.m., who signs the safety attestation, how to orchestrate change so the people living in the status quo do not reject the new tool, and how to be compliant before the regulators have even drafted the rules. For the last twenty years, I have built a career around solving these problems for the early adopters, paving the way for the majority that follows.

The next big opportunity and challenge in that space is autonomous robotics and humanoids.

Some may see “humanoid” and react with thoughts of science fiction and a future that will never come. If that’s you, let me be the first to shine light on what may be an uncomfortable reality: the robots are coming, and fast. In fact, in areas, they’re already here. The pilots are running in companies you know, the governance committees exist, the disappointment is starting to show up in the post-mortems, and the second wave of more grounded use is forming. Humanoids are sitting roughly where generative AI was in 2022. The demos are impressive, the funding is flowing like cheap beer at a frat party, the founder narratives are sweeping, and the gap between what is being said about the field and what enterprises will actually have to do with it is the widest it will be for the rest of the cycle.

That gap is where I thrive and what I’ll be learning about over the next several months. I have decided to make that journey public, and I hope that you’ll be interested in learning alongside me.

I should be honest about where I’m focused and where I’m not. I am a used-to-be software and systems engineer, and I lead an enterprise strategy and modernization practice for a mid-tier consulting firm. My day job is helping large organizations change how they operate, adopt new technology, and make those changes work with legacy systems, compliance and regulatory regimes, and human behavior. I have a broad view of how technology gets bought, deployed, and either survives or does not across industries, enterprise scale, and geography.

I am not a roboticist. I do not build hardware. I do not work on AI model internals. The people who do those things will be the source of my research. I will be reading them, not pretending to be them. My contribution is the part that visionaries tend to undersell: how decisions get made inside a Fortune 500, how workflows need to evolve to maximize the return of new technologies, developing change strategies so that new initiatives don’t die the minute things get hard; essentially, ensuring that new technology survives contact with operational reality.

The reason I want to start now, and not in two years when the case studies get sanitized, is that the early framing of a technology cycle tends to set the terms of the later debate. If the only voices in the room during the orientation phase are vendors and roboticists, the questions enterprises end up asking later get shaped by people who have never had to write a deployment readiness review. I would like there to be at least one voice in the early record preparing the industry for success with enterprise adoption, even if (especially if) that voice gets some things wrong.

Let’s be clear: I will get things wrong. I will break things. I have always broken things. I break things so you don’t have to. This is exploration, not canon. I will be wrong in public. I will publicly update. When I change my mind about something I wrote in week three, I will say so in week eleven, and I will name what changed and why. The implicit deal I want to make with you is that I take the writing seriously enough to be embarrassed by parts of it later, and I will not quietly delete the embarrassing parts. That, and I promise to do the actual writing. It will be sloppy, there will be grammatical errors, but what you won’t get from me is AI slop.

Here are a few things that I am not going to do.

I am not going to make sensational predictions about timelines or how many jobs disappear by what year. The only things worse than AI slop are clickbaity articles and fear mongering. I am not going to take vendor money to write any post in this series. I am not going to act as a marketing channel for any specific company’s robot, even the ones I find interesting. And I am not going to claim expertise I do not have. When I get to a question that requires robotics or AI internals knowledge, I will name the limit and quote someone who knows. I may even ask an expert to co-write with me.

What I will do is read carefully, watch the field, and write to answer questions that an enterprise would want answered if a CIO walked in tomorrow and asked whether to pilot one of these things. I will explore how a humanoid program may get funded, what first experiments could look like, how ROI could be measured, what a first deployment looks like in a warehouse, a plant, or a hospital. How procurement, safety, and labor reshape the pace of adoption. What separates a pilot that scales from a pilot that becomes a permanent demo. I will also discuss what should be monitored at the horizon 3 level, how to move those learnings into a horizon 2 experiment, and how to prepare to extract value from the new tech as it becomes operationalized in horizon 1.

Some of those posts will read like field notes. Some will be reactions to a specific thought that blew up, some will be short-form videos, and others will be questions I cannot yet answer, written down so I have to come back to them.

The field is moving fast, the resistance is already rising, and the people who will eventually have to make real decisions about humanoids are mostly focused on AI and not yet in the conversation. I would like to be a library ready by the time they show up.

-AM

Views are personal and do not represent any employer, past or present.

The first testing engagement I led was in 2009, at the Social Security Administration. The process was straightforward enough. I’d write a test case in a document, validate the test with the engineer, open HP’s QuickTest Pro, walk through the steps, narrate what I was doing and what I expected to happen, and save the recording as evidence that the test had been performed and had passed or failed. If the test needed to be re-run after a code change, I re-recorded the whole thing. Every time, for every test, for an entire year before the contract was done and I ran away as fast as I could.

That was the state of the art in a large federal agency sixteen years ago. I remember thinking, even then, that there had to be a better way. I was right, but the better way took longer to arrive than I would have guessed, and the organizations that were still doing some version of that work in 2020 were not outliers. They were the norm. The truth is, there are just as many organizations running this way in 2026 as there were in 2020, and probably now many fewer than 2009. If I had to guess, the SSA isn’t much better off nearly 20 years later.

I bring this up because the current AI-for-testing conversation tends to skip past the long arc. The conversation I have been having with clients is usually something like “we have an AI mandate from the board, and the CIO thinks we need to start with the manual testing.” What many dev managers are thinking right now is some version of: point the model at the codebase, let it generate tests, watch your manual QA footprint shrink. Too easy, right?

So, here’s the honest version of the problem. The technology is further along than most people give it credit for, even if your organization and dev infrastructure are not. Model-generated unit tests, AI-assisted exploratory testing, self-healing selectors, natural-language test authoring, flake triage, visual regression that doesn’t fall over when a padding value changes by two pixels. All of it works well enough to move numbers in any program. I’ve watched teams cut their manual regression footprint by meaningful percentages inside a single quarter with tooling that was considered experimental eighteen months ago.

And yet most of the dev managers I talk to are sitting in the same spot. They know the capability is available, they know the ask from leadership is founded, and they can’t move forward along a path that feels right. Every time they map the AI capability onto the existing testing practice, one of two things happens. Either (1) they end up with a proposal that looks like replacing the QA team, which they don’t actually want to do and can’t defend politically. Or (2) they end up with a proposal that looks like adding AI tools on top of the existing QA team, which doesn’t change the economics enough to show meaningful ROI.

Getting It Right

A few years ago my team started working with a large logistics company based in Memphis. When we came in, their manual regression process was so heavy that they could only safely release new code about every three years. Three years. For a business whose operations were increasingly dependent on the software keeping up with what the warehouses and the planes and the drivers were doing. The testing wasn’t the only reason for the release cadence, but it was the load-bearing one. Every release required a full manual regression pass, the pass took months, and by the time it was done, the next batch of work had accumulated into another multi-year cycle.

A three-year release cadence wasn’t a testing problem. It was a business problem that manifested as a testing problem.

We’ve been working with them for a while now, and the cadence has come down dramatically. Some teams can even release multiple times a day. Other parts release monthly or weekly depending on risk profile. The manual regression suite still exists, but it’s targeted at the parts of the system where the cost of getting it wrong justifies the time, and everything else is handled through automated pipelines with AI-assisted test generation, triage, and coverage analysis layered in.

The point of that story isn’t the tooling. It’s the compounding cost of not modernizing. Three years between releases wasn’t a testing problem. It was a business problem that manifested as a testing problem, and it took a serious investment in engineering practice, CI/CD discipline, test data management, deliberate reduction of technical and organizational debt, and culture change to unwind. AI was eventually part of the answer, but it was never the whole answer, and it wasn’t even close the first thing we touched.

The Art of Manual Testing

Before you can decide what to automate, you have to be honest about what your manual testers are doing, because the job title “manual tester” covers at least four different jobs.

The first job is executing predictable test scripts. Somebody wrote the script, the tester runs through it, the tester files the defect. This was exactly what I was doing in 2009, and it’s the job most vulnerable to AI. It’s deterministic, it’s repetitive, it’s the thing your QA lead has been trying to automate for five+ years anyway. If this is a large chunk of your manual footprint, you have a ton of opportunity.

The second job is exploratory testing. The tester gets a feature, forms a mental model of what could go wrong, and goes looking for it. This job is not primarily about executing a script. It’s about knowing where to push. AI can support this work, and is starting to generate plausible exploratory scenarios, but the thing that makes a good exploratory tester good is the accumulated judgment about this specific product, this specific customer base, and the specific ways users get themselves into trouble. Replace it with a generic model and you lose the edge cases that only get caught because someone remembers the 2023 incident with the export tool.

The third job is environmental and integration testing. The person who knows that the staging environment’s cache behaves differently from production, that the nightly ETL needs to finish before the API tests run, that the third-party payments sandbox will sometimes just stop working on Thursdays. This is knowledge of the seams, not the code. AI can be taught some of it, given enough observability data, but the person currently doing it is doing it partly through pattern recognition and partly through relationships with the people who run those systems.

The fourth job is the quality conscience of the team. The tester who pushes back in sprint planning. The one who asks “are we sure this is a good idea” before the architectural decision gets locked in. Every team I’ve worked with that had a healthy quality posture had at least one person playing this role, and none of those teams called it out as a role. It just happened.

If you walk into the AI-for-testing conversation without naming which of these four jobs you’re trying to automate, you will end up optimizing the first one, congratulating yourself, and losing ground on the other three without noticing.

This is a modernization failure mode that shows up across every category of work, not just testing. The measurable parts get better. The load-bearing but invisible parts erode.

Where AI Wins

I’ll name the capabilities I’ve seen move the needle in real engagements, with the honest caveat that the list is moving fast enough that any blog post is a lagging indicator.

Generated unit tests for new code, written alongside the developer as they go, are now good enough that most teams should be using them. Coverage goes up, the dev is not pulled out of flow to write them, and the tests themselves are usually fine. The failure mode is that generated tests drift toward testing the implementation rather than the behavior, so you get brittleness if you don’t review with an eye for it.

Generated integration and end-to-end test scaffolding, from a feature description or a user story, is getting close to useful. What the model writes is usually 70 to 85 percent of what you want, and the last bit is fixing the selectors, the timing, and the assertions that only a human familiar with the actual UI will catch. Net time savings are real, but the handoff still matters.

Flaky test triage is one of the clearest wins. Large codebases accumulate flakes the way old houses accumulate small leaks, and manually classifying which ones are product bugs, which ones are environment issues, and which ones are bad tests is a terrible use of senior QA time. AI does this well, and the payoff in signal quality is larger than the payoff in hours.

Visual regression, self-healing locators, and log-based defect clustering have all quietly crossed the threshold from novelty to default. If your current testing stack doesn’t include some version of these, the AI conversation is secondary. Get the fundamentals modern first.

Natural-language test authoring, where a product manager or business analyst can describe a scenario and get a runnable test, sounds further off than it is. I’d caution against rolling it out broadly before the engineering org has a clear opinion on test ownership, because it tends to create tests that are hard to maintain and nobody wants to own.

AI-assisted exploratory testing, where the model proposes edge cases based on the codebase and the requirements, is genuinely useful as a second opinion. It is not a replacement for the human doing the work. It’s a way to stretch what the human covers.

The Bottleneck

I’ve worked on QA practice across a lot of different industries and organizations, and one thing shows up in nearly every engagement: test data. The quality of the test data, the availability of the test data, the speed at which realistic test data can be provisioned into a non-production environment, and the degree to which that data can be trusted to reflect production conditions without leaking sensitive information. This is the bottleneck.

It’s a bottleneck that doesn’t get included in the AI-for-testing pitch, because test data is unglamorous, and because the platforms selling AI test generation mostly assume you already have good data to test against. Most organizations don’t. They have stale snapshots from months ago, partially masked in ways that break referential integrity, sitting in an environment that was last refreshed when somebody cared enough to do it manually.

What this means in practice is that you can generate all the tests you want with AI, and your test pass rate is still going to be dominated by environmental and data issues rather than by actual product behavior. The signal gets drowned out. The QA team spends its time doing forensics on why a test failed, not on whether the product is good.

The encouraging development is that AI is genuinely useful on this problem, and in my view the test data angle is where the next wave of real value is going to come from. Synthetic data generation that preserves the statistical shape and referential relationships of production. Privacy-preserving data synthesis that lets you test realistic scenarios without carrying PII into lower environments. Context-aware subsetting that pulls the slice of production state relevant to the feature you’re testing. Automated drift detection between production and test environments so you find out before your test run that the schema has moved. These are not hypothetical. They are in reasonable shape today and improving quickly.

If I were running a dev org and I had budget for one AI-in-testing initiative this year, and my test data hygiene was typical, I would spend it on test data before I spent it on test generation.

The generation problem is mostly solved. The data problem is the multiplier, and fixing it makes everything else you do downstream better.

A Note on CI/CD

I’ve spent a good amount of time over the last several years working to advance the body of knowledge around CI/CD practices in large enterprises. Contributing to how frameworks think about continuous delivery, what mature CI/CD looks like at scale, and how engineering practices connect to portfolio-level outcomes. Some of that work has shown up in SAFe guidance. Some of it has shown up in the way we serve clients at TSG.

One thing I’ll say from that work, which applies directly to the dev manager reading this post: AI-in-testing is a CI/CD conversation, not a QA tools conversation. The organizations that get the most value from AI-assisted testing are the ones that already have a functioning delivery pipeline. Trunk-based development or something close to it. Operationalized code review practices. Environment parity that isn’t a pipe-dream. Feature toggles that are used in-practice. Observability that lets you catch problems fast when they escape into production. When those fundamentals are in place, AI in the testing layer compounds quality. When they aren’t, AI in the testing layer is a faster way to produce junk, or as my friend Steve Adolph says, “garbage in, landfill out.”

This is why I’m cautious when I see organizations treating AI-for-testing as a discrete initiative, run out of the QA budget, owned by a QA leader. It isn’t a QA initiative, but a delivery modernization initiative that happens to show up most visibly in the testing layer. Framing it that way changes who’s at the table, what the success metrics are, and whether the investment actually produces the economics leadership is expecting.

How It Lands

If you take those four manual jobs and those six AI capabilities and put them in a room, the mix that comes out is not “replace manual testing with AI.” It’s not “keep everything and layer AI on top,” either. It’s something messier and more interesting.

The first manual job, script execution, should largely move to AI-assisted automation over the next twelve to eighteen months if it hasn’t already. This is the part of manual testing that leadership is right to want gone. The work was never the highest use of the people doing it, and it was never a good use of mine in 2009 either.

The second job, exploratory testing, should become a hybrid. Your best exploratory testers get AI tooling that proposes scenarios and runs the routine passes, and their time shifts toward the hard cases, the new features, and the pattern recognition work that the model can’t do. Fewer people doing more valuable work. You’ll likely need fewer exploratory testers than you have today, but the ones who remain should be more senior and better paid.

The third job, environmental and integration testing, needs to be reframed entirely. The manual tester in this role was often carrying knowledge that should have lived in your observability platform, your runbooks, and your platform engineering team. If you’re serious about AI for testing, the upstream investment is in making that environmental knowledge legible. Tests that pass in a broken environment are worse than no tests at all, and AI-generated tests are particularly vulnerable to this because they don’t have the tacit sense of “something’s off today” that a human operator develops.

The fourth job, quality conscience, does not get automated. It gets renamed, elevated, and kept. The best version of what comes out the other end of a thoughtful AI-for-testing program is that you still have that person, they’re now a quality engineer or a senior SDET or whatever your org calls it, and the ratio of their time spent on judgment versus execution has gone up substantially.

Going Live

A few notes for the dev manager who has to run this.

Start with what you can measure honestly. The cost of your current testing practice is usually understated because it includes a lot of implicit work. Before you commit to a target, spend a couple of weeks with your QA leads getting an honest picture of where the hours go. You will be surprised. Almost everyone is.

Don’t set the adoption target in hours saved or headcount reduced. Set it in defect escape rate, time-to-feedback on a pull request, release cadence for the parts of the system that should be releasing frequently, and coverage on the parts of the codebase that actually change. Hours saved is a lagging, politicized metric. The others are leading indicators of whether the program is working. The Memphis logistics company we worked with didn’t move from three-year releases to daily ones by targeting hours saved. They targeted cycle time, and the hours came with it.

Treat the manual testers you have as the most valuable input to the program’s design. The person who has been running the regression suite for four years knows more about where the bugs hide than any model will know for the next several years. Bring them into the design of the AI-assisted replacement, and pay them as the senior engineers they will need to become. The organizations that quietly win this transition are the ones that retain and retrain. The ones that treat it as a staffing exercise lose the knowledge and then spend three years rediscovering it through production incidents.

Fix test data before you scale test generation. I cannot say this loudly enough. If your lower environments are unreliable, AI-assisted testing will amplify the unreliability, not resolve it.

Build the rollout in phases that assume the first version of the AI-assisted practice will be wrong in ways you can’t predict. Generated tests will occasionally be confidently wrong. Self-healing locators will occasionally heal themselves into testing the wrong thing. Flake triage will occasionally mark a real bug as a flake. You need the feedback loops to catch these, and you need them before the program is declared complete, not after.

And accept that “done” is the wrong frame. The tooling will keep changing. What your model is good at in the spring isn’t what it’ll be good at in the fall. The dev managers who get the most from this are the ones who build a practice of reassessing the mix every couple of quarters, rather than running a single transformation and declaring victory.

Closing Thoughts

The manual testers in your org are not the problem AI is solving. The problem is that testing in most organizations has been under-invested, under-staffed, and under-respected for a long time, and the recent AI capability gives you cover to fix that. Not by removing the humans. By moving the work they do up the stack, automating the parts that were never a good use of them, fixing the test data infrastructure that has been quietly taxing every program for a decade, and paying for the judgment that’s left.

I think about the 2009 version of me, recording those screen captures of my own test runs, and I don’t romanticize any of it. The work was tedious and the feedback loops were terrible and the profession deserved better tooling. What the 2009 version of me had, though, was a slowly accumulating sense of where the system was going to break, built from the hours of sitting with the product. That’s the thing I’d want to protect as you run your program. Not the tedium. The judgment that grew out of it.

The dev managers who get this right won’t be the ones with the most aggressive automation targets. They’ll be the ones whose quality posture, twelve months from now, is obviously stronger than it was before the program started, and whose best testers are still on the team.

That’s a harder program to sell in a single slide, and it’s also the mix that works.

BLUF: Most organizations aren’t losing the data game because they lack data. They’re losing because nobody agrees on what the data means. A semantic data layer is the organizational and technical infrastructure that fixes that. The hard part isn’t building it, but treating data like a product with an owner, a roadmap, and a seat at the leadership table.

If data is the new oil, the oldest legacy enterprises in business should be poised for a whole new wave of investment. But they’re not. And just like oil trapped in the Canadian oil sands, the data is useless until someone figures out how to make it usable.

In most organizations, the pattern is almost predictable. Someone from finance pulls a customer count. Someone from sales pulls a different one. Someone from the data team pulls a third. All three numbers are technically correct. All three are sourced from systems in the same company that someone paid millions to build and maintain. And yet the executive sitting at the head of the table has to choose which one to believe.

That moment of paralysis is not a technology failure, and it isn’t that the people gathering the data don’t know what they’re doing. The problem is systemic. And until organizations treat it as such, no amount of investment in AI, business intelligence, or data modernization will fix it.

Several years ago I was working with a large, established insurance company to develop a strategy for the future. The executive sponsoring the engagement was certain that future profitability would come not from selling insurance and carefully managing a fund, but from their data. I dropped the South Park Underpants Gnome analogy. He didn’t get it.

I tried again: just as stealing underpants isn’t a path to profit, neither is reducing investment in your core products because you’ve decided that data equals revenue. The company was a trusted insurance provider, not a data broker. Their data could make their core business sharper, faster, and more competitive, but only if they could actually use it. That was the part nobody had thought through.

When we dug in, the picture was familiar. They had a lot of data. They also had no coherent way to work with it. It was siloed across systems that didn’t communicate, defined differently by every team that touched it, and governed by nobody in particular. The strategic conversation they thought they were having, about monetization and future revenue, turned out to be a much more foundational one: we shifted to exploring what their data meant, and whether anyone in the organization agreed.

Realize it or not, most organizations today are in the midst of an underpants gnome conundrum of their own.

Over the last several years, across industries and geographies, I’ve seen organizations struggle with what to do with their data and how to make it accessible. The symptom changes. The root cause rarely does.

Somewhere in the organization’s history, someone decided that shared meaning was a problem each team could solve independently. This is a risk I flagged often when organizations pursued aggressive team autonomy models. The larger and more complex an organization’s business, the less likely any team will ever operate with true independence: the system is simply too big. For a while, the methodological purists proved louder than that concern. Organizations pursued the belief that they could succeed as a collection of independent teams, with coordination and planning recast as overhead rather than value. And the consequences of that decision stayed invisible because the cost of misalignment was low enough to absorb. Reports had footnotes. Analysts reconciled manually. Leaders learned which number to cite in which room.

The cost is no longer low enough to absorb. And the reason why is worth understanding before we talk about the solution.

What We Built Before

The concept of a semantic data layer isn’t new. The problem it solves has been with us since organizations started running on more than one system of record. What has changed is how consequential the absence of one has become.

Before semantic layers became a defined category, organizations managed the meaning problem in one of two ways. Both worked well enough for long enough that the problems they created didn’t become visible until the data environment got large enough and interconnected enough to make them unavoidable.

The first approach was ETL-layer logic. Extract, transform, load pipelines became the de facto home for business definitions. If the finance team needed “active customer” to mean something specific, that logic got baked into the pipeline that fed their reporting database. If the sales team needed a slightly different definition for their dashboard, a different pipeline got built with slightly different logic. Over time, organizations accumulated dozens, sometimes hundreds, of pipelines each carrying their own embedded definitions. Nobody documented the differences systematically. Nobody governed them. The pipelines kept running, the definitions kept drifting, and the organization kept producing reports that didn’t agree with each other without anyone being able to explain exactly why.

The second approach was Master Data Management, or MDM. MDM was the enterprise’s formal attempt to solve the meaning problem before semantic layers existed as a concept. It was ambitious: a centralized system of record for the entities that mattered most, customers, products, suppliers, locations, with governance processes to keep definitions clean. In the right conditions, MDM worked. In most enterprise conditions, it didn’t. The implementations were expensive, the governance overhead was heavy, and the business participation required to keep master data current was difficult to sustain. MDM projects became known for taking years and delivering less than promised. Many organizations still carry the scars of a failed MDM implementation, which makes the conversation about semantic layers politically complicated before it even starts.

What both approaches shared was a fundamental design assumption: that the meaning problem was a data problem, solvable by data teams, and that the business’s job was to consume the results rather than participate in defining them. That assumption is where both approaches broke down.

A semantic data layer, properly implemented, rejects that assumption. The technology part is straightforward. The harder part, getting the business to co-own the definitions, is where most organizations struggle and where most of the real work lives.

What the Layer Does

The term sounds like something a data architect invented to win a budget conversation: confuse the accountant with big words.

A semantic data layer is a shared, governed definition of what your data means. Not what it technically contains. What it means. The difference matters more than most technology leaders realize.

Your CRM calls them clients. Your ERP calls them accounts. Your data warehouse references them by a party identifier that means nothing to any human being who hasn’t memorized a data dictionary. When your AI model, your BI dashboard, or your executive report pulls data, it is drawing from at least three different definitions of the same concept. The downstream result is what you saw in that meeting: three numbers, zero trust.

A semantic data layer sits between your source systems and their consumers. It translates technical data structures into business-meaningful definitions, applies consistent business logic, and ensures that when your analytics tool says “active customer,” it means the same thing whether the query hits your CRM, your data warehouse, or your operational database.

The diagram above illustrates the vocabulary problem. More pipelines won’t fix it. Faster pipelines won’t fix it. A shared dictionary that the systems are required to honor fixes it, and that is what a semantic layer does.

Two Problems, Not One

It is worth being precise about what a semantic layer covers, because two related problems often get conflated in the same conversation.

The first is entity definition: what is a “customer,” a “product,” a “location”? These are the foundational objects your business runs on. When systems use different names or slightly different scopes for the same thing, every report built on top of them inherits the disagreement. This is a structural problem, and it sits underneath everything else.

The second is metric governance: what is “revenue,” “active user,” or “churn rate”? These are calculations, and they can produce different numbers even when the underlying entity definitions agree, because the business logic embedded in the calculation differs by team or tool. Finance calculates monthly recurring revenue one way. Sales calculates it another. Both are pulling from the same source system and still arriving at different answers.

A semantic layer addresses both. But they are not the same problem, and they don’t respond to the same fix. Entity definitions are foundational. Metric governance is built on top of them. The sequence matters: get the entities right first, then govern the metrics built from them. Organizations that skip straight to metric governance without resolving the entity layer underneath tend to find that their governed metrics are consistent but still wrong, because the objects they’re measuring were never properly defined to begin with.

The practical implication is worth stating directly. The “start with ten metrics” advice that appears later in this post is a metric governance move. It is the right place to start building organizational credibility and executive buy-in. But it won’t automatically resolve the entity definition problem underneath. Both need attention, and knowing which one you’re working on at any given moment is the difference between a semantic investment that compounds and one that plateaus.

The Urgency

For years, the absence of a semantic layer was a nuisance organizations could manage. Reports required footnotes. Analysts reconciled manually. Leaders learned which number to cite in which room. The tax was real, but it was distributed and largely invisible.

Generative AI has transformed that manageable nuisance into a structural liability, and it is doing so faster than most organizations realize.

The investment thesis behind most enterprise AI initiatives assumes that connecting capable models to rich data produces reliable insight. That assumption depends entirely on the data being consistent and trustworthy. When it isn’t, when “customer” means three different things in three different systems and none of those systems is authoritative, the model does not throw an error. It synthesizes. It finds a plausible answer from the available inputs and delivers it in whatever format you asked for, with no indication that the foundation it reasoned from was broken.

This is not a model problem. The models are performing as designed. The problem is that the data infrastructure most large organizations have built over the last two decades was not designed with shared meaning as a requirement, because the cost of inconsistency was low enough to absorb before AI made that cost visible.

The risk compounds further as organizations move toward agentic AI. A confused reasoning system that produces a wrong answer is a problem you can catch in review. A confused agent that takes a wrong action, updating a customer record, routing a transaction, triggering a downstream workflow, based on a semantically broken input is a different category of problem entirely. The stakes of semantic inconsistency go up significantly when AI moves from answering questions to taking actions.

The flip side is worth stating plainly. Organizations that do establish semantic clarity before connecting AI to their data get something their competitors don’t: a model that reasons from a shared, trustworthy foundation. That means more reliable answers, faster time to insight, and AI outputs that executives are willing to act on rather than second-guess. Semantic clarity doesn’t just reduce AI risk. It is what makes AI genuinely useful at the enterprise level.

I’ve seen this shift accelerate in a specific way. Engagements that a few years ago started with “we need better reporting” now start with “we’re deploying AI and our outputs aren’t reliable.” When the conversation reaches that point, semantic inconsistency is almost always part of the diagnosis. The organizations moving fastest to fix it aren’t doing so because they read about semantic layers. They’re doing so because a failed AI initiative made the cost of inconsistency impossible to ignore.

Organizations that invest in AI capability before establishing semantic clarity are not getting ahead of the problem. They are getting behind it faster.

The Gap Is Costing You

The cost of semantic inconsistency tends to be invisible on any individual line of the budget. Analysts spend time reconciling instead of analyzing, governance programs stall without shared definitions to govern against, and the cost compounds quietly across every team that touches data.

The most visible damage shows up at the top. The three-numbers problem doesn’t just create a moment of awkwardness in an executive meeting, it creates a pattern of hesitation that slows everything down. Leaders who have learned not to trust their data ask more questions before committing. They wait for reconciliation. They hedge. That caution is rational given the environment they’re operating in, and it is expensive.

The Failure Modes

The absence of a semantic layer creates predictable, consistent problems across organizations regardless of industry, size, or technical maturity.

Definitions get negotiated in spreadsheets. In the absence of a governed layer, individual teams create their own definitions and encode them in Excel files, BI reports, and tribal knowledge. Those definitions drift over time, diverge across teams, and become almost impossible to reconcile systematically because they were never managed as organizational assets. They were managed as individual workarounds.

New systems inherit old ambiguity. When organizations implement a new ERP, a new CRM, or a new data platform, they almost always bring the definitional inconsistency forward with them. The migration project focuses on moving data. Nobody has a mandate to resolve what the data means. The new system goes live with the same meaning problem the old system had, plus new terminology to argue about.

The data team becomes the scapegoat. When reports disagree, someone has to take the blame, and it almost always lands on the data engineering team, because they built the pipelines the reports run on. In most cases, the data team is not actually at fault. They implemented what was asked of them, often by multiple business stakeholders with conflicting requirements. The fault is organizational: no one with sufficient authority held the business accountable for providing consistent definitions before the technical work was done. The data team absorbs the blame for a governance failure that sat above them.

BI tools multiply the problem rather than solving it. Organizations that invest in self-service analytics hoping to broaden data access sometimes find that they have instead broadened data inconsistency. When every analyst can build their own reports, and every report can embed its own business logic, the number of competing definitions of any given metric grows with the number of analysts. The semantic layer problem doesn’t get easier as BI tooling gets more accessible. It gets harder.

AI answers the wrong question fluently. A language model connected to semantically inconsistent data doesn’t know it is working from inconsistent inputs. It synthesizes what it finds and presents it with the confidence of a well-trained communicator. The result is answers that sound authoritative and are frequently wrong in ways that are difficult to detect without already knowing the answer. This is the failure mode that is moving the semantic layer conversation from data team priority to C-suite priority faster than most other forces in enterprise technology right now.

The Infrastructure Trap

Most organizations that do invest in a semantic layer make a consistent mistake: they treat it as infrastructure rather than as a product. The distinction is not a small one. It has concrete operational consequences.

Infrastructure gets built once. It gets documented once. It gets maintained reactively, when something breaks. Nobody owns it in a meaningful way. Nobody measures whether it’s working. The business never really asked for it, which means the business has no stake in keeping it current.

A semantic layer treated as infrastructure decays. Business definitions change. New source systems get added. Organizational mergers bring in entirely new vocabularies. Nobody updates the layer because nobody’s job it is to update it. Within eighteen months, the layer that was supposed to create shared meaning has become another source of inconsistency, only now with the additional problem of looking authoritative while being wrong.

The difference between the two approaches is illustrated below.

The organizations getting real value from their semantic investments treat the layer as a product. That means it has owners. It has a roadmap. It has adoption metrics. Business stakeholders are part of the governance process, not passive recipients of definitions handed down from IT. The definitions evolve as the business evolves, through a deliberate change process rather than through drift.

Treating semantic data as a product is a governance decision as much as a technology decision. It requires someone with organizational authority to hold both the technical and business sides of the conversation accountable to the same vocabulary.

Getting It Right

The enterprises I have seen navigate this successfully share a consistent set of moves. None of them are complicated in concept. All of them are hard in practice.

Put a senior executive in charge of data strategy, not just data operations. This is the move that separates organizations that resolve the semantic problem from the ones that keep managing around it. The definitional disagreements that prevent a semantic layer from taking hold, what counts as a closed deal, what makes a customer active, how revenue is calculated across business units, are not questions a data engineering team can answer. They require someone with organizational authority to convene the right business stakeholders, surface the disagreements, and make binding decisions.

In practice, this means a Chief Data Officer, or a senior executive with equivalent authority, who holds both the business and technology sides of the semantic conversation accountable. Not a data steward committee with no enforcement mechanism. Not a center of excellence that produces recommendations business units are free to ignore. An executive with a mandate to establish and maintain shared definitions, the organizational leverage to hold business units accountable to those definitions, and a reporting line that makes data strategy a C-suite concern rather than a back-office function.

The organizations that have gotten this right have typically made this move before the AI conversation started, which is one of the reasons their AI initiatives are performing better than their peers. The semantic foundation was established because someone with authority decided that shared meaning was a strategic requirement, not an IT project. The AI capability was layered on top of a foundation that could support it.

Start with the entities your systems disagree about most, then move to the metrics your leadership team argues about most. Get the foundational objects right first: customer, product, location, account. Then define, formally, in writing, with sign-off, the business concepts that generate the most disagreement when they appear in executive reports. Revenue. Active user. Churn. Margin by product line. Both layers of work matter. Neither substitutes for the other. Getting them sequenced correctly is what makes the investment compound rather than stall.

Treat the semantic layer’s health as a board-level metric. The organizations that sustain this over time measure it the way they measure any product: adoption rates across business units, query volume against governed definitions versus ad hoc queries, time-to-answer for common business questions, and whether executives actually believe the numbers they’re seeing. These aren’t vanity metrics. They are leading indicators of whether the investment is growing stronger or quietly falling apart.

The Takeaway

The technology leaders positioned well on the other side of this problem aren’t the ones who bought the best semantic layer tooling. They’re the ones who recognized early that the meaning problem is an organizational problem, and made the leadership investments required to solve it at that level.

That work is not glamorous. It involves sitting in rooms where executives from different business units disagree about the definition of their most important metrics, and holding the line that the organization needs a single answer rather than a convenient plurality of them. It involves explaining to a board why a data governance initiative is a strategic investment rather than a cost center. It involves building the organizational infrastructure that makes AI initiatives reliable, which is less visible than the AI initiatives themselves but more important to whether they actually succeed.

The leaders who look back on this period with satisfaction won’t be the ones who deployed the most AI pilots or adopted the most capable models. They’ll be the ones who asked the harder question first: does our organization have a shared language for what our data means? And then built the organizational infrastructure required to answer it.

That infrastructure starts with someone in the room who has the authority and the will to say: we are not leaving until we agree on what a customer is.

We have spent the last three years obsessing over how much AI can produce — and it has delivered. Faster code. More content. Product cycles compressed from weeks into hours. We built the tools, staffed the pilots, and celebrated the throughput. Frankly, I’m tired of it. Because now I’m watching some of the most capable enterprises I know quietly fracture under the weight of what they built. Not because the tools failed. Because they worked too well.

This is the problem nobody in the AI conversation wants to say out loud: we have solved for production capacity and ignored absorption capacity entirely. We have handed organizations a firehose and called it progress. The organizations that cannot answer the question of how much change their customers and employees can actually absorb at any given moment are building a structural problem that will cost them more than any transformation they have ever attempted.

The constraint of the agentic AI era is not what you can produce. It is what your market, your customers, and your own organization can receive.

Reruns Abound

There is a category of financial services company that most people recognize, even if I cannot name it. A large institution with a strong brand and deep customer trust built over decades. And somewhere around 2017 or 2018, a mandate from above: we are going to be the everything provider. Insurance, banking, investing, mortgages, auto, home, auto buying, home buying. We are going to be the best at all of it simultaneously.

The teams delivered. They shipped what was asked. New products came to market at a pace the organization had never seen.

The customers were lost.

There were so many products, and the brand was evolving too fast, in too many directions at once. Customers who had trusted this institution for decades, who had chosen it precisely because of its clarity and reliability, started experiencing something they could not quite name. Confusion. Friction. A vague sense that the organization had stopped knowing what it was there for. Core product quality slipped, not dramatically. Compliance slipped quite dramatically. In financial services, product is one thing, but compliance is everything.

The institution had optimized for production and lost the trust of the people that made it great. No mechanism existed to ask how much change customers could metabolize. No framework to sequence change against readiness. No visibility into the cumulative burden landing on the people they were ultimately building for.

This is what happens when production velocity outruns absorption capacity. Agentic AI is about to supercharge that exact dynamic.

The institution had optimized for production. It had not built any instrumentation for absorption. And there was no mechanism to ask the one question that mattered: how much change can our customers actually receive right now?

The Agentic Multiplier

Agentic AI refers to systems that pursue goals autonomously — not tools that respond to prompts, but systems that plan, act, and iterate across multiple steps without a human in the loop at each one. That distinction matters more than most organizations currently appreciate.

When I talk to executives and product people about agentic AI, the conversation almost always centers on capability and throughput. What can the agents do? How much can they automate? What is the ROI model? These are legitimate questions, and the answers can be genuinely impressive.

What almost never makes it into the conversation: agentic systems do not just produce more, they produce more continuously, and they do it across every surface simultaneously.

A single well-configured agentic system can touch customer communications, product configuration, internal documentation, workflow sequencing, and reporting in a single cycle. It can deploy a change to your customer experience, your employee experience, and your operational layer without any human reviewing whether the cumulative effect is something the receiving end can absorb.

This is new. The digital transformation era had a quarterly release cycle — a natural throttle. The Agile era had iteration cadences — natural checkpoints. Agentic AI removes the friction that previously forced organizations to pace themselves. For most enterprises, that friction was not waste. It was load-bearing.

Gartner predicts that by 2028, at least 15% of day-to-day work decisions will be made autonomously through agentic AI, up from virtually zero in 2024, and that 33% of enterprise software applications will embed agentic capability by the same timeframe.[1] The throughput is undeniable. The governance infrastructure to match it is almost universally nonexistent.

The Velocity Gap

Production is climbing. Absorption is not keeping pace. That is the gap, and most organizations are not measuring it because they have never had to. The natural brakes of the previous era gave the system time to absorb what was being deployed. Those brakes are gone. What replaced them is a question most enterprises have not yet asked — until the returns fail to materialize.

A BCG study from 2025 found that only 5% of companies have achieved AI value at scale, while 60% report no material returns despite substantial investment.[2] That is not a technology problem. The tools are working. The gap is the organizational capability to land change well — to put it somewhere it actually takes hold, in the hands of people who are ready to use it, in systems stable enough to carry it.

Change Saturation

Market and customer saturation from change overload follows a recognizable pattern. You can feel when you’re overburdened with change, and you can see it in your customers. It looks like resistance and disengagement.

Most organizations misread those signals when they appear. They diagnose a communication problem, a training gap, a product issue. The response drives more activity, which compounds the original problem. By the time the real cause surfaces, the organization is already in stage three of a pattern that was entirely visible from stage one — to anyone who was looking at the right thing.

The Three-Stage Saturation Pattern

First, engagement metrics soften. Not collapse. Soften. Customers interact a little less. Support tickets start referencing confusion about recent changes. Employees ask a few more questions about why things work differently now, and long-tenured people quietly stop volunteering ideas. These signals get attributed to execution problems, communication gaps, or training deficits. The real cause, cumulative change burden exceeding absorption capacity, never makes it into the diagnosis.

Second, the organization accelerates in response. Because the metrics softened, there is pressure to ship the next thing. Surely the next feature, the next product, the next release will turn the curve. The volume of change goes up in direct response to the symptoms of too much change. This is the pattern that turns a manageable problem into a structural one.

Third, trust erodes in ways that take years to rebuild. The customer who once gave you benefit of the doubt stops extending it. The employee who once championed the new way of working starts keeping her head down. The institutional confidence built over a decade gets spent in eighteen months of overdeployment.

By the time the pattern is visible to leadership, the cost is already sunk. The organizations that hit this wall with AI velocity in the system will hit it faster and harder than anything the digital transformation era produced.

The organizations that will win this era are not the fastest deployers of agentic capability. They are the ones that build, alongside that capability, a rigorous and continuous answer to one question: what is landing on our customers and our people right now, and what is their remaining capacity to receive more?

Absorption Capacity

I have sat across the table from a lot of leaders who hear “absorption capacity” and think it is a case for slowing down. It is not. It is a case for knowing what you are doing to your customers before they tell you.

The organizations I have watched get this right share one thing: they know where their customers are. Not in a CRM sense. In a change sense. Which segments are still orienting to the last release. Which employees are running on fumes from the last reorganization. Which products have been touched so many times in twelve months that the people using them have stopped trusting them.

That knowledge shapes sequencing. What goes next. What waits. What needs a stabilization period before the next build lands on top of it.

MIT Sloan Management Review’s 2025 research on the agentic enterprise, conducted with BCG across 2,100 executives in 116 countries, underlines the point: the organizations that thrive focus less on the technology itself and more on the human systems that surround it.[3] Most enterprises have not operationalized that observation. They are still governing AI adoption the way they governed software releases, which was already not working before the velocity got 10x faster.

You cannot manage change absorption from a program dashboard. You need signals from the delivery layer, the product layer, the customer layer, and the organizational layer, running continuously, visible in relation to one another. You need a framework that surfaces the problem before it becomes a crisis, not after it shows up in quarterly metrics.

The Change Radar

Years ago, working through one of the earlier transformation waves, I came across a concept called the change radar. It came from a persistent frustration: organizations were consistently surprised by change that had been visible for months to anyone with the right vantage point. Not unpredictability. The absence of any shared visualization of what was already in flight.

Hard to prepare for what you cannot see, and most change falls into that category. To stop inundating an organization and its customers with more than they can absorb, we need a mechanism to make the invisible visible.

The change radar organizes all change across two axes. The first is origin: who is driving the change? Some of it we are imposing — new products, new platforms, restructured experiences. Some is being imposed on us — regulatory shifts, competitive moves, market pressure. Both consume organizational and customer capacity, and most change management frameworks only account for the first. The second axis is impact: does this change land on our internal organization, our people and processes, or on our external customers and market?

Mapped across those axes, with a horizon model distinguishing between change that is assessing and visioning, change that is preparing, and change that is actively implementing, you get something most executive teams have never seen clearly: the full picture of cumulative change landing on any given audience at any given moment.

Think of it the way air traffic controllers manage a major hub. At any point, hundreds of aircraft are in motion simultaneously. The controller’s job is not to determine whether flying is a good idea. It is to manage sequencing, spacing, and load so everything can land safely. The radar does not slow the planes down. It makes the density visible so the right decisions can be made about what comes next.

That is what the change radar does for enterprise transformation.

Unlike a change advisory board or a program status dashboard, the radar is cumulative, cross-layer, and continuous. It does not ask whether one initiative is ready to launch. It asks what the entire change environment looks like for a given audience at a given moment — including what is being imposed on them from outside the organization.

The value compounds when layered against portfolio and program prioritization. Most portfolio decisions are made against one question: can we build it? The change radar adds the prior question: can our customers and organization receive it right now? If the answer is no, the sequencing decision is not to delay the work. It is to identify what must land first to create the capacity for what comes next.

As is often said: timing is everything. If we land the right change at the wrong time, we risk losing the strategic opportunity it was designed to create.

In the agentic AI era, this is not a governance artifact for large change programs. It is the fundamental discipline for responsible velocity. The agents will produce, continuously, across every surface. The question is whether leadership has the instrumentation to sequence what gets deployed, when, against a real model of customer and organizational readiness.

What Sustains the Advantage

I wrote recently about why the transformation program model keeps failing. The argument was structural: programs are designed to end, and the capability they build dissipates when the program closes. The organizations that break the cycle are the ones that build continuous modernization into their operating model permanently. Not as an initiative. As how they operate.[4]

The change radar is part of that. Not a one-time assessment. A continuous instrumentation layer that sits alongside your portfolio, your delivery system, and your customer feedback loops. It makes the question of change capacity a standing discipline rather than something that surfaces in a crisis.

The organizations I have watched absorb agentic AI capability well share a common characteristic: someone is tracking the cumulative weight of what is landing on customers and people, in real time, with enough visibility to make sequencing decisions before the damage is done. The ones that struggle are not less ambitious. They are less instrumented.

Most organizations are not stuck because they lack the ambition to change. They are stuck because they have never built the muscle that makes change visible before it becomes damage.

The goal is an organization that does not need to be rescued from its own velocity. One that can see its system clearly enough to deploy at the pace that compounds its advantage rather than erodes its foundation.

A Risk of the Agentic Era

The enterprise technology conversation right now is dominated by one concern: falling behind. The risk of being outpaced by competitors who move faster on AI adoption. That risk is real.

The one I am watching is the other side of it. Organizations spending their most valuable asset — customer trust and employee confidence — faster than any productivity gain can replace it. Moving so fast, with so little visibility into the cumulative change burden they are creating, that the damage is already done before anyone sees it coming.

The financial services company I described earlier recovered. Slowly, carefully, by getting serious about what their customers actually needed and rebuilding the clarity they had traded for ambition. It cost them years. They did it in a relatively slow-moving deployment environment, where the damage accumulated over quarters.

With agentic AI in the system, that same pattern plays out over weeks.

The leaders who navigate this era well are the ones who can hold two things simultaneously: speed is a genuine competitive advantage, and the pace of change must be calibrated against the real capacity of the humans on the receiving end.

That calibration requires visibility. Visibility requires instrumentation. And instrumentation requires the kind of deliberate, continuous operating discipline that transformation programs were never designed to build.

The constraint is not what you can produce.

It is what the world can receive.

The organizations that build the discipline to see that clearly, and continuously, are the ones that will still be compounding their advantage when everyone else is in recovery.

References

[1] Gartner, Predicts 2025: Agentic AI — 33% of enterprise software to embed agentic AI by 2028; 15% of daily work decisions made autonomously by 2028. Reported via RCR Wireless, June 2025.

[2] BCG, The Widening AI Value Gap, 2025. Only 5% of companies have achieved AI value at scale; 60% report no material returns despite substantial investment.

[3] MIT Sloan Management Review and BCG, The Emerging Agentic Enterprise: How Leaders Must Navigate a New Age of AI, November 2025. Global survey of 2,102 senior executives across 21 industries and 116 countries.

[4] BCG, Flipping the Odds of Digital Transformation Success, 2020/updated 2024. Roughly 70% of digital transformation initiatives fail to achieve stated objectives.

Well friends, it has been quite the eventful Q1, and I’m excited to be back to my positive, creative, inspired, and goal-driven self! Truth be told, it had been a while.

After leaving my old company at the start of the year, I planned to build a firm of my own. One focused on an amazing team of A-players, a culture of winning, and best-in-class results-oriented solutions, all with a little swagger.

That changed when my buddy Eric told me the company he works for already had all of those things and was launching a consulting arm. They asked if I wanted to help. Not that I don’t love a challenge, but not having to worry about cash flow or rebuilding a network was too appealing to pass up.

I started at The Select Group in late February, and it has been a very refreshing experience. The people and culture feel like what I experienced at Under Armour from 2010 to 2013: gritty, results-oriented, amazing people who want to work together and WIN.

All of this isn’t to say I don’t have other things cooking (I always do). The Mattis Foundation is already making an impact, Jenelle is sourcing land for our first real estate development project, we’re thinking about funding a roll-up of local septic companies, and we’re looking at a short-term funding solution for small businesses.

Oh, and I’m back to writing and thinking through new ways to solve complex business problems.
Oh, and I launched The Adam Mattis Show because I miss giving people a platform from which they can tell their stories.
Oh, and I bought a Corvette that I’ll start racing in time trials this summer.
Oh, and Ford turned one. He is walking, starting to talk, and at the rate he’s progressing he’ll be our CPA by October.

But hey, you know, things have been pretty chill around here. 😉

Latest Writing

It’s amazing how the ideas flow when you remove stress variables from the system. It has been a long time since I’ve experienced such mental clarity, and damn — it feels good.

Things really began to unlock when I co-hosted the Triangle Digital Products and Innovation Meetup with my friends at Lucid. It didn’t occur to me until I arrived that it had been four months since I had been on a stage or even presented to a small group.

It felt great, and the next day I was back to writing.

Here’s what I’ve published over the last month (as always, your feedback and comments are appreciated!):

• Augmenting Your Dev Org with Agentic Teams (also on DZone)

• Who’s Left to Buy Your Product?

• Your SDLC Doesn’t Know What to Do With AI. It’s Costing You $ & %.

• The Product Model is Alive

• The Case Against Perpetual Transformation

Date Your Wife.

Last week, for my wife’s birthday, I arranged for a photographer to meet us at the restaurant. She had been feeling a little bummed about turning the age she did (I’ve learned my lesson about disclosure and won’t be sharing the number 🫢), so I wanted her to have the chance to see herself the way I see her every day.

For just $150 and 15 minutes, the photographer completely changed the tone of the night and shifted Jenelle’s perception of herself.

I’m sharing this because last night reminded me that the best gifts don’t have to cost a fortune and sometimes they require a little sacrifice (photos are definitely not my favorite way to spend time).

That, and because she’s an absolute smokeshow and I wanted to brag a little. 😎

Ford’s First Lap

I can’t believe our little dude is already one. What an insanely fast year it’s been!

Being Ford’s dad is hands-down the best thing I’ve ever done. He’s incredibly smart, loves people, is endlessly curious about how things work, has a big personality, and loves cars and motocross almost as much as I do.

It’s been so cool watching the things that light him up — and seeing him learn to love our dogs, Bailey and Ellie.

I love being Ford’s dad.

A Business You Should Know: Crawford Hospitality

Guys Mills, Pennsylvania, the small town where I grew up, isn’t exactly known for producing internationally renowned talent. We do have a few standouts, though. For example, Tiffany Beers built the actual self-lacing shoe from Back to the Future for Nike.

So when someone from your hometown makes it big and lives in your current town, I feel it’s my responsibility to help them compound their wins.

Scott Crawford, the nephew of the guy my dad worked for growing up, is a Michelin-recognized chef who operates six amazing restaurants in Raleigh.

I never reached out directly. I’m always paranoid about seeming like I’m using a loose family connection to “get” something. Instead, I supported him from a distance: Jenelle and I have eaten at every one of his restaurants, and I’ve followed him on Instagram.

After I interacted with one of his stories, Scott messaged me: “Are you Jeff’s son?” Shocked he even knew who I was, I replied yes. He remembered meeting me when I was about Ford’s age and said my dad had made a positive impression on him.

We exchanged numbers and now stay in casual contact over our shared love for fast things on two wheels.

While planning Jenelle’s birthday, I asked Scott for advice about his new speakeasy, Sous Terre. He not only helped with the key for a nightcap but also rolled out the red carpet. Even on a busy Wednesday night, he sent his General Manager and hostess to take excellent care of us.

Absolutely not expected. Absolutely appreciated.

If you’re ever in Raleigh, check out one of Scott’s restaurants. Even if you only make it to the airport, you’re in luck. He’s got one there too.

Cheers.

• Crawford and Son

• Jolie

• Bordetto

• Sous Terre

• Crawford’s Genuine

• Crawford Brothers Steakhouse

Thank You.

As always, I appreciate your support of myself, my family, and my people. The fact that so many of you have been following along with my shenanigans for all of these years is humbing.

I know I dropped the ball in terms of value over the last couple of newsletters, but in the immortal words of Frank Costanza: I’M BACK, BABY!

More to follow.

Cheers,
-AM

For my entire professional career, we have been in transformation, and I am calling it done. At some point, you have to exercise the muscles you built and get serious about being great at change itself. That is a different discipline than transforming, and it is exactly what The Select Group (TSG) helps enterprises do.

I have spent more than twenty years helping enterprises transform. I do not say that with exhaustion, but with the kind of perspective that only comes from having lived the full arc several times over, with the scars to tell their own stories. Twenty years is long enough to have ridden a few waves: the web build-out of the early 2000s, the digital transformation decade that followed, the methodological revolution that reshaped how teams work, and now the AI era that is reordering everything again. I have helped guide organizations through all of it as an engineer, architect, executive, and thought leader contributing to one of the most significant operating frameworks of modern history. Reflecting on all of it, I have noticed something that nobody else seems to be ready to discuss.

We have been transforming the same organizations over and over again. We have called it progress. In some cases we have even declared victory, and at the time, rightly so. Then leadership changes, people change, the transformation is declared “done,” and progress goes into regression.

Each wave arrived with genuine urgency and a solid business case. Each was the right thing at the time. Companies that did not build for the web lost. Companies that did not modernize their digital customer experience became irrelevant.

But somewhere between the first wave and this one, the enterprise stopped treating transformation as a response to a specific forcing function and started scoping it as a permanent program. The transformations kept rolling. The capability transfer rarely made it into the next evolution.

Here is what I believe after watching this cycle repeat for two decades: the problem is not the ambition. The problem is that we never built the muscles to stay changed.

The Wave Pattern

The web work came first. We built the digital storefronts, stood up the e-commerce infrastructure, moved the customer interaction layer online. That was genuine, consequential transformation. It was actually the foundation for my first real business, Carzz. The platform, pre-Cars.com, helped powersports and auto dealers easily manage their inventory on their very own .com. What a time that was. The .com era rewired business models and forced organizations to develop capabilities they had never previously needed. The companies that did it well came out structurally different.

Then came the broader digital transformation era. The mandate expanded beyond the customer-facing layer: data strategy, cloud architecture, experience design, platform thinking. Enterprises made enormous investments and brought the customer closer than ever. BCG’s global study of over 850 companies found only about one in three of those initiatives delivered on their stated value targets.

I personally led a digital transformation at an education consortium spanning 86 universities, 22 campuses, and 5 geographic regions. The impact was profound in terms of operational efficiency, student experience, and EBITDA gain, only to be eroded nearly as soon as the work was complete by a series of divestitures.

Then the wave shifted to how organizations work. Faster delivery, modern operating structures, rearchitected team models. The underlying problem was obvious: the delivery vehicle at most large enterprises was a product of the industrial age. It had to be shifted for a world where knowledge and context drove innovation. But the solution got packaged and industrialized in ways that prioritized repeatability over fit. Many organizations emerged with new processes layered on top of the same structural problems that made the work slow in the first place.

Now here comes AI. And I will tell you exactly what I tell every executive I sit across from: if you approach this wave the same way you approached the last three, you will get the same result. A program. An engagement. Measurable gains at close. And eighteen months later, someone in your organization asking what the next thing is. The gains will not stick, and the pain will be much greater this time than any previous wave due to the speed and scope of AI tooling. If you do not approach this differently, you will compound the friction already in the system, and you will fail.

A 2024 Bain analysis found that 88 percent of business transformations fail to achieve their original ambitions. Not a slim majority. Eighty-eight percent. The failed efforts cost organizations an estimated $2.3 trillion annually. We have been spectacularly, consistently bad at the thing we have been selling for two decades.

I do not think the problem is incompetence. I think it is something more structural, and more fixable.

“At some point, you have to stop getting in shape and start being an athlete. Those are not the same thing.”

I run six days a week. Cold plunge to start, sauna to finish. I have done it long enough to understand the difference between transformation and performance. Year one, you are chasing a distance. Year three, you are not transforming anymore. You are performing, and your goal shifts to sustainability and efficency. The gains are harder and slower, but they do not evaporate when you miss a week. You built the version of yourself that just keeps getting better. But you recognize that if you do not care for the system you have built, it will fail.

Enterprises need to make the same shift. The goal is not to complete a transformation. The goal is to build the operating model, the team capability, and the organizational reflexes that make improvement the default, and then seek sustainability in that system. This is a fundamentally different discipline than how most companies have operated throughout history. And most transformation programs were never designed to leave it behind.

Why the Model Keeps Failing

I want to be careful here, because I have been on both sides of this. I have run transformation programs. I have landed the engagements. And I have a lot of respect for the practitioners doing this work. The problem is not the people. The problem is how the work gets scoped.

Transformation programs are built to have an end. Scope, timeline, deliverables, handoff. That structure makes sense when you are solving a discrete, bounded problem. It does not make sense when the underlying issue is an organization’s ongoing capacity to absorb change. The mistake is not in the engagement itself, but in the scoping: optimized for delivery of a defined output rather than transfer of a durable capability. When the program ends, if building that internal muscle was never part of the scope, the decay begins. And even in the cases where internal discipline was established, organizational politics typically prevent the same level of transparent conversation that is free to take place between external advisors. Internal team members tend to call these crucial conversations CLMs: career-limiting moves.

I watched this play out at a major financial services firm. A large investment of time and capital was made over many years, and meaningful results were delivered from a talented team. Release frequency improved materially. Teams were better aligned. The metrics looked strong at program close. Two years later, the gains had largely reversed. Leadership was gone, new perspectives were brought in, reductions happened, and trust vanished. This did not happen because the organization lacked commitment, and not because the consultants did poor work. Because capability transfer was not in the scope, and the change had not been made foundational to how work was done at the enterprise, it did not stick when pressured by new voices. They had been handed a transformation. They had not been built into an organization that could own one.

McKinsey’s organizational health research adds an edge to this: performance transparency (the internal capacity to measure, see, and act on improvement feedback) appears in only four percent of transformation programs. The single practice most correlated with sustained gains is the one that almost never makes it into the statement of work.

The Structural Problem

Harvard Business Review noted last year that the traditional transformation model, rooted in Lewin's 1950s "unfreeze, change, refreeze" framework, was designed for discrete projects. It was never designed for an environment where the external landscape evolves faster than any single program can address. The organizations that outperform are the ones that have built change into their operating rhythm permanently, not as an initiative, but as a core organizational competency.

What Comes After Transformation

There is a better model, and I have seen it work at Fortune-50 enterprises with organizational gravity and firm resistance to change. The organizations that break the transformation cycle share a common set of characteristics, and none of them are mysterious.

These organizations treat their delivery model as a product. A product has an owner, a roadmap, a continuous improvement cycle built in. They apply the same rigor to the machinery of delivery that they apply to the products they ship. Ownership is permanent. Investment is operational, not capital. The improvement cycle does not close.

They build internal instrumentation before anything else. You cannot improve what you cannot see, and most organizations cannot see their own delivery system with any precision. The ones that sustain their gains have invested in flow measurement, quality signals, and structural friction visibility. They have built the systems to surface problems continuously, which means that when outside expertise comes in, it can go deeper faster, because the organization already knows where the drag is.

They close the loop between technology adoption and delivery capacity. This is the most urgent gap right now. AI tooling has accelerated development velocity at a pace that most downstream governance, quality, and release infrastructure was never designed to absorb. The organizations getting this right are not just adopting the tools. They are retooling the systems downstream to match the velocity the tools create upstream. The ones who are not are building fragility they cannot yet see.

And they develop leaders who own the change, not just sponsor it. Executive sponsorship is table stakes and everyone knows it. What actually determines whether an organization sustains its gains is whether there are leaders inside the delivery organization, not above it, with the knowledge, authority, and credibility to make ongoing modernization decisions without escalating every one of them. Those leaders are not hired. They are built, deliberately, over time.

“Most organizations are not stuck because they lack the ambition to change. They are stuck because they have built every muscle except the one that makes change self-sustaining.”

This is what I mean by continuous modernization. We do not want to launch another program. We do not want to rebrand a transformation. We aim to co-create an operating model where the organization's ability to detect what needs to change, sequence it, execute it, absorb it, and apply it to the next thing is built permanently into how the business runs. The measure of success is not program completion, but organizational self-sufficiency: the point at which the external partner is no longer necessary because the capability is owned.

AI Is Accelerating the Gap

A few weeks ago I published a piece on the AI Development Lifecycle. The argument: AI-native work operates by different rules than conventional software delivery, and organizations governing it with models built for a different era will underperform. I stand by every word. But there is a layer underneath it that connects directly to everything I have said here.

AI is accelerating the divergence between organizations that have built the continuous modernization competency and those that have not. If you have the internal instrumentation, the adaptive governance, and the change-ready delivery culture already in place, AI adoption amplifies your advantage. You absorb the capability, retool downstream to match the new velocity, and come out ahead of every competitor still running the transformation program model.

If you do not have that foundation, AI adoption accelerates your fragility. It makes a poorly-structured delivery system produce more output, more quickly, in more directions, with less visibility. That is not speed. That is scale-up failure on a faster timeline.

The organizations that win this era will not be the fastest AI adopters. They will be the ones with the absorptive capacity to translate AI capability into sustained competitive advantage. Closing that gap is, without qualification, the most consequential work available to enterprise technology leaders right now.

The Human Cost

I want to close with something that does not surface in executive conversations the way it should, because it lives below the waterline in the people doing the work.

The program manager who has built the deck, run the kickoff, earned the team’s trust, and delivered the results. Three times now, on three different initiatives with three different names. The technology leader who has stood in front of her organization and made the case for the new way of working, again, with genuine conviction, watching the skeptics in the back row who have seen this before. The delivery professional who poured himself into the work, watched it take hold, believed it this time, and then watched a leadership change quietly undo two years of progress in a single quarter.

These are not cynics. They were believers. And somewhere along the way, the model made them cynical.

That is the human cost of perpetual transformation. It does not show up in a program dashboard. It shows up in the leader who stops raising her hand. The engineer who updates his resume every time a new initiative kicks off. The institutional knowledge that walks out the door because they stopped trusting that the work would last.

When my son Ford was born, something shifted in how I think about the things worth doing. I wrote about it at the time: the move from training for vanity to training for longevity. The work I am most proud of in my career has that quality. It lasted. The organizations that own it today do not think of it as a transformation they survived. They think of it as how they operate. Change is not a program to them. It is a reflex. A competitive advantage.

That is the version of your organization that we need to build. Not the one that completes the next transformation. The one that never needs another one.

Ready to build the muscle?

TSG helps enterprises build the internal capability to modernize continuously, not episodically. If your organization is ready to stop starting over and start building change resiliency, let’s talk.

There is a particular kind of truth that only becomes visible in retrospect. The kind that was always operating in the background, shaping outcomes, but had no name yet. The product model is one of those truths.

The Mountain as a Product Lab

There is a particular kind of truth that only becomes visible in retrospect. The kind that was always operating in the background, shaping outcomes, but had no name yet. The product model is one of those truths.

In the winter of 2011, somewhere in the Appalachian highlands during a cold-weather direct action training exercise, a group of U.S. Army Special Forces soldiers were doing what they always did: they were breaking things. Never carelessly, always deliberately. The cold had stiffened the articulation points on a prototype boot designed for rapid elevation changes. A moisture-wicking base layer was wicking in the wrong direction under sustained exertion. A load-bearing integration panel on a plate carrier vest was creating friction at exactly the wrong point of the hip flexor during a tactical low-crawl.

I know this because I was tracking it. Not from a desk at Under Armour’s headquarters in Baltimore. Because feedback like this was the product. Between 2010 and 2013, I served as Global Product Line Manager for apparel, footwear, and accessories within Under Armour’s Military Tactical Business Unit. During that period, our team did something that the formal language of product management had not yet found words for. We built a real-time product development cycle, tested not in a usability lab or a survey panel, but on the side of mountains and inside live training environments.

We didn’t call it continuous discovery. We didn’t call it an empowered cross-functional team. We didn’t have a product development lifecycle document or a project backlog. We had soldiers, altitude, cold, and mere minutes between prototype and field correction. And looking back now, as enterprise organizations worldwide struggle to internalize what the market now calls the product model, I believe those mountain exercises were not just early prototyping. They were an early expression of the only way product has ever actually worked.

“The mountain doesn’t lie to you. A soldier in a cold-weather direct action environment cannot tell you politely that your moisture management system has a problem. He shows you. His core temperature tells you. His movement efficiency tells you.”

The moment you put distance between the people building a product and the people using it, whether that distance is geographic, organizational, or mediated by requirements documents, you introduce a translation layer that distorts feedback. Requirements become proxies for needs. Specifications become proxies for outcomes. The organization starts optimizing for hitting the proxy rather than achieving the underlying objective.

On the mountain, there were no proxies. The boot either performed at the required temperature gradient or it did not. The vest either distributed load acceptably during a six-hour movement or it created injury vectors. This is, in miniature, exactly what the modern product model attempts to replicate at enterprise scale. The difference is that in 2026, we have tools that can make the feedback loop not just fast, but effectively continuous, and intelligent in ways that were previously impossible.

What We Mean When We Say “Product Model”

The phrase has proliferated enormously in the last several years. Like most good ideas that achieve mainstream adoption, it has picked up conceptual debris along the way. Let’s be precise.

A product model is not an organizational chart. It is not a methodology. It is not agile, or lean, or any named framework whose certification you can hang on a wall. It is something more fundamental: the answer to the question, how does your organization decide what to build, learn whether you built the right thing, and improve continuously on the basis of that learning?

Practitioners across multiple traditions have arrived at the same destination by different roads. Marty Cagan and colleagues at SVPG define the product model around a single organizing principle: empowered teams, given a clear problem to solve and the authority to solve it, consistently outperform feature teams executing a predetermined roadmap. Teresa Torres, in Continuous Discovery Habits (2021), operationalizes what this looks like in practice: small cross-functional teams maintaining ongoing, structured contact with customers on a weekly cadence, using that contact to generate and test assumptions before committing resources. Enterprise scaling frameworks like SAFe extend these principles into larger organizational contexts, addressing the coordination and governance layers that emerge when dozens of teams need to operate coherently toward shared outcomes.

These are not competing philosophies. They are different lenses trained on the same operating reality. What they share is more important than what distinguishes them.

Both SVPG and SAFe converge on a distinction that sounds simple and is, in practice, organizationally difficult.

Project model: A fixed scope is delivered by a fixed date. Success equals delivery. The team disbands. The learning dissipates.

Product model: A continuous mission is pursued by a persistent team. Success equals outcome. The learning compounds. The capability grows.

What strikes me about the cross-functional team structures that serious enterprise organizations are now formalizing is not that they are new. It is that they are a formal articulation of something effective product teams have been doing informally for decades. In garages, on factory floors, in field training environments, and increasingly inside AI-augmented operations centers. The terminology evolves. The underlying logic does not.

The deeper challenge is not conceptual clarity. Most product leaders understand the distinction between project and product. The challenge is organizational: implementing a product model on top of an organizational architecture designed for projects. Funding models, governance structures, headcount allocation, performance measurement, and leadership behavior all evolved to support project delivery. Changing the operating model without changing those underlying systems produces the hybrid that large enterprises know all too well: agile language on top of waterfall execution.

Research across multiple sources puts the failure rate of product model transformations in large enterprises between 70 and 97 percent. The model works. The foundation underneath it usually does not.

Testing on the Side of a Mountain

When I joined Under Armour’s Military Tactical Business Unit, the company was navigating a fascinating inflection point. Under Armour had built its brand on performance compression wear for athletes, a domain where feedback loops are relatively controlled. You put an athlete in a garment, they compete, you observe and iterate. The cycle, while fast, operates in a bounded environment.

The military and tactical context was categorically different. Our customers were not competing in a stadium. They were operating in environments that no human-factors lab could replicate: sustained cold-weather movement at altitude, rapid transition between exertion states, load-bearing configurations that interacted unpredictably with layering systems, and mission contexts in which a product failure was not a performance inconvenience but a potential safety or operational incident.

Standard development timelines were insufficient. What we needed was something closer to what Teresa Torres would later describe as continuous discovery: a state in which the team maintains ongoing, direct contact with the people who use the product in the conditions where it actually operates. We arrived at this not through design theory, but through necessity.

Prototype garments and load-bearing equipment were introduced into live training exercises with operational units. We didn’t send a survey. We sent the product into the environment and established feedback mechanisms with the users inside it: performance debrief sessions, materials analysis after sustained wear, biomechanical observation during training scenarios, and direct dialogue with operators about what the product did and did not do under stress.

The feedback was not filtered through a procurement specification. It came directly from people whose professional lives depended on their equipment performing correctly. The valuable-feedback-to-junk ratio was extraordinary. And the iteration cycle compressed to hours rather than months, driven by the structure of training cadence.

What the Mountain Taught About Scale

The most important lesson from that period was about the relationship between user proximity and product quality. Every layer of organizational distance between builder and user is a translation layer. Requirements become proxies for needs. Specifications become proxies for outcomes. Roadmaps become proxies for strategy. And organizations gradually shift their energy from solving customer problems to defending their interpretations of them.

On the mountain, that dynamic was impossible. The feedback was unambiguous and immediate. And because the team was embedded close enough to receive it directly, we could act on it quickly.

This is, in miniature, exactly what the modern product model attempts to replicate at enterprise scale. The difference is that in 2026, we have tools that can make the feedback loop not just fast, but effectively continuous, and intelligent in ways that were previously impossible.

A Wireless Insurance Provider Discovers What We Already Knew

Consider a wireless insurance provider, the kind that sits behind your carrier’s handset protection program, handling device replacement claims and customer service for a few million policyholders.

In 2019, their call center was the canonical project-model operation. Agents handled claims according to a script developed by a product team that had last conducted systematic customer interviews eighteen months earlier. The claims processing platform, built in 2014, had been maintained through a series of discrete projects, each scoped and funded separately, each delivering against a requirements document already outdated by the time code shipped.

The system worked, in the narrow sense that claims were processed. But the metrics told a more complicated story. Average handle time was well above industry benchmarks. First-call resolution was declining. CSAT scores were flat at a level leadership characterized as “acceptable,” which in practice meant they had stopped trying to improve it.

The issue was not effort or talent. It was architecture: the organizational architecture of how the product was developed and improved. There was no continuous feedback loop between the people experiencing the product and the people shaping it. There was no persistent, empowered team with a clear outcome mission, ongoing customer access, and the organizational authority to act on what they learned. There was a roadmap. There were project teams to execute it. And there was a growing distance between what customers actually needed and what the organization was building.

The Transformation

Beginning in 2021, the organization restructured around a product model. The change was not primarily technological. It was organizational.

A cross-functional team was assembled around the claims resolution product: engineers and a product manager, yes, but also a UX researcher embedded in the call center two days per week, a data analyst with direct access to call recordings and resolution metadata, and a customer success partner maintaining direct relationships with frontline agents who provided ongoing feedback on product friction.

The team’s mandate was redefined from “deliver features on the roadmap” to “improve claims resolution outcomes.” This shift, from output accountability to outcome accountability, is the pivot on which effective product models turn. Cagan and his SVPG colleagues call it the move from feature teams to empowered product teams. Torres calls it the shift from build-trap thinking to continuous discovery. Whatever you call it, the organizational experience is the same: the team stops asking “what did we ship?” and starts asking “what did we change?”

The critical shift was governance, not technology. Leaders gave up control of the what, specific features and delivery dates, in exchange for greater influence over the why: strategy, outcomes, mission. Most found this harder than they expected.

Within twelve months, average handle time had decreased significantly. Not because of a technology revolution. Because of a series of small, evidence-based product improvements discovered through continuous engagement with agents and customers: a simplified device verification flow, a proactive status update system that eliminated a large share of inbound status-check calls, and a contextual knowledge surface that surfaced relevant policy information to agents at the precise moment they needed it. None of these improvements appeared on the original roadmap. All were discovered through ongoing, embedded customer contact.

Then AI Arrived, and the Cycle Got Faster

In 2023, the organization began integrating AI-powered capabilities: an AI-assisted triage system that pre-classified inbound claims by complexity and routed them accordingly; a real-time transcription and sentiment analysis system providing supervisors with live call quality indicators; and an automated processing pathway for straightforward device replacement claims requiring no human agent involvement.

This reflects an industry-wide shift. According to McKinsey’s 2024 analysis of AI in insurance, UK insurer Aviva deployed more than 80 AI models in its claims domain, cutting liability assessment time for complex cases by 23 days, improving routing accuracy by 30 percent, and reducing customer complaints by 65 percent. Broadly, AI assistance has reduced overall claims resolution time by as much as 75 percent in high-performing implementations, from 30 days to under 8, with routine claims moving from a week or more down to 24 to 48 hours.

The AI system didn’t tell us what to build. It told us, faster and more clearly than anything before it, what wasn’t working, and for whom, and under what conditions.

What these AI systems did, beyond their immediate functional benefits, was something more structurally significant: they created an unprecedented volume of continuous feedback. Every automated claim that succeeded or failed generated data. Every sentiment inflection in a live call was timestamped and tagged. Every routing decision could be evaluated against its outcome. The product was, for the first time, generating its own discovery data at scale.

This is where the product model and AI become genuinely inseparable. Not because AI replaces the human judgment at the center of good product work. It does not, and the organizations that believe it does will discover this expensively. But AI provides the feedback infrastructure that makes continuous discovery operationally feasible at enterprise scale.

What the Frameworks Got Right, and Where Most Enterprises Are Still Stuck

Multiple research streams now agree on why product model transformations fail at scale. The model itself works. The failure is almost always organizational readiness, not conceptual validity.

The root cause is consistent across frameworks and traditions. Cagan and his SVPG colleagues argue in TRANSFORMED (2024) that the degree of change required is more disruptive than most companies expect, not because the principles are complicated, but because they require genuine behavioral change from senior leaders, not just organizational restructuring. SAFe’s enterprise guidance points to the same failure mode: building a product-based way of working on top of an organizational culture optimized for centralized decision-making and project delivery.

Both diagnoses point to the same root cause: product model adoption is a leadership transformation before it is an organizational one. You can restructure teams, rename roles, and stand up discovery rituals without changing the underlying dynamic in which senior leaders maintain control over the what, the specific features, timelines, and delivery commitments, rather than the why, the strategy, outcomes, and customer problems the team is authorized to solve.

This produces the hybrid that large enterprises know all too well. Teams that are nominally empowered but practically constrained. Discovery rituals that generate insight but no authority to act on it. Roadmaps that are labeled outcomes but function as feature delivery plans. The language of product model maturity layered on top of project model execution.

The Three Foundations

Across the practitioners and frameworks that have studied enterprise product transformation most rigorously, three non-negotiable conditions emerge. Each is load-bearing. Addressing only one or two of them produces stall, not transformation.

Team and technical agility. Teams need the structural conditions to move fast: small enough to coordinate without ceremony, persistent enough to develop domain knowledge over time, and cross-functional enough to carry a problem from discovery through delivery without handoffs that introduce delay and distortion. Technical practices matter here too. Continuous delivery, automated testing, and modular architecture are not engineering preferences. They are organizational capabilities that determine how quickly a team can act on what it learns.

Strategy clarity and outcome orientation. Teams need to know what they are optimizing for at a level of precision that makes daily decisions possible without escalation. OKRs and similar instruments are not about measurement. They are about communication: translating organizational strategy into team-level operating clarity. Without this, empowerment is directionless and accountability is theater.

Leadership behavior, not just structure. The product model asks senior leaders to give up control of the what in exchange for greater influence over the why. Most senior leaders in large organizations have built their careers on being good at controlling the what. The transition requires a genuinely different kind of leadership fluency. As Torres frames it in Continuous Discovery Habits, the team closest to the customer should have the most authority over the solution. In most large organizations, the inverse is true. Changing this requires sustained behavioral change at the leadership level, not just a new org chart.

The Leadership Paradox

The hard work is not in the ceremonies or the tooling. The hard work is in the leadership decisions that either enable or disable the model.

Dedicated cross-functional teams require leaders to give up the resource allocation control that matrix organizations are designed to provide. Outcome-based deliverables require leaders to accept the ambiguity of result-based measurement rather than the false certainty of feature delivery metrics. Continuous learning requires leaders to treat team capability development as a strategic investment rather than a cost to minimize.

In the Under Armour military context, this leadership question was answered by the nature of the customer relationship. When your end users are operational units with specific mission requirements and the organizational credibility to specify what they need with clarity and authority, it is very difficult for a product leader to substitute their own judgment for that of the user. The customer context forced a kind of organizational humility that civilian product organizations often have to cultivate deliberately.

The best product leaders I have worked with share this quality: a genuine conviction that the customer’s reality is the product’s truth, and a willingness to let that reality reshape their assumptions in real time.

A Brief History of How We Got Here

2010 to 2013. Under Armour’s Military Tactical Business Unit embeds prototype garments and equipment in live training exercises, creating near-real-time feedback cycles that anticipate the continuous discovery discipline by a decade. The operating insight: user proximity is not a research technique. It is an organizational design principle.

2017 to 2020. Two bodies of product thinking mature in parallel. Cagan’s revised INSPIRED (2017) and EMPOWERED (2020) formalize the vocabulary of empowered product teams and outcome orientation for technology companies. Enterprise scaling frameworks evolve their product delivery competencies to place customer-centricity and continuous feedback at the center of delivery at scale.

2021. Teresa Torres publishes Continuous Discovery Habits, providing the operational framework for what weekly customer engagement by the building team actually looks like in practice.

2022 to 2024. Large industrial, financial, and insurance organizations begin serious attempts at product model adoption. TRANSFORMED (2024) and LOVED (2022) complete the SVPG series. Research from McKinsey and others begins documenting the gap between pilot success and enterprise-scale transformation.

2023 to 2024. Generative AI and intelligent automation begin augmenting product operations at scale. McKinsey reports that leading insurers are deploying dozens of AI models in the claims domain, achieving routing accuracy improvements of 30 percent or more and customer complaint reductions of 60 to 65 percent. The AI system becomes feedback infrastructure, generating continuous discovery feedback from every customer interaction.

2025 to present. The distinction between “building a product” and “operating a continuously improving system” collapses. Full AI adoption in the insurance sector jumped from 8 percent to 34 percent year-over-year between 2024 and 2025. The product model becomes the only viable organizational architecture for companies competing in AI-native markets.

The Road Ahead

The fundamental logic of the product model is not new. It is, in its essentials, the same logic that governed effective product development long before anyone had a name for it. It is the logic of the mountain exercise, of the embedded prototype cycle, of the team that stays close to the user and lets user reality shape product direction. What is new is the scale at which that logic can now operate, the speed at which feedback can now travel, and the intelligence that AI can bring to the task of making that feedback legible.

For a wireless insurance provider running AI-powered claims triage and automated processing, the product is no longer a static artifact that improves in discrete quarterly releases. It is a living system that learns from every interaction, surfaces its own improvement opportunities, and delivers value in increasingly precise alignment with individual customer needs. The product model is not just the organizational structure that governs this system. It is the only organizational structure that can keep pace with it.

When I was tracking boot performance on a hillside in Appalachia, I had no idea I was doing product management. I was just trying to make something work better for people who needed it to. That impulse, that fundamental orientation toward the user’s reality, is the origin of everything that the product model tries to formalize.

AI gives us tools to pursue that impulse at a scale and speed that would have seemed implausible five years ago. The product model gives us the organizational architecture to use those tools well. And the mountain, wherever you find it, gives us the reminder that none of this was ever about the framework. It was always about getting close enough to the truth to do something useful with it.

The shift from project model to product model is not, in the end, a transformation of process. It is a transformation of relationship: a fundamental reorientation of the organization toward the people it serves, sustained by the structures, disciplines, and now the intelligent systems that make that reorientation durable. Organizations that make this shift will compound their advantage over time. Those that do not will find themselves increasingly unable to explain why their investments in technology and talent are not translating into outcomes. The gap between those two futures is the gap between project and product.

— Adam Mattis

Working on This Problem? The Select Group Can Help.

The distance between understanding the product model intellectually and executing it inside a real organization, with real teams, real stakeholders, and real AI infrastructure to integrate, is where most transformations stall. That gap requires more than a framework. It requires the right people, the right capability, and a partner who has built at the intersection of technology and organizational change.

The Select Group (TSG) has spent more than three decades helping Fortune 500 and mid-sized companies turn ambitious initiatives into working outcomes.

Headquartered in Raleigh, NC and operating across the United States and Canada, TSG delivers end-to-end technology consulting across Data and AI, Digital Transformation, Cloud and Infrastructure, and Agile and Product practices. Their adaptive model brings together solutions strategy, high-caliber technical talent, and dedicated engagement oversight: the three things most organizations are missing when a product transformation quietly becomes just another project.

If your organization is asking how to move from shipping features to creating outcomes, how to build continuous discovery into your operating rhythm, or how to make AI a genuine part of your product feedback loop rather than just a technology investment, TSG is the partner equipped to help you answer those questions with action, not just analysis.

Connect with Adam on LinkedIn to continue the conversation.

References

[1] Scaled Agile, Inc. (2025). The Product Operating Model at Scale: Three Keys to Implementation Success. Executive Guide, April 2025. scaledagile.com

[2] Cagan, M., Hickman, L., Jones, C., Idiodi, C., and Moore, J. (2024). PRODUCT IS HARD: SVPG Box Set. John Wiley and Sons. ISBN: 9781394326266. svpg.com/books

[3] Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC. ISBN: 9781736633304. producttalk.org

[4] McKinsey and Company. (2025). The Future of AI in the Insurance Industry. mckinsey.com

[5] Datagrid. (2025). 42 Insurance AI Agent Statistics (Adoption and Impact). datagrid.com

BLUF: The Software Development Lifecycle was built for a world where software shipped on a schedule. Unfortunately, our AI-augmented world doesn’t work on a schedule. CIOs who keep mapping AI initiatives onto SDLC assumptions are doing worse than just slowing things down. They’re structurally misaligned with how value actually gets created now, and the gap between organizations that figure this out and the ones that don’t is widening faster than most people realize.

The pattern is undeniable. The AI pilot lands well. Leadership gets excited. Someone stands up a project team, drops it into the delivery framework, and the whole thing slows to a crawl. Eighteen months later, the board asks what happened, and the honest answer nobody gives is: we tried to deliver a different kind of work using a process designed for a different era.

I’ve seen this play out time-and-time again; delivery frameworks failing, people scrambling, only to be left asking “why?”. The teams aren’t failing. The technology isn’t failing. The system is failing. (Where have I seen this movie before?) In this case, the system is the SDLC.

Let’s be clear, this isn’t a process optimization problem that we can “Lean” our way out of. You can’t iterate your way out of it, either. What’s breaking is more fundamental than that, and the organizations getting ahead of it aren’t doing it by running better retrospectives.

What the SDLC Was Built For

To understand why it’s breaking, it helps to understand what it was designed to solve.

Enterprise software development in the mainframe and early client-server era was expensive, slow, and largely irreversible. Hardware constraints meant that rework was operationally dangerous. Requirements had to be locked early. Testing had to be exhaustive. Release cycles were long because deployment itself was a high-stakes event with real failure modes.

In my early days of operations consulting, I remember working with an enterprise client who was certain there was no way they could release more frequently than once per three years due to the dangers of the “corporate load.” We managed to reduce that cycle to a quarterly release, but doing so safely required re-architecting the entire tech-stack and a good bit of their business operations as well. Too many consultants are quick to peg this a “leadership problem” without thoroughly understanding the complexity of the operations. The point is, the SDLC as we know it served a purpose. And, even in 2026, in some enterprises, that context still exists.

The SDLC emerged as a rational response to those constraints. Define the work, sequence it, gate it, ship it. That model worked remarkably well for decades, and it produced a generation of enterprise delivery professionals who built discipline around it.

Agile modernized the cadence. Two-week iterations instead of multi-year waterfall projects. Incremental delivery instead of big-bang release. Continuous feedback instead of requirements locked in Phase 1. It was a genuine improvement, and it’s the right model for a wide class of software work.

But here’s what Agile didn’t change: the underlying assumption that the job is to build a defined thing to a defined specification, and ship it.

That assumption is what AI breaks.

AI Development Doesn’t Have a Finish Line

Traditional software is deterministic. Given the same inputs, a well-built system produces the same outputs. You can write a requirement for it, test against it, and know when you’re done. The definition of done is binary: it works as specified, or it doesn’t.

AI systems are probabilistic. Given the same inputs, a model produces outputs that vary based on training data, fine-tuning decisions, inference parameters, and the statistical properties of the task. There is no requirement you can write that fully specifies model behavior in advance, because the model’s behavior is an emergent property of training on data, not a direct implementation of logic.

This has concrete consequences for how an enterprise manages delivery. You don’t write requirements for a model. You define a problem, form a hypothesis, run experiments, evaluate outputs against business outcomes, deploy, observe real-world behavior, and iterate based on what you learn. The specification for success is probabilistic and contextual, not binary and universal.

A model that performs well in evaluation can perform differently in production because production data has different statistical properties. A model that performs well in one customer segment can underperform in another. A model that performs well in March can drift by September because the world it’s predicting has changed.

There is no “shipped” state that ends the development work. The model in production is a living artifact. It requires ongoing monitoring, evaluation, retraining, and refinement as long as it’s in use.

The model in production is still a development artifact. There is no “done.”

Sources: Andrew Ng, “AI Transformation Playbook,” Landing AI; Sculley et al., “Hidden Technical Debt in Machine Learning Systems,” NeurIPS 2015; Google, “Practitioners Guide to MLOps,” 2021

When You Force AI Into an SDLC Container

When AI development gets managed through SDLC assumptions, the consequences are predictable and consistent. I’ve seen the same patterns across clients regardless of industry, size, or technical maturity.

• Requirements get written for unknowable things. Business stakeholders are asked to specify model behavior before anyone has run a single experiment. The result is requirements that are either so vague as to be useless or so specific as to be wrong. Neither gives the team what it needs to deliver actual business value.

• Iteration velocity becomes a fiction. AI development work doesn’t decompose cleanly into stories and tasks. The value isn’t in completing a ticket, it’s in learning whether a hypothesis is true. A sprint where the team ran three experiments and learned that two approaches don’t work is a successful sprint. In an Agile framework, it looks like zero velocity. So teams game the metrics.

• Definition of done gets misapplied. A model is never done; it’s just performing at a certain level given current data and conditions. Organizations that apply traditional done criteria to AI work end up either declaring victory on systems that aren’t actually working, or never declaring anything done because the goalpost keeps moving.

• Production becomes an afterthought. SDLC treats production as the end state. In AI, the production signal is a development input. What happens when real users interact with the model is data you need to improve it. Organizations that separate development from operations for AI work are cutting off their most valuable feedback source.

• Governance creates adversarial dynamics. Phase-gate reviews were designed to catch scope creep in projects with known deliverables. They are not equipped to evaluate AI initiatives where the right path forward isn’t knowable in advance. So they slow things down without adding value. Teams learn to perform for the review rather than doing the work that matters.

Sources: Amershi et al., “Software Engineering for Machine Learning: A Case Study,” Microsoft Research, 2019; Sculley et al., NeurIPS 2015

The ADLC Is a Different Set of Physics

The AI Development Lifecycle isn’t a replacement for discipline, but a discipline built for different physics. And the differences aren’t cosmetic.

Where SDLC optimizes for predictability, ADLC optimizes for learning velocity. The measure of a healthy ADLC isn’t how closely the team hit their iteration commitments. It’s how quickly they moved from hypothesis to validated outcome, and how much of what they learned in production shaped the next iteration.

Where SDLC treats production as the endpoint, ADLC treats production as a continuous feedback source. Monitoring, observability, and model performance tracking aren’t post-delivery operations concerns. They are core development infrastructure that has to be designed and built before the first model ships.

Where SDLC separates development from operations, ADLC requires them to be integrated. MLOps, the operational discipline that makes this integration work, has matured considerably. But most enterprise organizations haven’t restructured their teams to take advantage of it, because doing so requires dismantling organizational boundaries that have been in place for decades.

Where SDLC measures quality as conformance to specification, ADLC measures quality as performance against outcomes.

A well-functioning ADLC asks:

• What business outcome is this model driving?

• How is that outcome trending over time?

• Where is the model underperforming relative to opportunity?

A well-functioning SDLC asks:

• Are we on schedule?

• Are we on budget?

• Did we hit the acceptance criteria?

Those are the right questions for the wrong problem.

The organizations getting real value from AI are not the ones with the best SDLC hygiene. They’re the ones that stopped asking their SDLC to do work it wasn’t designed to do.

Sources: Kreuzberger et al., “MLOps: Overview, Definition, and Architecture,” 2022; Google, “Practitioners Guide to MLOps,” 2021

Why the Mismatch Keeps Winning

If the problem is this clear, why is it so consistent? Because the incentive structures that govern enterprise technology delivery are built on SDLC assumptions, and those structures don’t change just because the work does.

• Funding models expect a scope, a timeline, and a deliverable. Capital expenditure frameworks are designed around projects with terminal endpoints. AI capabilities don’t have terminal endpoints. Organizations that fund AI initiatives the same way they fund a new ERP implementation end up either underfunding continuous development work or forcing it into artificial project structures that don’t reflect how the work actually operates.

• Governance frameworks expect phase gates. ADLC’s continuous iteration model looks, to a traditional governance body, like a team that never finishes anything. The natural institutional response is to add more structure: more gates, more documentation requirements, more review cycles. The structure makes the problem worse.

• Organizational metrics reward on-time, on-budget delivery of defined scope. They don’t have vocabulary for “we ran twelve experiments, eight didn’t work, four produced insights that changed our approach, and we’re now three months ahead of where we’d be.” That outcome looks like replanning. It gets scored as underperformance.

• Talent structures were built around role definitions that separate development from operations. The people who build software and the people who run it are different teams, different career tracks, different management chains. AI work requires them to be the same conversation. Reorganizing around that requirement is hard, and most organizations haven’t done it.

The people running these frameworks aren’t the problem. They built strong discipline for real problems. The issue is the assumption that the same framework governs work that operates by completely different rules. That assumption is invisible until it costs you something.

For CIOs, the practical consequence is a team executing well on the wrong model and getting punished for it. That is a leadership problem, not a delivery problem. It won’t be solved by better retrospectives.

What the Organizations Getting It Right Do

The enterprises I’ve seen navigate this transition successfully share a consistent set of moves. None of them are complicated in concept. All of them are hard in practice because they require changing structures that have organizational momentum behind them.

• Reform the funding model first. AI capabilities need to be funded as ongoing operational investments, not capital projects. The SAFe Lean Portfolio Management model offers a practical solution: replace traditional project-based funding with Lean Budgets allocated to value streams, governed by guardrails rather than detailed upfront business cases. Funding flows to the capability continuously, and reallocation decisions happen at cadence-based portfolio sync events rather than through formal change control. For organizations with existing SAFe adoption, this isn’t a new concept, it’s applying LPM discipline to AI investment the same way you’d apply it to any product value stream. For organizations without it, the principle still translates: fund the team and the capability, not the project. Treat improvement over time as a success criterion, not an exception. Frame it as a shift from “build and done” to “build and run” — a model finance already understands from infrastructure investment, and one that SPM practitioners recognize as the natural extension of participatory budgeting into AI operational spend.

• Redesign governance, don’t bypass it. The question shifts from “is this project on track against original scope?” to “is this capability performing against business outcomes, and are we learning fast enough to keep improving it?” Portfolio Kanban gives you the structural answer here: AI initiatives flow through portfolio-level visibility as epics, with progression gates tied to hypothesis validation rather than phase completion. Instead of asking “did we finish the build phase,” you’re asking “did we validate the business hypothesis that justified this investment?” That’s a meaningful governance event. Pair that with Weighted Shortest Job First prioritization at the LPM level and you have a framework for making active reallocation decisions based on learning, not waiting for a quarterly steering committee to approve a change request. For organizations with mature SPM functions, this maps directly to the strategic portfolio review cadence: AI capabilities belong on the portfolio Kanban board alongside other value stream investments, governed by the same outcome-based guardrails, not siloed into a separate “AI governance” structure that operates outside normal portfolio discipline.

• Change what you measure. The delivery metrics that matter for SDLC tell you nothing useful about AI initiative health. The metrics that matter for ADLC: how quickly are we moving from hypothesis to validated outcome? Is model performance improving or degrading over time? What’s our data drift detection latency? How much of what we observe in production is feeding into the next development cycle?

• Integrate development and operations structurally. Some organizations start by creating AI capability teams that own both development and operations for specific use cases, then use those teams as a model for broader structural change. The common thread is making the production signal a first-class development input, whatever structural form that takes.

• Sequence the transition intentionally. The organizations that try to shift everything at once tend to create chaos without benefit. The ones that do it well start with one or two AI capabilities of sufficient strategic importance to justify building the right infrastructure around them, then use those as proof points to drive broader organizational change.

A Note on What This Is Not

This is not an argument against rigor. SDLC disciplines emerged because software development without structure produces expensive, late, and incorrect software. The discipline is real. The need for discipline in AI development is equally real.

What ADLC rejects isn’t rigor. It rejects the specific application of SDLC-shaped rigor to AI-shaped work. The rigor looks different: hypothesis-driven experimentation instead of upfront requirements, outcome metrics instead of acceptance criteria, continuous monitoring instead of pre-release testing, production observation instead of deployment as endpoint.

This is also not an argument that SDLC is dead. A significant portion of enterprise technology work is still traditional software development, and it should still be managed with SDLC discipline. The point is that organizations need to distinguish between which work fits which model, and stop applying SDLC assumptions uniformly across a portfolio that increasingly contains AI capabilities requiring a different approach.

The CIOs I see struggle are the ones who either try to run AI work like software development, or overcorrect by treating all AI work as uniquely ungovernable. The right answer is structural clarity: different work requires different delivery models, and the organization needs the capability to run both.

What This Is Asking of You

The technology leaders positioned well on the other side of this transition aren’t the ones who ran the fastest pilots. They’re the ones who recognized early that delivering AI value requires different organizational infrastructure, and made the structural investments to build it.

That work is not glamorous. Funding model conversations with CFOs who have capital budgeting frameworks that are forty years old. Governance redesign with boards who want phase gates and milestone reviews. Metric evolution with business stakeholders who want to know what they’re getting and when. Team restructuring with engineering leaders who have built their careers around role definitions that need to change. None of it generates the announcement that a new AI product went live. All of it determines whether the AI capabilities you’re building actually improve over time, or plateau and decay.

The data on where most organizations are right now isn’t encouraging. McKinsey’s 2024 State of AI report found that while 72% of organizations had adopted AI in at least one business function, fewer than 10% described themselves as having mature AI deployment capabilities — defined as the ability to move from pilot to production to continuous improvement systematically. The gap between “we ran some pilots” and “we have an organizational capability to develop and operate AI” is where most enterprises currently live.

That gap isn’t a technology problem. It’s an organizational architecture problem. And it won’t close by running better sprints.

The CIOs who look back on this period with satisfaction won’t be the ones who ran the most pilots. They’ll be the ones who built the organizational infrastructure AI actually requires.

Sources: McKinsey Global Institute, “The State of AI in 2024,” May 2024; Gartner, “AI Engineering: A Key Capability for Scaling AI,” 2023

The Takeaway.

The SDLC was a genuine achievement. The discipline it created, applied at scale, produced decades of reliable enterprise software delivery. That’s not nothing.

The work has changed. The work of developing AI capabilities operates by different rules, and the organizational infrastructure required to do it well is different from the infrastructure enterprises have spent decades building. The gap between those two realities is where most AI investment gets lost right now.

The leaders who navigate this well won’t be the ones who shipped the most pilots. They’ll be the ones who recognized that the organizational architecture question is the real one, made the structural investments to answer it, and built the continuous capability to develop, operate, and improve AI in a way that compounds over time.

That’s harder work than optimizing a sprint ceremony. It requires holding the tension between near-term pressure that is absolutely real and structural change that takes longer than a quarter but matters more than any individual initiative. And it requires someone in the room willing to name the actual problem instead of proposing a better version of the solution that isn’t working.

If you’re a CIO working through what that transition looks like in your organization, I’m interested in that conversation. The variables are real, the path is navigable, and the distance between organizations that figure it out and the ones that don’t is compounding faster than most people want to admit.

Care to chat? Find me on LinkedIn.

BLUF: Enterprise leaders are making AI efficiency decisions optimized for the wrong time horizon. The demand consequences are economy-wide, they’re already starting, and they belong in your model now, regardless of what you sell or who you sell it to.

You’ve seen the Block announcement. Jack Dorsey cut nearly half his workforce and framed it as an AI efficiency play. Then every board and CEO watched the stock jump 24%.

Now the question is sitting on the desk of every enterprise CEO: how much of this applies to us?

Over the last eighteen months I’ve been in that room across enterprise clients and PE advisory work, all around the world. The pattern I keep seeing is consistent enough that I want to name it directly, because I don’t see it being named at all anywhere else.

The leaders making these decisions aren’t wrong that AI creates genuine efficiency opportunity. They are, in many cases, running an incomplete model. They’re solving for the cost variable while leaving the demand consequence out of the forecast entirely. The incentive structure they operate inside makes that omission not just understandable but, in the short term, rational.

That’s the barrel of the gun the global economy is staring into. And before I explain the demand consequence, I want to address an error I see in almost every version of this conversation: the assumption that demand risk only applies to companies that sell directly to consumers or to knowledge workers specifically.

It doesn’t. The ripple is economy-wide, and world-wide. If your current model doesn’t account for that, it isn’t a complete model.

The efficiency gain is undeniable. The question is whether you’re modeling the full cost of how you capture it — and on whose watch the bill lands.

The Pattern I See

Let me be specific, because vague warnings about systemic risk are easy to dismiss.

In PE-backed enterprises, the pressure comes from the fact that the cheap pandemic-era debt they leveraged to gain liquidity in their acquisitions is now expensive. Variable interest is compressing margins, and the board needs EBITDA improvement to support an exit thesis. AI-driven workforce reduction is a clean story. It improves the multiple, it’s defensible to the next buyer, and the timeline to exit means the operational consequences of moving too fast land after the transaction closes. The incentive to optimize for the near-term number is almost perfectly constructed.

In public enterprises, the mechanism is different but the outcome is similar. Quarterly earnings pressure, institutional investor expectations, and compensation structures tied to near-term performance create a planning horizon that systematically discounts consequences arriving beyond the current cycle. When Block cut four thousand people and the stock jumped 24%, every public company CEO with a board to answer to ran the same mental calculation. The market just told them what it rewards.

In both cases, what gets left out of the model is the same: a serious analysis of what happens to the broader economy, and ultimately to demand across every sector, when you systematically eliminate the wages of people who spend almost all of what they earn.

That omission isn’t stupidity, but a systemic byproduct of how decisions get evaluated and rewarded. But it’s still an omission, and the consequences will impact us all.

The Economy Runs on Middle-Class Spending.

Here is the foundational fact that most AI workforce conversations skip entirely: consumer spending accounts for approximately two-thirds of U.S. GDP. Not corporate investment. Not government spending. Consumer spending.

Source: U.S. Bureau of Economic Analysis; BLS Consumer Expenditure Surveys, 2024

The professional middle class, the knowledge workers earning roughly $75,000 to $150,000, represents the core engine of that spending. Not the wealthiest households, whose consumption is increasingly driven by asset appreciation rather than wages, and who spend a smaller share of each incremental dollar. Not lower-income households, who are already stretched. The middle. The people buying cars on five-year loans, renovating kitchens, taking the family vacation, replacing electronics, furnishing homes, and spending steadily on Amazon.

When those wages disappear, the spending doesn’t get redirected. It contracts. And that contraction doesn’t stay contained to the categories those workers were buying from directly.

Consider the chain from a single layoff decision: A financial analyst at a mid-size firm loses her job to AI automation. She stops the kitchen renovation mid-project. The contractor who had two months of work loses the job. The contractor’s spending at the local hardware supplier drops. The supplier’s transaction volume, processed through a payment platform, declines. The building materials distributor sees order volume soften. The trucking company that moves those materials runs fewer loads. The fuel supplier sells less diesel. The regional bank that lends to all of these businesses sees loan demand weaken.

Your SaaS payment platform never sold anything to a financial analyst. But it just felt her layoff.

There is no sector structurally insulated from a contraction in the spending of people who earn $75,000 to $150,000.

This is not a hypothetical chain. It is how economic multipliers work, and it is why the Federal Reserve, the Congressional Budget Office, and every serious macroeconomic model treats middle-income wage contraction as a systemic risk.

What the Data Shows

If you look at the numbers, the canary has already died in the coal mine. But you need to know where to look.

The displacement is concentrating in exactly the income segment that drives the spending the broader economy depends on. In January 2025, the U.S. Bureau of Labor Statistics reported the lowest rate of job openings in professional services since 2013, representing a 20% year-over-year drop. Analysis by Vanguard found that hiring for positions paying over $96,000 annually had reached a decade low. White-collar job postings fell 12.7% between Q1 2024 and Q1 2025, while white-collar wage growth stalled even as blue-collar wages continued to rise. This is a structural shift in the professional labor market, not a cyclical one.

Sources: U.S. Bureau of Labor Statistics, January 2025; Vanguard Research, 2025; Revelio Labs White-Collar Labor Market Analysis, 2025

The consumer data is catching up. McKinsey’s ConsumerWise research found that 75% of U.S. consumers reported trading down in at least one spending category through 2025, with sentiment declining considerably from the start of the year. Cardboard box shipments — a reliable proxy for goods movement and middle-market consumer activity — have fallen to multi-year lows, with the decline concentrated among lower- and middle-income households.

Sources: McKinsey ConsumerWise, December 2025; Cascade Partners U.S. Consumer Economy Analysis, October 2025

There is a nuance here worth naming. Recent Moody’s Analytics data shows that the top 10% of earners now account for nearly half of all U.S. consumer spending, and that spending has been sustained by asset appreciation rather than wages. Goldman Sachs Research found no significant statistical correlation between AI exposure and broad labor market measures as of mid-2025, and projects that AI-related displacement effects tend to be temporary at the aggregate level.

Sources: Moody’s Analytics/Wall Street Journal, February 2025; Goldman Sachs Research, August 2025

Here is why those findings only reframe the problem.

An economy increasingly dependent on top-earner spending sustained by asset prices is an economy with a fragile consumption base. Mark Zandi at Moody’s said it directly: relying on stock-market-driven spending from the top 10% makes the economy more vulnerable, not less. The professional middle class — the segment now in the AI displacement crosshairs — is precisely the stabilizing layer between subsistence spending at the bottom and asset-driven spending at the top. Remove it, and you destabilize the entire economic engine.

For enterprise leaders, the diagnostic question is this: what percentage of your revenue — directly or through one or two steps in the value chain — is downstream of consumer discretionary spending driven by professional middle-class wages? For most Fortune 1000 companies, that answer is closer to ‘most of it’ than any current model reflects.

Reskilling Isn’t the Solution

There’s a standard response to this concern: workers will reskill. New jobs will emerge. Technology transitions always create as many opportunities as they eliminate.

Partially true and wildly overstated as a complete answer.

The WEF’s Future of Jobs Report 2025 — surveying over 1,000 employers representing 14 million workers — projects 92 million jobs displaced by 2030 and 170 million created, a net gain. But the WEF itself noted that these are not direct exchanges happening in the same locations with the same people. The challenge is the gap — geographic, temporal, and skill-based — between where jobs vanish and where new ones appear.

Source: World Economic Forum, Future of Jobs Report 2025

That gap is where the spending contraction lives. The net employment number over five years does not prevent a demand trough in years two and three. And years two and three are on your planning horizon.

The workers most exposed right now are mid-career knowledge professionals: analysts, coordinators, compliance roles, financial planning support, junior legal and consulting functions. These are not people who absorb a multi-year retraining program without meaningful financial disruption. The AI engineering roles being created require mathematical foundations that six-week bootcamps don’t produce. The trades pipeline isn’t designed for this volume or this demographic.

More fundamentally: every previous automation wave pushed displaced workers toward cognitive roles. This wave is targeting the cognitive layer directly. The refuge that absorbed previous displacement is being automated. The historical analogy being used to reassure people doesn’t hold in the way it’s being applied.

For enterprise leaders, the practical implication is this: whether or not displaced workers eventually find new roles, the demand consequence of the transition period belongs in your model. Reskilling optimism doesn’t eliminate the timeline mismatch. It just means you didn’t account for it.

What the Full Analysis Looks Like

The organizations I’ve seen navigate this well — the ones that captured genuine AI efficiency gains without creating the downstream problems I’m describing — ran a four-part analysis that most enterprise AI workforce discussions skip.

• First: demand exposure modeling. Not just cost reduction projections, but an honest mapping of your revenue base’s downstream exposure to middle-class wage contraction. This isn’t limited to your direct customers — it follows the value chain: who buys from your customers, and what drives their purchasing power? That exposure doesn’t show up in standard scenario planning, but it needs to.

• Second: workforce transition sequencing. The speed and order of headcount reduction matters as much as the final number. Where is human judgment genuinely irreplaceable in your value chain? What institutional knowledge leaves with the people you’re cutting? Which transitions can be managed through attrition and redeployment, and which can’t? Organizations that answer these questions before executing perform meaningfully better in the medium term than the ones that optimize for the speed of the announcement.

• Third: the trust variable. Your remaining workforce is watching. Your customers are watching. Your partners are watching. The reputational and cultural consequences of how you navigate AI workforce decisions will outlast the efficiency gain in both directions. I’ve seen organizations cut to a better multiple and lose the talent and customer relationships that justified the multiple in the first place.

• Fourth: competitive positioning for the recovery. The demand softening I’m describing is not permanent. Economies adapt and new equilibria form. The organizations positioned to capture the recovery are the ones that managed their human capital intelligently through the transition, not the ones that cut fastest and rebuilt from scratch. What does your organization need to look like on the other side of this, and are your current decisions moving you toward that or away from it?

This is a four-variable problem being solved as a one-variable problem in most boardrooms right now. That gap is where the real strategic risk lives.

The Silence is Deafening.

Most enterprise AI workforce discussions I’m aware of are structured only around a single question: “where can AI replace headcount?” This is not the wrong question, but only part of what needs to be considered.

The missing conversation is around the second-order consequence of these decisions on the broader demand environment, organizational capability, customer relationships, and competitive positioning. And are we prepared to manage those consequences, or are we going to discover them reactively in three to five years?

That conversation requires integrating workforce strategy, demand modeling, value chain analysis, and competitive scenario planning in a way that most enterprise planning cycles don’t naturally produce. It also requires someone willing to say the uncomfortable thing in the room: that the efficiency number your board is excited about is achievable, and the demand consequence might also be real, and both of those things can be true simultaneously.

In PE-backed environments especially, that conversation is hard to have because the exit thesis depends on a clean story. A clean story and a complete analysis are not always the same thing. The ones I’ve seen go sideways are usually the ones where that tension got resolved in favor of the story.

The Takeaway.

I’m not arguing against AI adoption. I’m arguing for a longer planning horizon and a more complete model.

The enterprise leaders who look back on this period with satisfaction won’t be the ones who cut fastest. They’ll be the ones who ran the full analysis, mapped the demand exposure across their value chain, sequenced the workforce transition thoughtfully, preserved what was valuable in their organizations, and came out positioned to capture the next growth cycle rather than be forced to rebuild from zero.

That’s harder work than a cost reduction initiative. It requires holding the tension between near-term pressure that is absolutely real and medium-term consequences that are equally real but less immediately visible. And it’s genuinely difficult to run that analysis from inside the same incentive structure that’s creating the problem.

If you’re working through AI workforce decisions right now and you want a thinking partner who will run the full model — not just the efficiency math, and not a pitch for a predetermined answer — I’m interested in that conversation.

Find me on LinkedIn. Tell me what you’re looking at. That’s where the useful conversation starts.