One program, not three
Architecture modernization, teams and AI move together, or you pay for the same migration twice.
There is a moment in a platform rebuild where you can watch the whole idea of this newsletter happen on one screen.
An analyst opens a validation queue every morning and works it by hand. Check the figure, check the source, flag the ones that smell wrong, escalate the rest. Skilled work, and most of it deadening.
I got to take that apart in different customers. We rebuilt the platforms underneath it, restructured the teams around the flow of the work instead of the old function boxes, and use AI when needed while prioritizing good software engineering practices. And not a single time we managed to fully automate the processes... we could speed up things, reduce toil... and that is what I want to keep on doing.
Here is the part that matters, and it is not the model.
It never was only about three projects, but always about 1 mandate. Rebuild the systems, reshape the teams that owns it, put AI in the loop when it makes sense and where the work actually happens, all at once… because any one of them alone moves the number by roughly nothing.
Everyone wants to talk about the GenAI model (“open weights is better, while the new claude/gemini/anthropic is this and that”) ... but that is the easy part. The hard part, the part that on a good engagement moves a grinding manual step from roughly 8% handled by a machine over 1 week of work to 80% automagically going in 2h, was that the platform, the team and the model were built to fit each other in a single pass. Do those in sequence, a year apart, three budgets and three sets of consultants, and you get three tidy successes and a number that never budges.
That gap is the thing I keep coming back to. It is the whole reason for this.
Who is writing this
I am Thiago. Twenty years ago I was a statistician in Brazil, then a data scientist, a DBA, a software engineer, data engineer, a hands-on architect, then a CTO… these days a recovering CTO who still writes the code and knows that systems design while keeping myself at the trenches is what makes me happy. The recovering part is that I have run orgs internally, sat as interim head of _fill the gap_, been on the hook for the quarterly number and still never managed to fully close the loop only with tech.
Most of my recent years went into modernization and into getting generative AI into how software actually gets built, not into slides about how software might one day get built.
This is issue one. Every week I am going to work one problem out loud here: architecture modernization, team design, and AI capability as a single program, written by someone still in the code and not narrating it from a stage.
No downloadable kit this week. No five-box framework in a tidy PDF. Just the argument, and an ask. If you have lived this, subscribe and tell me where I am wrong. That is not a growth tactic, it is genuinely half the point, because the interesting version of this idea is the one that survives contact with your actual estate.
Everybody already has an operating model. Almost nobody wrote it down.
Every company I walk into already has an operating model, whether or not anyone calls it that. It is just how IT creates and delivers value: who owns what, how work moves from an idea to something running in production, where the decisions actually get made versus where the org chart says they do.
Most companies never wrote it down. The ones that did wrote a box diagram, and the box diagram has not been opened since the offsite where it was drawn.
None of that is wrong, exactly. It is just not the part that decides whether you ship. The part that decides is whether the architecture, the teams, and the AI capability were built to fit each other, or merely filed in the same org chart and left to work it out.
The textbooks are winging it too
I went and read the research on this properly, because I wanted to know whether the academics had a cleaner answer than I did.
They do not, and I can point you to the receipt.
In 2025, Suleman, Pekkola, Ralyté and Ahola published a systematic review in Information Systems Management that went through 77 academic and consulting sources hunting for an agreed definition of the IT operating model. It came back without one. The number of components the thing is supposed to have swings from four to thirteen, depending mostly on which consultancy is holding the pen. It is open access, so you do not have to take my word for it: the link is in the Sources at the bottom, go argue with it yourself.
The people whose actual job is to define this cannot agree on what it is or how many pieces it has. I find that oddly reassuring. If you have ever sat in a transformation kickoff quietly unsure what “operating model” meant in that room, relax: neither does the literature.
They drew the box. They skipped the wiring.
Here is the more useful finding from that same review, and it is the one that explains your last reorg.
The research treats the operating model as a structure. Decision-rights grids. Boxes for standardization versus integration. Who reports to whom. All of it about shape.
The one principle that would make the thing actually work is mostly missing: designing the technical side and the human side to fit each other, on purpose, at the same time, instead of optimizing one and inheriting the other. That idea is not mine either. It is called joint optimization, and it has been around since Trist and Bamforth’s coal-mining studies in 1951. Somehow it never explicitly made it from the sociotechnical-systems literature into the operating-model textbooks. Tune the tech, take the team as given. Or reshuffle the team, leave the systems where they were. Either way you optimized one subsystem and let the other one ride along as a hostage.
That is why the last reorg did not take. You moved the boxes and the systems stayed exactly where they were. And it is why the AI pilot is sitting next to the work instead of inside it, technically running, in the sense that a treadmill in a spare room is technically a gym.
There is one idea the academics keep underusing that every engineer already lives: your system ends up shaped like your org chart. Conway named it in 1968, in a paper literally titled “How Do Committees Invent?”. Skelton and Pais turned it into a practice in Team Topologies. Org structure and system architecture are the same problem, which is exactly why you cannot move one and expect the other to hold still.
On AI, the theory has not shown up yet
Now put AI into that picture, and it gets funnier.
The most cited frameworks for an AI-era operating model are not peer-reviewed. MIT CISR put out a research briefing on it in late 2025 (Thorogood and Woerner, “Enterprise IT Operating Models in the AI Era”). The fashionable “agentic operating model” comes from a 2026 California Management Review Insights column (Saini, “Governing the Agentic Enterprise”), which is editor-screened online commentary, not a peer-reviewed journal article. Both are thoughtful. Both are essentially field notes with good production values. Nobody has settled research on how AI actually reshapes the operating model. Practice is ahead of theory here, which is a generous way of saying we are all making it up, and the only real difference is who is keeping honest notes.
That greenfield is exactly what this newsletter walks into.
And it matters more than it sounds, because AI does not stay a tool for long. It becomes an actor in how your organization operates.
When Air Canada’s chatbot confidently invented a bereavement-fare policy that did not exist, the airline’s defense at tribunal was that the chatbot was “a separate legal entity responsible for its own actions.” They lost (Moffatt v. Air Canada, 2024 BCCRT 149, if you want to watch a tribunal politely decline to believe a company). They paid about 812 Canadian dollars, plus the legal time, which I promise cost more than that.
The lesson is not that the chatbot was dumb. The lesson is that when AI becomes part of how your operating model runs, the accountability does not get to spin off into a separate legal entity. It is still yours. You have quietly hired a coworker who can commit the company to things, cannot be fired, and will never once feel bad about it. Deciding where that coworker sits, and what it is allowed to promise, is an operating-model question. It is not a procurement one.
Four questions to run on your own operating model
You do not need a new framework for this. You need four honest answers about your own shop.
If you changed the architecture next quarter, would the teams that own it have to change shape? If the answer is no, those are not the teams that own it.
Where does your AI actually sit: in the loop where the work happens, or beside it, in a knowledge base people are proud of?
When the last reorg landed, did the systems change, or did the boxes move while the systems stayed put?
Name the number your AI moved. Not tokens processed, not seats licensed. The business number. If you cannot name it, you bought the structure, not the capability.
If those questions sting a little, good. That is the material.
The whole thesis, in one line
Architecture, teams, and AI are one program, or they are three expensive rehearsals. Three moving parts, one mandate, a number at the end.
That is what I am here to work out, in public, every week, with my hands still in the code.
Coming up
Next week I go straight at the piece that started all of this: the difference between being AI-ready and being AI-native, and why most transformations buy the first, call it the second, and pay AI-native money for the privilege.
Quick tell before then. If your proudest AI artifact is a reference library and your delivery pipeline has not changed a single stage, you already know which one you bought.
More soon. :-]
Sources
Because none of this comes only from my head. Every link below was checked.
The definition problem: Suleman, Pekkola, Ralyté and Ahola, “IT Operating Models: A Systematic Review of Academic and Practitioner Literature,” Information Systems Management 43(1), 2025, 22-44. Open access, DOI 10.1080/10580530.2025.2513305.
Joint optimization: Trist and Bamforth, “Some Social and Psychological Consequences of the Longwall Method of Coal-Getting,” Human Relations 4(1), 1951, 3-38, the founding sociotechnical-systems study.
Conway’s Law: Melvin Conway, “How Do Committees Invent?,” Datamation, 1968. Turned into a practice in Matthew Skelton and Manuel Pais, Team Topologies (IT Revolution, 2019).
AI-era frameworks (not peer-reviewed): Thorogood and Woerner, “Enterprise IT Operating Models in the AI Era,” MIT CISR Research Briefing XXV-12, December 2025; Sandeep Saini, “Governing the Agentic Enterprise: A New Operating Model for Autonomous AI at Scale,” California Management Review Insights, March 2026.
Air Canada’s chatbot: Moffatt v. Air Canada, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal); the airline was ordered to pay 812.02 Canadian dollars in total (650.88 damages, plus interest and fees).
I make this Substack thanks to readers like you!
