Every great idea starts in a garage. Back in 2012, a group of rebels huddled in a temporary working space to discuss how to destroy the legacy of their parent company — and the entire tradition of the contact center industry. Perhaps what’s more interesting is that their parent company hired them to do it. That’s how the Genesys® PureCloud® product was born.

Traditional contact center software development has strongly followed the paradigm of high customization and control. This thought process is derived from possession: possession of the installation base; possession of the failover equipment; possession of the direct talent and third-party relationships needed to maintain all the overhead. The hosted cloud model advanced communication options and increased the integration of emerging technologies. But a lot of that control mindset came along for the ride with retained traditional complexity.

Backed by 20-plus years of maturity in the market — and an intensity to adopt disruption — the PureCloud application was chartered as a secret startup to accomplish several keystones:

  1. Start with Legos i.e., microservices, not a product suite
  2. Use open standards
  3. Operate with complete automation
  4. And do all of this for a generation who doesn’t give a rip about how you used to do it

I say “secret startup” because the small group of handpicked talent inside and outside of the company were sent away from any existing Genesys headquarters. They started in Raleigh, North Carolina, to work without political connections, technical constraints or any contact center traditions. In fact, only the chief executives knew of the initiative. This was a move inspired by Salim Ismail (Exponential Organizations) who proposed that disruptors must disconnect from the parent host in order to survive.  Welp… I’d say that notion was well-proven and shows a lot of grit in the history of PureCloud leadership.

The PureCloud secured API was announced, to the surprise of the company, a year later. Of course, there was a newly minted group of hand-picked talent who were in the know. They had received their MacBook Pros a week earlier so they could create a product suite out of this industry-first contact center API platform. In fact, one of the highlights of my career was to be a part of the first cloud-native contact center product suite made entirely from a public API.

This was an exhilarating time for me. All the stories of sex, drugs, and rock ‘n roll aren’t entirely correct. There was no sex nor drugs. (Frankly, there was no time.) It was just a bunch of rock stars that sold all of their notions of corporate-crap development for a new world of openness and trust. I should know, I was a software engineer through the banking and healthcare industries — and some of my colleagues were searching for something better.

We knew what it was like to protect your code-feature turf and to become the bottleneck for new features. As a traditional engineer, your value was based on the code-features you controlled. So, you can imagine why innovation slows down — everyone is spending their time being cautious that no one is encroaching on their “value turf.” (I’m not suggesting malicious intent, just the biases created in the typical development environment). This sentiment simply ripples adversely to the customer and traditional customer expectations.

My mind was blown to see how distributed power operates internally. We all embraced this change together as a family.

Development happened in short bursts with targets for deployment of new features in weeks — not yearly quarters. We worked in small, self-managed “cells.” Every rock star’s code was internally public across all cells; there were no more black boxes. If I needed a micro-feature (or microservice), I would re-use what already existed or create a new one and publish it for all to see, discuss, debate, approve and adopt.

If I saw a bug in something I was using, I didn’t wait for the original rock star to fix it; I fixed it for her or him and sent it out for discussion and approval. Everyone had complete freedom to promote code to the “master” product base with no technical constraints. Can you imagine what happened when someone nearly corrupted the global master copy by pushing broken code?

In the early Wild, Wild West days, the PureCloud deployment process didn’t have the intense compliment of automated testing that it enjoys today. It currently takes a full hour of thousands of tests to complete before new features are promoted for weekly production updates. Back then (twinkle in the eye), it only took three seconds to merge changes into the master code base. Someone did a push that messed up the master history — a special memory of mine is how it was handled.

Naturally, some suggested that we needed to control the ability for anyone to submit changes.  That wasn’t an unreasonable conclusion. We all debated — without political or management control — and settled on the official culture: Everyone would always have the power to push their changes. No one will be censored. We simply need to increase our rock star status, so it doesn’t happen again. (It did happen again a few weeks later; the decision was reaffirmed). The spirit of that decision is reflected today in the freedom my customers experience when they build something remarkable using the PureCloud API or simply buy the product suite first and build through the API foundations as they grow.

I have fond memories of the gritty PureCloud origin story. Through the roller coaster ride that many startups experience, I am proud of the maturity PureCloud now enjoys. To me, as a consumer and a businessman, the PureCloud app makes perfect sense as we head into the Roaring 20s. I’ll always be thankful that the PureCloud product is part of my own origin story.

To find out more about the PureCloud application, take a tour or watch the PureCloud app in action online.