It’s not easy integrating product teams post M&A

There is a lot that can go wrong.

Not only do you have to integrate the acquired product tech stack to work with yours, but you also have to (and this is the harder part) integrate the people, the process, their tools, their culture, and their mindset into yours.

Do it well, you end up creating a high performing product team. And it will show up in the products you deliver.  

Don’t do it well. The M&A value proposition begins to evaporate. And it is the products, the customers, and people who end up paying the price.

To help us figure out how to pull this off, I interviewed Brian Fugere. He has integrated 11 different product teams in the last 4 years.

Brian Fugere is the Chief Product Officer at symplr, where he leads all product management, strategy, and user experience (UX) design efforts across the rapidly expanding portfolio.  Concurrently with this role, he also served as Chief Marketing Officer and led the Engineering organization.

He has over 30 years of go-to-market experience in software companies of all sizes.  Brian was most recently the CMO of Virence Health, a carve out from GE Healthcare. Prior roles include President of The Estimating Edge, COO and CMO of RemitDATA, as well as leadership positions at Belo Interactive, Stryker, and America Online.

What follows is a condensed and lightly edited version of our interview.

Brian thank you for joining us.  I have been looking forward to this, simply because creating high performing teams is so close to my heart.

But before we get into the nitty gritty, do you mind sharing with our audience a little bit about symplr and the types of companies it has been acquiring over the last 3-4 years?

Brian Fugere:  Mustafa, glad to be here. I have been looking forward to this as well.

Let’s start with symplr.  We are a software company focused on the healthcare operations space. Think of us as the glue that binds all the big hospital systems – EMR, ERP, revenue cycle, etc.  

As for our growth, we’ve been acquiring companies, really since 2014. And since 2018, we’ve acquired about 11 companies which came in all shapes and sizes.  

The smallest we acquired was $4 million and about 20 people, and the largest was probably $95 million and around 500 people.  

In that time, our product organization has grown tremendously. I think we started with a handful of product managers and 30 or so engineers. Now, we have over 100 product managers and about 1000 engineers, with a mix of employees and contractors.  

Wow…that is a crazy amount of growth in such a short time.  And I am sure it has come with its own challenges.  May I ask what they were?

BF: Yes, lots of challenges.  

When you acquire that many companies, it’s a little bit like going to Baskin Robbins. You get your 51 flavors of everything – process, tools, mindset, personality. You name it.  

On one end of the spectrum, that little $4 million company I mentioned, we just bought them this spring, they were really tight. A couple of engineers in the US, a couple of engineers outsourced overseas, modern technology stack, good processes moving quickly. 

At the other end, we bought a 30-year-old software product. They were still using waterfall, maybe a little bit of agile, old tech stack, and lots and lots of neglect.  

That’s a huge range. 

BF:  Exactly. But that is not even the worst of it.  

Depending upon the type of the acquisition, you are viewed as a savior, because all of a sudden, you’re this advanced software company.  

Or you are viewed as a dinosaur. Compared to a small nimble company, you are this big behemoth organization with lots and lots of processes.  

And so trying to find that happy medium to get people excited, to find a common methodology around product operations, has not been easy.

So how do you do it?  How do you integrate all of these different organizations, at different maturity levels, into one cohesive product team?

BF:  So, before we talk about the how, let me talk about the goal or my vision for these teams.

The nirvana state is, when I know we have done a good job at integrating, is when I can put a product manager and an engineering manager from two very different parts of the business into the same room and they can collaboratively solve any problem I give them.

That’s the goal. It’s to build a culture of extreme collaboration where people can just work together. Of course, that means we have to have the right process, tools, mindset and all that stuff figured out so that they can do it.  

I love the vision.  You are almost creating an operating environment, where people can just work together and be productive, without being held back from where they came from, and which acquisition. Which brings me back to my earlier question…how?

BF:  The how is much harder (smiling).

So there are two fundamental things that we try to do with each acquisition. 

The first thing we do, when we acquire a company, is an assessment. Some of it is basic, like what is the tech stack, what tools they are using (Aha, Jira etc.). That stuff is easy.  

The hard thing is how the team works, their process, their culture, their norms, their skills.  Because then we can figure out how easily they will fit within our culture.  

And then we start to create migration or integration paths for the teams. Some we can absorb much faster. Others may take a bit more time.  

I love the fact that you guys do a holistic team assessment.  I agree that is so critical.  Because you just don’t know what you are going to inherit.  

BF:  Yup, no matter how deep we do diligence prior to the acquisition. There are always surprises.

As for the second thing, we create an investment budget to help the team not only deliver what needs to be done, integrate with our current product suite, etc., but also to help bring them up to speed.  

Sometimes the choices are we do nothing, and we just harvest. Sometimes we take the intellectual property and fold it into an existing product. And maybe there’s some duplication. Or sometimes we say, this thing is so unique, we’re going to go invest millions of dollars to modernize the tech stack. And we’re going to sprint for two years, and we’re going to put out a new version.

And so each one of those choices obviously has very different tradeoffs, especially when it comes to the investment thesis. But we have to make that decision relatively quickly, too, because you need to get going.

Brian, on the surface, all of this sounds great. You do an assessment, create an integration path, make investments and then you are off to the races. 

But you and I know this, integrating people and culture is the hardest part.  What have you experienced, or seen that works?

BF:  You are right on. People and processes are the hardest.  

The easiest is, when we find that the acquired company is lagging us from a process, or tool or something, we bring them up to our standard. That is easy and they want to be better.

The more challenging one is, what happens when they’re more advanced? For example, we acquired a company that leveraged Kanban. It worked well for them. We are a SAFe shop. So when we introduced them to our process, they balked.

It was very much of a culture clash for like six months, we couldn’t figure out how to get them across the line. And rightly so from their perspective there, because they believed we were slowing them down. Ultimately, we found a way to accommodate Kanban into our overall SAFe framework.  

We have to make accommodations. Not just with them, and not just this type. We’ve had to do that with every company. This way they are happy, and we are happy.  

And yes, it takes time. With the Kanban team it took 6 months. But it is now working. It’s actually working really well.

But it is really a very delicate balance.

Makes sense.  BTW, I am curious.  When you are integrating, do you have certain metrics?  Like a 30, 60, 90-day benchmark?

BF:  We do. Both from an engineering and product perspective.  

We spend a lot of time calculating, establishing metrics around adoption of processes and adoption of tools. Because those are the easy things to measure, hey, they were on Jira, we converted them to Aha, or they were on some source control system, and we moved them all over to GitHub. 

And so you know, those types of things are really easy to measure. We try to get all those done, really in the first 90 days. 

The longer-term ones are around process and people, like how well they have acclimated to SAFe.  What is it going to take to help them understand our version of how we’ve chosen to implement it, helping them understand our cultural focus from an engineering and product perspective, because we very much have made a conscious decision to focus on predictability versus any other attribute.

And then finally cultural fit. If they fit within the company and do they fit within the combined product and engineering group.

Brian, this has been fantastic.  I think what you have accomplished is absolutely amazing.  We did not really get into the whole product ops space.  I know you are building that capability.  But this just means that we will have to have you back for another Master of Product interview.  Thank you for being such a great guest.  

BF:  Thanks Mustafa, this has been fun. And, yes, I would love to come back.