The change management Informatica needed to overhaul its business model

What is the business transformation currently underway at Informatica?

When we were taken private in 2015, we were a traditional software vendor, but the market was starting to embrace the cloud. Many of our customers had already started to move their applications and it made sense they would want to transition to data management in the cloud as well. The investment thesis was we could dramatically change the value of the company by becoming a true cloud and subscription-driven company.

The business transformation we’ve led for the last several years has many parts; all our products have been re-built as cloud products and we continue our heritage of being neutral about data, supporting cloud, on premise, and hybrid workloads. While the product team was busy doing that, my team worked with the operations functions and our strategy team to completely reimagine our front- and back-office processes and supporting applications to enable this new cloud company. This isn’t just an IT or sales transformation; it’s a complete company transformation.

What has IT’s role been in the transformation to a SaaS model?

We built that end-to-end data model and process from scratch while we ran the old business. We still operated our core license and maintenance business, but we changed everything, including CRM, revenue recognition, reporting, and customer success to support the new cloud business operating model. We knew we had a unique opportunity to build a new end-to-end architecture with a common AI-powered data model.

When we started this transformation, we were running a billion dollars in revenue through a custom-built set of processes. Today, we’re a $1.6 billion business, and every dollar goes through a set of business processes and applications that didn’t exist in 2017. And while we did put in a new architecture, the objective was to enable a true cloud and consumption business model that was profitable. The architecture was a means to get there.

How would you characterize your architecture now?

All of our meaningful business processes are executed in a modern cloud application. We had a “once in a career” opportunity to start fresh with our technology, eliminate all the technical debt, and move processes onto a common platform that didn’t exist. Before this shift, we had four ways to sell products, but our product teams rebuilt them to be cloud native and work together, so today, we have one platform. Our new architecture enables all of that, but we didn’t just take the on-prem product and stick it on AWS. This allowed us to do some creative go-to-market innovation like the Informatica Processing Unit (IPU) model, which is a cloud credit that gives customers flexibility in purchasing when they’re unsure, for example, how quickly they’ll deploy or what precise mix of data management services they’ll need.

In hindsight, what were the keys to this successful wholesale company transformation?

First, we had complete buy-in from the board and the rest of the management team. I’ve never had to present a case to the board and say, “This is what we need to do, and here’s why we need to do it. If you ask me to guess how much it’s going to cost, then you’re asking me to lie, because there is no way to know.”

I also told the board I didn’t know how long the transformation would take, but I knew it was the direction in which we needed to move, and we needed to start yesterday. The board and executive team were all in. So, intellectually, there was no barrier to the need to change or what the new change state would look like. Buying-in can be a huge problem for companies, but one we didn’t have.

Second, we were a private company, so we were doing this under the cover of darkness and didn’t have to explain our revenue and costs every 90 days, except to the board. This gave our company the ability to make the best long-term decisions and truly build toward the end goal.

Looking back, what would you have done differently?

I didn’t fully consider we were changing the way our employees did their jobs, and that every person was going through their own change management challenges at various times. I learned that no matter how intellectually committed people are to change, and no matter how much they agree with what the end results should be, they can struggle with the day-to-day reality of changing their jobs.

For sales, marketing, and customer success teams, the change impacts their compensation, and compensation change is deeply personal. I didn’t anticipate the level of resistance to that change. In my simple Scottish brain, I thought, “We’ve all agreed we’re doing this, so we’ll all fall in line and tell our employees to prepare for change.” But it’s not that simple.

So what’s the change management lesson here?

If you take the bookends of change management, we did an excellent job up front defining the why and the what. Then at the other end, we did a fantastic job involving the sales operations, finance, and marketing teams in the testing and design, and we did a great job training people. But we faltered a little in the middle. We didn’t communicate the change frequently enough and ask people to recommit. We should have done more of the “let’s recommit and make sure we’re all still on the same page” communication. Just because we were on the same page in January doesn’t mean we still would be in November.

In addition to ensuring people recommit to the transformation goals, what advice would you offer CIOs driving major business model transformation?

Look at changing metrics and KPIs as a gift. The metrics you use to measure a cloud company are different than those you use to measure an enterprise license and maintenance company. In the old model, for example, we didn’t talk about churn, but in the cloud, churn is one of the key metrics. Net retention rate and annual recurring revenue also became key metrics, which were new to the entire organization.

When you have a new metric, you have to do the work to agree on what the calculation is, which sounds simple, but it isn’t. Take sales territories for example. When you measure the performance of a region, and a deal is papered in North America, but the real sales work was done in Europe, is it a US or a Europe deal? As a management team, we had to make these decisions, agree to them, and write them down.

This was a gift because it forced us into data governance and we sell data governance products, so this wasn’t a new concept to us. The new metrics, though, made us define them at the most senior level in the company. The definition of ARR, for example, required debate between the CFO and the CEO, and then my team built the definition into the data warehouse. So, if you’re in sales operations, and you want to grab the ARR for a region, you’re using exactly the same number as the finance team.

The term “governance” is unfortunate because it sounds like it’s control, which it is if you’re in a heavily regulated industry. But governance, when done right, can be a business enabler. You avoid conversations around, “Where’d you get that number from? What’s the calculation? Remind me again,” which wastes time. My advice is to embrace the concept that data governance is what can allow you to go faster.