How an English Major Became One of Networking's Biggest Voices

If you've listened to Drew Conry-Murray on Packet Pushers, you probably know him as the guy asking smart questions of very technical people.

I've listened to Packet Pushers for at least ten years, and that's one of the things I've always appreciated about Drew. He can sit in a conversation about some deeply technical networking topic, understand what's happening, contribute to it, and ask the question that moves the conversation somewhere interesting.

So I was surprised when I learned Drew didn't come from a technical background.

He was an English major.

I was a communication major, so maybe I shouldn't have been that surprised. But I also failed out of computer science before eventually spending 15 years as a network engineer, so I've carried around my own weird assumptions about who belongs in technical conversations and who doesn't.

Drew didn't fail out of computer science. He didn't even try it. He originally thought he was going to become a high school English teacher, earned a master's degree in education, went through his teaching practicum, and discovered that teaching wasn't what he wanted to do.

Then life took him somewhere unexpected.

In 1998, Drew and his wife moved to the Bay Area when she entered a graduate program. This happened to be right as the internet bubble was inflating and technology companies were everywhere. Drew found work as a copy editor at a technology publication. They didn't hire him because he knew networking. They hired him because he knew words.

At first, his job was basically to make sure the people who did understand networking were spelling things correctly. But if you spend your days editing articles about LANs, TCP/IP, switches, routers and firewalls, eventually you start wondering what the hell everyone is talking about.

So Drew started reading.

There were technical books sitting around the office. He picked them up. He read the articles coming through his desk. He asked questions. Slowly, some of the vocabulary started making sense.

Then somebody sent him to interview a firewall company. Drew said that at the time, he barely knew what a firewall was. A senior editor couldn't make the meeting, so they sent Drew instead. He asked what he was supposed to ask these people and essentially got the professional equivalent of, You'll figure it out.

I laughed when he told me this because I think almost everyone who spent enough time in technology has some version of that story. You're given access to something you don't understand. You're put into a maintenance window before you feel ready. Somebody escalates an outage to you and everyone suddenly looks in your direction. You get handed a project involving a technology you've never touched before.

Education is useful. Training is useful. Labs are useful. But eventually somebody throws you into the pool.

Drew figured out the interview. Then he figured out another one. Over time, he developed a set of questions that helped him understand unfamiliar products. What does it run on? What does it connect to? What's the throughput? What are the limitations? Why would somebody use this instead of something else?

Nobody handed him a magic list. Being in situations where he didn't know enough forced him to learn how to get to the information he needed. That's a much more interesting skill than simply knowing a lot of facts.

It also explains something I've noticed about Drew after years of listening to him. He's good at asking questions because he spent a career needing to understand things he didn't already understand. And that never stopped.

As Drew learned networking, he discovered the same mildly horrifying thing the rest of us eventually discover: the more you know, the more clearly you can see everything you don't know. You learn routing and switching, and somebody starts talking about security. You learn security and suddenly automation is everywhere. Then it's Python and APIs and JSON. Then containers. Cloud. Kubernetes. AI.

I remember early in my career believing there might be some point where I would just know networking. I'd get enough experience, pass enough certifications, survive enough outages, and eventually feel like one of the people who knew what they were doing.

That point never came. It probably doesn't exist.

Drew's career is an interesting example because he entered the industry knowing almost none of it and eventually became an editor-in-chief covering networking. He worked at publications including Network Computing and InformationWeek and became involved in developing technical content for Interop.

Then the media business started changing around him. The dot-com bubble burst. Advertising disappeared. Publishers acquired each other, consolidated, and shut titles down. Drew survived multiple rounds of that upheaval and kept moving into new roles until eventually his number came up too.

He got laid off.

We spent some time talking about that because I've been there, and losing a job hits differently when you're no longer a 25-year-old who can shrug and figure something out. There's a mortgage. Kids. A family depending on you.

There's also the part people don't talk about as much: work gets wrapped up in your identity. One day you know what you do and where you belong, and the next day you don't.

Drew wasn't sure what was going to happen. But something important had been happening throughout the previous years that had very little to do with certifications or technical expertise.

He'd been meeting people.

Through Interop and his work covering the industry, Drew had developed relationships with Ethan Banks and Greg Ferro, the founders of Packet Pushers. Greg eventually asked Drew to help with Network Break. It started as part-time work while Drew figured out what came next. Within months, Packet Pushers was able to bring him on full-time.

Drew described that initial offer as validation. Even if Packet Pushers didn't ultimately work out, somebody he respected thought he was worth hiring. When you're unemployed and wondering what the hell you're going to do next, that matters.

Obviously, it worked out. Drew has now spent years hosting Network Break and other Packet Pushers shows, and since Greg Ferro's retirement he has taken on co-hosting duties on Heavy Networking.

Looking backward, it's easy to draw a clean line through all of this. English major, copy editor, writer, editor, Interop, Packet Pushers.

Careers don't feel nearly that orderly while you're living them. There were acquisitions, layoffs, disappearing publications, technologies Drew didn't understand, jobs he didn't know were coming and relationships that didn't look particularly important when they began.

That's probably one of the things I took away from this conversation more than anything else. We spend a lot of time thinking about career development as skills acquisition. Learn Python. Get the certification. Learn automation. Understand cloud. Build the lab.

All of that matters. But Drew made a point during our conversation that I think engineers in particular tend to undervalue: people need to know you.

That doesn't mean becoming one of those weird LinkedIn people posting inspirational stories about something their seven-year-old supposedly taught them about B2B sales. It can be much simpler than that. Go to the local user group. Talk to somebody after the presentation. Attend the conference. Ask someone what they're working on. Help somebody when you can.

Drew said some of the biggest successes in his career happened because he'd built relationships with people who became comfortable with the idea of working with him. You still have to be good at what you do. Relationships don't compensate for incompetence. But when several qualified people are competing for the same opportunity, being the person someone already knows, trusts and would actually like to work with is a pretty meaningful advantage.

That brought us to another question I've been wrestling with lately: what exactly should technical people be learning now?

I've been building software with AI coding tools despite not being a developer. It's incredible. I can have an idea, work with Claude Code for a couple of days, and have functioning software at the end of it.

But there's a part of that experience that bothers me. I still don't really know Python. If something breaks, I don't necessarily understand why it broke.

So I asked Drew whether learning Python still matters in a world where increasingly capable AI can write it for us. His answer wasn't that every network engineer needs to become a software developer.

He thinks we need to be familiar enough with software to be knowledgeable consumers of it. If software is going to become an increasingly large part of operating networks, we need enough understanding to recognize when something is wrong and reason about why it's wrong. That means being comfortable with things like Python and JSON without necessarily becoming an expert programmer.

That feels like a useful distinction. The same goes for AI itself.

I'm simultaneously fascinated by AI and uneasy about it. I use it constantly. I've built things with it that I couldn't have built a year or two ago. At the same time, it's impossible to ignore the conversations about what happens to white-collar work as these systems get better.

Drew is skeptical of some of the grand predictions coming from technology executives, particularly when those predictions conveniently align with the interests of the people making them. But he isn't suggesting we ignore AI. Quite the opposite.

His advice is to become conversant with it. Treat it like Wireshark, Python or any other significant tool that entered the networking profession. You don't have to build the model, but if the industry is adopting the technology, understanding what it does, where it's useful and where it fails becomes part of staying technically relevant.

The funny thing is that this brings Drew's story almost all the way back to where it started. In 1998, he was an English major sitting in a technology publication surrounded by terminology he didn't understand. He started reading. He asked questions. He found people who knew more than he did. People sent him into situations before he felt ready for them.

Nearly thirty years later, all of us are staring at another wave of technology that we don't completely understand, trying to figure out what it means for our careers.

Maybe the response doesn't need to be much more complicated than Drew's was. Stay curious. Learn enough to ask better questions. Get uncomfortable occasionally. Build relationships with good people. And when the industry hands you something you don't understand yet, don't mistake I don't know this for I can't learn this.

Drew certainly didn't.