Providing the missing foundation for Mujtaba Hamid’s “The New Source of Software Differentiation” post (Booz Allen Hamilton, 13 November 2026)
Booz Allen’s EVP of Product, Mujtaba Hamid, published a piece this week that every CTO and CIO should read. His argument is simple and, I think, right. Agentic coding has made custom software fast and cheap to build. His opening example is a federal agency engineer who built a working replacement for a grants management system in a week. When anyone can build personalized software, personalization stops being an advantage. What sets one organization’s software apart is the tradecraft inside it: the operational experience, decision logic and judgment of the people who do the work best. In his words, the advantage goes to organizations that “know what their software should know.”
I agree. I want to add the step that comes before it, because that step is where most initiatives go wrong.
The tradecraft nobody can describe
Hamid advises CTOs and CIOs to work with leaders across the organization to identify which parts of their tradecraft can be captured, tested and improved in software. That is the right instinct. But there is a catch: people can only describe the work they know they’re doing.
In 1998, I was brought in on a defense maintenance contract that was running at 51% next-day delivery against a contractual requirement of 90%. The service provider wanted to automate procurement, because procurement looked like the bottleneck. Everyone involved knew their own part of the work:
The technicians knew they held their part orders until late afternoon, because they were measured on call volume and stopping to order a part interrupted a service call.
The suppliers knew when they received orders, and the couriers knew their own cutoff times.
Procurement knew it processed every order it received before the end of the day.
Every one of those accounts was accurate. Nobody could see how they combined: orders arriving after the courier cutoffs, which made next-day delivery impossible no matter how fast procurement worked. That only became visible by tracing back from the missed deliveries.
If we had asked each group to describe its workflow and encoded the answers, we would have built a faster version of the failure. That is the risk in capturing tradecraft by asking for it. The most important parts of how an operation really works are often the parts no one can tell you, because no one sees them whole.
This isn’t a concept for us. It’s a method with a record.
I want to be direct about one thing, because it matters to anyone deciding whether this is good advice or a proven approach. Finding those hidden crossings is not something we worked out in response to AI. It is a method with a name and a history: Hansen Strand Commonality™.
1983. Programming in dBASE II, I first saw that improving one line of code could stop another, once working, from working at all. The parts of a system interact in ways no single part reveals.
1998. The defense maintenance contract above, where I formulated that observation as a theory and a practice: start from the outcome that didn’t happen, follow the strands back, and find where they cross.
Since then. Applied across every technology wave that followed, and today built into ARA™ RAM 2025™, where it averages 91% output accuracy across our documented case labs, assessed against the evidence.
Booz Allen calls the knowledge inside great software tradecraft. McKinsey describes its AI operating system as an enterprise “second brain.” Whatever the name, Strand Commonality™ is how you find the part of that knowledge nobody can articulate, before it gets encoded.
“Illustrative. AI operating system layers as published by McKinsey, 13 October 2026. Hansen is not affiliated with McKinsey.”
The graphic shows how that works. On the left is the operation as it actually runs, including the incentives, shadow systems and workarounds that never appear on the documented map. Tracing back from an outcome that fell short shows which of those strands crossed. That validated picture of how the work really happens is what should feed the software, whatever operating system or platform sits on top. A second brain is only as good as the first brain that feeds it.
We have seen this before
This is not the first time building got cheap and the value moved somewhere else. In 2003, the web had made it easy to put procurement online, and the Ottawa Business Journal profiled the company I was running at the time. Its niche was a problem that had nothing to do with the platform itself: for the high-tech companies we served, the process of obtaining a specialized part often cost more than the part. The value was in understanding that process, not in the software that put it online.
The same article quoted Greg Boyle of the Stonewood Group on why so many companies were stagnating after the dot-com crash. Ottawa, he said, had been “very techno-centric,” and too few people were comfortable engaging the clients the technology was meant to serve. Twenty-three years later, the technology is different. The trap is the same.
What is different now
What has changed is the speed. In 2003, a hidden process problem slowed people down. Software built by agents, and agents acting on their own, will run whatever has been encoded, at machine speed and at scale. What they won’t run is what nobody knew to encode: the shadow workarounds and the incentives that actually keep the operation working. A seam nobody traced becomes a mistake repeated thousands of times before anyone notices.
That makes Hamid’s point more urgent, not less. If tradecraft is the product, then getting the tradecraft right is the whole job. And the reliable way to find the part nobody can describe is to start from an outcome that didn’t happen and trace backward until you see where the strands cross.
Ten years from now, the technology will have another name. The principle won’t change. It’s in the seams where everything happens, but no one is looking.
So here is the question I would put to any leader about to encode their organization’s expertise: before you encode the tradecraft, how will you find the parts of the work nobody knows they’re doing?
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Before You Encode the Booz Allen Tradecraft or McKinsey Second Brain, Trace It
Posted on November 14, 2026
0
By Jon W. Hansen, FCIPS · Procurement Insights
Providing the missing foundation for Mujtaba Hamid’s “The New Source of Software Differentiation” post (Booz Allen Hamilton, 13 November 2026)
Booz Allen’s EVP of Product, Mujtaba Hamid, published a piece this week that every CTO and CIO should read. His argument is simple and, I think, right. Agentic coding has made custom software fast and cheap to build. His opening example is a federal agency engineer who built a working replacement for a grants management system in a week. When anyone can build personalized software, personalization stops being an advantage. What sets one organization’s software apart is the tradecraft inside it: the operational experience, decision logic and judgment of the people who do the work best. In his words, the advantage goes to organizations that “know what their software should know.”
I agree. I want to add the step that comes before it, because that step is where most initiatives go wrong.
The tradecraft nobody can describe
Hamid advises CTOs and CIOs to work with leaders across the organization to identify which parts of their tradecraft can be captured, tested and improved in software. That is the right instinct. But there is a catch: people can only describe the work they know they’re doing.
In 1998, I was brought in on a defense maintenance contract that was running at 51% next-day delivery against a contractual requirement of 90%. The service provider wanted to automate procurement, because procurement looked like the bottleneck. Everyone involved knew their own part of the work:
Every one of those accounts was accurate. Nobody could see how they combined: orders arriving after the courier cutoffs, which made next-day delivery impossible no matter how fast procurement worked. That only became visible by tracing back from the missed deliveries.
If we had asked each group to describe its workflow and encoded the answers, we would have built a faster version of the failure. That is the risk in capturing tradecraft by asking for it. The most important parts of how an operation really works are often the parts no one can tell you, because no one sees them whole.
This isn’t a concept for us. It’s a method with a record.
I want to be direct about one thing, because it matters to anyone deciding whether this is good advice or a proven approach. Finding those hidden crossings is not something we worked out in response to AI. It is a method with a name and a history: Hansen Strand Commonality™.
Booz Allen calls the knowledge inside great software tradecraft. McKinsey describes its AI operating system as an enterprise “second brain.” Whatever the name, Strand Commonality™ is how you find the part of that knowledge nobody can articulate, before it gets encoded.
“Illustrative. AI operating system layers as published by McKinsey, 13 October 2026. Hansen is not affiliated with McKinsey.”
The graphic shows how that works. On the left is the operation as it actually runs, including the incentives, shadow systems and workarounds that never appear on the documented map. Tracing back from an outcome that fell short shows which of those strands crossed. That validated picture of how the work really happens is what should feed the software, whatever operating system or platform sits on top. A second brain is only as good as the first brain that feeds it.
We have seen this before
This is not the first time building got cheap and the value moved somewhere else. In 2003, the web had made it easy to put procurement online, and the Ottawa Business Journal profiled the company I was running at the time. Its niche was a problem that had nothing to do with the platform itself: for the high-tech companies we served, the process of obtaining a specialized part often cost more than the part. The value was in understanding that process, not in the software that put it online.
The same article quoted Greg Boyle of the Stonewood Group on why so many companies were stagnating after the dot-com crash. Ottawa, he said, had been “very techno-centric,” and too few people were comfortable engaging the clients the technology was meant to serve. Twenty-three years later, the technology is different. The trap is the same.
What is different now
What has changed is the speed. In 2003, a hidden process problem slowed people down. Software built by agents, and agents acting on their own, will run whatever has been encoded, at machine speed and at scale. What they won’t run is what nobody knew to encode: the shadow workarounds and the incentives that actually keep the operation working. A seam nobody traced becomes a mistake repeated thousands of times before anyone notices.
That makes Hamid’s point more urgent, not less. If tradecraft is the product, then getting the tradecraft right is the whole job. And the reliable way to find the part nobody can describe is to start from an outcome that didn’t happen and trace backward until you see where the strands cross.
Ten years from now, the technology will have another name. The principle won’t change. It’s in the seams where everything happens, but no one is looking.
So here is the question I would put to any leader about to encode their organization’s expertise: before you encode the tradecraft, how will you find the parts of the work nobody knows they’re doing?
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
Share this:
Like this:
Related