I like to learn, and I have learned more in the past eight months than in the previous eight years.
In part, our world has started moving quickly enough that you either learn quickly or face irrelevance. But also: AI allows us to research new ideas and experiment with their implementation at a faster pace. I had forgotten how much you learn when you just do things rather than asking others to do things.
Our next Technology Leadership Forum is coming up. [1] I write a little welcome note for each event -- for this fall’s note, I started jotting down what I think I have learned this year.
Which raises a question: do we always want to learn true things? How true are the things I think I have learned and under what circumstances are they true? An example: I might say: people are not seven feet tall. You might go a lifetime without meeting a seven-foot-tall person. You would never design a car to make seven-footers comfortable. Yet about 3,000 people that tall are walking the planet. Presumably bumping their head on things.
As always, large institutions make Bayesian epistemology more complicated because of small ns and a diversity of independent variables. You can estimate how many people grow to seven feet. In contrast, I used to say “lift-and-shift” didn’t make sense as a cloud migration approach and hosting cost reductions (by themselves) wouldn’t justify migration investments. True -- unless you faced a major facility investment to improve resiliency or if you hadn’t taken advantage of previous innovations like server virtualization.
So of the propositions I jotted down, how often are they true? Under what circumstances do they serve as useful design and planning assumptions -- and when not?
1. Now more than ever, advantage derives less from adopting technology than from integrating it into an operating model
Radar didn’t win the Battle of Britain for the RAF. The Dowding system (which used radar) did. Which improves operating income: using chatbots to write longer emails or figuring out what AI does well and then building a reimagined business process around that? The Jevons paradox applies to both knowledge work and busy work -- so be careful about what you automate.
2. GenAI is a discontinuity because for the first time we can process the thicket of business rules and messy data that bedevil systems projects without doing that by hand
This changes the ROI dynamics of technology investment by reducing the cost of translating entropic reality into structured data and explicit rules. The returns from AI investments will vary widely by domain -- high-entropy domains (with unstructured data and tacit business rules) will yield higher returns because you couldn’t automate them as well previously. We have organized factories and call centers, but chaotic offices -- GenAI may create the opportunity to repair this discrepancy.
3. You can invest some of the engineering productivity GenAI creates in empowering users
In seeking to contain system cost and complexity, companies have often burdened users with painful interfaces and designed processes around data models. How much stress could we remove from the user experience with composable UIs, chatbots that accept free-text input and composable documents -- as well as with tools that help users think and communicate more effectively?
4. Your business strategy and operating model rest on a set of relationships, which you can encode in a graph built on an ontology.
How you run your business rests on a set of assumptions about which customers value which product features, and which levers drive which metrics. Your ontology becomes a way for you to encode your business strategy and operating model -- and decide how to optimize them.
5. AI will reshape tech economics in surprising ways
You can triple the EBITDA lift from enterprise technology by using AI to free up more budgetary capacity for business-driven investment and getting more from each dollar invested. You need AI to redesign enterprise technology no less than any other business domain; for example, you may find that agentic software engineering upends some of your traditional buy-build decisions and you can’t succeed with AI using manual technology governance.
Tech-for-tech investments may represent some of your company’s highest ROI opportunities -- and the build cost of AI systems rather than tokens will be the gating factor in AI adoption over the next several years.
But CIOs must elicit cooperation from the rest of the executive suite to change technology economics in positive ways, rather than letting them change in negative ones.
6. Build an AI platform for rapid scale. Build a modular platform for flexibility
Transforming your business via a series of use cases is like getting to the moon by climbing the tallest tree -- the first fifty feet feels great, but you wind up with a disconnected mess that you can’t scale or support -- and business leaders who must sub-optimize in each silo. You need to build, secure, discover and monitor agents at scale. Cutting-edge capabilities may be obsolete in a year, so you need to switch components in and out of your platform.
7. The model is not the architecture, and often not the most important part of the architecture
Models just predict outputs based on inputs -- no model can reason over context it does not have. Memory is often the constraint, not compute -- there won’t be a window big enough to hold all your business context any time soon. Models reason better over structured input than over free text, improving reliability, speed and cost.
8. You want to focus on where you use non-deterministic processing because deterministic processing is faster, cheaper and more reliable
Sometimes you want to use agentic software engineering to build deterministic business rules -- and take advantage of thirty years of experience in software quality assurance. Sometimes you want to use agentic data ingestion or agentic UIs to convert free text to structured data. Reserve non-deterministic processing where ambiguity, complexity and exceptions require it.
9. Agents don’t eliminate software engineering. They move it up a level of abstraction, so team cyborg will beat team android
Agentic development abstracts away syntax and reduces toil; it doesn’t eliminate the physics of software engineering. Current coding agents create technical debt and risk at high speed without adult supervision. Large institutions will use the talents of software engineers and citizen developers, who will look more like strats than vibe coders -- and you should ask whether it’s easier to teach business analysts about software engineering or software engineers about business domains!
Are some of these true in some circumstances and less true in others? Of course!
When might there be use cases so economically attractive (e.g. contract terms enforcement for procurement, revenue leakage) that you should just execute on them quickly?
Is compute rather than memory the bottleneck in R&D application in sectors like materials science?
When might full autonomy beat team cyborg – because the task is high-volume, bounded and easily verified, making human review more expensive and less reliable than automated validation (e.g. data center scheduling)?
That’s the difference between formulating strategy and receiving dogma. I look forward to the discussion about the validity of these learnings -- and their applications!
Footnotes
[1] Confirming emails! Menu choices! Seating charts! For a couple of weeks in the spring and the fall each year I become a party planner.
Spot on! Can't wait for TLF!