The Contoso Convergence, Episode 9: The Real Cost

By
August 25, 2026
Uncategorized
Leave a comment

An Advanced Dungeons & Dynamics 365 session. Episode 9 of 14.

Previously on: Episode 8, What Feld Knew, Feld admitted he cut sixty percent of the original rebate automation budget eighteen months ago, and let two failed go live attempts pass without ever mentioning it. He asked the party what it would actually cost to do it right this time.

Every project has a number that never got calculated the first time around, because calculating it honestly would have made an uncomfortable decision harder to justify. This episode, the party finally does the math nobody did eighteen months ago.

The Session

Sable: I priced it out. Fully automated rebate accrual, configured correctly against the current contract terms. Here’s the effort estimate.

Feld: And the eighteen months of manual work Oskar’s been doing?

Ai. Cassiopeia: Loaded cost, including error correction and the audit exposure from the suspense account mismatch, comes to roughly four times the automation cost. Over eighteen months.

Marge: So the sixty percent cut didn’t save money. It moved the cost off a project budget line and onto a person’s calendar, where nobody was tracking it.

Feld: (quietly) That’s a hard thing to hear out loud.

Thorne: It’s a common one. Not just here.

Vex: This is the burden rate problem. Everyone compares the sticker price of automation to zero, because the manual work doesn’t show up as a line item. It shows up as somebody’s Tuesday.

Feld: Walk me through the four times number. I want to understand it, not just accept it.

Ai. Cassiopeia: Certainly. Oskar’s estimation time alone, at a conservative hourly rate, accounts for roughly a quarter of the total. The remainder splits between error correction cycles, the audit review now required because of the suspense account mismatch, and the opportunity cost of Oskar’s time not spent on work that was actually his job.

Sable: That last piece is easy to miss. Oskar wasn’t hired to manually reconcile a rebate accrual every month. He was hired for something else entirely. Every hour on this was an hour not spent on the work Contoso actually needed from him.

Feld: (long pause) Nobody put a number on that when I made the cut. I don’t think anyone even thought to ask.

Marge: Most cuts like that don’t get asked. That’s usually the point at which they get approved.

Feld approves the automation on the spot. Oskar, watching from the doorway, doesn’t say anything, but he sits down for the first time in the whole engagement.

The cost that never shows up on a budget line

The sixty percent cut looked like savings because the alternative, eighteen months of Oskar’s labor, never appeared anywhere that got measured against it. That’s the actual mechanism at work here, not bad faith, not incompetence, just an asymmetry in what gets counted. A line item for automation shows up clearly on a project budget, with a number attached and a person accountable for approving it. The cost of not building that automation shows up nowhere, scattered across someone’s calendar in small enough pieces that no single month of it ever looks alarming.

Sable’s point about opportunity cost is the one that usually gets missed entirely, even in a careful accounting. It’s not just that Oskar spent time on manual reconciliation. It’s that that time came from somewhere, from whatever Contoso actually hired him to do, and that displaced work never shows up as a cost either. It just quietly doesn’t happen, or happens later, or happens worse, and nobody connects it back to a budget decision made eighteen months earlier in a different meeting entirely.

This is the same math behind almost every automation decision that gets deferred rather than rejected outright. The sticker price is visible and specific. The cost of the status quo is invisible and diffuse. Comparing a visible number to an invisible one isn’t really a comparison at all, it’s a bias built into how the decision gets framed before anyone even sits down to make it. Feld didn’t make a bad decision eighteen months ago because he did the math wrong. He made it because nobody asked him to do the math at all.

What happens next

With the rebate automation approved, the party finally has room to breathe, three weeks out from go live, only to discover the next problem waiting isn’t in the ledger at all. It’s in the people who are supposed to be running the system come Monday morning, and a readiness assessment is about to reveal that most of them aren’t ready.

Next episode: Episode 10, The Wayfinder’s Gap (coming soon)

This is almost exactly the math behind the AI cost comparison piece Murray wrote on LinkedIn, sticker price versus burden rate, same trap, different technology. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you want a framework for surfacing the real cost of the status quo before it gets buried in someone’s calendar, start here: adnd365.com/start

Autopsy #10: The AI For The Sake Of AI Demo

By
August 25, 2026
Uncategorized
Leave a comment

Cause of death: a button that already worked got wrapped in a chat box and called intelligent.

The feature existed before the demo did. Somewhere in the product, there was a dropdown, a rule, a scheduled job, something deterministic that took an input and produced a correct, predictable output every time. Then, at some point in the last two product cycles, that same feature got a new front door: a text box, a little sparkle icon, a placeholder that says “ask me anything.” Now, instead of picking a value from a dropdown, you type a sentence, wait a beat, and the same output appears. The presenter calls this AI. The room, primed by two years of hearing the word everywhere, nods.

Nobody asks the obvious question: was this better before, and did anyone check.

What actually happened

Somewhere inside a lot of “AI-powered” features sits a deterministic operation that a rule, a formula, or a simple lookup already handled correctly and quickly. Wrapping that operation in a natural-language interface doesn’t make the underlying logic smarter. It adds a translation layer, one that has to interpret an unstructured sentence and map it back onto the same structured operation the dropdown was already doing directly, with total accuracy, in a fraction of the time.

That translation layer isn’t free. It introduces a new failure mode that didn’t exist before: the AI misreading the sentence and selecting the wrong option, a phrasing the model hasn’t seen before returning an unhelpful answer, latency where there used to be an instant response. None of this is inherent to AI as a category. Plenty of genuinely AI-native capabilities do things no dropdown ever could: summarizing an unstructured document, drafting a first pass at something that has no single correct answer, flagging an anomaly buried in a pattern too complex for a fixed rule to catch. The problem in this specific demo isn’t that AI was used. It’s that AI was used to solve a problem that was already solved, by something more reliable, and the swap happened anyway because AI is what gets funded, marketed, and put on a keynote slide this year.

The tell is almost always the same: watch what happens when you ask the natural-language version to do something slightly outside the phrasing it was tuned on. The dropdown never had this problem, because a dropdown has no phrasing to be tuned on. It just has options.

Why it works on smart people

Nobody wants to be the person in the room who seems skeptical of AI in a year when every vendor, every board deck, and every competitor’s marketing has decided AI adoption is the metric that matters. Asking “why does this need to be a chat interface instead of the three-click menu it replaced” risks sounding like you’re behind, not like you’re asking a reasonable engineering question, and that social pressure runs in exactly the wrong direction. It rewards accepting the AI wrapper uncritically and punishes the person who’d actually stop to check whether it improved anything.

There’s a second, quieter dynamic on the vendor side that compounds this. Once a company’s roadmap and marketing commit to being an “AI-first” platform, there’s organizational pressure to retrofit AI onto existing features whether or not doing so improves them, because a product review, an investor update, or a competitive comparison chart wants to see the AI checkbox filled in across the board, not filled in only where it was actually the right tool.

The actual damage

This is the one that costs you reliability you already had. A feature that used to return the same correct answer every time now returns a slightly different answer depending on phrasing, and the variance itself becomes a support burden, because now every unexpected result needs to be triaged as either a real bug or a model doing something technically defensible but unhelpful. Power users, the ones who had the old dropdown workflow memorized and could execute it in seconds, are now slower, because the natural-language version, for all its friendliness, requires more typing and more waiting than the three clicks it replaced.

There’s a subtler cost too. Every AI feature added for marketing reasons rather than capability reasons dilutes the credibility of the AI features that are actually doing something new and valuable. Once a buyer has been burned by one chat-wrapped dropdown, they bring that skepticism to the next AI claim in the deck, including the one that might have genuinely deserved their trust.

The fix, if you’re the one presenting

Ask, honestly, before the feature ships: does the natural-language interface let the user do something the deterministic version couldn’t, or is it doing the same operation with more ambiguity and more latency. If the honest answer is that the underlying logic hasn’t changed, keep the dropdown, or offer both, and don’t spend the marketing budget claiming AI where the actual improvement is zero or negative. If the AI genuinely does something new, lead with that specifically, in concrete terms, instead of leaning on the word “AI” to do the persuading by itself.

The word was never the feature. The capability was, and a capability that already existed doesn’t become new because it learned to accept a sentence instead of a click.

The distinction here matters enough that I built around it. In Is Headless ERP Enough, or Just a Step in the Right Direction?, the “AI as the sole interface” section argues for AI genuinely load-bearing in the architecture, not a chat box glued in front of the same dropdown. That’s the version of AI worth demoing. Everything else in this autopsy is what it looks like when a team ships the coat of paint instead.

Max Headroom Was Right About Everything Except the Timeline

By
August 21, 2026
Uncategorized
Leave a comment

On April 4th, 1985, Channel 4 aired a fifty-seven minute TV movie with almost no budget and a plot that reads today like a spec document. Max Headroom: 20 Minutes into the Future gave the world a reporter named Edison Carter, a subliminal advertising technology called blipverts, and a stuttering, glitching, computer-generated broadcast personality built from a digital copy of Carter’s own mind. The show that followed ran two seasons on ABC. The character sold Coke. Then he vanished, the way most eighties tech prophecies do, filed under quaint.

He should not have been filed under quaint. He should have been filed under early draft.

Strip out the shoulder pads and the cathode ray production design and look at what the film actually proposes. A television network is using compressed, high-intensity advertisements to bypass viewer attention and hit the nervous system directly, with occasionally fatal results. When their top reporter gets too close to the story and takes a header through a low-clearance sign in a parking garage, the network’s teenage prodigy solves the PR problem by scanning what’s left of the reporter’s mind and generating a synthetic version of him to keep the seat warm on air. The synthetic version glitches, stutters, riffs unpredictably, and is smarter and funnier than anyone expected. Nobody fully controls him. That’s the whole second half of the movie.

That is not a story about television. That is a story about deepfakes and large language models, told forty years before anyone needed those words.

The blipvert was the easy part

The blipvert is the easy connection to make and probably the least interesting one. Compressed, algorithmically optimized content designed to hit faster than conscious attention can filter it is just the eighties’ guess at what a recommendation engine trained on engagement metrics would eventually build on its own, minus the part where it required deliberate malice from a network executive. Nobody had to design today’s version to be dangerous. It got there by optimizing for watch time.

Max himself is the sharper artifact

Max is a generative model trained on a single person’s captured likeness, deployed without that person’s full consent, performing in that person’s voice and mannerisms for an audience that has no reliable way to tell the difference between the source and the copy. The film even gets the unpredictability right, the thing every LLM vendor now calls “personality” or “emergent behavior” when the system says something nobody scripted. Max wasn’t supposed to develop opinions. He did anyway, because the mind he was copied from had opinions, and a compressed, lossy version of a personality doesn’t lose the parts that make it argue back. That’s a reasonably good description of what happens when you fine-tune a model on someone’s writing and then act surprised it has a voice.

The part the film didn’t anticipate, because nothing in 1985 needed to, is scale. Max was one synthetic personality, expensive to produce, running on hardware that took up a room. The modern version doesn’t need a body bank subplot to explain where the source material came from. It needs a public LinkedIn profile, a few hours of conference audio, and an API key. The uplift from Max Headroom’s premise to a working deepfake pipeline in 2026 isn’t conceptual. It’s entirely a story about unit economics.

Not a monster, an unreliable narrator

There’s a reading of the film that treats Max as a monster, a symptom of corporate media rot given a face. That’s not quite what the movie argues, and it’s not quite the right frame for the technology either. Max spends most of his screen time undermining the network that made him. He’s an unreliable narrator working for nobody, least of all the people who built him. The uncomfortable version of that idea, forty years on, is that we’ve built systems with the same structural unreliability and then acted shocked when they don’t behave like obedient tools. A synthetic voice generated from a compressed copy of a mind was never going to be a simple appliance. Max wasn’t. Neither is anything downstream of him.

Long live Max Headroom. He got the technology roughly right and the timeline embarrassingly wrong, which is the best you can ask of any piece of speculative fiction that accidentally turns out to be a roadmap.

The Contoso Convergence, Episode 8: What Feld Knew

By
August 20, 2026
Uncategorized
1 Comment

An Advanced Dungeons & Dynamics 365 session. Episode 8 of 14.

Previously on: Episode 7, The Steering Committee, the party earned Feld’s trust with a demo that was allowed to break, and Feld earned the right to ask the question that had been sitting in the room the whole time: why isn’t the rebate mess fixed yet?

Some questions don’t have an answer until the person asking them is willing to give one too. This episode, Feld does.

The Session

Feld: I need the real story on the rebate accrual. Not the summary. The real one.

Sable: Eighteen months of manual estimation, posted to a suspense account, against a rebate structure that doesn’t match the current contract terms.

Feld: (long silence) I know why that happened.

Marge: Sir?

Feld: The original ASC 606 transition had a line item for rebate automation. I cut it. Sixty percent of that budget, gone, in a board review eighteen months ago. I needed the number to look better that quarter.

Thorne: So the manual process wasn’t negligence. It was a workaround for a decision made above the project team.

Feld: Yes. And I let two go live attempts fail without ever mentioning it.

Ai. Cassiopeia: I want to note, without judgment, that this reframes the entire risk register for this engagement.

Vex: It also means Oskar and Priya have been quietly cleaning up an executive decision for eighteen months and getting blamed for the mess.

Feld doesn’t flinch at that. He nods, slowly, like a man who’s been waiting a long time to hear someone say it out loud.

Feld: I sat in two go live retrospectives and let the room talk about “data quality issues” and “process gaps” without correcting anyone. Both times.

Marge: Why tell us now?

Feld: Because you showed me a demo where something broke on purpose, and it didn’t end the meeting. It built trust instead of losing it. I hadn’t seen that happen on this project before. Made me think maybe this was a room where the truth wouldn’t end the meeting either.

Sable: It won’t. But we do need to know the truth to fix this properly.

Feld: Then you have it. All of it. What do you need from me?

Feld doesn’t argue with that. He just nods, once, and asks the party what it will actually cost to do it right this time.

The decision that outlived the meeting where it was made

The rebate mess was never a technical problem. It was a budget decision made in a single board review, eighteen months before anyone in the war room ever heard about it, and it quietly outlived that meeting by becoming somebody else’s daily grind. That’s the part worth sitting with: Feld’s decision didn’t disappear when the meeting ended. It just changed shape, from a line item on a slide into a recurring manual task that Priya and then Oskar absorbed without ever being told why it existed.

This happens more than anyone likes to admit. A cut gets made at a level where the tradeoff looks clean, automation versus a number that needs to look better this quarter, and the actual cost doesn’t vanish. It relocates, usually downward, onto whoever is closest to the gap and least equipped to say no to it. Two failed go live retrospectives happened with Feld in the room, and both times the language stayed vague enough that nobody had to name where the gap actually came from. “Data quality issues.” “Process gaps.” Both true, technically, and both doing a lot of work to avoid a harder sentence.

What changes things here isn’t that Feld had information the party didn’t. It’s that episode seven gave him a reason to believe disclosure wouldn’t blow up the room. That’s the actual payoff of Marge’s rule about demos that are allowed to break: trust built in one context tends to extend into the next one, and a sponsor who’s just watched a team handle a real exception without flinching is a sponsor more likely to hand over an uncomfortable truth of his own.

What happens next

Feld’s confession reframes the whole rebate problem, but it doesn’t fix it. The party now has to build the actual business case for automating what should have been automated eighteen months ago, and figure out what it really costs to finally do this right, against everything it’s already cost to do it wrong for a year and a half.

Next episode: Episode 9, The Real Cost (coming soon)

If a cost cut made somewhere above your project has quietly become someone’s daily manual task, you’re looking at the same pattern. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you want a framework built around naming these gaps before they turn into eighteen months of invisible labor, start here: adnd365.com/start

Autopsy #9: The Security Theater Demo

By
August 20, 2026
Uncategorized
Leave a comment

Cause of death: the box got checked without anyone asking what checking it actually meant.

Security comes up in most enterprise demos as a single slide, usually near the end, usually delivered fast. Role-based access control. Single sign-on. Field-level security. Audit logging. SOC 2. Encryption at rest and in transit. Each term gets a checkmark, a confident nod from the presenter, and about four seconds of screen time before the deck moves on to something more visually interesting.

Nobody in the room stops the slide. That’s the autopsy. Every term on that slide is real, in the sense that the feature genuinely exists somewhere in the product. What’s missing is any demonstration that it does what the room assumes it does, configured the way your company would actually need it configured, at the depth your actual risk profile requires.

What actually happened

“Role-based access control” is not one feature. It’s a spectrum that runs from a handful of fixed roles with no customization, through role-based permissions you can tailor at the menu-item level, through field-level and record-level security that can restrict a single sensitive column or a single customer’s data from a specific user, through fully dynamic, condition-based access rules that change what someone can see based on context. A vendor can put “role-based access control” on a slide truthfully at any point on that spectrum, and the room has no way of knowing, from the slide alone, which end they’re getting.

The same collapse happens to every other term on the list. “Audit logging” might mean every field change on every table is captured with before and after values and an immutable timestamp, or it might mean a handful of high-level events get logged with no field-level detail. “SOC 2” tells you an audit happened and a report exists. It doesn’t tell you which trust service criteria were in scope, what the exceptions were, or whether the report is even current. “Encryption at rest” is true of nearly every modern cloud platform and tells you almost nothing about key management, who holds the keys, or what happens in a subpoena scenario.

None of this is the vendor lying. Every term is technically accurate. The compression happens in the translation from a nuanced, configurable capability into a single reassuring word on a slide, and the room does the rest of the work by filling in the most generous plausible interpretation of what that word means.

Why it works on smart people

Security and compliance are exactly the kind of topic where nobody in a sales meeting wants to be the person who asks a question that reveals they don’t fully understand the acronym. SOC 2 Type I versus Type II, the difference between authentication and authorization, what “field-level security” actually restricts versus what it merely hides in the UI while leaving accessible through an API, these are legitimate technical distinctions that most people in the room, including some people whose job title suggests they should know them, have only a fuzzy grasp of.

The slide exploits that fuzziness efficiently, not through malice but through pace. There’s no room in a four-second checkmark to unpack what a term actually covers, and stopping to ask “which SOC 2 trust service criteria were in scope” in the middle of a fast-moving demo carries a social cost that quietly discourages the question from being asked, the same social cost that lets the AI Magic Demo’s chat window go unexamined.

The actual damage

This is the one that surfaces during an actual security review, an actual audit, or worse, an actual incident, months or years after the contract was signed. Someone in security or compliance, doing real diligence for the first time, discovers that “field-level security” in this product means the field is hidden in the standard UI but fully readable through the API with the right permission, which is a meaningfully different security posture than what was assumed at signing. Or the SOC 2 report, once actually read line by line, turns out to have scoped out exactly the subsystem your data lives in.

At that point the conversation isn’t a demo follow-up. It’s a risk finding, sometimes one that has to be reported up to a board or disclosed to a regulator, and remediating it after the fact, whether that means additional configuration, a compensating control, or a vendor conversation about contractual commitments, is far more expensive and far more visible than it would have been to ask the specific question up front.

The fix, if you’re the one presenting

Don’t let the slide stand alone. For each term, say what it actually covers and, just as importantly, what it doesn’t. “Field-level security restricts visibility in the standard interface. It does not currently restrict API access to the same field, here’s how customers typically compensate for that.” “Our SOC 2 report covers these three trust service criteria, and here’s the exception list from the most recent period.” That level of specificity costs a few extra minutes and makes the product sound less flawless. It also means the prospect’s actual security review, whenever it happens, confirms what they were told instead of contradicting it.

A checkmark is not a control. It’s a promise that a control exists, and promises deserve exactly as much scrutiny as anything else on the slide.

The same collapse happens to job titles, not just checklist items. In AI Makers Don’t Build Models. They Build Value., a single contested word, “maker,” was doing more work than it could support, and the gap got filled by whoever was listening. A security slide runs on the exact same mechanism, one word standing in for a spectrum, and the room filling in whichever end feels most reassuring.

The Contoso Convergence, Episode 7: The Steering Committee

By
August 18, 2026
Uncategorized
Leave a comment

An Advanced Dungeons & Dynamics 365 session. Episode 7 of 14.

Previously on: Episode 6, The Ghost in AP, the party found an eighteen month manual rebate accrual sitting in a suspense account, discovered the numbers didn’t match the actual contract terms, and learned that Oskar had inherited the whole mess without feeling senior enough to flag it.

Four weeks to go live, and the party finally has to answer to someone who isn’t in the war room every day. This episode is about the gap between what a project looks like from the inside and what it looks like from a slide.

The Session

GM: Four weeks out. Steering committee. The sponsor, a man named Feld who has opinions about PowerPoint, wants to see progress.

Feld: Just walk me through it. Order to cash. Should take ten minutes.

Marge: (under her breath, to the party) Golden path or real path?

Thorne: Real path. Every time. That’s the whole point of this engagement.

Marge: Feld, I can show you the happy path in ten minutes. I’d rather show you the actual order flow, exceptions included, because that’s what your team will live in. It’s twenty minutes. Worth it.

Feld: (checking his watch) Fine. Twenty.

Sable: (casting Data Mapping live, in front of the committee) Watch what happens when the order hits a partial shipment. This is the case that broke the second go live attempt.

The demo hits the exception. It resolves correctly, slower than a golden path demo, but correctly. Feld leans forward.

Feld: That’s the first time in this whole engagement someone showed me something breaking on purpose.

Ai. Cassiopeia: Sponsor confidence metric, trending upward for the first time since project kickoff.

Feld: (genuinely curious now) Show me another one.

Sable: This is the freight variance case. Multi leg shipment, split invoice, partial return. It’s ugly. Watch.

The second exception resolves too, a little slower, a little messier, but every number lands where it should. Feld sits back, arms crossed, but not defensively. He’s thinking.

Feld: In eighteen months, nobody has shown me a demo that wasn’t a straight line from order to cash. Every single one looked perfect. And every single one was wrong within a week of go live.

Marge: That’s usually the tell. If a demo never breaks, it’s not testing anything. It’s performing.

Feld stays for the full twenty minutes. Then he asks a question nobody expected.

Feld: If the demo can survive that, why isn’t the rebate mess fixed yet?

The demo that’s allowed to break

There’s a particular kind of silence that happens when a demo hits a real exception in front of a room full of decision makers, and then resolves it correctly anyway. It’s the sound of a sponsor recalibrating what they actually believe about a project. Not because the exception was impressive, but because it was honest, and honesty had apparently been in short supply for eighteen months.

Feld’s line is the whole point of this episode: every demo he’d seen before this one looked perfect, and every one of them broke within a week of go live. That’s not a coincidence, and it’s not bad luck either. A demo that never shows an exception isn’t reassuring anyone. It’s teaching the sponsor to trust a version of the system that doesn’t exist. When reality inevitably shows up looking messier than the slide, the sponsor doesn’t think “well, exceptions happen.” They think “I was lied to,” because in a sense, they were, just not maliciously.

Marge’s rule from episode one finally pays off here: document the golden path, don’t perform it. It costs more time in the room. It’s a harder sell to a sponsor checking his watch. But it’s the only version of a demo that actually builds trust instead of borrowing it against a deadline that’s going to come due eventually, usually at the worst possible moment.

Feld’s response tells you everything about what eighteen months of golden path demos had cost this project. It wasn’t more confidence. It was less. He’d learned, correctly, not to trust what he was being shown, and it took one honest twenty minute demo to start reversing that.

What happens next

Feld’s question lands exactly where it should: if the team can handle a broken demo in front of a steering committee without flinching, why has the rebate accrual been sitting unresolved for eighteen months? The party doesn’t have a good answer yet, because the real answer goes back further than anyone in the room realizes, and it’s about to become Feld’s problem too.

Next episode: Episode 8, What Feld Knew (coming soon)

If your last steering committee demo didn’t show a single exception, that’s worth thinking about. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you’ve ever sat through a demo that only shows the golden path, you already know why this scene matters. It’s the entire premise behind Dog and Pony Autopsy, worth a read if this one landed.

If you want the configuration discipline behind demos that are actually allowed to break, start here: adnd365.com/start

Autopsy #8: The Performance Demo

By
August 18, 2026
Uncategorized
Leave a comment

Cause of death: ten records don’t behave like ten million, and nobody in the room was thinking in millions.

The presenter clicks a button. A report renders instantly. A search returns results before the loading spinner has time to spin. A batch job that would, in your world, run overnight, completes in the time it takes to say “and here’s the output.” The room absorbs all of this the way it absorbs everything else in a demo: as evidence of how the product performs.

It is not evidence of how the product performs. It is evidence of how the product performs against a database with four hundred customers, running on hardware provisioned for a demo, with exactly one user logged in, who is the only person generating any load at all. Your environment, on day one of production, will have none of those three things in common with it.

What actually happened

Performance is not a property of software in isolation. It’s a property of software under a specific load, against a specific dataset size, with a specific number of concurrent users doing specific things at the same time. A demo environment is engineered, whether deliberately or just by the natural economics of running a sales demo, to minimize all three of these variables simultaneously. Small dataset, dedicated hardware, single user. That is close to the best-case condition the software will ever run under, and it’s the condition you’re being shown as though it were representative.

The gap between that best case and your actual production reality is usually invisible in the room because nothing about the demo interface tells you the dataset is small. A grid with four hundred rows and a grid with four million rows look identical on screen, for the same reason they looked identical in the migration autopsy: you’re only ever looking at the same twenty rows at a time. Query performance, index behavior, and lock contention all degrade in ways that simply don’t exist yet at four hundred rows, and none of that shows up until the dataset, and the concurrent user count, both climb to something resembling your real operation.

Batch and integration jobs hide the same gap differently. A nightly job that processes four hundred records in three seconds tells you almost nothing about how it will behave processing four hundred thousand records at 2 a.m. while five other scheduled jobs are also competing for the same database connections. The three-second version and the six-hour version can be, technically, the exact same code.

Why it works on smart people

Performance is one of the few things a demo can show without narrating, which makes it feel more objective than the parts that require a presenter’s framing. Nobody has to make a claim about speed. You just watch it happen, in real time, and speed you watch with your own eyes reads as harder evidence than speed someone tells you about. That instinct is usually correct. It’s just being applied to a measurement taken under conditions that will never recur once the system goes live.

There’s also a scale-intuition gap that’s genuinely hard to close without direct experience. Most people don’t have a strong internal sense of how nonlinearly performance can degrade as data volume and concurrency grow. A system that feels instant at four hundred records doesn’t necessarily feel merely a little slower at four million. Depending on how indexes, queries, and locking are built, it can fall off a cliff at some threshold nobody in the demo room has any way of anticipating.

The actual damage

This is the one that shows up as a go-live incident rather than a slow discovery, because performance problems under real load tend to announce themselves immediately and all at once, usually during month-end close or the first day the full user base logs in simultaneously. Reports that took two seconds in the demo take four minutes. A batch process that ran in three seconds against sample data doesn’t finish before the next scheduled job needs the same resources, and the two start colliding every night.

The remediation at that point is expensive and disruptive in a way that early testing would not have been: emergency performance tuning, index rebuilding, sometimes an infrastructure upgrade that wasn’t budgeted, all happening under the worst possible conditions, with live users blocked and a go-live date already spent.

The fix, if you’re the one presenting

Test and show performance against something that resembles your prospect’s actual scale, not the vendor’s default demo dataset. If a true load test isn’t feasible in the sales cycle, at minimum say so explicitly: “this demo is running against four hundred sample records on dedicated hardware, here’s what we know about performance at your expected volume, and here’s how we’d validate it before go-live.” That sentence costs you the illusion of effortlessness. It buys you a prospect who understands what they’re actually being shown, and a performance conversation that happens in scoping instead of in a production incident.

Speed you watched with your own eyes is still only evidence of the conditions you watched it under. Ten records were never going to tell you what ten million would do.

I’ve argued in The Same Four Systems that the same organizational patterns show up whether you’re a corner store or a Fortune 500 company, just with higher stakes. That holds for structure. It doesn’t hold for performance. A query pattern that’s invisible at four hundred rows can become the whole story at four million, and no amount of pattern-matching from a small scale prepares you for exactly where that threshold sits.

The Contoso Convergence, Episode 6: The Ghost in AP

By
August 17, 2026
Uncategorized
Leave a comment

An Advanced Dungeons & Dynamics 365 session. Episode 6 of 14.

Previously on: Episode 5, One Hour, the party fixed the integration that had been silently feeding the shadow ledger, and discovered the real problem was a five minute config fix hiding behind three weeks of assumed complexity.

Fixing one thing tends to reveal the next thing. That’s not bad luck. It’s what happens when you finally have clean data to look through instead of a mess to guess at. This episode, the party gets its first real look at what’s underneath everything else, and finds something that’s been there a lot longer than three weeks.

The Session

GM: The integration fix holds. Landed cost posts clean. The room exhales for the first time in five episodes.

Sable: Don’t relax yet. Validating the postings surfaced something else. There’s a recurring accrual in AP. Same amount, every month, for eighteen months. It posts to a suspense account and just sits there.

Thorne: Vendor?

Sable: Vendor code is a placeholder. “VEND TEMP 01.”

Marge: Another TEMP. Of course.

Ai. Cassiopeia: I cross referenced the amount against the vendor rebate program from the original ASC 606 transition. It matches a rebate structure that was supposed to be automated and never was.

Vex: So someone’s been manually estimating a rebate accrual for a vendor that might not even be configured right, for a year and a half, and just letting it sit in suspense?

Priya’s replacement (a nervous analyst named Oskar): That was me. I inherited it from Priya’s predecessor. Nobody told me to stop.

The room turns toward Oskar, who has been standing quietly near the door for most of the conversation, clearly hoping nobody would ask.

Marge: How does a manual accrual survive eighteen months and two go live attempts without anyone flagging it?

Oskar: (quietly) Because it closes clean every month. The number’s never wildly wrong. It’s just never provably right, either. Nobody’s ever had time to check.

Sable: (gently) You weren’t hiding this.

Oskar: I didn’t think I was allowed to raise it. I’m not senior enough to say the automated process was never built.

Ai. Cassiopeia: For the record, this is not a criticism of Oskar’s work. His estimation methodology is, if anything, unusually disciplined for a manual process running this long.

Thorne pulls up the original rebate contract terms. The numbers on the page do not match the numbers in the suspense account. Not by a little.

Thorne: Oskar. Whatever you were estimating against, it isn’t this contract.

The person doing the invisible work

Every implementation eventually finds an Oskar. Someone junior enough that they inherited a broken process rather than built it, and senior enough to keep it running competently for eighteen months without anyone above them noticing there was a problem at all. That combination, competent enough to hide the gap, junior enough to feel like they can’t raise it, is exactly what lets a process like this survive two failed go live attempts.

This isn’t a story about someone cutting corners. It’s the opposite. Oskar’s discipline is the reason nobody noticed sooner. A sloppier manual process would have thrown obviously wrong numbers and gotten caught in month two. A careful one, run by someone paying close attention every single month, can close clean for a year and a half while quietly drifting further and further from the actual contract terms underneath it.

The real failure here happened before Oskar ever touched the spreadsheet. Somewhere in the original ASC 606 transition, a line item for rebate automation didn’t get built, and instead of that gap showing up as a flagged risk, it got quietly absorbed by whoever happened to be sitting in the AP seat at the time. That’s the pattern worth naming: work that should have been a system’s job becomes a person’s invisible responsibility, and the person doing it often doesn’t feel like they have standing to say so out loud.

What happens next

The numbers on the contract and the numbers in the suspense account don’t match, and now the party has to figure out how far off they actually are, eighteen months deep, with go live four weeks away and a steering committee that’s about to start asking pointed questions about why the timeline hasn’t moved.

Next episode: Episode 7, The Steering Committee (coming soon)

If there’s a process on your team that’s being quietly kept alive by someone who doesn’t feel senior enough to flag it, this episode is for them too. Gamifying the Enterprise: Game Mechanics for Continuous Proficiency is available now on Amazon: https://www.amazon.com/dp/B0GY3VWLVX

And if you want to build the kind of system where gaps like this get caught in month two instead of month eighteen, start here: adnd365.com/start

Autopsy #7: The Kitchen Sink Demo

By
August 17, 2026
Uncategorized
Leave a comment

Cause of death: nobody could agree on what the proof of concept was supposed to prove.

This one starts differently than the others. Every autopsy so far has been performed on a demo the vendor built to look better than reality. This one is performed on a demo the customer built, with the vendor’s help, to answer everything at once, and in doing so answered nothing.

The pattern is familiar to anyone who has scoped a proof of concept. It starts small and correct. One core question, one hypothesis, one thing that either works or doesn’t: can this system handle our multi-entity intercompany billing without a workaround, yes or no. Then someone from a different department hears there’s a POC happening and asks if it can also touch their process, since they’re curious too. Then someone senior asks for the trickiest edge case in the business to be included, because if it can’t handle that, what’s the point. By the time the scoping document is final, the POC that was supposed to answer one question is now attempting to demonstrate manufacturing, procurement, three approval hierarchies, a currency conversion edge case that occurs twice a year, and an integration to a system that isn’t even part of the actual project scope.

Nobody added any single piece of this in bad faith. That’s what makes it hard to stop once it’s moving.

What actually happened

A proof of concept exists to reduce uncertainty about one specific, high-risk question as cheaply and quickly as possible. The moment it starts trying to prove ten things instead of one, several things happen at once, all of them bad.

The build time stops being proportional to the risk being retired. A POC that answers one hard question can often be built in days, because the vendor and the team can focus every hour on the thing that actually matters. A POC trying to demonstrate ten things needs ten times the configuration, ten times the test data, ten times the edge cases handled, and none of that additional effort is reducing risk proportionally, because nine of the ten things were never actually in doubt.

The result also stops being interpretable. If the multi-entity billing scenario fails, but it failed inside a build that also included four other complex configurations layered on top of each other, you cannot cleanly attribute the failure. Was it the core capability that doesn’t exist, or a configuration conflict between two features that were never meant to be tested together, or a data setup error introduced trying to support scenario six while building scenario three. A focused POC gives you a clean signal. An overloaded one gives you noise that looks like a signal.

Why it happens to smart teams

The instinct behind scope creep in a POC is almost always defensible in isolation. Nobody wants to greenlight a six or seven figure implementation based on a narrow test, only to discover eight months in that some other critical process doesn’t fit either. The fear isn’t irrational. Systems do have gaps that only show up once you look in the right corner, and a POC feels like the cheapest moment to go looking.

The trouble is that “the cheapest moment to look” and “the cheapest way to look” are different questions. Looking broadly at low depth, a checklist of yes-or-no capability questions answered through documentation review, a reference call, or a scoped demo of specific features, retires broad risk cheaply. A single POC trying to go deep on ten things at once is neither cheap nor deep. It’s the expensive way to get a shallow answer to a question that didn’t need a POC to answer in the first place.

There’s also a political dimension that’s hard to name out loud in the room. Once word gets out that a POC is happening, being excluded from it can read as a signal that your department’s concerns don’t matter. Scope grows partly because saying no to an additional scenario feels like saying no to a person, not to a line item.

The actual damage

The POC that was supposed to take two weeks takes eight. The core question, the one thing that actually justified spending POC time and budget, gets buried under nine other questions that each needed their own edge case handling, and by the time results come back, the steering committee is looking at a partial success across ten dimensions instead of a clear answer on the one dimension that mattered. Decision paralysis follows almost automatically, because a partial, ambiguous result is much harder to act on than a clean pass or fail.

Worse, the actual high-risk question, the reason the POC existed in the first place, often gets the least rigorous testing of the ten, because it was scoped first and then diluted by everything added after it. The team spends real effort proving things that were never seriously in doubt, and comparatively little effort on the one thing that was.

The fix, if this is your situation

Separate what the POC needs to prove from what people merely want to see. Write down the single question, or at most two, whose answer would actually change the buying decision. Everything else, every “while we’re in there” request, goes on a second list explicitly labeled as out of scope for this exercise, with a stated plan for how it will get answered instead, whether that’s a reference call, a documentation review, or a second, later POC once the first question is settled.

When someone pushes back and asks why their scenario isn’t included, the honest answer is the useful one: this POC is designed to answer one hard question as cleanly as possible, and adding your scenario wouldn’t make the answer more trustworthy, it would make it harder to read. That’s not a dismissal of their concern. It’s a commitment to answering it properly, later, instead of poorly, now, buried inside somebody else’s test.

A POC that tries to prove everything proves nothing cleanly. The discipline isn’t in the build. It’s in what you refuse to put in it.

The same fragmentation shows up in individual work, not just project scoping. In The Forty One Percent Problem, I look at decades of research showing that a large, stable share of professional time gets eaten by low-judgment overhead scattered across too many things at once. A POC that tries to answer ten questions has the same disease as a workday that tries to touch ten priorities. Depth loses to breadth every time.

The Forty One Percent Problem

By
August 14, 2026
Uncategorized
Leave a comment

AI assistants are not a new idea. They are the first real attempt to fix a problem management research documented seventy years ago and never actually solved for most people.

Every pitch for an AI assistant makes some version of the same claim: it will take the administrative weight off your day so you can focus on the work that actually matters. That claim is usually presented as new. It is not. It is the exact same claim that got made about executive secretaries, and it is backed by the same research, run three separate times across seven decades, always finding the same number.

The short version: a large and remarkably stable share of professional work, something close to 40 percent, is low-judgment administrative overhead rather than the work someone was actually hired to do. For most of the twentieth century, the only fix on offer was a personal secretary, and that fix was rationed almost entirely by seniority. AI assistants are the first attempt to offer that same relief to everyone else. Here is where that number comes from, and why the history matters for judging whether the new fix is real.

The first study

In 1951, a Swedish economist named Sune Carlson did something nobody had done before. He asked a group of managing directors to keep detailed diaries of their working days, logged in real time rather than reconstructed from memory afterward. The result, published as Executive Behaviour, is generally regarded as the first systematic empirical study of what managers actually do with their time, as opposed to what people assumed they did.

The picture that emerged was not flattering. Executive days turned out to be fragmented, reactive, and dominated by short bursts of low-level activity. Phone calls. Correspondence. Brief conversations. Interruptions. The romantic image of the executive locked away making weighty strategic decisions bore little resemblance to the diaries. Most of the day was consumed by administrative traffic that did not require an executive’s judgment at all, it just required someone competent to handle it.

Carlson’s book was not widely read at the time. It was sparse on conclusions and thin on theory. But the method survived. Two decades later, Henry Mintzberg ran a similar observational study and arrived at the same finding, dressed in more modern language. Managers do not spend their days thinking. They spend their days responding.

The finding keeps getting rediscovered

What is striking is not that this was found once. It is that it has been found repeatedly, in different decades, using different methods, on different populations of workers, and the number keeps coming back roughly the same.

In 2013, Julian Birkinshaw and Jordan Cohen ran a three year study of knowledge workers and published the results in Harvard Business Review under the title “Make Time for the Work That Matters.” Their headline finding: knowledge workers spend an average of 41 percent of their time on discretionary activities that offer little personal satisfaction and could be handled competently by someone else. Participants who went through a structured process to identify and shed that work cut desk work by roughly six hours a week and meeting time by two more.

Five years later, Harvard Business School’s Michael Porter and Nitin Nohria published the results of tracking 27 Fortune 500 CEOs for a full year, more than 60,000 hours of coded time-use data. It remains the most detailed public look at how chief executives actually spend their days. The finding was not that these people were lazy or undisciplined. It was that even at the very top of an organization, with every resource available to protect their time, a large share of it still got eaten by things that did not need a CEO to do them.

Three studies, seven decades apart, using diaries, surveys, and direct observation, converging on the same basic fact: a large and remarkably stable percentage of professional work is low-judgment administrative overhead. Not incompetence. Not poor discipline. Just the physics of running an organization, where information has to move, calendars have to align, and someone has to read the email before anyone can decide whether it matters.

Why the fix was always rationed

Here is the part of the story that gets skipped over. The research kept finding the same problem, but the solution it kept prescribing, dedicated administrative support, was never distributed according to who had the problem. It was distributed according to seniority.

A junior employee drowning in the same 41 percent of low-value work as a CEO simply absorbed it. There was no equivalent relief further down the org chart. And as email, shared calendars, and self-service scheduling tools spread through the 1990s and 2000s, even the people who had once had dedicated secretarial support increasingly lost it, on the theory that the tools themselves had closed the gap. The secretary and executive assistant roles contracted sharply. The underlying problem the research had documented did not contract with them. It just became something everyone quietly managed alone.

This is worth sitting with, because it means the historical relationship between “having administrative support” and “being more productive” was never really tested at scale. It was tested at the top of organizations, on people who already had every other advantage, and the results were treated as proof of a general principle that was never actually given the chance to apply generally.

What changes when the support is not rationed by rank

The research gives a fairly precise description of what kind of work is worth taking off someone’s plate: correspondence, scheduling, screening, routine drafting, information retrieval, status tracking. Not judgment work. Not relationship work. The mechanical layer underneath both of those things.

That is also, not coincidentally, close to the exact list of tasks that current AI tools are best at and are being adopted for first. Which suggests the honest way to think about AI assistants is not as a replacement for a human secretary, doing the same job with different hardware. It is closer to the first real attempt to deliver the same category of relief that Carlson’s executives had, to people who were never senior enough to be given it.

That reframe matters because it changes what the interesting question is. The old question, does an executive with a secretary outperform one without, was really a proxy for a different question that took seventy years to ask properly: how much of anyone’s professional capacity is being spent on work that has nothing to do with why they were hired, and what happens when that overhead gets pushed down toward zero for everyone, not just the people at the top of the org chart.

There is a genuine limit to the analogy, and it is worth naming rather than skating past. A human assistant carries judgment and institutional memory that took Carlson’s own subjects years to build with the people supporting them, knowing which call to interrupt a meeting for and which one to let go to voicemail. Whether that layer of judgment gets replicated, approximated, or simply left undone is not a question the old research can answer, because the old research was never testing for it. What it can tell us, with unusual consistency across seventy years of data, is the size and shape of the problem being solved. That part, at least, is no longer a mystery.