If you trace the last 60 years of American computing history, one name keeps popping up in the background: Jim Holtman.
Bell Labs missile systems? He was there. The modern phone network? There. The simulation models that redesigned Kroger’s warehouses? Also him. Holtman is a rare engineer who, on top of witnessing the major eras of American technology across defense, telecom, and enterprise systems, helped build them, boots on the ground.
From 1968 to 1991, Jim spent 23 years at AT&T Bell Labs, one of the strangest and most powerful institutions America ever minted, working on Cold War missile guidance and the phone-network software that made dial-tone America hum. Later, he held key roles in Kroger’s R&D and Operations Research group, simulating distribution centers, rethinking store technology like electronic shelves, “scan, bag, and go”1, and generally trying to make a hundred‑year‑old grocer behave more like a learning system than a legacy utility. These days, in “retirement,” he gives tours at the Computer History Museum in Mountain View, where undergrads and computer nerds pull him aside to ask the same thing I did: what was Bell Labs actually like from the inside, and how do we get back to building an exciting future again?
That’s why I’m talking to him.
We like to tell ourselves a simple story about innovation, that it comes from hungry startups, that ‘necessity is the mother of invention’, and, crucially, that it comes from founders chasing the next funding round. Bell Labs doesn’t fit that story. It was funded by a tax on your grandmother’s phone bill, protected by regulators, and staffed by people who could spend years on ideas that might never ship commercially. The mystery is why that world turned out to be so good at inventing the future, and why our faster, leaner tech ecosystem struggles to do the same. That’s the thread I’m pulling on with Jim.
The project started, weirdly enough, with a street sign—Dey Street in lower Manhattan, a few blocks north of Wall Street, where, in 1915, Alexander Graham Bell made the first transcontinental phone call from a building on a street that bears my last name. From there it turned into a kind of field study built out of my own time running data science teams and leading operations research projects at places like Kroger, watching up close which mechanisms actually make innovation work and which don’t.
This series is me sitting down with Jim and trying to reverse‑engineer the factors—cultural, technical, and financial—that made Bell Labs actually work when they worked and fail when they failed. What follows is one slice of that larger conversation, zoomed in on a single theme inside Jim’s career and the systems he helped build.
Below is a lightly edited transcript of my conversations with Jim Holtman in the Fall of 2025. Our conversation has been edited and condensed for clarity. Some questions and answers have been lightly reordered for coherence.
Brandon:
When Bell Labs was working at its best, what specific mechanisms made it work so well—from your firsthand experience, not just the mythology?
Jim:
I can talk about the areas I was working in. I started off doing defense‑related work—radar and missile programs. At the time, probably twenty to twenty‑five percent of the folks in Bell Labs were on government work. This was the late 1960s.
One thing I still remember fondly: if you were on those government contracts and you worked overtime, even as a salaried employee, you got paid overtime. Today you might work sixty or eighty hours a week and still only get paid for forty. Back then, if you put in the time, you got compensated.
The working conditions were good. When I joined, I was in what you’d now call an open office: six‑person offices with the supervisor in a little room in the middle and three people on each side. Later those got converted into two‑person offices, which was even nicer. You had decent space, decent equipment.
The environment mattered as much as the layout. You were surrounded by strong people. That’s one of the things that made Bell Labs a nice place to work: you knew the people around you were good at what they did and they would help you do your job better.
We also had a very good library right in the building. Almost any technical book—if they didn’t have it, they’d get it for you. So you always had material to read.
And then there were the memos. One of the requirements was that everybody wrote up memos about their projects. Over time that became a huge internal archive2. You didn’t have to go knock on a door to find out what someone was working on; they’d already written it up and you could just go read it.
Culturally, it was encouraged that you did go knock on doors. At Murray Hill, where a lot of the research was, the standard thing was: you walk up and down the hall, most doors are open, and if you see something interesting on the blackboard or hear something in a room, you just stop in and talk.
And because of the way Bell Labs was funded, if you came up with something interesting—even if it wasn’t directly related to telephony—you could probably get funding for it. That’s why you see so many things that came out of Bell Labs that had nothing to do with “phone calls.” They hired people with strong interests, and then they let them pursue those interests.
So if you ask, “What made it work?” I’d say: good people, good working conditions, lots of resources, and management that would actually back you when you wanted to explore something.
Brandon:
It sounds like a mix of talented people, creative freedom, abundant capital, and knowledge discovery encouraged cross‑pollination. That’s not unexpected. I suspect what’s unique was the fact that the whole Bell System was one big testbed?
Jim:
Right. When we were developing systems for the telephone company, we had a very extensive environment we could test in because it was all one Bell System.
New York Telephone, for example, was one of our main test sites because it was only a couple of hours away. We could drive over, install experimental systems, and test them in a real‑life environment. Sometimes we’d inflict a bit of pain on the call centers—systems wouldn’t always behave perfectly at first—so the customers might not get as quick a response. But we had that freedom to experiment at scale3.
Because it was one integrated system, you had urban, suburban, and rural environments you could test in. And as you said, we defined the standards. There was something called Bell System Practices4—those documents defined how things were supposed to work.
We didn’t have to worry about compatibility in the modern sense because we defined compatibility. If testing showed that a standard needed to change, we rewrote the standard. That’s a very different world than trying to roll out some new thing today and having to negotiate with ten different vendors and platforms to get permission.
We weren’t careless about it, but we were the “big gorilla.” If we needed to change something and it made sense technically, we could.
“We didn’t have to worry about compatibility in the modern sense because we defined compatibility. If testing showed that a standard needed to change, we rewrote the standard.”
Brandon:
Did Bell Labs’ defense work basically start with anti‑ballistic missile systems, or did it have deeper roots?
Jim:
Oh, it started well before that—back in World War II. A lot of the logistics work, scheduling, figuring out where things were, a lot of the statistical processing that went on during the war, Bell Labs had its hand in that.
They were doing early computation before they were really “building computers.” Underwater sound was a big area—sonar, acoustics. Guidance systems for planes, for torpedoes. All that started during the war and continued afterward.
When I got there, there was a big effort on what they called “underwater sound.” If you think of The Hunt for Red October5 and all the sonar and acoustics they dramatize, a lot of the real underpinnings of that sort of work were developed at places like Bell Labs.
The anti‑ballistic missile work—the Nike system6—grew out of that earlier work. Bell did a lot of the guidance and supporting systems for those as well.
“There are lots of things that never saw the light of day. People would spend a year or two on something and then decide, ‘This really isn’t possible,’ and that was okay.”
Brandon:
You’ve mentioned that Bell Labs could fund a lot of undirected research—projects that might never ship. What did that look like from the inside? Was there any stigma when something didn’t pan out?
Jim:
One of the key things we’ve talked about is that you really did have undirected research. If people wanted to pursue something, they could usually find a way to do it, because the money was there.
We were a regulated monopoly, and Bell Labs got about 1% of what AT&T made. That doesn’t sound huge, but off a giant revenue base, it was a lot of money. That kind of funding model simply doesn’t exist today.
If you wanted to recreate that now, you’d need an environment where you can go out and recruit top scientists, pay them well, and then let them pursue pretty much anything they want, on the understanding that only some fraction of that work would ever become a product.
I don’t see anything exactly like that today. If I want to start something now as an entrepreneur, I have to get venture capital. To get that, I need a vision, a pitch deck, a “this is where we’re going” story.
Whereas at Bell Labs, a lot of folks in research could not have written down a clear vision of where their work would end up. They just had the ability to pursue it until something happened—or didn’t. There are lots of things that never saw the light of day. People would spend a year or two on something and then decide, “This really isn’t possible,” and that was okay.
Bubble memory is a good example. It was a magnetic storage technology—kind of like what you’d think of today as a thumb drive. You had this material where you could shift bits around using magnetic bubbles. On paper it looked very promising: something small you could carry around with your source code on it instead of having a large box of punched cards with your source to carry around.
There were lots of internal write‑ups; people were excited about it. But you couldn’t actually manufacture it economically. It just wasn’t practical to produce. So bubble memory never became a product.
What happened to the people who worked on it? Nothing terrible. Nobody got fired. Nobody got demoted. It was one of those interesting checkmarks—“We tried this, it didn’t work out”—and then folks went on to something else.
That kind of tolerance for “we learned something, even if it didn’t ship” is harder to sustain today.
Brandon:
I’m curious about the emotional side of that. For something like bubble memory, what was it like for the people when it became clear it was not going to work?
Jim:
I don’t know the exact moment, but in general, management gave you enough rope to explore. They’d tug on it now and then if it looked like you were heading into danger or something clearly unproductive, but they didn’t yank it all the way back; they let you decide how to proceed.
If a project didn’t work out, people just moved on. I remember some things we tried on other projects that looked promising for the first year, but once we really tried them out, they didn’t pan out. The people involved just went on and did the next thing.
I honestly don’t remember anyone being “taken down” because a research project failed. That was part of the deal: some things succeed, some things don’t.
Where it got touchier wasn’t in research, it was in big development projects with large teams and commitments. There I did see failures with real consequences, and I spent a couple of years doing project architecture reviews to help catch those before they went too far. But that’s more the subject of another story.
Brandon:
Can you tell me a story that really captures what the place felt like from the inside? Maybe something about how people worked together on a project?
Jim:
An interesting one came back to me because of a tour I just did at the Computer History Museum. I was guiding a group of human‑factors students from San Jose State—people who study how humans interact with systems, time‑and‑motion, man‑machine interaction.
Back at Bell Labs, we had a human‑factors group embedded with our team on a project where we were automating an old manual system. These were psychologists. Their job was to watch how people used the system--both the old and new versions--and help us design it so they could be more effective.
One of the key artifacts was a printed report the system produced. As programmers, we’ll just throw information anywhere on a page. The human‑factors folks did a time‑and‑motion study. They literally watched where people’s eyes went.
What they saw was: when you pick up a page, you start reading in the upper‑left. So they rearranged the report. All the essential information went in the upper‑left. The less important stuff went down in the lower‑right.
That tiny change saved about fifteen seconds per report for someone to interpret what was in the report. Now, the magic of the Bell System is in the numbers: if you’re processing ten thousand trouble reports a day, saving fifteen seconds on each one is real money. Do that a couple of times and the human‑factors group pays for itself.
Today you’d probably call that “design” or “UX,” and it’s more widely appreciated. But at the time, having dedicated human‑factors people as part of a development team was unusual. Somebody at Bell had decided that was important and gave it budget. That says a lot about the culture.
I also liked the freedom they gave you. You had a lot of leverage because of the size of the Bell System. If you came up with a good design, and you could defend it, people would adopt it. If your design wasn’t so good, they’d tell you that too.
I remember designing a database structure that I thought was very elegant. Our chief database person took one look and said, “Yes, it’s elegant—but it’s going to be incredibly expensive in computer time.” That was when CPU time was a real cost driver. We sat down together and came up with a better design.
That kind of back‑and‑forth was normal. The expectation was that you’d challenge and improve each other’s work.
Brandon:
You mentioned once you missed out on a trip to Kwajalein. What happened there?
Jim:
We were measuring performance on a Safeguard system. At Whippany we had a machine with four processors, but we wanted to test the software on a larger system. The only larger one we had was out on Kwajalein Atoll, in the Pacific—that’s where some of the missile sites were.
I was hoping to go out there. It’s an interesting trip: you fly to Hawaii, then down to Kwaj. My supervisor at the time told me, “You’re too valuable to leave here. I’ll take the software out and test it.” So he got to go.
He had to spend a couple of days in Hawaii waiting for a connection—very rough duty. The flight from Hawaii to Kwaj is six or seven hours, on a charter where all the drinks are free. They kind of roll the people off the plane at the end. I missed out on that experience.
Every time he tried to run the software, he was on the phone with me asking, “Okay, how do I run this again?”
I worked for him for a while afterward and reminded him of that story regularly. It also shaped how I behaved when I was a supervisor later. I tried not to block my people from those kinds of opportunities just because it was “more convenient” for me to go.
Again, that’s culture. You learn from how you’re treated and you either repeat it or you decide to do it differently.
“You didn’t spend much time talking about who had a PhD and who had a bachelor’s degree. You just worked on the problem in front of you.”
Brandon:
You’ve said Bell Labs was full of very educated people, but no one made a big deal of their degrees. It was more about “What can you do?” How did that culture happen? Was it by design, or did it just emerge?
Jim:
I’m not sure exactly how deliberate it was, but Bell Labs was the place you wanted to work if you were an engineering student back then. That was the reputation: it’s where the interesting R&D happened.
I remember in college, just getting an interview slot when Bell Labs came to campus was hard. They only had so many interviews, so you submitted your information and hoped you made the cut. People would go buy a new sport coat just for that interview.
If you got through that and they were interested, they brought you in for a two‑day interview. You’d talk to three or four different organizations—defense, electronic switching, whatever. At the end they’d ask which group you liked best. That didn’t guarantee you’d get that group, but you got a pretty good overview of the work.
You were talking to technically strong people. They understood what they were doing and could explain it. So from your first contact, you’re in a culture where the focus is on the work.
When you started, the office structure reinforced that. Early on, the six‑person offices meant you knew what other people were doing. If you had a problem, you could just ask the person next to you. There weren’t plaques on the door listing degrees.
In terms of hierarchy, there were basically four levels on a typical project:
STA – senior technical associate, often lab assistants or people without the full engineering role.
MTS – member of technical staff; that’s where most folks were.
Supervisor – managing eight to twelve people.
Department head – managing several supervisors.
Most supervisors and department heads had been promoted from within, from MTS roles. There was very little outside hiring directly into management. That told you: if you do good technical work here, there is a path up.
But day‑to‑day, MTSs were peers. You didn’t spend much time talking about who had a PhD and who had a bachelor’s degree. You just worked on the problem in front of you.
Brandon:
How did people think about “moving up the ladder”? Was there pressure to become a manager to grow in pay and influence, or were there real technical paths too?
Jim:
There was definitely a sense that moving up got you more recognition, more salary, more perks. I remember people who very much wanted to become supervisors and go up the ranks.
But Bell Labs also had room for strong individual contributors. When we did salary reviews, we’d look at a scatter plot of years of experience versus compensation. There’d be a nice trend line—more years, more money—but also a lot of outliers high above the line. Those were people who didn’t want to be in management but were outstanding technically.
In research, you saw that a lot. Take the Unix group—Richie, Thompson, Kernighan, and others. They contributed hugely to the Labs’ success, but from what I’ve read, most of them had no desire to be supervisors. They liked being individual contributors.
There was no hard ceiling that said, “As an MTS you can only make this much.” If management wanted to compensate you properly, they could. Some individual contributors were paid as well as supervisors and, in some cases, as well as department heads.
So you didn’t have to go into management to be recognized. For some people it made sense. For others, staying technical did.
Later, when I left Bell Labs and went to Convergys (which came out of Cincinnati Bell’s side of the world), they started with a more traditional hierarchical structure—you had to climb the ladder to get the pay. But they ran into the same problem: they had good people who didn’t want to be supervisors or VPs.
So they created a dual track: an executive/managerial track and a technical track. You could get compensated appropriately without being a manager.
I was actually the first person to move onto that technical track. I’d been hired in as VP of System Architecture with a small group working for me. Over time I realized I liked being an individual contributor more. Managing people stopped being fun.
So they moved me into an “executive consultant” role. I kept the same pay and perks—stock plans, all that—but I focused on architecture and technical work instead of supervision. A few others followed later. It was a way to keep senior technical talent without forcing them into roles they didn’t want.
“There are strong research organizations today, I don’t think anything quite matches that combination of monopoly funding, broad mandate, and willingness to let people explore without a business case.”
Brandon:
Do you follow what today’s Bell Labs does under Nokia7 at all?
Jim:
Not closely. What I do know is: the Bell Labs that exists today is not the Bell Labs I knew. From what I understand, the work is almost entirely product‑related—things that feed directly into Nokia’s business. They don’t do undirected research.
Brandon:
Is there any modern company or institution that even comes close to what Bell Labs and the Bell System were doing? I know we don’t really have regulated monopolies like AT&T anymore.
Jim:
It’s hard to say. You can point to Microsoft or Google. Microsoft had a lot of control over Office—Word, PowerPoint, Excel. Every so often they’d come out with something different.
Google changes things and you adapt. Now we’ve got ChatGPT and other AI systems, and that’s changing quickly too—how you use them, what they’re good for.
Those companies certainly do serious R&D. But it’s tightly tied to products and business models. At Bell Labs, a lot of research had no obvious product when it started. People could spend a long time on something that might never become a product and that was still considered a good use of time because of what you learned.
So while there are strong research organizations today, I don’t think anything quite matches that combination of monopoly funding, broad mandate, and willingness to let people explore without a business case.
Brandon:
Given that Bell Labs had a regulated monopoly and that 1% of AT&T’s revenue, what—if anything—about that model could realistically be copied inside a smaller, non‑monopoly organization today?
Jim:
That’s the hard part. The funding model.
At Bell Labs, you could recruit top scientists, compensate them well, and then let them pursue open‑ended work. Nobody was asking, “What’s the ROI on this in 18 months?”
If you wanted to create that today, you’d have to convince investors to fund a group of people who don’t necessarily know where their work is going to lead. And you’d have to do it at a scale where enough of those bets pay off to justify the many that don’t.
In today’s environment, most funding—venture capital, corporate R&D budgets—expects a clear line to a product or a business outcome. You can copy some cultural elements: encouraging people to walk the halls, write internal memos, collaborate across groups. But the patience and freedom that came from being a regulated monopoly with a guaranteed revenue stream are much harder to recreate.
Sitting with Jim, what struck me was a special mix of the contrast between the mythology of Bell Labs—the Nobel Prizes, the Unix lore, the grainy photos of the Murray Hill campus—and how prosaic the mechanisms that made it possible actually were. A regulated monopoly taxed every phone bill in America and skimmed roughly one percent into a place where smart people had time, space, and permission to chase ideas that often went nowhere. Out of that combination of patience and pressure came radar systems, missile guidance, new ways of routing phone calls, and an operating system that still underpins much of the Internet.
What a time to be alive.
I’m writing a book about the hidden side of progress and how we got here. If you’d like early chapters and behind-the-scenes notes as I write, subscribe to the Book in Progress section of this newsletter.