More from our blog

The search for my first job

Back in 2003, I was finishing off my Master’s degree in Engineering at the University of Waterloo.  I was doing work in distributed, multi-agent AI systems in grad school, and had decided that academia wasn’t going to be for me. After finishing my thesis over the summer, I started looking around for jobs in the fall and was introduced to ComputerTalk at one of the local career fairs. I’d done some work in the contact center space through co-op jobs with Nortel and BMO, so I had some knowledge of the industry.

ComputerTalk was looking for individuals to work for their Research and Development group, which was attractive because I still wanted to work on cutting-edge stuff. I knew that if I was going to work in software, I wanted to be able to spend time on big-picture design and larger, more complex systems. I knew too many people who ended up at large companies and were responsible for a small corner of a large application, and I didn’t want to end up somewhere I didn’t have at least some control over what I worked on.   

Early years at ComputerTalk

One of the things I learned early on was that, despite having been around for 17 years at that point, ComputerTalk still operated very much like a startup. Job roles and responsibilities still existed, but the lines between the roles were fuzzy, presenting ample opportunities to contribute to different areas of the business. ComputerTalk was smaller back then, with around 65 employees in total.  There were seven of us in R&D, and we were building a platform that competed (and won) against companies with much larger R&D teams. That taught me to make smart bets on what I designed, and to make sure we could adapt what we built to whatever might come our way.

Within my first few weeks, I had ownership of one legacy application (real-time monitoring), and a new component for integration with third party IVR and speech systems. I also had enough autonomy to design things end to end, including experimenting with and adding new technology to the pipeline. I was able to do things early on like advocate for moving parts of our codebase to .net (back when .net 2.0 was still pre-release), which meant becoming the C# expert on the team and training others. Having the freedom to go off and say that I wanted to learn this new platform that I think is going to be important and being given the time to do it was incredibly valuable, and this same pattern would repeat many times over the years.

The evolution from R&D Engineer to a technical leader

In my first few years here, my role started to transition from being just another R&D Engineer to being in a technical leadership position in the company. It seemed like I was doing everything: high-level design and architecture, presales support, marketing docs, analyst relations, attending and presenting at conferences, partner TAP programs, creating product demos, and product strategy development, all while also writing new product code.

There wasn’t a specific internal job posting that I responded to saying I wanted to do all these things. But the company culture at ComputerTalk was (and still is) open to someone like me being able to insinuate myself into different functions, and when I see something that needs to be done, my first instinct is usually to do it myself.

At one point there was a more formal codification of my role, but even then, I took the interpretation pretty loosely as “come up with a vision for what’s next”, “make sure the team can execute on it”, and “make sure ComputerTalk succeeds.” This has encompassed an unbelievably wide range of problems, from designing a whole new telephony platform with Microsoft, to ways to further distribute services and improve high availability, to multiple iterations of new agent, administration, and monitoring tools.

It has been a blend of my own research, design, and prototyping, and helping to guide the rest of the R&D team to build a better ice Contact Center solution. Aside from all of that, my role often means picking up a bunch of odd tasks that didn’t really fall under anyone specific’s job description, but that needed to be done, which has included things like building out a load testing lab, migrating source control and developing a DevOps process, and championing our internal migration to Teams and O365.

Working at ComputerTalk

One of the things that’s great about this place is that you almost never hear the phrase “that’s not my job.” Many people are able and willing to do what needs to be done for ComputerTalk to succeed, and there are several times I can recall where it’s been an all-hands effort to pull something off. 

My career path at ComputerTalk up until this point has definitely been unique, and I’d like to think that I’ve made things better for us by being here. I can also count on my fingers the number of people on the R&D team (which is now significantly larger than when I started) that have started and left in the last 20 years. For a technology company to have that level of tenure and expertise is unheard of, and I do what I can to make sure that everyone stays engaged, myself included.

I’ve been asked multiple times over the years by friends, family, former colleagues, and even strangers at conferences, “why are you still there?”  My stock answer is still true - I said I’d stick around until it got boring, and it still hasn’t.