The Dream Machine: What a 1960s Computer Visionary Can Teach Today's Product Managers

I just finished "The Dream Machine" by M. Mitchell Waldrop, and I can't stop thinking about J.C.R. Licklider.

The book is a biography of Licklider and the history of the early computing revolution. "Lick" (as everyone called him) was a psychologist who became one of the most influential figures in computing history. He helped fund and shape ARPANET (the precursor to the internet), championed interactive computing and the concept of "human/computer symbiosis," and mentored a generation of researchers who would go on to build the modern tech industry. He also happens to be from Missouri (as am I) and an alumnus of Washington University in St. Louis (as am I).

But here's what struck me most: Lick wasn't a computer scientist. He was a psychologist who taught himself computing because he had problems he wanted to solve. That orientation—coming to technology from the problem side rather than the solution side—is exactly what makes great product managers tick.

The Outsider's Advantage

Lick came to computers with a fundamentally different orientation than most of his contemporaries. He wasn't asking "what can this machine do?" He was asking "what do humans need, and how might machines help?"

This is exactly how great product managers should think. We're not technologists first—we're problem-solvers who happen to work with technology. The best PMs I know maintain that outsider's perspective even as they develop deep technical knowledge. They never lose sight of the human need underneath the technical implementation.

Lick's psychology background wasn't a limitation—it was a superpower. He understood human cognition, attention, and workflow in ways that pure engineers didn't. He had studied how people actually worked, how they processed information, where they got stuck. That's what led him to envision interactive computing—the idea that humans and computers should work together in real-time—decades before it became the mainstream concept it is today.

At the time, the dominant paradigm was batch processing: you'd submit a job to the computer, wait hours or days, and get your results back. Lick found this absurd. He had spent time observing his own workflow and realized he was spending most of his thinking time on clerical tasks—graphing, calculating, searching for information. What if a computer could handle that grunt work in real-time, freeing the human to focus on actual thinking?

That's a product insight, not a technical one. It came from understanding users, not from understanding machines.

Philosophy Before Implementation

I'm struck by how much of the early computer revolution was people having ideas that were philosophical in nature—concepts they didn't necessarily know how to implement yet. The vision came first. The technical path revealed itself through exploration and experimentation.

Take time-sharing, one of the breakthrough concepts of the era (Time-sharing is a technique that allows multiple users to interact with a single computer simultaneously by rapidly switching between their tasks, giving each person the illusion of having the machine to themselves). It emerged from a much broader vision of what computing could be. Researchers weren't just solving a technical problem (how do we let multiple people use one expensive computer?); they were pursuing a philosophical ideal (how do we make computing interactive and personal?). The time-sharing concept was born of an idea for artificial intelligence that was much broader—a belief that computers should augment human thinking, not just crunch numbers.

The pattern was consistent throughout the book: articulate what you want to achieve at a conceptual level, then break it down into achievable steps. Grand vision first; technical path second.

For PMs, this is a reminder that vision and strategy should precede tactics. We often get pulled into implementation details before we've truly crystallized what we're trying to achieve and why. It's easy to skip straight to "what should we build?" without spending enough time on "what are we really trying to accomplish here?"

Lick would spend enormous energy getting the problem framing right before worrying about solutions. He wrote memos and papers articulating his vision for "man-computer symbiosis"—not technical specifications, but conceptual frameworks for what the relationship between humans and machines could become. Those frameworks then guided decades of research.

This is something I've been trying to internalize in my own work. When scoping a new initiative, I've started asking: can I articulate the philosophical case for what we're doing? Not the business case—though that matters—but the deeper belief about what should be true that isn't true yet. If I can't articulate that, I probably don't understand the problem well enough.

The Art of Convening

One of Lick's superpowers was his ability to bring brilliant people together and create conditions for them to do their best work. As the head of ARPA's Information Processing Techniques Office, he didn't just fund research—he built a community. He connected researchers across institutions, fostered collaboration over competition, and trusted people to pursue ambitious ideas without micromanaging the path.

The researchers he funded went on to invent most of what we now consider foundational to modern computing: interactive computing, computer graphics, networking, the mouse, windowed interfaces. But Lick didn't invent those things himself. He created the environment where they could emerge.

There's a leadership lesson here that I've been sitting with. As I've stepped into bigger leadership moments this year—harder conversations, higher-stakes decisions, new team dynamics—I've been thinking a lot about what it means to lead without doing. Lick's example suggests that sometimes the highest-leverage thing a leader can do is shape the context: define the vision, assemble the right people, remove obstacles, and then get out of the way.

"No Rules Rules" (which I also read this year) reinforced a similar idea from Reed Hastings's experience at Netflix: that high-performance cultures are built on context, not control. You hire talented people, give them the context they need to make good decisions, and trust them to figure out the how.

Lick seemed to operate this way instinctively. He had strong opinions about where computing should go, but he held those opinions loosely when it came to implementation. He backed people who disagreed with him on approach, as long as they shared the broader vision. That combination of conviction and flexibility is hard to pull off.

Follow the Joy

One detail from the book that stuck with me: Lick gave up tenure at MIT and everything he'd been working toward for years because he found a passion for computers.

He had built a successful career in psychology—he was a respected researcher with a secure academic position. And then he encountered computers and became obsessed. He walked away from the safe path to chase something that genuinely excited him, even though it meant starting over in a field where he had no formal training.

Never be afraid to switch up what you're doing to pursue something that gives you joy.

This feels especially relevant in product management, where it's easy to get stuck in a role or domain because it's comfortable. You develop expertise, you build relationships, you know how things work. Starting over is costly. But Lick's career is a reminder that the best work comes from genuine curiosity and enthusiasm. He was effective because he was passionate, not in spite of changing direction.

Lick's willingness to reinvent himself multiple times throughout his career is part of what made him so impactful. He moved from psychology to acoustics to computing to research management. Each transition brought new perspectives that informed the next chapter. He wasn't optimizing for a linear career trajectory; he was following his interests wherever they led.

I don't think this means everyone should constantly switch fields. But it's a useful counterweight to the pressure to specialize and stay in your lane. Sometimes the most valuable thing you can bring to a problem is a perspective that nobody else in the room has, and that perspective often comes from an unexpected path.

Building for Humans, Not Machines

Perhaps the deepest lesson from Lick's career is the importance of keeping humans at the center of technical work.

His foundational paper, "Man-Computer Symbiosis" (1960), argued that computers shouldn't replace human thinking—they should augment it. The goal wasn't artificial intelligence that would make humans obsolete; it was intelligence amplification that would make humans more capable. The human remains in the loop, directing and judging, while the computer handles the mechanical and computational parts of thinking.

This distinction feels incredibly relevant today as we navigate the AI era. There's a lot of rhetoric about AI replacing human workers, automating away entire job categories. But Lick would probably push back on that framing. The question isn't whether AI can do the task; it's what role AI should play in helping humans do the task better.

This maps directly to the AI Maker Matrix framework I've been using from Reforge. The distinction between building for "Prosumers" (who want AI to amplify them) versus "Delegators" (who want AI to replace them) is essentially Lick's distinction between symbiosis and automation. Different users want different relationships with the technology, and the job of the product builder is to understand which relationship fits which context.

Lick's insight was that the most powerful applications of computing would be the ones that made humans more effective, not the ones that removed humans from the equation. Sixty years later, I think that's still the right frame for most of what we build.

Bringing It Home

The Dream Machine is a long book (over 500 pages) and it covers far more than Lick's career. It's really a history of the ideas and institutions that shaped personal computing. But Lick is the thread that ties it together, and his story offers a surprisingly practical set of lessons for anyone building products today.

Come to technology from the problem side. The best product thinkers maintain an outsider's perspective, even as they develop deep technical fluency. Never lose sight of the human need underneath the technical implementation.

Think philosophically before tactically. Articulate what you're trying to achieve at a conceptual level before diving into how to build it. Grand visions can guide decades of work; tactical plans often don't survive first contact with reality.

Create context, not control. Leadership often means assembling the right people, defining the vision, and then getting out of the way. Trust talented people to find the path.

Follow your genuine interests. The best work comes from curiosity and passion. Don't be afraid to change direction if something new captures your imagination.

If you're looking for a read that will shift how you think about technology, product work, and leadership, I can't recommend The Dream Machine highly enough.