IT Doesn’t Matter. Again.
tl;dr: The world is telling us that coding is disappearing, and with that software development will be commoditized. Instead, we need to proactively own the transition towards agentic companies.
Once upon a time, I used to joke that when I became a VP, I stopped coding in repos and started coding in spreadsheets. My spreadsheets would have long complex google scripts coordinating activities, sending emails, tracking company performance reviews, summarizing infra KPIs, scheduling meetings, etc. Truth is, until 2024, for anyone outside Tech, spreadsheets were the closest thing to an IDE. And those that truly knew how to leverage them were seen as wizards. Then, we started vibecoding.
The story goes like this:
1958 - Harold J. Leavitt & Thomas L. Whisler define Information Technology.
They envisioned a distant corporate world (”the 1980s” XP) where technology completely shifted management practices. It would be at the heart of every company. Two things worth reflecting on:
The challenge to get an organization to heavily lean on computers.
We achieved it 30 years later, circa ‘10.The misreading of management practices.
Even though they said the exact opposite, early technification resulted in completely different organizations where “participative” management became the de facto modus operandi. Andrew Grove, John Doerr, Bill Campbell, Stanley McChrystal, and many others made it so that empowerment and giving objectives instead of listing activities became the way to lead knowledge workers. They realized that automating low-level tasks implies low-level jobs are displaced upwards, but they didn’t see the corresponding shift in management.
Information technology is likely to have its greatest impact on middle and top management. In many instances it will lead to opposite conclusions from those dictated by the currently popular philosophy of “participative” management. - Management in the 1980’s - Harold J. Leavitt & Thomas L. Whisler
1979 - VisiCalc puts out there the first “real” spreadsheet software.
Now you could program your computer data to crunch numbers without bothering your IT Department. This is the first time we have vibe-coders, i.e. non-IT people programming… We grew so used to them that we stopped noticing.
10 years later, Microsoft Office was born, and it would push for VBA, Microsoft Access and Microsoft Excel as a bundle to bring coding to everyone. After all, ‘developers, developers, developers!’ always meant we want more people developing.
2003 Nicholas G Carr publishes “IT Doesn’t Matter”.
The gist of it, his belief that IT/Infra had been commoditized. The corollary: From now on the smart play is to treat it more as a cost-center than as a competitive leverage. Again, a worth reading article, incredibly accurate, and unfortunately incomplete.
“When a resource becomes essential to competition but inconsequential to strategy, the risks it creates become more important than the advantages it provides.” - Nicholas G. Carr.
The irony, this contentious article appeared just when a revolution was gestating behind closed doors.
Nicholas G. Carr’s view, while accurate on ‘the problems that existed’, failed to see what was evident for visionaries, ‘the problems to come’. Steve Ballmer replied to him with a ‘unrealized, unrealized, unrealized’, called it hogwash, and dismissed the idea entirely. He was somewhat right, but the ones that truly seized the opportunity were silently working on the winning strategy.
2011 Steve Yegge’s “Google Platforms Rant” exposed Bezos 2002 strategy.
“His Big Mandate went something along these lines:
All teams will henceforth expose their data and functionality through service interfaces.
Teams must communicate with each other through these interfaces.
There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols – doesn’t matter. Bezos doesn’t care.
All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
… “ - Steve Yegge.
AWS shifted their Engineering teams to build strategic advantage through software. In 10 years, they became a platform provider for a new generation of companies that now would eat the world. (Yes, Marc Andreessen “Software is eating the world” is from that same year).
AWS today has 28% of the cloud infrastructure market vs 14% from Google. The e-commerce platform saw it clearly 24 years ago. So they shifted internally to work with APIs & Services. Eventually, that platform became a source of revenue, after years of being a competitive advantage.
Carr didn’t know it, but while he was dooming the industry, the pioneers were a decade ahead in their thinking, over investing in technology to be the next moat, the secret sauce, the leverage for all.
If your company’s moat was never really software, e.g. risk models, clinical outcomes, funding facilities, energy providers, 2-sided marketplace dynamics, hard integrations, media content, etc. Then:
Your software solution is only one surface to expose value.
Own that reality and proactively expose it everywhere.
Check this essay on the cultural side of this.
When coding becomes commoditized, as information supposedly did, then it’s your duty to find the next Tech lever. You are in a unique situation to bring Technology to your whole organization.
First: It’s not about the product, it’s about agents.
The first definition of IT included the following:
“One includes techniques for processing large amounts of information rapidly, and it is epitomized by the high-speed computer. A second part centers around the application of statistical and mathematical methods to decision-making problems; it is represented by techniques like mathematical programing, and by methodologies like operations research. A third part is in the offing, though its applications have not yet emerged very clearly; it consists of the simulation of higher-order thinking through computer programs.” -
Harold J. Leavitt & Thomas L. Whisler
There’s no coding there, and that’s telling. You need to embrace the idea that coding was never in the job description. Not since inception. Instead, we now have a simulation of higher-order thinking, we call that Agents. This is your in.
Each CTO I talk to seems to have a CEO behind that is just pushing them to go faster. Usually, it’s because the conversation started from a false premise: if the tech team goes faster, then we will have more revenue. Or, if we can do the same with less, then our company will earn more. Neither are usually true, at least not significantly. There’s worse.
In some cases, the conversations turn into a roadmap on how, when and what agents to build from Tech for other departments. This turns Tech into the innovation bottleneck and further that image of gatekeepers instead of enablers. That won’t survive the next few years, not with AI becoming an even more powerful tool.
If instead you focus on the fundamental increase in revenue & reduction in cost per customer, you can introduce a different question:
How do we give everyone tools to create corporate agents?
The same way that everyone can create a spreadsheet, and they are accountable to those, they need to be creating and managing agents. Those agents need to live in the cloud, and they belong to the company. So you will need a vision on how this will be technically feasible, and a plan on how you would educate your organization in this new world.
Second: Don’t create a committee, onboard individuals.
HR needs to be at the table, it’s a cultural change.
Finance needs to be at the table, they need to be able to control the expenditure.
GTM needs to be at the table, we want more sales.
Ops needs to be at the table, we need to optimize their processes.
We will prioritize everything, and tech will execute in that direction.
Sounds familiar? I’ve been talking with tens of leaders during the past weeks, failure smells like this. The idea that AI is a new feature, or software, that you are deploying in your organization is as wrong as the idea that IT was a commoditized area. In fact, it makes it so that Tech continues to be a bottleneck instead of an enabler for all to do more and better.
This is the AI First method, AI as a feature. The second option is worse, though.
In some organizations, the CTO, or CEO, relinquishes this responsibility, and they hire an AI Expert. The new hire mandate is to make everyone adopt AI. This person is in between an internal sales engineer for random new providers and an L&D resource specialized in AI. Performance is impossible to measure, or limited to one team. If the former, they become the catalyst for all AI Brawls, ie. a political beast showing why others failed at implementing their ideas, nagging more than doing. If the latter, they are just another functional role with AI rubber stamped in the front.
You need to own the transformation.
Few times in your career you’ll have such a clear opportunity to team up with your CEO, put together a plan, and bring in the rest of the organization. Actually, the path is simpler than you may expect:
Pick your infrastructure,
Pick your Evangelist Tech team,
Pick 1 SMEB (Subject Matter Expert Builder) per cross-functional team.
Start in one or two areas, once you have a way for anyone in the organization to build shared agents in the cloud. The mandate for your Tech team is simple: they give guidance, never code. If a new capability needs to be added, e.g. integrating with a system, that’s valid work for the agentic system you are putting together. The days in which Tech was implementing solutions are long gone, at least at the level of traditional requirements from a team. You are building the machine that builds the machine.
The hard shift
Last week I had 1<>1s with 4 HR leaders. 3 were bold about the change, 1 was skeptical. The skeptical one, bluntly believed AI wouldn’t help them. Their team wouldn’t get subscriptions (AI Breadlines). Ok, moving on. The rest were all thinking in these lines:
“I can provide better insight tools to my executive team, while saving time for my team to focus on action planning & delivery”
And they built their very own amazing things (AI Obscurity):
One of them created custom dashboards for their onboarding/offboarding reports,
the other one was building an in-house continuous performance tracker,
the third one was taking it one step further, creating compensation software.
None of them was thinking agentic, neither was questioning adoption. They are falling into that same trap software engineers have always fallen into: loving thy software.
The AI promise is making grunt work disappear, and the only way to do so is if it doesn’t require input from humans. That’s your hard shift. You need to push even the most AI savvy in your organization away from GUIs, and into real agentic automation.
Third: Tech as Leverage
In the early 2010s SaaS became ubiquitous. That created a tale of two Tech. Those teams focused on providing solutions for business and consumers, and those providing services for those SaaS builders.
The SaaS industry taught Tech teams to be opinionated on what you could or couldn’t do, and spend as little as possible building custom solutions. Customizations, configurations, optionality, every little branch was seen as a disadvantage to move fast. Software engineers in those teams became frantic for control, allowing for as few knobs as possible, and trying hard to make sure everything worked perfectly out-of-the-box.
The second group, the docker, k8s, AWS, GCP, terraform, github, posthog, datadog, cypress, cloudflare, and all other framework/infra solutions grew in the opposite direction. They expanded the surface to allow for extreme customization. In some products you would have infinite ways of achieving the same result and they have whole Engineering organizations dedicated to onboard and service their customers. Their solutions are not simply software, they are an ecosystem of partners, services and specialized products.
Today you need to ask yourself:
How do I give more (safe & secure) power to all company employees?
If all software develops itself, the mandate for Tech is either to create the infrastructure by which the company leverages the latest technology, or become the cost-center race to the bottom, the commodity. It’s the Bezos/Ballmer vs Carr understanding of that same reality.
If you ask me, your team needs to do both. Focus on ‘building the machine that builds the machine’(MTBTM). Shift your roadmap and abstract your team from the product/feature battleground. Instead, go after the next big abstraction: the company platform so everyone can create agentic flows (a Compounding Intelligence Layer).
You are now AWS, and everyone in the company is a developer.
The one thing
“Extracting business value from IT requires innovations in business practices.”
- John Seely Brown and John Hagel III in response to IT doesn’t matter.
The counter-argument to Carr’s article pushed on a key factor: embracing new technologies creates the possibility of constant differentiation. IT is ubiquitous, but the insights extracted from it aren’t. That is why this is a business effort, and the largest leverage is in changing the business to leverage that new technology.
Spreadsheets made everyone a programmer, this time making it in-house.
That’s your future. Take the leap.
Footnote on AI.
Harold J. Leavitt & Thomas L. Whisler meant AI in the way we understand it nowadays.
“Current research on the machine simulation of higher mental processes suggests that we will be able to program much of the top job before too many decades have passed. There is good authority for the prediction that within ten years a digital computer will be the world’s chess champion.”
“top job” means executive roles. They cite Herbert Simon and Allen Newell, who two years earlier had built the Logic Theorist, the first program to reason on its own, and unveiled it at Dartmouth ‘56. Now called the birth of AI. It wasn’t a metaphor, it was a citation.
It took ~65 years. It’s just getting started. The jury’s still out.