A Jamaican Experience: John Conway, my new manager, turbo charged my career at IBM

By: Baron Stewart

When Frank Caridi, my first manager at IBM, left PID for greener pastures, John Conway became my new manager. Looking back, I realize that John’s arrival was my career's single most significant event.

Shortly after he arrived, John called me into his office to introduce himself. During our conversation, he casually mentioned that he had read Frank’s assessment of my contributions. Frank had grudgingly noted that I “had good ideas,” even while rating me as average in every category. But John didn’t focus on my so-called averageness. Instead, he zeroed in on where I could make a difference.

That moment stuck with me. It became a lesson I’ve carried throughout my life—especially now when I teach young children. I focus on their strengths and help them build on them, just as John did for me.

John asked if I would like to present my ideas to the Technical Staff at PID—the group of executives who approved which projects were funded and pursued. I said yes, and John scheduled the meeting without hesitation.

The following week, I walked into a room where four executives were seated in front of me. To my side: a flip chart and a few marking pens. Calmly, I explained the problems I saw in PID’s operations. Clearly, I outlined how to solve them—and, more importantly, how IBM would benefit.

It reminded me of defending my understanding of Real and Complex Analysis in graduate school. Back then, I had been overwhelmed. But this time, I was clear, confident, and in control. I presented seven ideas. The Technical Staff accepted every single one.

It felt like a rookie scoring a hat trick in his first professional soccer game.

I wasn’t the “average” programmer when I walked out of that room anymore. I had gone from the back of the line at PID to the front. My proposals were funded, and I became the project leader tasked with fixing the problems I had identified.

PID was IBM’s central software library. It housed every operating system used to run its vast array of computers. The updated software was stored at PID and distributed to IBM’s clients worldwide when a system was fixed.

By 1979, IBM was the world’s most powerful computer manufacturer. Each of its computer models had a different operating system, and as businesses around the globe became more dependent on IBM, the volume of software moving through PID exploded. PID had become IBM’s distribution hub for major corporations worldwide.

However, PID was a relatively small facility. There were plans to build a more significant center at Sterling Forest, New York, but that would take time. Meanwhile, PID was running out of space. The building couldn’t hold any more disk drives or tape drives—and certainly not another computer, each about the size of a two-bedroom apartment.

The only answer was to compact the data.

The Technical Staff came to the programming team with an urgent challenge: write a compaction routine that would reduce the amount of space the data consumed. Everyone jumped on the assignment, including me. But as I dug into the problem, I asked myself a simple question: Why reinvent the wheel?

I remembered George Radin.

George worked at IBM Research in Yorktown Heights, just a few miles north of PID. He was also the father of Dan Radin, my student at RCDS; George had written me a glowing recommendation—the very one that helped me get hired at IBM. I picked up the phone.

“George,” I asked, “do you guys at IBM Research have any compaction routines?”

He didn’t hesitate. “Definitely,” he said. Then, he connected me with a researcher working on precisely that.

While my colleagues were still figuring out how to write a compaction routine, I already had one ready to install. And when I did, John and I were heroes.

That success confirmed what the Technical Staff had already begun to believe: they had put their faith in the right person.

PID held an all-hands meeting and gave me an award in front of the entire programming department. I was on my way.

But the compaction routine was just a stopgap. IBM needed time to finish building the new PID facility. Without the compaction project, PID would have run out of storage space long before the new center was ready.

Still, that wasn’t PID’s only problem. There was a more profound, systemic issue.

In 1979, programming at IBM was considered an art. It should be treated as a science.

At the time, every programmer had their style. There are no universal standards. There is no structured approach. What seemed like creative freedom led to chaos. When a programmer left, maintaining their code became expensive—and sometimes impossible. Without documentation, a program was a black box. You had no idea how it worked. Bugs were costly. Fixes took forever. IBM lost valuable time and money while engineers struggled to reverse-engineer each other’s work.

After the compaction routine, the Technical Staff trusted me enough to greenlight my next project: bringing structured programming to PID.

I was paired with Keith Fessler, a master programmer. Structured programming methodologies were gaining traction in academia, but few had been tailored for an organization like PID. Keith and I researched, adapted existing concepts, and developed a structured process for the entire programming department.

We standardized requirements gathering, created formal design specifications, and introduced state-of-the-art coding techniques. From then on, everyone at PID followed these standards.

As you might expect, not everyone was thrilled. Many programmers resented the new process. After all, I’d been “one of them” just a year earlier—an average coder. Now, I was the guy telling them how to do their jobs. Some resented me openly.

But the organization was behind me. The new process wasn’t optional. It was the way forward.

And it worked.

For my efforts, I received my second award in two years. But when I accepted it, the general manager of PID mumbled as he handed me the plaque: “Don’t expect this to continue.”

He was right—success breeds envy.

After the compaction routine, Keith and I became PID’s top programming team. We weren’t maintaining old programs but building new systems and driving innovation. I came up with the ideas and designed the systems. Keith led the coding and testing. We complemented each other perfectly.

But our success didn’t sit well with everyone. Many programmers had spent their careers coding as they pleased, accountable to no one. Suddenly, I was enforcing structure—and they didn’t like it. Some attacked me openly. (That’s a story for another time.)

Despite the resistance, Keith and I pushed forward.

We introduced a formal requirements generation process, where users were interviewed and had to sign off on the requirements before development began. This simple change dramatically reduced costs. Mistakes were caught early—when they were cheap to fix. In the past, users wouldn’t find problems until after the software was installed, and by then, the cost of repairing them was enormous.

At first, programmers tried to bypass the new procedures, clinging to the old ways. But over time, they fell in line. Structured programming became the standard—not just at PID but across the industry. Today, almost every company follows a structured development methodology. The stand-alone, “romantic” approach to programming faded—not because people wanted it to, but because it wasn’t sustainable.

I wouldn’t describe myself as a leader. I was a pioneer. I found the way forward. But once the path was clear, I turned my knowledge over to others who managed the day-to-day progress.

At the time, I was still an analyst with little people management experience, and it hurt me. I had to change.

But that’s a story for later.