Craig Dunk
10 min readJan 23, 2019


About a week or two ago my son Ben gave me a bit of a hard time when I referred to BBM and BlackBerry and some of the projects I was involved in as potentially significant in the past but not really relevant day to day. He felt I might not be giving RIM the credit it deserved, and that I was understating the opportunity I had to be involved and make an impact in some pretty special projects. The subsequent conversation was a nostalgic and energizing trip down memory lane. By the end of that chat I was reminded that “Hell Yeah, it was awesome!”

So when Mark Church shared a CTV segment and Dave Jaworski shared his video it fit nicely with my conversation with my son from the week earlier. So I am jumping in with my own highlights of how I recall BlackBerry on this #BlackBerry20 anniversary.

I started January of 1995; big shout out to Dale and Gary M for taking a chance on a first year student and getting me involved in what would become an epic company. I think there was about ~40 other people in the office at the time. I was a first year coop testing “Mobidem ATs”. It was a large brick sized device to connect to your computer and use a network called “Mobitex”. The product name was a contraction of “Mobitex” with the word “modem” (with AT referring to the command set used to manage setup of data channels). It was a pretty descriptive brand strategy at the time :-) .

I recall my first projects working on manually running test scripts and then writing test apps such as a chat app. The chat test app was an early introduction to subtle but ridiculous bugs: I had 2 or 3 senior developers spending a bunch of time coming to look at a an issue I was having where typing the letter ‘r’ as the second character in the chat window would cause a seg fault (as in when I tried to type ‘Craig’ it would crash on the second letter). Turns out I was so naive and early in my career that I didn’t know you had allocate and manage memory buffers and the letter ‘r’ happened to step on the stack in a subtle way to cause program counter to jump to somewhere bad. Ahh buffer overflow bugs.

Thinking about how early that was in my career and education I realize there are a ton of things I learned and did at RIM/BlackBerry. My former colleague Yvonne from D2L has been recently sharing stories about gratitude so I am going to share some recollections in the form of thanks for special people and times. In writing this a hundred other recollection came to mind as well, so consider this a snapshot of my experience only:

Thanks for the opportunities: It was admittedly out of the necessity in the early days of “having a lot to do” but RIM gave new employees, including coops a ton of opportunity to succeed and contribute. Just as we were launching a backend service internally called “Page Mail” (as in “email to your pager”) we decided as a tech group that we could increase the number of people who could use the service if we ran a bunch of servers that would take TCP/IP connections from the software and then pass the information to the gateways and modems into the Mobitex (and DataTac) networks. In the matter of a couple days the tech group had shaped up the design of “Relay” that would serve PageMail (or as it was branded externally “BlackBerry Enterpise Server” aka BES). And RIM gave me an opportunity to organize a small team and run the first early stage of the project including having senior/full time devs develop pieces of it. I of course underestimated that it would just take two weeks (I learned software estimation from the extremely hard working @Herb Little for whom everything only took two weeks). BI had now worked long enough to have noticed that meetings that had pizza or food seemed to just run better. And at the time I was such an earnest combination of “geeky” and “just off the farm” that I hosted the first meeting with pies that I had made; which admittedly was odd. But the senior tech team and company took a chance and gave me the opportunity to organize this from my role as a student intern. Small companies tend towards this, but, I appreciated this influential opportunity and have tried to emulate this attitude of creating opportunities.

Thanks to mentors and the opportunity to experience talented colleagues : I recall distracting Allan, Ian, Barry and others who patiently indulged long conversations around such as the idea of making software “provably correct” . And then working with Allan in various ways for a decade. And Herb explaining in my first few weeks the fascinating symmetry and nested nature of protocol stacks across communication nodes. As well as his outright intellectual excitement connecting the concepts of cryptographic techniques and computer security. Harry helped me in early days understand organizations and early ideas about how to help other people be successful is a success. Hugh seemed always available to devote his full attention to discuss deep and interesting concepts, and still get real problems solved. Russell helped me put almost everything about work and life in some interesting, relevant intellectual context (and sometimes with a _very_ dry wit that I loved). Matt was esoterically brilliant and I understood more about people who think and approach things differently. Tom and Atul gave me a chance to understand the art of the possible, finessing committees, and the intersection of tech and patents and the legal system (and Tom for being a character and for introducing me to Japan with Nobu Yoda — DoCoMo has a stunning lobby). Mark Carragher for the conversation about asics, vhdl and for rides to work ( apologies for making you late so often) Chris for helping me understand big plays and some of the M&A world when integrating teams/roadmaps (and of course the business leader bringing BBM to life) Gary K for being a trusted colleague to rely on and to explore what an org that supports its team members could be like (and bringing BBM to life). Brian for helping me make the shift to technical leadership. Dave Kruis for letting me join him to be one first cohorts of RIM spinoffs (Metranome) Jay for coffees, and planting the seeds of startup passion I still pursue. Jake for his zest and rocking stride through the office. Vytas for really helping me understand what rigourous engineering could be like. And many people from outside the software group or immediate teams I worked with that helped connect and solve all the non-local challenges of the system; Thanks Richard, Sean , Dave Rose, Steve , David Y, John, Tony, Michael , Michael , Michael, Greg and many many more that I apologize for missing here. Not all of us were deep specialists and not all of us were put together generalists, but, RIM was a uniquely concentrated group of talented people; and a tremendous place to learn from others.

Thanks for the vision: I was first exposed to the value for a team of working through an intense articulated vision with MikeL’s “success lies in paradox” document (Aside: I kind of want a copy of it; but I kind of don’t in case it is different than my memory ;-) ) . As I recall it, the software team had got ourselves tangled up in the limitations of the device we were building software for and were being very literal in extending what we understood about computer systems into the mobile context. (“Is it a computer or is it a pager; we have to decide”). We all came together to talk through the document which laid out the way that we could flip our thinking. That idea of flipped thinking is itself is quite interesting, but, what I remember more about it was its role in rallying behind a change. I don’t think it really put to rest the tension and sometimes frustration of expectation vs limitation mismatch. But it put a lot in context for me and I recall it affecting the team and an increase focus on solutions rather than articulating problems. I only remember one paraphrased point from the doc, but, it is illustrative: It wasn’t that the “screen was too small” it was that “our handheld could uniquely help users focus on what mattered”. The ability to layout a vision that acknowledges and then transcends perceived limitations was not always present at RIM of course, but, I was exposed to the some great examples of it.

And this vision was in an interesting mix of aspiration and scrappiness. On one hand there was this idea that we could do amazing things and talked about ourselves in the same breath as companies 100s of times bigger. But there was also a real “get it done” and hardwork aspect to those early days too.

Thanks for the technical education: RIM undertook a system that started right from material science and electrical properties of antennas up through signal processing to real time operating systems into applications with interesting design constraints, across to distributed systems with security implications, and into integrations with enterprise software. My education on system design and the role of statelessness, what makes maintainable software, how to deal with technical change, raw coding expertise, performant systems, confidentiality/authentication/authorization, ideas of latency and stability and innumerable more were not just available to be discovered, but actually flowed to you as you in your day to day work. To this day with a ton of change in our industry (yeah I am someone who thinks it is easier to build software now :-) ) very few tech problems arise where I don’t lean on some of my tech experiences from RIM.

Thanks for the mistakes: My apologies if you were a PIN messaging user in the early 2000’s but for about 20K of you early adopters I was one of a couple people who was responsible (random aside on blame) for your lost message. Turns out I learned you don’t really have backups if you don’t test restoring them and that you shouldn’t run servers under your desk. Oh and that “Relay” project I was given an opportunity to lead in its very early phase? I later came to feel that we made big mistake using a “store and forward” design. And while I was unable to to influence a change at RIM for it to become stateless (i.e. more like a packet router) I learned something about how one might make changes of this kind. And in shout out to my later experiences at D2L; I think I would have a better chance now :-) . I am relatively recently, and kind of grudgingly, thankful for these mistakes. But there definitely is something to be said for learning more when things go off track than when they are easy.

Thanks for the lesson in decentralization and design nuance: I was part of the small team that created BBM. That team was also working on integrating other messaging systems at the time such as AIM and ICQ. I honestly missed how successful BBM was going to be and instead thought our ICQ integration was going to be a hit. I assumed the network effect of millions of existing users would be better than a new system. But the new system on BlackBerry was subtle shift away from “presence” (used with modems) to the idea of delivery and read receipts. A subtle design change that made a tremendous difference. I now try to watch for the role of design differently, and really appreciate the idea that some things just have to be in front of users in the spirit of lean ux to really understand how they change behaviour. (FWIW: I also missed how the BlackBerry brand had become a premium and desirable brand: being part of a BBM group became a status signal that, for instance, AIM just did not have.)

Meanwhile the project itself could not easily fit into the planning cycle of what was becoming a large organization. I don’t think I really appreciated before this project how creating space for people to work on projects that didn’t really fit a central plan could be important; i.e. I didn’t understand what would have been called skunkworks. Chris , Gary, Garth and I were all in a situation to create some space for ourselves (or for each other) to work on this. I am sure lack of alignment and focus has damaged many small organizations; but in scaled organizations you need space for decentralized initiatives. RIM and BBM has helped me remember how important it is to be deliberate in enabling decentralized decision making and investments.

Thanks for the taste of excellence: Four months after starting university I joined a small tech startup in a pair of office suites near the campus. I kept my RIM access code (and later my access cards) all through my school terms. Occasionally I parked in the RIM parking lot (don’t tell the facilities team) and got a coffee from the kitchen before going to class . I left about 10 years later in 2005 having learned a ton, worked with amazing people and played a small part in a company that changed at least Waterloo and mobile computing, and very arguably the world (for better and probably for worse in some ways) . It changed my life too, giving me an opportunity to both fund startup that was later wound down, and to take some time off, and co-found a startup that had an exit to D2L, and more.

During the time at RIM I got a sense of what it felt like on projects when things were going poorly and when things were going well. And some direct experience of how it feels and how one might influence some of the currents when you are “winning” at something really big. Candidly, that desire to be part of the kind of scale and impact and excellence stays with you (also for better, and probably for worse in some ways :-) )

I think there were approximately 13K people working at RIM when I left so my involvement had a different flavour than in the early days. And of course there were challenges and problems and lessons to consider about paths not taken by all of us, including the organization as a whole. But I still found myself very moved when, on my last day, I let the door to the office close behind me and for the first time in my professional career I was in a chapter of my life that did not involve BlackBerry.

But I did get to share in something excellent.




Craig Dunk

Tech leader, speculative fiction fan, parent to adult children, and a big fan of camp fires.