Category: IBM

Categories
AI Business IBM Management

Making It Up As We Went Along

There was a building along Route 270 in Gaithersburg, Maryland where people kept secrets for a living. Not the cloak and dagger kind. The corporate kind, which in its own way requires just as much discipline. The IBM Washington Systems Center occupied a two-story modern building that looked, from the outside, like any other outpost of late twentieth century American business. Inside it was something else. It was where IBM sent its hardest problems, and where the largest IBM customers in the world — the ones whose names you would recognize immediately — sent their most urgent ones back.

I worked there as a manager. But before I was a manager there, I was a hire. And before I was a hire, I was like every other IBM professional on the outside of a particular line — a line I didn’t fully understand until I crossed it.

At IBM there was a protocol so embedded in the culture it had almost ceased to be a rule and become something closer to a religious observance. New products were not discussed until they were announced. Not hinted at. Not alluded to. Not whispered about with a favored customer over lunch. The announcement came in the form of something called a Blue Letter — a formal communication from senior leadership that functioned as the official moment a product entered the world. Before the Blue Letter, the product did not exist in any conversation you were permitted to have. After it, you could talk about nothing else.

Violation was not a career setback. It was a firing offense. Full stop.

That clarity had a kind of elegance to it. You didn’t have to calibrate how much you could say or navigate gray areas. The line was absolute. And because it was absolute, and because everyone knew the consequence of crossing it, the culture enforced itself. You didn’t need surveillance. You needed people to understand the stakes, and they did.

What I didn’t understand, from the outside, was what that line was doing to my imagination.

When you can’t see the roadmap — when the strategy and the unannounced products and the long arc of where the company is going are all behind a wall you have no access to — you don’t experience that as absence. You experience it as depth. The things you don’t know feel like they must be there for a reason. The gaps in the announced picture feel like the gaps in a great iceberg — what’s visible is impressive, but what’s below the surface must be more impressive still.

I had faith in IBM’s strategic intelligence the way you have faith in things you can’t fully see. And faith, uncontradicted by evidence, tends toward beauty. The hidden roadmap wasn’t just unknown — it was, in my imagination, a thing of coherence and intention and vision. It had to be. The alternative was too unsettling to consider.

Then I got hired into the Washington Systems Center and crossed the line.

There was no single moment of disillusionment. No specific product that shattered the dream, no strategy document that read like a disappointment. It was more like a gradual adjustment of the eyes — the way they adapt when you move from bright sunlight into a room lit quite differently than you expected. The room isn’t dark. It’s just not what you anticipated. And once your eyes adjust you can see perfectly well, but you can never quite recover the image you had of the room before you entered it.

The reality on the inside was messier than the dream on the outside. More improvised. More human. We were, in ways I hadn’t anticipated, almost making it up as we went along. Not carelessly — the people at WSC were extraordinary, the work was serious, the commitment was real. But the beautiful coherent roadmap I had constructed in my imagination from the outside bore only a partial resemblance to the actual thing. Strategy, it turned out, looked different up close. Less like architecture. More like weather.

I absorbed this alone. Nobody sat me down and named what I was experiencing. Nobody had the conversation with me that I would later learn to have with others. I found my way through it by degrees, the way you find your way through most things that don’t come with instructions.

What came out the other side wasn’t cynicism. It was something more useful — a clearer eye, a more grounded relationship to the institution I was part of. The faith hadn’t been wrong exactly. It had just been innocent. And innocence, once lost, can’t be recovered. But what replaces it, if you’re lucky, is something steadier.

Years later I was the manager. And I was hiring IBMers — good ones, experienced ones, people who had spent serious careers on the other side of the blue line. They knew the products cold. They knew the customers. They knew how to work. What they didn’t know, couldn’t know, was what waited for them on the inside of the wall they were about to cross.

I knew it. Because I had been them.

There is a particular expression that crosses a person’s face when the actual roadmap becomes visible for the first time. It isn’t dramatic. It doesn’t announce itself. It’s more like a subtle recalibration — a slight stillness, a momentary adjustment behind the eyes. The person in front of you is doing quiet interior work, reconciling what they imagined with what they’re now seeing. The gap between those two things is doing something to them, and they’re not sure yet what to do with it.

I learned to watch for that expression. And when I saw it I knew what was coming if I didn’t get ahead of it.

The danger wasn’t disappointment. Disappointment is temporary, and smart people move through it. The danger was what disappointment hardens into when it isn’t named and worked through — a corrosive cynicism that poisons not just the person carrying it but everyone around them. A talented IBMer who had invested a career in faith, discovered the faith was misplaced, and decided the whole enterprise was therefore hollow — that person could do real damage to a team. I had seen it happen, or the early stages of it, which was enough.

So I developed what I came to think of as the god is dead conversation.

The name came from Nietzsche, though the application was strictly practical. What Nietzsche meant — or one of the things he meant — was that when the organizing faith of a civilization collapses, the collapse doesn’t leave nothing. It leaves a vacancy that has to be filled with something else, something built rather than inherited. The god is dead conversation was about helping someone through that vacancy quickly, before they filled it with the wrong thing.

It wasn’t a long conversation. It didn’t need to be. What it needed to be was honest, and direct, and delivered before the cynicism had time to set.

I would tell them what I saw happening. I would tell them it was normal, expected, that everyone who crossed this particular line felt some version of it. I would tell them the dream they’d carried on the outside wasn’t foolish — it was a reasonable response to incomplete information, and the information had been incomplete by design, and the design had served real purposes. None of that made them naive. It made them human.

And then I would tell them what I’d learned on my own, without anyone to guide me through it. That the messiness on the inside wasn’t a failure of IBM’s intelligence or intention. It was just what strategy actually looks like when you’re close enough to see the seams. Every institution looks more coherent from the outside than it does from the inside. That’s not a scandal. That’s organizational life.

The conversations were tricky. There was real care required. You were asking someone to grieve something — the beautiful imagined roadmap, the faith in a hidden coherence — without tipping them into bitterness about what replaced it. You were trying to accelerate a process that, left alone, might drag on for months and quietly corrode their effectiveness. And you were doing it while also being their manager, which meant you needed them functional and engaged on the other side of the conversation, not just unburdened.

What I had going for me was credibility. I wasn’t delivering a message from outside the experience. I had made the same crossing. I knew the specific texture of what they were feeling because I had felt it myself — the diffuse quality of it, the absence of a single dramatic moment, the gradual adjustment of the eyes. When I told them I understood what was happening to them, I actually did. I think they could tell.

Trial and error had taught me the shape of it. What didn’t work I had found out the hard way, at some cost, early on. What I arrived at had been load tested by real people in real situations. It wasn’t a framework from a leadership seminar. It was something I owned completely, which meant I could adapt it in the moment rather than execute a script.

Most of them came through it well. Better than well, actually.

What I hadn’t fully anticipated — though in retrospect it makes complete sense — was what replaced the faith once it was gone. It wasn’t the steadier, clearer-eyed pragmatism I had found my way to alone. It was something more potent than that. Something that surprised me the first time I saw it and then became one of the things I quietly counted on.

They came out the other side feeling superior.

Not arrogant. Not dismissive of colleagues still on the outside. But quietly, privately elevated — because they were now keepers of the secrets they had once only believed in. The blue line that had shaped their entire professional identity, that had defined the boundary of what they could know and say and imagine, was now behind them. They were on the inside. They had access. They had been trusted with the actual roadmap, the real strategy, the unannounced products that the rest of the world was still constructing faith-based pictures of.

The believer had become the keeper. And keeping, it turned out, was a more powerful identity than believing. The believer is passive — sustained by what they imagine. The keeper is active, responsible, trusted. They carry something real rather than something projected.

It solved my practical problem neatly, though that wasn’t why it moved me. What moved me was watching people find their footing on the other side of a genuine loss and discover that the ground there was solid — different from what they’d imagined, but solid. They hadn’t just survived the crossing. They’d been changed by it in a way that made them more valuable, more grounded, more fully present to the actual work.

Which was, I suppose, what the god is dead conversation had been for all along.

I think about that blue line often these days.

We are living through a moment when artificial intelligence is advancing faster than most people can track, and the organizations building it — the labs, the research teams, the companies placing enormous bets on where this technology is going — have their own version of the wall. Not identical to IBM’s. The competitive and legal architecture is different. The culture is different. But the basic structure is the same: there is what has been announced, and there is everything else, and most people are working entirely from the announced side.

Which means most people are doing what I did before I crossed the line at WSC. They are filling the gaps with faith. And faith, uncontradicted by evidence, tends toward beauty.

The unrevealed AI roadmap looks, from the outside, like a thing of coherence and intention. The capabilities that haven’t been announced yet must be more impressive than the ones that have. The strategy must be more considered than what’s visible. The gaps in the public picture feel like depth rather than uncertainty — like the part of the iceberg below the surface, which must be vast because the part above is already remarkable.

I am not saying this faith is wrong. I held the same faith about IBM and it wasn’t wrong exactly — it was innocent. The people constructing faith-based pictures of where AI is going are doing a reasonable thing with incomplete information. The information is incomplete partly by design, for reasons that make competitive and strategic sense, just as IBM’s secrecy made sense. None of that makes the faith naive.

But I’ve been inside enough walls to know what the inside tends to look like. And I think it’s worth saying, clearly and without cynicism, that the reality is probably messier than the dream. More improvised. More uncertain. More human. The people building these systems are extraordinary — the work is serious, the commitment is real — but they are also, in ways that might surprise you, almost making it up as they go along. Not carelessly. But without the complete map that the outside imagines must exist somewhere, fully drawn, waiting to be revealed.

Strategy, up close, looks less like architecture and more like weather.

This isn’t a counsel of despair. It’s almost the opposite.

The IBMers who crossed the line and survived the god is dead conversation didn’t end up with less than they started with. They ended up with more — a clearer eye, a more grounded relationship to the institution, a more useful kind of engagement with the actual work. The faith they lost was the innocent kind. What replaced it was steadier and more durable.

I suspect something similar is available to anyone willing to look at the AI moment with clear eyes. Not the disappointed cynicism of someone who expected a beautiful coherent roadmap and found a human institution instead. Not the breathless faith of someone still on the outside of the wall, filling gaps with generous assumptions. Something in between — harder to sustain, more honest, ultimately more useful.

The technology is real. The progress is real. The stakes are real. None of that requires the roadmap to be a thing of beauty. It just requires it to be worked on seriously by people who understand what they don’t yet know — which, from everything I can observe, it is.

What I couldn’t give those IBMers, and what nobody can give you, is the experience of crossing the line yourself. The god is dead conversation only works because the crossing has already happened — because the person sitting across from you has already seen the actual roadmap and is already processing the gap between what they imagined and what they found. You can’t have the conversation in advance. The disillusionment has to be real before it can be worked through.

Most of us will never cross the line into the AI labs. We’ll stay on the outside of the wall, working from the announced picture, filling the gaps as best we can. That’s not a failure — it’s just the condition most of us are in, the same condition those IBMers were in for their entire careers before I hired them.

But knowing the wall exists, and knowing what walls do to imagination, seems like it ought to change something about how we hold our faith. Not abandon it. Just hold it a little more lightly. Stay curious about the seams. Remain open to the possibility that the most important thing about the unrevealed roadmap isn’t what’s in it — but what we’ve projected onto it.

The blue line is still there. Most of us are still on the outside of it.

And the hidden roadmap still looks, from here, like a thing of beauty.

Categories
Business History IBM Infrastructure Nvidia Programming Semiconductors

The Half-Life of Moats

Prompted by an article on X by @magicsilicon on the CUDA moat. Research and drafting assistance from my AI intern assistant Clark.

The NVIDIA H100 looks, in retrospect, like an inevitability. It wasn’t.

What Jensen Huang built is more accurately understood as a sixteen-year accumulation of optionality — a platform investment made in 2006 for a market that wouldn’t fully materialize until 2022. NVIDIA intros the G80 architecture in November 2006, laying the groundwork for CUDA’s release a few months later. The stated ambition was to let scientists write C++ that ran on GPU cores without needing to understand 3D graphics pipelines. The unstated bet was that parallel computation would eventually matter for something bigger than rendering shadows in video games.

For sixteen years, it mostly didn’t. Not at scale. Not commercially. CUDA lived in research labs and HPC clusters. It attracted a small, devoted, and economically marginal user base — the kind that papers cite but investors ignore. NVIDIA kept investing in it anyway: cuDNN for deep learning operations, cuBLAS for linear algebra, a layered ecosystem of libraries that made CUDA not just accessible but nearly irreplaceable for anyone doing serious numerical computation. When TensorFlow and PyTorch emerged as the standard frameworks for neural network research, they didn’t adopt CUDA because it was the only option. They adopted it because CUDA was where the optimized kernels already lived.

AlexNet won the ImageNet competition in 2012 and did it on two NVIDIA GPUs. The deep learning community noticed immediately. The financial community largely did not.

Then ChatGPT launched in November 2022, and suddenly everyone needed H100s they couldn’t get.

The parallel to Intel is instructive and also undersells how strange this kind of story looks while you’re living through it. Intel was founded in 1968 as a memory company. DRAM. The founders — Noyce, Moore, Grove — were materials scientists and engineers who believed the future was in silicon memory chips. They were right, briefly: in the early 1970s Intel dominated the DRAM market. By 1984, that share had collapsed to 1.3%, ceded almost entirely to Japanese manufacturers who had commoditized the product.

What saved Intel wasn’t a pivot so much as a realization that a stopgap had become a foundation. The 8086, conceived in 1976 as an internal hedge and launched in 1978 was never supposed to matter. It was a 16-bit processor designed to hold off Zilog while Intel finished its ambitious 32-bit iAPX 432 architecture. The 8086 was assigned to a single engineer. “If management had any inkling that this architecture would live on through many generations,” its designer Stephen Morse later recalled, “they never would have trusted this task to a single person.”

IBM chose the 8088 — a cost-reduced variant — for the original IBM PC in 1981. That decision wasn’t destiny, it was simply a procurement. And yet from that accident of selection, Intel’s x86 line became the backbone of personal computing for four decades. The Pentium in 1993 was Intel’s Wintel moment — the flag bearer the @magicsilicon tweet gestures at — but the flag had been quietly sewn since 1978.

What these histories share is not just a pattern of “slow build, explosive payoff.” The structural similarity is subtler: in both cases, the moat was a software abstraction layer built on top of hardware. Intel’s real lock-in wasn’t transistor count or clock speed. It was backward compatibility — the commitment, formalized with the 80386 in 1985, that every future Intel chip would run software written for older ones. That promise created a flywheel that trapped developers and buyers in a virtuous (for Intel) dependency loop for decades.

CUDA is the same architecture at a different layer. The lock-in isn’t the H100’s 80 gigabytes of HBM3. It’s that switching to an AMD MI300X or Google TPU means potentially rewriting training pipelines that have been optimized against CUDA kernels for years. AMD’s ROCm platform exists. It is, by most accounts, maturing. Engineers who have tried the migration report that it costs months and hundreds of thousands of dollars. The moat isn’t a wall. It’s accumulated friction — the switching cost of a decade of engineering decisions baked into codebases that no one wants to touch.

But to find the actual origin of this pattern, you have to go back further than Intel. To 1964, and to a decision IBM made that Fred Brooks — its project manager — called a bet-the-business move.

The IBM System/360 was announced on April 7, 1964, after five years of turbulent internal development. What it introduced wasn’t just a new computer. It was a new concept: the separation of architecture from implementation. Before the 360, IBM ran five incompatible product lines simultaneously. A customer who outgrew their machine had to scrap all existing software and start over. The 360 replaced all five lines with a single unified architecture — six models covering a fiftyfold performance range, all running the same operating system, all sharing the same instruction set. The name itself encoded the ambition: 360 degrees, all directions, all users.

Gene Amdahl, the 360’s chief architect, had a precise formulation for what this meant: the architecture was “an interface for which software is written, independent of any implementation.” The Principles of Operation manual described what the machine did; separate Functional Characteristics documents described how each model did it. This distinction — separating the contract from the execution — was genuinely new. It’s the conceptual root of everything that came after.

The 360 generated over $100 billion in revenue for IBM and established the first platform business model in computing. Jim Collins would later rank it alongside the Model T and the Boeing 707 as one of the three greatest business achievements of the twentieth century. But its deepest legacy was architectural: the insight that if you make your abstraction layer the standard, the hardware underneath becomes fungible. Customers didn’t buy specific IBM machines. They bought into OS/360. The machines were an implementation detail.

Intel understood this by the 1980s, even if implicitly. The 80386’s backward compatibility commitment in 1985 was IBM’s 360 insight applied to microprocessors — the architecture is the product, the silicon is the vehicle. CUDA is the same insight applied to GPU compute. What NVIDIA sold researchers in 2006 wasn’t the G80 card. It was the abstraction: write parallel code in C++, run it on any NVIDIA hardware, trust that the next generation will be faster and compatible.

The pattern is now sixty years old. It has reproduced in every major platform transition. And it keeps working for the same reason it worked in 1964: when you own the layer that developers write to, your customers’ switching costs compound every year they stay.

There’s something worth sitting with here. Neither Jensen Huang in 2006 nor Gordon Moore in 1968 could have specified exactly what the payoff would look like. What they shared was a willingness to build infrastructure for a demand they could sense but not yet see — and the discipline to keep investing in it through the long years when it looked like a research project rather than a business.

The question that doesn’t resolve cleanly is whether that kind of patience is a strategy or a personality. And whether, in an industry that now moves faster than the cycles it’s lived through, sixteen-year moats are still the kind that get built.

Which raises the uncomfortable corollary: the same AI tools that CUDA enabled may be what ultimately erodes it.

The attack on CUDA’s moat is now structurally different from anything AMD or Intel could mount before. OpenAI’s Triton compiler lets developers write GPU kernels in Python without touching CUDA at all, and generates optimized machine code that often matches hand-tuned CUDA performance. MLIR — Multi-Level Intermediate Representation, originally from Google — provides a compiler infrastructure that can target any hardware backend from a single codebase. AMD’s ROCm has historically been dismissed as immature; ROCm 7, released this year, delivers meaningfully better inference performance than its predecessors. And perhaps most directly: Claude Code reportedly ported a CUDA codebase to AMD’s ROCm in thirty minutes — work that previously took months of engineering time.

The irony is almost too neat. CUDA’s moat was built on accumulated switching costs: the friction of rewriting code, the library dependencies, the tribal knowledge encoded in a decade of kernel optimizations. AI coding tools are specifically good at exactly that kind of mechanical, high-context translation. The weapon is attacking the wall it was built behind.

That said, it’s worth being careful about the speed of this. Abstraction layers that “should” erode moats often take far longer than expected, because the moat isn’t just the code — it’s the ecosystem of tooling, documentation, community knowledge, and hardware-software co-optimization that took eighteen years to compound. Triton and MLIR are real. They’re also early. The question isn’t whether the moat is vulnerable; it’s whether it erodes before NVIDIA’s next generation of chips makes it irrelevant to argue about.

As for what comes next — which company is building the IBM 360 of this decade — the honest answer is that it’s too early to call with confidence. But there’s a candidate worth watching.

Anthropic’s Model Context Protocol, launched in late 2024, has the structural fingerprint of a platform play. MCP is a standard for how AI agents connect to external tools and data sources — a common interface layer, hardware-agnostic (or rather, model-agnostic), that any system can implement. By late 2025 it had been donated to the Linux Foundation, adopted by OpenAI and Google, and was tracking 97 million monthly SDK downloads. There are now over 10,000 MCP servers. It is becoming the way agents talk to the world.

The parallel to OS/360 is imprecise but instructive. What IBM built in 1964 was a standard interface between software and hardware that decoupled what you wrote from what you ran it on. MCP is attempting something similar one abstraction layer higher: decoupling what an agent does from the specific models, tools, and data sources it does it with. If it becomes the standard — the layer that developers write to — then whoever owns or most deeply shapes that standard controls the integration tax of an industry whose applications we can’t fully specify yet.

The counterargument is that open standards, once donated to foundations and broadly adopted, don’t generate the same lock-in as proprietary platforms. OS/360 was IBM’s. CUDA is NVIDIA’s. MCP is now the Linux Foundation’s, with OpenAI and Google as co-stewards. The historical pattern suggests the moat accrues to whoever owns the layer, not whoever invented it.

Which may mean the next great platform play is still being assembled in a room we haven’t seen yet — the way IBM’s System/360 was being architected in a Connecticut motor lodge in 1961, three years before anyone else knew what was coming.

Categories
AI IBM

From Picnic to Workforce: The New Scaling

In 1977, Charles and Ray Eames released a short film for IBM called Powers of Ten.

The film opens with a couple picnicking on a blanket in Chicago and zooms out—every ten seconds, the field of view increases by a factor of ten.

We move from the intimacy of a lakeside lunch to the edge of the observable universe, then plunge back down through the skin of a hand into the subatomic architecture of a carbon atom.

The subtitle was “A Film Dealing with the Relative Size of Things and the Effect of Adding a Zero.”

It was a meditation on scale, suggesting that as we add zeros to our perspective, the very nature of what we are looking at transforms.

Today, with AI, we are living through a new kind of “Powers of Ten” journey, but the zeros aren’t being added to meters; they are being added to tokens.

I recently read a reflection by Azeem Azhar where he chronicled his shift from using 1,000 AI tokens a day to nearly 100 million. In the Eames’ film, adding a zero moved you from a park bench to a city, then to a continent. In the world of Large Language Models, adding a zero moves the AI from a novelty to a tool, then to a collaborator, and eventually—at the scale of 100 million—to something resembling a “workforce.”

“At 100,000 [tokens], a collaborator. At 1 million, I was building workflows. At 10 million, processes. At nearly 100 million – something closer to a workforce.”

This shift is more than just “more of the same.” It is a phase change.

When the Eames’ camera zoomed out to $10^{24}$ meters, the Earth didn’t just look smaller; it disappeared into a texture of galaxies.

When we scale our interaction with intelligence by several orders of magnitude, the “picnic” of human cognition—the way we think, draft, and create—is no longer the center of the frame.

At the 100-million-token-day scale, we aren’t just “using” AI. We are orchestrating vast, invisible ecosystems of thought. We are seeing companies like Spotify where top developers reportedly haven’t written a line of code in months, instead directing systems that ship features while the humans review the output from their phones.

We have added so many zeros that the “relative size” of human effort has changed.

The chilling yet beautiful thing about Powers of Ten was the realization of our own insignificance in the face of the cosmos, balanced by the intricate complexity found within our own cells.

As we zoom out into the “Token-Verse,” we face a similar existential pivot. If an AI can process a hundred million tokens of “thought” in a day—a volume no human could read in a lifetime—what does it mean to be the “author” of our lives?

The answer, I suspect, lies back on the picnic blanket.

The Eameses knew that while the scale of the universe is staggering, the meaning is found in the connection between the two people on the grass.

As we add zeros to our digital capabilities, our value shifts from the production of tokens to the intention behind them.

We are no longer the builders of the cathedral; we are the ones deciding why the cathedral needs to exist at all.

We are moving from the era of the “Worker” to the era of the “Architect” or maybe just the “Witness.”

Categories
Computers FORTH IBM Programming

The Architecture of the Stack

Back in the early 1980’s when I worked for IBM, I was able to acquire my own IBM PC and experience my own form digital frontierism. Today I really wish I had a logbook at hand with a record of everything I did as my ability to recall those details has faded with age. A couple of those memories that still do remain with me involve two obscure languages: APL and FORTH. And then there was Borland Turbo Pascal.

In those early days of the 1980’s, memory wasn’t an infinite field; it was a precious, finite resource. While most of us were content living with the structured guardrails of BASIC, there was a subset of us drawn to the elegant, stripped-back world of FORTH.

Learning FORTH felt less like coding and more like learning a new way to breathe. It was lean. It was efficient. It stripped away the overhead of high-level syntax until it was just you, the dictionary, and the stack. There was an honesty to it—no hidden abstractions, just a direct conversation with the hardware.

Then, of course, there was the hurdle of Reverse Polish Notation (RPN). Grokking the stack meant rewiring your brain. You couldn’t just state an operation; you had to prepare the world for it first. You pushed your data onto the stack, one piece at a time, and only then did you call the action. It was a rhythmic, almost percussive way of thinking: Input, input, act.

“In FORTH, you don’t just write programs; you build a language to solve the problem.”

This “bottom-up” philosophy changed the relationship between the creator and the machine. You weren’t just a user; you were an architect of your own vocabulary. To define a new “word” in FORTH was to permanently expand the capabilities of your environment. It was a recursive journey where every small success became a building block for the next complexity.

Looking back, those days with the IBM PC and the stack weren’t just about efficiency. They were about the discipline of clarity. When resources are limited, your thinking must be precise. The difficulty of RPN wasn’t a bug—it was a feature that forced you to understand the flow of data at its most fundamental level.