Change the Problem

You don’t always need to fix the problem.

The summer air conditioning hummed as I shuffled into the packed auditorium with dozens of other interns. It was July 2008, and I was working as a software engineer intern at BlackBerry—almost five years before I’d transition full-time into design.

I was working on the ill-fated BlackBerry Storm at the time, though I don’t share that often. (I have many theories for why that device failed but that’s another story for another day.)

The quarterly intern talk was about to begin, and today’s speaker was Mike Lazaridis himself—co-CEO and co-founder of Research In Motion. For a room full of mostly Canadian engineering interns, this was like getting a masterclass from Steve Wozniak.

Lazaridis took the stage and began sharing his experience founding BlackBerry, the challenges of building a tech company in Canada, and the early days of mobile innovation. But then he said something that completely reframed how I think about engineering problems.

“Sometimes if you can’t fix the problem, you need to change the problem.”

He painted a picture of the mobile landscape in the late 1990s. Phone networks could barely handle voice calls reliably, let alone data. The infrastructure simply wasn’t there to send and receive emails—we’re talking kilobytes at best, when emails required much more data to function properly.

BlackBerry couldn’t just wave a magic wand and upgrade the world’s telecommunications infrastructure. It would be years before networks could handle megabytes of data efficiently.

But even if they could solve the network problem, Lazaridis explained, they’d hit another wall: batteries. “Engineering is about trade-offs,” he said. Even the few kilobytes that phones could theoretically handle would drain the tiny batteries of the era in a few hours.

Most companies would have thrown more engineers at the problem. They’d try to fit in bigger batteries, build better antennas, or wait for network infrastructure to improve.

Instead, BlackBerry changed the problem entirely.

“Emails require too much data?” Lazaridis asked rhetorically. “What if the phone didn’t connect directly to the internet at all?”

Their solution was elegant: instead of having phones struggle to download full emails directly, BlackBerry created servers that would intercept your emails, compress them, strip out unnecessary formatting and meta data, and send only the essential content to your device. Less data, less battery drain, real-time email.

The BlackBerry Enterprise Server (BES) was born from this insight—and it worked brilliantly.

If BlackBerry hadn’t invented this approach, it would have been years before mobile email became practical. They didn’t wait for the world to change; they changed how the problem worked.

The impact was so significant that even when rivals like Nokia launched BlackBerry-like devices with full keyboards, they still had to license BlackBerry’s BES technology to make email actually work.

If you can’t fix the problem, change it instead. Don’t wait for the world to change. Try a different angle, a different approach.