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.

I thought I was fast. The data disagreed.

I’m 43, and I recently took my pitbike to the track convinced I still had it. The lap times said otherwise. Turns out I’m not the only one with a perception gap.

A 2025 METR study found that experienced developers using AI coding tools actually took 19% longer to complete tasks, while believing they were 20% faster. The gap reveals something important: agentic AI isn’t a plug-and-play productivity boost. It’s a fundamentally different way of working that requires deliberate adoption.

Since ServiceNow Knowledge 25, I have been experimenting with agentic AI both on my own and with clients. What follows is what I’ve found to work, what I’ve broken, and the lessons I’ve learned so you don’t have to.

The Opportunity

By late 2025, industry surveys suggested 80-90% of developers were using AI tools in some capacity (per Stack Overflow’s 2025 Developer Survey and Google’s DORA Report). But most are still on autocomplete. Agentic tools (systems that reason, plan, execute multi-step changes, and iterate on their own) are an entirely different animal.

What we’re talking about is the speed at which a team can experiment and innovate. Complex refactors that used to eat an iteration. Migrations that would’ve taken months. Architectural changes that were “too risky” because nobody had time. Agentic tools make these manageable.

Early adopters report release cycles speeding up significantly in some cases. Fewer bugs because agents enforce standards automatically. For a growing org, this means scaling without ballooning headcount. Your senior team punches above their weight. Agents handle CRUD apps, simple tools, and API glue code at dramatically lower labor costs than a decade ago. Some teams report saving several hours per developer per week. For a 50-person team, that’s meaningful.

But remember: when you automate a broken system, you’re only perpetuating the pain inherent in that system. The productivity can be achieved, but only when the workflow is dialed in first.

For the Executive

If you’re in the C-suite, here is the BLUF: agentic teams should augment your organization to speed innovation and time-to-value. They should not replace actual humans.

The companies getting this wrong are using AI headcount math: “If agents can do 30% of the work, we need 30% fewer developers.” That’s a mistake. The companies getting it right are using AI leverage math: “If agents handle the repetitive work, our developers can ship features that were previously out of reach.”

Junior devs (yes, we still need junior devs) onboard faster with AI as a supervisor. Automated deployments minimize downtime. Predictive maintenance catches issues before production. The outcome you should expect: more predictable quality, fewer post-release fires, lower maintenance bills, and a team that can take on more ambitious projects.

The question to ask your CTO isn’t “how many heads can we cut?” It’s “what could we build that we couldn’t before?”

The question to ask your CTO isn’t “how many heads can we cut?” It’s “what could we build that we couldn’t before?”

The Human Element

The biggest challenge to agentic AI adoption, same as with any change, is people. Specifically, the fear of being replaced.

Your senior developers have spent years building expertise. When you introduce a tool that can “write code,” their first thought isn’t “great, I’ll be more productive.” It’s “am I about to be automated out of a job?” That fear is rational, and ignoring it guarantees failed adoption.

The only solution is trust, and trust is built over time. This isn’t a technology rollout; it’s a change management exercise. Kotter’s framework applies: create urgency around the opportunity (not the threat), build a coalition of early adopters who can demonstrate success, communicate relentlessly that the goal is augmentation not replacement, and generate visible short-term wins that benefit the team.

The teams that succeed are the ones where developers see agents as tools that make their work better, not threats that make their work disappear.

How to Think About Tools

The market has split into two categories: IDE-first copilots that augment your editor line by line, and agentic systems that plan and execute multi-step changes with human checkpoints. Different problems, different tools.

Choosing which is best in your context is simpler than you may think. For daily flow (small tasks, quick completions, staying in the editor), you want a copilot like Cursor or GitHub Copilot. For complex work (large refactors, multi-file changes, architectural migrations), you want an agentic tool like Claude Code that can read your entire repo and execute a plan across dozens of files.

Don’t standardize on one tool. Smart teams use different tools for different jobs. The pattern I’m seeing work: Copilot for daily flow and peer reviews, Claude Code for planned refactors and migrations, Cursor for deep codebase work.

If your organization has strict data privacy requirements (fintech, healthcare, defense), tools like Tabnine offer air-gapped deployment. If you want agentic capabilities baked into CI/CD, GitLab AI and Apiiro are worth evaluating. If you have non-developers drowning in requests for simple automations, Claude Cowork (research preview, requires Claude Max subscription) can offload that demand to business teams directly.

Don’t chase features. Switching tools every month means you never build muscle memory or prompt engineering skills. Each switch resets your learning curve. Commit to one tool for 60-90 days. Learn its patterns. Evaluate alternatives after you’re proficient.

Security

This is where orgs suffer the most anxiety. That anxiety can lead to missteps. They treat agentic AI like another dev tool when it’s actually a new attack surface. Generative AI creates content. Agentic AI executes commands. Different beast.

Compromised agents mean data leaks or malicious behavior. Dependency risks are huge: outdated libraries, unvetted code.

The threat landscape includes prompt injection (adversaries force agents to execute malicious commands), cross-agent privilege escalation (low-privilege agents manipulated to trick high-privilege agents), non-human identity compromise (hardcoded API keys giving attackers months of access), and MCP server vulnerabilities (shadow agents linking LLMs to corporate databases without oversight).

Mitigation: Zero Trust for Agents. Every tool call and API request verified, logged, scoped. Think of agents as digital insiders. They can cause harm unintentionally or deliberately if compromised. Establish governance: ownership, monitoring tied to KPIs, escalation triggers, accountability standards. Treat LLM-generated code as untrusted. Sandbox everything. Enforce pre-commit hooks, automated scans. Least-privilege, no blanket access.

Code Quality and Maintainability

AI-generated code quality varies wildly. Some companies see huge gains, others see nothing. The difference is process discipline.

The “vibe coding” backlash is something you can’t ignore. There’s an “AI slop” crisis in production codebases and it is creating problems greater than any low-cost offshore dev shop of the early 2000s. One researcher documented a junior engineer merging 1,000 lines of AI-generated code that broke a test environment. The code was so convoluted that rewriting from scratch was faster than debugging.

Treat AI code like contractor code. Review it like it came from someone who doesn’t know your codebase. AI generates plausible code. It doesn’t understand why your team made specific architectural decisions.

Automate testing. Non-negotiable. The tools can run tests and iterate. Claude Code can run your test suite and fix failures before presenting code for review.

Don’t skip planning. Make the agent generate an architectural plan and review it before code gets written. This will catch misunderstandings before they become debt.

Watch for over-engineering. Agents go too far. One team reported Claude building a database-backed session management system when JWTs would’ve sufficed. Review for simplicity, not just correctness.

Studies suggest agent-generated code can spike complexity significantly and increase static warnings. Documentation matters more than ever. Humans carry mental context about why decisions were made. AI doesn’t. Require inline documentation explaining the reasoning, not just the what.

A Framework for Scaling

Once you move past pilots into production agentic systems, you need structure. A three-layer framework helps:

Layer 1: Model Routing (The Traffic Cop). Not every query needs your most expensive model. Route simple questions to fast, cheap models; route complex reasoning to powerful ones. This is how you control costs while maintaining quality. Without routing, you’re either overpaying or getting bad results.

Layer 2: Agent Orchestration (The Team Manager). Some tasks are too big for one agent. Orchestration breaks them down, assigns parts to specialized agents, and combines the results. One agent searches, another calculates, a third summarizes. The orchestrator keeps it cohesive. This is how you handle complex, multi-step problems.

Layer 3: Context Patterns (Memory and Flow). Agents forget. Context patterns are reusable templates for handling memory, conversation history, and reasoning flow. Chain-of-thought prompting. Memory buffers for key facts. Structured inputs that guide better outputs. This is how you make the system feel coherent over time instead of starting fresh every interaction.

The layers stack: routing picks the right tools, orchestration assembles them into a team, context patterns make the whole thing coherent. Teams using this framework report significant reductions in refactoring time.

The Cost

Your API bill is just the tip of the iceberg. I learned this the hard way running experiments in my office. What started as a few hundred bucks a month in API calls turned into weeks of engineering time spent optimizing prompts, building infrastructure that could actually scale, navigating security compliance reviews that nobody budgeted for, and standing up monitoring stacks to figure out why things were breaking. That “reasonable” API bill became unreasonable fast. DX research and industry reports consistently show total costs running 5-10x higher than what shows up on the invoice.

The cost iceberg: Your 200-token demo becomes a 1,200-token production interaction once you add conversation history, user profiles, and system state. Demo failures become complex recovery workflows. Your token math assumes perfect inputs; production assumes everything breaks. Your systems weren’t built for AI, and AI wasn’t built for your systems. “Simple” integrations turn into building APIs that don’t exist.

Subscription tools (Copilot, Cursor, Windsurf) run $10-40/seat/mo. Predictable. API tools spiral fast: an agent on complex tasks can consume 5-10M tokens monthly, costing $45-150/mo for Sonnet on a single workflow. Multiply across a team and things can get expensive fast.

Optimization strategies: Smart prompting can cut token usage significantly (PromptLayer research shows 40%+ reductions with concise prompts). Model routing (cheap models for simple tasks) can save up to 85% on certain workloads according to LMSYS benchmarks. Caching reduces redundant calls. Open-source frameworks (LangChain, LlamaIndex) lower costs vs proprietary options but require more expertise.

For 10-20 developers, budget $200-800/dev/mo in subscriptions, with total business cost at 5-10x that when you add integration, training, and maintenance. Enterprise implementation runs $50K-200K for rollout.

The economics still work. A skilled US developer costs $100-150/hr fully loaded (salary plus benefits, taxes, overhead). A $2K/mo AI investment delivering 3x on routine tasks pays for itself quickly.

Risks

Agentic AI isn’t perfect. Without oversight, agents spit out bad code that takes longer to fix, or nuke your production DB. (Looking at you, Replit horror stories.) Stack Overflow’s 2025 Survey found only 3% of developers “highly trust” AI output, while 46% actively distrust it. Maintainability is a top concern: DX research shows code quality impacts vary wildly by organization.

Hallucinations and errors: agents “vibe code” without understanding, creating vulnerabilities. Over-reliance degrades dev skills. Diminishing returns if your team’s already saturated with AI IDEs. Accountability shifts to humans overseeing agents. Track provenance or you’re the one holding the bag.

Treat it like buying a used sauna on Facebook Marketplace. Great deal if it works. Inspect it first.

What to Do Monday Morning

Build a team of two engineers. Give them 30 days to see what an agentic team can deliver within your organization’s architecture.

1. Map the process: what did they build, how did they build it, what did the agents actually do?

2. Map the bottlenecks: where did agents struggle, loop, or produce garbage?

3. Map the wins: what shipped faster than it would have otherwise?

4. Map the friction: what was harder than expected, what required workarounds, what annoyed the team?

After 30 days, look at the results. Consider improving the outlined friction. Decide if the juice is worth the squeeze.

One caveat: if your value streams, business architecture, or technical architecture are already a mess, fix that first. AI doesn’t fix broken systems. It automates them. You’ll just experience the same pain you already have, faster and more often.

That’s it. Not a massive transformation initiative. Not a tool procurement process. Two engineers, 30 days, and an honest assessment.

Closing

Agentic AI is a fundamental economic shift in software development. Not a productivity tool. The orgs capturing value treat this as an operating model change, not a tool purchase.

The cost of not leveraging this is greater than you think. Ask why your competitors are adopting it, and what you’re missing.

The era of “magic” AI coding is over. The era of managed, verified, economically rational AI engineering has begun.

Sources

METR Study: “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (arXiv:2507.09089, July 2025). metr.org

Stack Overflow: 2025 Developer Survey. survey.stackoverflow.co/2025

Google DORA: 2025 State of AI-assisted Software Development Report. cloud.google.com/devops

Anthropic: Claude Opus 4.5 System Card and SWE-bench Verified Results (November 2025). anthropic.com

DX: AI-assisted Engineering: Q4 Impact Report (2025). getdx.com

LMSYS/RouteLLM: Model routing research (ICLR 2025). github.com/lm-sys/RouteLLM

PromptLayer: “How to Reduce LLM Costs” (2024). blog.promptlayer.com

The big news is… that I’m not ready to share the big news yet. 😊

It’s been nearly three months since my sabbatical and my subsequent decision not to return to my role at SAI after the new year. At the time, I thought I knew exactly what I was going to do, but the more time I spent with Jenelle and Ford, the less clear the path forward became.

I’m currently considering three different options. Each is great in its own way, and I anticipate making a decision within the next two weeks.

It’s a complicated world out there right now, but one that’s also insanely fascinating.

No matter the decision, expect some cool new events, writing, and nerd-media to drop in the very near future.

Stay tuned.

Cool House Projects

With a little extra time on my hands, I’ve had the opportunity to take on some house projects that I had been putting off. Here are the details on the “big three”.

The Garage.

The garage is my favorite room in the house. Yes, you read that right.

I spend a lot of time out there. Between tinkering with Ford’s dirt bike (yes, you read that right too), working on the cars, and hitting the gym, I spend a ton of time out there. Being the motor-head that I am, I’ve always wanted a cool garage—and I finally built it out.

I went with a dark grey flake polyaspartic on the floor and black epoxy on the upright cinder blocks. The floor came out amazing, thanks to Signature Concrete Coatings. I have no idea why I waited so long.

I had the ceilings painted black by Mathias Painting, and Hexglow lights installed by Jado Customz. Everything looks better than I anticipated. The garage has turned into such a cool space.

Paint.

Ever since finishing Ford’s room, Jenelle and I have been really into color washing. Last year we painted our parlor room navy and immediately wished we had color washed the space instead. We also knew I didn’t have the skills to do it properly, so we leaned on our friends at Mathias.

There’s still a lot of work to do in the room, but it’s off to a great start. Next up: art, chairs… actually, we’ll probably turn the whole thing over to our friend Kelly at GoldLeaf Interiors.

Next up was the bedroom. There wasn’t anything wrong with it, aside from the fact that I royally screwed up a wall when touching things up. So, while fixing that, we decided to do a little extra. We lightened the color of the room and did a modified color wash. We painted the trim and doors the same color as the walls, and decided to leave the ceiling tray white to help keep the room feeling “tall.”

The Cars.

The last of the big-three projects was to have the cars ceramic coated. In our family, we only buy black cars. If you’ve ever had one, you know how great black looks when clean—and how horrible it looks when dirty. Additionally, you’re probably more familiar with swirl marks in your paint than most other car owners.

With my car being six years old, Jenelle’s car having soft paint typical of a GM product, and our desire to hang on to these rides for several more years, we decided to invest in a quality ceramic coating service.

Daniel at Perfect Finish did a three-step paint correction on each vehicle, applied the Modesta BC-X 5-year coating, and added a protective film to my windshield.

Both rides came out great. My 6-year-old Mercedes looks better than anything I’ve seen on the showroom floor recently.

If you care about the finish on your car, ceramic is a must (just be sure you care for it properly).

The Adam Mattis Show

I have built two pretty solid podcasts over the years. My first, The Everyday Executive, which I launched after Orion’s Kin was cancelled. I learned a lot about production during that experiment. I shut EdE down after I inherited Agile Amp’ed while at Accenture. It was pretty popular in our community, but more curated than I would have preferred.

Where I really hit my stride with podcasting was when a rogue team and I took Business Agility Now to a top 5% podcast on iTunes and Spotify while at Scaled Agile. I had a lot of freedom in terms of style with this one, but I was still constrained from fully expressing my natural voice.

As things changed last year at SAI, I put the podcast on the shelf after we published our last episode in June.

Now that I’ve created some separation and had time to reflect, I’ve come to realize how much I miss recording. Beyond that simple realization, I’ve learned that what I miss most is the opportunity to get to know interesting people and their stories—and to help give people great content to promote whatever it is they’re doing.

So, I’m getting back to it. And I’m doing it my way, in my own voice, with The Adam Mattis Show. I’m excited to host a show where I can be myself: a little punk rock, a little moto, a little nerd, and a lot of interesting people.

I intend to release 2 episodes per week—one car-thought and one long-format. The first will drop on February 2 with a hotly anticipated guest: my wife, Jenelle. This one will be fun, funny, and uncomfortable. I’m much more excited about it than she is.

Please subscribe on your favorite platform via the links at TheAdamMattisShow.com. I will publish on Spotify, Apple Podcasts, and YouTube.

A Business You Should Know:
The Balcerzak Group

Annie Balcerzak is a badass.

In the world of real estate, it can be hard to stand out. Annie and her team at The Balcerzak Group don’t have that problem. Their style, their approach to business, and their approach to people are second to none. The driving force behind that is Annie.

If you follow Annie on Instagram, you’ll quickly see a lot of her personality—and also her deep knowledge about property maintenance, staging, rehab, and more. They really are in a class of their own.

With all of that said, what is most remarkable about Annie is her approach to people, business, and life. We are aligned on so many perspectives, and I find myself learning a little more from her almost daily.

If you’re in the Baltimore metro area and need a real estate partner, check out The Balcerzak Group.

Oh, and you may catch her on an upcoming episode of The Adam Mattis Show too.

In Closing.

My sabbatical helped me realize that I needed to make a change and focus on my little dude, Ford. The time away made me understand that I had to shift things so I could spend more time with him.

I’m excited for the next step in my career, and I’ll be able to share those details soon.

But for now, please take a lesson from what I’ve (again) learned the hard way: family first. You can never reclaim time, so protect it with everything you’ve got. Also, if you ever find yourself in a situation where you feel like you can’t be yourself, consider that it may be time to change your circumstances.

Until next month!
-Adam

The engagement season of a relationship is peak euphoric happiness, and I don’t think enough couples take full advantage of it.

Before you get defensive, hear me out.

Do you remember your first relationship? Probably in high school or college. Do you remember how it felt? The butterflies, the thrill of seeing that person, holding their hand, the longing to spend every waking moment together?

Most people call this “puppy love.” Some lucky ones turn it into a lifelong relationship, but many don’t, and they end up holding those early feelings as the gold standard for what “right” should feel like in a relationship.

Then life happens. Dating in your 20s is full of exploration, meeting new people, figuring yourself out, and cycling through a lot of relationships. Inevitably, people put up walls and become jaded. This isn’t unique to men or women. I’ve felt it myself and watched it happen to plenty of my (female) friends too.

If that pattern carries into your 30s, things get even harder. You’ve become independent and comfortable being alone. Relationships feel riskier because you’re weighing the safety of your single life against the vulnerability of letting someone in.

Dating apps only make it worse. One weird feeling, one fight, one “not sure?” and thousands of other options are just a swipe away.

Despite all of this, most people eventually find someone they’re willing to risk it all for. The relationship blooms, someone pops the question, and, if it’s truly right, those early feelings of first-relationship euphoria come flooding back. You feel safe and confident about the future. You’re excited, your person is excited, and everyone around you is excited for you. In this sweet phase, before wedding planning kicks in, a couple genuinely enjoys each other. Everything feels easier, the guard is down, the air is sweeter, and life just feels great. (If that’s not the case, that’s a different conversation.)

Then wedding planning begins. Trust me: the stress and pursuit of perfection is never worth it. The day will be beautiful even if the timeline, seating chart, and flowers aren’t perfect. People will have fun. The whole thing will fly by in a blur. Don’t waste a single minute of your engagement stressing over things that won’t matter the second the wedding day starts.

After that? Life.

Am I saying happiness fades after marriage? Absolutely not. But it does change. Life changes it. Careers, building a home, growing individually and together, starting a family, raising kids, moving. It all reshapes what happiness looks like and how it feels.

Now happiness feels like watching your partner succeed, like solving problems and overcoming adversity together. It feels like building a safe place for your family. And time passes faster than you’d ever want. Some days you grow closer, some days you drift a little, but the commitment to always finding each other keeps everything moving forward.

I love my wife and I love my family. I couldn’t be happier with where we are.

So why am I writing this?

Yesterday I was walking around North Hills in Raleigh with Jenelle and Ford when I saw a couple get engaged. In an instant, I was transported back to proposing to Jenelle in Ebensburg in 2018. Almost immediately after the ring went on her finger, I heard someone ask, “When’s the wedding?” I wanted to run over and shout, “No! Enjoy every single minute of this. Don’t rush!”

But that would’ve been weird, so instead I’m writing this.

If you’re in that magical engagement season right now, please don’t let it slip by. Savor the butterflies, the ease, the pure joy. Those feelings don’t disappear after the wedding; they just evolve into something deeper and more enduring. But this particular sweetness? It only lasts for a little while. Make the most of it while it’s yours.

If you opened this email based on the subject and hope of some drama, I’m sorry to disappoint. But, the related blog post is something that every guy should read.

With that out of the way, it’s time for some life changes and a fresh start.

Something shifted in me on the flight home from my 8th trip in 9 weeks (September through November). I realized I wasn’t just jet-lagged from bouncing between APAC → ET → EMEA → MT → ET time zones.
I was physically, mentally, and emotionally exhausted from the last three years.

From losing our daughter, to fertility treatments, health scares, welcoming a newborn, and relentless pressure at work, something inside me had finally broken.

As I write this, I’m two weeks into a six-week sabbatical, asking myself one question: “What’s next?”

I know I need to get back to building and helping others.
Back to doing the things that make me feel alive.
Back to being the patient, focused father and husband my family deserves.

The exact shape of all this is still coming together, but I expect to have a much clearer picture to share when January’s newsletter lands in your inbox.

If you want to offer some unsolicited feedback or advice, feel free to hit “reply” and lay it on me. I want to hear all of the ideas!

Until then, I hope you have a wonderful Christmas and get to spend as much time as possible with the people you love most.

Cheers to ‘26!

-AM

Men: Chase Adrenaline - Save Your Marriage

I am an adrenaline addict, and over the years I’ve lost a lot chasing the rush I used to get from combat, motocross, and starting companies… except recently, the only thing I was hunting was the next work crisis.

Work travel. Bills. PE pressure. Fertility hell. Dramatic life changes. Somewhere in there the fire went out and I didn’t even notice until I was sitting in a dark garage staring at empty space that my motorcycles used to fill.

A lot of men are one mid-life itch away from an affair, a heart attack, or just checking out completely. Why? Because we stopped feeding the beast and started numbing it instead.

If this feels too close to home, have a look at THIS post and start making some changes.

If you’ve got a family, a wife, or a pulse, you need this one.

Then forward it to the brother who’s quietly dying on the couch.

What I Read in 2025

From Jack Carr to Brown Bear Brown Bear and everything in between, I have put together a list of everything I read in 2025. It’s crazy to think that I’ve been building my “what I read” list for almost ten years now. This years list is a little thin, but there is still some gold.

Have a look HERE!

Savannah Homecoming

Jenelle and I have been slipping down to Savannah, Georgia for quick escapes ever since we moved to Raleigh in 2020. For me it always feels like a bit of a homecoming. I lived there from 2004 to 2009, first with the Army and then at VeriSign after I got out. I even owned a rental property in the area until 2021.

What I love is how Savannah seems to have grown up right alongside me.

Early days with the boys we never left the River Street to Broughton Street corridor. Life revolved around bars and meeting SCAD girls. That was it.

Later when I was working on Oglethorpe I suddenly cared about the city’s history, quiet cafés, and networking at First City Club (RIP).

Now when we come back with Jenelle and these days with Ford we’re drawn to completely different corners. River Street is still River Street, but the old west-end industrial lots have turned into slick Marriott properties and our favorite hotel The Thompson sits on what used to be marsh. The whole place has matured, picked up great restaurants and shops, and traded a lot of drunk soldiers for strollers (Fort Stewart isn’t what it used to be).

These days we’re the ones pushing a stroller through the squares, lingering in Forsyth Park, and hunting down the quiet spots. Savannah’s still got its soul. I’d like to think I still have mine.

We might move back one day. For now it’s our favorite place to escape.

While we’re at it...

Monday, December 8th marks my 20th “Alive Day”, and 20 years since Kevin Smith gave up his life to save mine.

That’s all I have to say about that.

A Business You Should Know: Osteria G

Joe and Ashley have built the best Italian restaurant you’ve probably never been to.

And now they’re also building an Italian deli and an NYC-caliber steakhouse right here in Holly Springs.

What makes Joe, Ashley, and OG so special isn’t that they set out to be best-in-class restaurateurs, it’s that they set out to be good people and provide a killer experience, and that’s exactly what has made them the best in the area.

When you walk into OG, you’ll be greeted by a great hostess and a big smile from Mack working behind the bar. Next, you’re almost guaranteed to run into Joe or Ashley, who will welcome you like you’re their oldest friend.

Then the real experience begins: the food, the wine—everything is perfect. But there’s one little detail that lets you know this isn’t your grandma’s Italian restaurant: the playlist, packed with songs your mom probably wouldn’t let you listen to growing up.

This place and the people behind it are truly special. The food is outstanding.

Make the trip, you’ll be glad you did.

Osteria G
OG Deli

In Closing

It’s been one hell of a 2025, and I’m excited to make a change. Exactly what that looks like is still a little TBD, but I’m ready for it.

I hope everyone has a wonderful Christmas season. Take a minute to step back, look around, and feel real gratitude for all the goodness in your life. Despite all the chaos swirling around us, it really is a damn fine time to be alive.

Cheers,
AM

I scrolled past an Instagram reel the other day that made more sense than I expected. The creator laid it out plain: men are wired to hunt, compete, conquer, and win. We all have our own version of this. For me it was hosting a hunting TV show, starting businesses, building, competing, and winning. For others it’s learning, gaming (I’m not a fan), DJ’ing, adventure races, cars, or anything else that defines who a man is.

Then life happens. Marriage, kids, mortgages, corporate politics, pressure. That fire gets buried under routine, responsibilities, and resentment.

Single-Adam spent a ton of time on the road: new cities, new friends, new hunting spots. It filled my cup. Even after Jenelle and I were married, we kept that lifestyle, just did it together. When the pandemic killed travel I went back to my roots and got on a motocross track again. It felt good to wrench on a bike and pin the throttle.

Then work pressure ramped up. Jenelle and I lost our daughter. We fought through years of fertility treatments that finally gave us Ford. Then we had a newborn. And somewhere in all of that… I lost myself. I was living to work and survive the pressure. I lost my outlet, and I lost joy.

There were nights I’d sit in the dark garage after Ford went down and stare at where my dirtbikes used to be. I bought another new car. I felt empty. That’s when you know you’re in trouble: when the things that used to light you up feel distant and out of reach.

Many guys bury it. Misery, weight gain, food, booze. And some guys miss the rush so badly they go looking for it in the worst possible place: other women. The reel was right: the affair usually isn’t about the other woman. It’s about trying to feel young, alive, and free again, like time-traveling back to the man who didn’t have to adult 24/7.

There’s truth in the evolutionary story (men’s infidelity tends to be about novelty, women’s more about emotional connection), but biology is not destiny. Failing to give that energy a constructive outlet is, in my opinion, the ultimate form of weakness.

As a former competitive BMX rider, motocross racer, mountain biker, and a guy who got addicted to the rush of combat, I know the void better than most. When the helmets come off and the deployments end, the emptiness can be overwhelming. The same wiring that kept me alive on the streets of Baghdad or convinced me to send a 100-foot triple still tastes like dust and cordite twenty years later. That switch never turns off. It just waits for orders.

Right after I retired from the Army I was a train wreck, terrible in relationships, a reckless friend, and absolutely dangerous with Terry on our “blood-money” Harleys. How either of us are still breathing is a mystery. Most guys don’t go that extreme, but too many still answer that scream with secrecy and self-destruction instead of strategy and strength.

There’s a better way. And it will literally save your marriage, your sanity, and your soul.

1. Give the beast an outlet
   You need something that spikes your heart rate, demands focus, and leaves you physically spent.
   • Brazilian Jiu-Jitsu (getting choked unconscious by another grown man weirdly heals the soul)
   • Hunting in the back country
   • Track days, enduro rides, or throwing a barbell around until you see stars
   • Ice baths, obstacle races, ultras, whatever reminds your nervous system you’re still in the game

   These aren’t “nice-to-haves.” For me they’re maintenance, same as brushing my teeth. Over the years I’ve chased trail running, Ironmans, mountain biking, road biking, rock climbing, and travel. If you think you “don’t have time,” remember I trained for an Ironman while working 70-hour weeks and traveling constantly. You don’t find time; you steal it from anywhere you can. It’s not easy or comfortable, but it’s worthwhile.
   

2. Build your tribe
   Lone wolves die young, both literally and figuratively. Find men who train hard, have aligned values, and want to get better. The garage gym crew, Thursday-night BJJ, Bible study, the dawn ruck group; these guys become your accountability, your therapy, and often your best friends. Real masculinity isn’t suffering in silence; it’s choosing to improve your life, and it’s always easier together.

   I’ve buried too many friends who never found their five guys. Suicide rates for men 35–54 are obscene for a reason. Your tribe isn’t a luxury; it’s your insurance policy.
   

   Right now my tribe is basically me and Eric once a week. I need to do better. We all can. Here’s the dirty secret: most of us are one text away from starting one. Today, I am sending four guys: “Saturday 0600, 5-mile ruck, coffee after. No excuses.” That’s how tribes are built, one awkward text at a time.
   

3. Say the hard thing out loud
   The strongest man in the room is the one who can look his wife in the eye and say, “I love you and the kids more than anything, but some days I feel like I’m disappearing. I need to go punch myself in the face at the gym a few nights a week so I can be fully here when I come home.”
   

   Vulnerability isn’t weakness. Most women would rather buy you a gym membership than bury you at 50 from a stress heart attack, or lose you to someone else.
   

   A few months ago I felt us slipping, so I sat Jenelle down and told her exactly how hollow I was feeling. I asked her to start therapy with me, not because we were broken, but because I never wanted us to get there.

Your primal wiring isn’t the enemy. Neglecting it is.

You have a responsibility, to your family and to yourself, to be the best man you can be. Do good work, do hard things, invest in yourself, and be brutally clear about your needs. Most families don’t blow up from one big betrayal; they erode from years of laziness and unspoken resentment.

Ford is ten months old. Every time we walk into the garage he makes a beeline for his balance bike or my old dirt bike and grabs the handlebars. He’s never seen me ride, and he can barely stand on his own bike, but he already knows those machines are something special. I don’t want his first memory of Dad to be a burnt-out guy scrolling his phone on the couch. I want him to remember a man who still had dirt under his nails and fire in his eyes at 70. That story starts with the choices I make this year.

So here’s what I’m doing: I rebuilt my home gym, bought a sauna, and I’m building my garage gang. I’m shopping for a new motocross bike. And come January I’m walking away from the job that was no longer serving me. It’s time to get back to building, creating, and making the world better for my son.

I’m not saying you have to quit your job, but you do have to do something. Your older self will thank you.

Chase the rush. Build the brotherhood. Speak the truth.
Do these things relentlessly and you won’t need to chase ghosts from your past, because your present will feel alive again.

And your family gets to keep the man they fell in love with.

2025 was the year of Ford: crazy days, lots of supported steps, and roughly 4,000 readings of Brown Bear. Travel, work, and sleep deprivation meant the grown-up reading pile grew slower than usual. Still, I carved out enough pages for a handful of books that actually stuck. Some challenged me, some entertained me, a couple changed me.

Here’s the shortlist.

• Under Siege: My Family’s Fight to Save Our Nation

  I make a point of reading books by people who hold power; a key player in one of America’s most influential families offers a perspective worth understanding. The sharpest, most non-partisan takeaway was his insistence that the people closest to a problem are almost always the ones best equipped to solve it.

• 107 Days

  A minute-by-minute look at the whirlwind of a presidential campaign’s final stretch. The clearest non-partisan takeaway: real leadership isn’t about having all the time in the world; it’s about making the right calls when every hour counts and the pressure never lets up.

• Cry Havoc: A Tom Reece Thriller

  I am a huge Jack Carr fan. Though, I did not expect to enjoy this book as much as I did. Being a GWOT Veteran, Vietnam has always felt a bit disconnected from my own experience. Carr corrected that perception with his story of the father of his main character, James Reece. If you haven’t reach Carr’s previous books, don’t start here. Begin with The Terminal List and read the series in order.

• The Coming Wave: AI, Power, and Our Future

  This one is a bit of a horror story, written by one of the people who built the monsters. The next decade of AI (and synthetic biology) will be the fastest, most consequential technological leap in human history, and right now literally no one has a workable plan to keep the benefits while containing the risks.

• Trump: The Art of the Deal

  I was surprised by how much I didn’t know about Trump’s involvement in the modern history of NYC: the Grand Hyatt, Wollman Rink, Trump Tower; he really did reshape huge chunks of the Manhattan skyline in the ’80s. Love him or hate him, the guy has an almost obsessive eye for leverage, timing, and turning constraints into selling points, lessons any builder, negotiator, or entrepreneur can pocket regardless of politics.

• The Laws of Human Nature

  A 600-page dissection of why people do the stupid, brilliant, cruel, and heroic things they do. Once you start seeing the predictable patterns (narcissism masks, envy triggers, groupthink spirals, the shadow side everyone denies), you can’t unsee them in yourself or anyone else. It’s like getting night-vision goggles for human behavior.

• The #1 Dad Book: Be the Best Dad You Can Be in 1 Hour

  Yes, the title is pure clickbait and the book is basically a pamphlet wearing a hardback costume. Still read it in one sitting on a flight. Surprisingly solid reminder that 90 % of great fatherhood isn’t grand gestures; it’s showing up, staying calm when you want to yell, and asking one good question a day.

• The Technological Republic: Hard Power, Soft Belief, and the Future of the West

  A manifesto that argues the West’s real power now lives in code, networks, and engineers, not in parliaments or legacy institutions. If democratic governments keep treating frontier tech as something to regulate instead of something to wield, the next century will be written by whoever does master it first.

• Attract or Repel: Seven Keys to Magnetize Your Company

  A practical sales-culture book that lives up to its binary title: every choice you make as a leader either pulls the right people (and customers) toward you or pushes them away; there’s no neutral. The reminder that culture isn’t a poster on the wall; it’s the cumulative magnetic charge of thousands of tiny daily decisions.

• Do Hard Things: Why We Get Resilience Wrong

  A former Olympic coach tears apart the grit-is-everything myth and rebuilds resilience: real toughness isn’t pushing through pain while pretending you feel nothing; it’s learning to listen to the discomfort, respond instead of react, and choose the hard thing because it still aligns with who you want to be.

• Brown Bear, Brown Bear, What Do You See?

  This one is Ford’s #1 favorite book (and his cousin Luca’s, too.) I’ve read it no fewer than 500 times in the last 10 months.
  

• The Very Hungry Caterpillar

  Ford’s second favorite book, and I’m pretty sure it was my sisters #1 way back in the day.
  

• Goodnight, Goodnight Construction Site

  And finally, my #1 favorite book to read Ford. Though, he seems to be more interested in eating it than reading it.

That’s the 2025 roster. Fewer books than past years, but every one earned its keep, either by making me think harder, parent better, negotiate sharper, or just laugh at 2 a.m. while a toddler demanded “Brown Bear” for the 47th time.

Cheers!