Simplifying Shared Services

It doesn’t matter how big or small your company is, you may need shared services. Harish Parwani, VP of Engineering at CarGurus, explains why in this episode.

Or listen on

Simplifying Shared Services

It doesn’t matter how big or small your company is, you may need shared services. Harish Parwani, VP of Engineering at CarGurus, explains why in this episode.

Or listen on

Description

This episode of The Tech Trek features Harish Parwani, the VP of Platform Engineering at CarGurus. Host Amir Bormand and Harish discuss the intricacies of shared services and how teams can maximize their productivity.

Show Notes

00:56 – Harish offers his perspective and experience with shared services.
03:12 – Why do we need shared services?
06:37 – How do shared services impact team structure?
13:02 – Demonstrating the value of shared services to leadership teams.
16:45 – Prepping shared service teams for mergers and acquisitions.
21:04 – What’s the “wrong way” of organizing shared services?

Harish Parwani

VP of Platform Engineering at CarGurus

Meet our guest

Harish Parwani is VP of Platform Engineering at CarGurus. He is responsible for managing and leading multiple teams responsible for varying aspects of platform engineering. He brings with him almost 20 years of experience in the tech industry focused on DevOps and the previous avatars of DevOps.

Episode transcript

Amir Bormand: [00:00:00] Welcome to the Tech Track where technology leaders share their insights, experiences, and views. Every week, I bring you a new guest, and on today’s episode.

Harish Parwani: my name’s Harish Pani. I’m the Vice President of Platform Engineering at CarGurus. CarGurus is the largest. Destination for buyers and sellers to find used cars in the country.

We’re traditionally being a marketplace, but now moving into the digital transaction space with things like sell my car come in, which allows you to sell your cars through our site to multiple dealers instead of just going to a single dealer. I run Platform engineering here responsible. All of our developer experience teams are site reliability teams, database, reliability teams.

Platform is a service, and our core infrastructure teams. 

Amir Bormand: Thank you for being on the show. Super excited to have you. I know we’re gonna be talking about shared services, something that [00:01:00] is kind of core to what you do. I know we’re gonna cover a few different areas within shared services. I guess just to start off and, and kind of just establish, you know, things in terms of your team and, and what shared services means to you in terms of how you guys are using it.

That that’d probably be a good starting point. 

Harish Parwani: Absolutely. Thanks and thank you for having me on this. Just to give a little more context, you know, shared services is another name and, and there are a lot of different variations of the name platform engineering, shared services, developer facing infrastructure back in the days.

This used to be called application service providers and, and, and other names. So a fairly common responsibilities. So you’ll hear me use some of those terms synonymously and interchangeably during our. Dubs of shared services responsibilities, I would say at a very high 30,000 foot overview.

Look at it as teams that will help your core product focus product [00:02:00] development teams go quicker, faster, more secure. And they could be in the forms of, in the form of shared components that they’re building. It could be in the form of shared platform. Or could be something very specific around pipelines, infrastructure how we’re gonna use the cloud, how do you run on the cloud, et cetera.

So, shed services by itself has a very, very wide gamut. I have previously run shed services teams that have focused on front end platforms to allow folks to develop the micro front ends quicker, faster, all the way to. Teams that have focused on cloud center of engineering as a shared platform, so you could run your services on either a single cloud or multiple cloud in a shared services fashion.

Amir Bormand: I guess we, you know, this, this episode we’re gonna talk about maybe two aspects. One, kind of where to start if you wanna establish shared services and, and kind of, [00:03:00] you know, areas of opportunity. And the other is, What happens when you yourself are, you know, already, you know, in flight and, and you might go through an m and a or you might have to deal with incorporating a, a different organization and, and some of the challenges.

But I guess let’s start at the beginning. You know, let, let, let’s say obviously CarGurus, you’re responsible for shared services. If you don’t have shared services, right, you haven’t gone to the point in, in your development maturation as a company where you need it. What are some of the signs where, Hey, you know what?

Shared services could be a good, good solution to a problem 

Harish Parwani: if you realize that you’re duplicating work. If you realize that your teams are not able to focus on their core competencies so for example, if you have a very front end focused team having to worry about how my front ends are gonna be built and deployed[00:04:00] and consumed and up, you know, updating my infrastructure behind those things if you, if you’re in an area where you’re really spending more time and money and not really getting the returns on.

The way you would imagine too, probably a good reason is because there’s duplication of efforts. You’ve not looked at consolidating things into a shared services platform. You know, some other signs are competing stacks, competing technologies, you know, where one part of the business might be super excited about.

Running a, a Java stack versus another part running a mean stack versus the third part, which swears by Kotlin and, and everything that’s associated with it. I think those are great areas and great signs for any leader to recognize that we, we’ve been effective so far, not because we don’t have a set services [00:05:00] engineering team, but we’ve been effective despite not having a shared services engineering.

So I, I would really go and say that, you know, if you have those problems, yes, you’ve, you might have been able to move fast in the initial stages of those teams just because you are honing onto what the teams already know. But you’ll realize that the speed of change is now decelerating very, very rapidly.

And I think that’s a real telltale sign of the fact. Either we, we don’t have things in a standardized fashion, or we’re missing shared services or a platform team that will help consolidate and pick duplications that, that are happening within the organization or even inefficiencies that are happening across the organization.

And this goes not just on your developer sort of core tooling frameworks but, but sort of also infrastructure tools, platform tools you use to even things around. Monitoring and [00:06:00] observability, you’ll often realize that you’re using a different tool set to do same things that you’re trying to accomplish in different parts of the company, depending on which team is doing most of the heavy lifting here.

So I would say those are the signs that I would, you know, keep an eye out on. Obviously if you’ve had wider issues around security threats, et cetera you know, that’s a clear red flag that you haven’t invested or haven’t looked at, shared services or platform teams as the right path to move to.

Very 

Amir Bormand: nice. And I guess as you, let’s say, see those opportunities and you wanna put together your shared services team, what’s the impact on the, you know, the other engineering teams? Obviously they probably. Some inefficiencies they’ve taken on some things that they shouldn’t have. What happens to the other engineering teams when shared services comes in?

Harish Parwani: Sure. So, there’ll be two effects. You’ll see you’ll either see, Hey, thank God we’ll love this in, in ju humiliation or, or, or the counterside to that is [00:07:00] oh my God, why are we doing this right? You know, what did I do wrong? That is that is defining the need for a shed services engineering team to come in.

So I wanna make. As we’re looking at making these changes and introducing a shared services team you really talk about clarity and sort of roles and responsibilities, because that’s gonna be very important for the current teams, both because now, Instead of working in a new close that they’ve worked in the past, they’ll need to sort of close the coordinate and have dependencies on the shared services team.

And two is obviously you’re, you’re growing a new team. It’s a new way of doing things. There’s cultural changes that will come with it. So you gotta keep those things in mind as you’re setting this up. These are some of the things that sort of, I would say just be on the lookout for, from a positive perspective.

I think it’s a lot of, it’s the inverse of some of the issues that I spoke about. If you’ve put the right investment in the shared services team, you know, you should see improvements in speed, [00:08:00] right? You should see happier developers because now they can focus on the things that they rarely care and love about which in most cases is writing, you know, good high quality code.

You should see teams being able to consistently operate and, and it’s the whole, you know, the build and operate part. Your tech stack that you can focus on. And you should be, you know, teams should see that uniformity and take advantage of that. I, I can keep talking about the benefits. If you are moving people between teams right now, you are not moving somebody from you know, A to B without.

You know, them having to retrain everything that they do. There’s some uniformity around, you know, how you’re doing observability, your monitoring tools, your build tools, your DevOps tools, your security tools, et cetera. So it’s a lot easier to move folks from folks between teams as for the work changes, [00:09:00] as your business goals change, et cetera.

And as you’re growing as a company. So definitely a lot. Benefits, you know, there’s a lot more flexibility into what you can do and what you can, you know, versus what you’ve been restricted to in the past in terms of your stack, et cetera. I would say a huge improvement in the quality of the product because you’ve got, you know, these baseline processes and shared services teams that will help you implement the right tooling around quality.

You should absolutely see an improvement in sort of your security posture. I know a lot of companies have requirements to fill from a security perspective if they’re dealing with the government or if they’re dealing with, you know, any private company. You know, I can give you some examples from, from our side before we, you know, pull in any new vendor, right?

We make, we make them go through a full security and risk assessment. Right. And as part of those risk assessment assessment, some of the best [00:10:00] practices define things you’ve done around call quality and security. And the way to achieve them is not by having each individual team work on their own security piece, but having a centralized shared services team that’s gonna help you achieve and, and get those protocols in place, which is actually gonna help you sell, sell more of your business.

So what I’m trying to. Paint a story here. This is not just an operational efficiency. This is, this is real business value for software companies, tech companies, and even like, you know, non-tech companies who are looking at, you know, selling their services, et cetera. 

Amir Bormand: I get you mentioned, you know, some, some different, what sounds like metrics that you’re probably managing or observing.

Are there any metrics that you’re like, these are some key areas that you have? Have to keep an eye on when it comes to, you know, measuring the value of shared services or the impact of shared services? 

Harish Parwani: That, that’s a great question. I wish I had a, [00:11:00] here’s the golden rule. And, and these are the four metrics.

I think a lot of it will really depend on the type of shared services organization you set up. There’s, there’s some great documentation out there, but I would definitely encourage folks to, Please look at the DORA metrics. Which is basically, you know, they talk about, you know, looking at your deploy frequency, looking at your change failure rates, looking at things such as M T T I M T T R M, ttm, you know, your, your means, mean times to investigate resolve and mitigate your issues among others.

I think those are great metrics. I love change failure rate. That encompasses so many quality aspects in it which are really, you know, hard to pinpoint down to a single area, but they, because the income pass a whole gamut of changes that you would’ve made to achieve, you know, [00:12:00] positive impact to your change failure rate.

It’s basically talks about, you know, how good of software releases are you. And, and it all comes through some of these metrics. So absolutely, I would say the Dora metrics I believe Google was one of the pioneers or put out the original thought leadership on. These are great metrics to, you know, start, start looking at.

So I 

Amir Bormand: guess, you know, a question I did wanna ask you you know, when it comes to shared services, Feels like it’s a little bit more behind the scenes, you know, they don’t ship directly to the customer. You know, maybe have some less visibility in that sense. How do you help bring and celebrate the team wins because obviously seems very mission critical and not, it seems, it is very mission critical.

The role, 

Harish Parwani: Great question. And it, it’s a question that I can tell you every single leader in this space struggles with a little bit, but, but also needs to get creative and smart about how they present the story. And, and I often have this [00:13:00] conversation with my leadership team now, my C level execs, especially folks who are not technical to help them understand the value of shed services just because they’re behind the scene.

And I think the best way to do that is sort of to present you know, what, if he did not do this, So when I, when I take the value of shed services and I want to talk to my CFO and help ’em explain why we’re spending, you know, x number of dollars and, and number of people we have working on shed services, the way I paint the picture is to help them understand that if it wasn’t a single team doing this, You probably have to duplicate 75% of this in each and every single team, and, and there’s a real roi.

So let’s, let’s take some numbers, right? Let’s make this a little more concrete. Say you’ve got four dev teams who are working on different parts of product and, and releases and features, and you, you know, got a shared services team in there, [00:14:00] say five people, right? If you didn’t have that shared services team, you’ll probably.

Three people in each of those four teams duplicating the work and the efficiency that is required for the business to be successful. So just a very, very brute force, Matt, there is, if you didn’t have that 5% shared services team, you’d need, you know, 12 employees in those five different product teams working on these things in order to gain those same benefits.

And I. When you start talking to non-technical leaders, you know, you gotta put it in some real numbers to help them understand the ROI behind this. You know, think of it as you’re building a house and you know, you have six different plumbers coming in and six different carpenters coming in for each room because each room has a unique flavor.

But you don’t do that, right? You, you bring in a single plumber who. Who does plumbing for the entire house, you’re bringing a single carpenter who does framing for the entire [00:15:00] house. So that’s how I think of shed services as as this unifying factor that if you didn’t and you had to duplicate it multiple times, you’d be paying a lot more and have a huge differentiation in terms of quality, in terms of expectations and outcomes coming from those.

It all comes down to the roi, and, and I think it’s, it’s a very valid way to look at it, right? If you didn’t have that roi, why would you invest in shared 

Amir Bormand: services teams? Absolutely. That makes sense. I, I, I like the examples and the analogies. I think it it, it makes you feel more real as to the you know, how, how that ROI needs to be viewed and how it’s spread across, you know, the organization slightly differently than, than what a tech leader.

Be thinking. Yeah. I know you mentioned when we were talking before, you know the other area, obviously, if you don’t have shared services, you, you, you walked us through that and some of the challenges, some of the, you know, what to watch for and how to do it. The flip side is when you actually [00:16:00] have to go through and bring another company on, whether it’s a merger acquisition, there’s various.

Different factors based on where they’re at, at, at the stage of their development of that organization and how you actually will view shared services in that environment. So I guess maybe a a, a good starting point would be is, you know, if you’re going through a merger acquisition and you do have a shared services team, And you’re looking at the other company and you’re gonna have to start determining their maturity and what you know, where they’re at.

What, what are some of the things that you need to, you would be starting to do as part of your due diligence of, of getting ready to, you know, build that common shared services across two, you know, a new entity. 

Harish Parwani: Sure. Thanks Amara. I’ve, I’ve had the pleasure of, you know, being on. Both sides of this conversation, right.

With, in, in, in my past with companies that are acquiring other companies as well as being on the other side where one of [00:17:00] my previous companies where I was working at was in the process of being acquired. So I’ve seen the scenario from both sides play out. I think as, as a acquirer I definitely value if the company we’re looking at has a shed services platform, because now you’ve got.

Homogeneity to the platform that you’re looking at. Right. And typically when a company acquires another company, you know, there’s, there’s multiple layers of integrations they’ll look at, you know, they’ll, they’ll generally start at the boundary. So, you know, imagine this, you’ve, you’ve got a, you’ve got the rings of Saturn, the outmost ring that you want to conquer first.

Things on the periphery, things like your CDNs, your core infrastructure, which clouds are you running on now once you’ve consolidated or you think this is a great place for us to work together, you then step in to the next ring, which I like to call the shed services engineering ring or the platform [00:18:00] engineering ring.

Like do you have a platform that’s easily consolidated to boom? Do you have tools and technologies and processes in place that would go. With the new company or after the company’s march and, and those are some of the things that very often companies take for granted. Right? But, but they don’t incorporate the fact that moving products between platforms and moving products between tech stacks is extremely hard, ANDP.

It’s doable, but you know, it’s probably not a great ROI if you’re, if you’re buying a company and, and you want to have a quick turnaround there. So I would be very careful when you’re doing due diligence, make sure that it’s got, you know, it’s my, my, my mantra around these things is the four Ps, you know, it’s, it’s got the right people in place.

It’s got the right process in place. It’s got the right. Product in place and you’ve got [00:19:00] the right plans to integrate these things. So that’s typically how I like to think about these things. But it’s, it’s really important because if you don’t have a, a shared services platform, right, your integration costs will be multiple x because now instead of integrating with one company, you will need to integrate with three product teams or four different product teams.

So your integration cost could be three x four. If you’re coming in from an m and a versus a team that has a shared services engineering, and now you know, oh, okay, everything that runs for this company is running on this single platform, so I need to integrate with this platform. So real cost, you know, real outcomes in terms of, you know, is this m and a worth it?

Is it, you know, gonna give us the cost benefits or the product benefits that we need to, et 

Amir Bormand: cetera. It sounds like a lot of short-term gain, you know, short-term pain and, and, and a lot of long-term benefits. Cuz, cuz obviously as you’re trying to figure out some of these things, it’s, it [00:20:00] seems. It sounds pretty daunting.

Like it seems like you have to, you know, pull, pull a lot of strings to figure out all the right areas, but everything you’re telling me sounds like it’s, it’s gonna pay off once it’s in place. And once you know, whether you, you’re gonna stay, whatever size you’re gonna get acquired, you’re gonna be an acquirer.

There’s a host of benefits. So I guess from, from that standpoint, when you’re looking at that short term component versus the long term and you’re talking to. You know, business and you’re trying to, you know, for, for your budget and your funding for your team, how do you position that balance? 

Harish Parwani: Great question.

And, and I think that’s probably a little bit of a fallacy that we gotta make sure we don’t fall into, right? The, the, the wrong way or the bad way of organizing shed services. Engineering is if you’re gonna try to boil the ocean. And, and very often people fall for that because, There’s this really nice shiny end goal three years out, and we all know, everybody in the tech industry [00:21:00] knows that, you know, multi-year projects like those have very small percentage of success, right?

The success ratios are ridiculously small there. So your goal has to be, you know, what can I gain efficiency on in a quarter? Right? I mean, a lot of agile principles also talk about these things, but your, your goal absolutely has to. What value add can I provide quarter after quarter? And that’s about it.

And even if you focus on just the first quarter, I think you’ll have success there because you wanna iterate slowly on these things, right? You don’t wanna build a shared services engineering team that will support a 10,000 person organization five years down the line. If you’re a 300 person startup.

You’re gonna invest in the wrong areas. You’re gonna build for the wrong reasons. So you’ve gotta focus on today’s problems, make small investments. I, you know, I’ve seen teams carve out, you know, you know, one [00:22:00] individual from, you know, three different teams and, and bring them into a virtual team as beginning to a shared services organization.

And I think that’s a fantastic way of doing it. Take baby steps. Bring a few people, some thought leaders you know, some of your key architects who know where the platform’s going and what is really needed, and, and just build upon that. So it doesn’t have to be a huge investment. As a matter of fact, I would probably, you know, take a stance and, and go the other way and tell people no.

If, if somebody’s asking you to make a huge investment upfront, and the benefits are gonna be, you know, 12, 18 months down the line and nothing before. You probably should reevaluate what, what you’re doing there. So, small steps. Look at a quarter, you should absolutely have significant ROIs. As a matter of fact, like when you are early in the process, you’ve got a lot of low hanging fruit.

So you should be able to get really good benefits right up front by investing in, in, you know, dedicated or [00:23:00] even a, a small virtual shared services team. 

Amir Bormand: I like that a lot. I think. I think the payoff has to, has to be sooner, otherwise people lose patience, lose priority business changes. And I was gonna actually, you know, ask you about that and you know, as the business does change and evolve in your, you’re watching your Sure Services team, how are you adjusting your roadmap?

How are you keeping up in making sure that you’re supporting the growth of the business in the right direct? 

Harish Parwani: The, I mean, there’s one certainty, right? I know it’s, it’s super cliche term that, you know, change is the only thing that’s constant. But listen, the business environment changes, right? Did any of us predict covid and prepare for that before it hit us?

Absolutely not. And doesn’t matter which industry you are in, even some of the most conservative industries will have a lot of change. I think the key is to have sort of the right balance in place. And by balance, I. Yes, you have your longer term goals but you have to make sure [00:24:00] that you’re making, you know, what we call one way decisions very carefully around those and, and, you know, providing the ability to be nimble around it.

You know, I always tell sort of my engineers, right, you know, let’s be nimble, let’s be smart. Let’s you know if you can push out a decision to the last responsible moment, that’s a great way of doing. And I think that really pays dividends in a world where your business environment’s changing, your requirements will change.

And, and as much as technologists, we would love for our requirements and ask to be standard and and non-moving, the reality is, you know, there’s a higher chance they’re gonna change on you then. Then so, you know, staying nimble and again, you know, just small increments, right? Don’t, don’t aim for the.

You know, if, if you’re gonna build a, a spaceship, right? You know, do it in bits and pieces. So if you can adjust and adapt and, and you know, I mean, I can go on a whole [00:25:00] thing about sort of being agile and, and using agile methodologies, but I think that will take us from where we are. But, but it’s true, right?

I, I really vouch for that. You know, small incremental changes get good, constant feedback. Your users. And one of the, a really interesting trend that has come about in the last couple of years in shared services and platform engineering has been heavy investment into technical product managers, right?

So somebody who can be the voice of the business, the voice of your customer, be it internal customer to help you refine what you need, when you need, where your priorities are. And, and this is something that has not exist. For many, many years. I mean, back in the days shed services engineering team were like, yeah, this is not an external customer facing team.

You don’t need product managers here. But that mindset has changed and I, I’ve really seen that change in the last couple of years only, and it’s paid fantastic dividends. So I would say if you have the ability to invest in [00:26:00] a technical product manager to support your shared service engineering team, you’re increasing the chance of success drastically for your.

Amir Bormand: I think that’s, that’s fantastic. I, I was gonna ask you, obviously you’ve been, you’ve been doing this for a while, technology’s evolving, it’s changing over the last, let’s say two, five years, you know, however long back, have you seen some distinct shifts? Have you seen some changes to how you should view shared services based on your learned experiences and, and I guess how technology’s iterating and, and shifting as.

Harish Parwani: Yeah, I, I would say, I mean, the biggest change has been around cloud and cloud adoption, and I wanna talk a little bit about sort of the impact that has had, right? I would say shared services has gone from being a purely cost center to a business accelerator. And I can give you examples. You know, we have teams internally that are looking [00:27:00] at using AWS services.

Are gonna help us deliver products and deliver new products to our customers. So this is absolutely a business distinction. Something that we never thought about years ago when everything was, you know, on-prem infrastructure. That’s something that I’m super excited about because now I can pitch to my stakeholders that, hey, this is not just a cost investment around productivity and security and speed and flexibility, but this could also.

A business differentiator that will allow you to deliver customers, you know, features that you wouldn’t have been able to in the past. And, and yeah, I think by far that’s been sort of the biggest, you know, macro level change in how we are viewing, you know, shared services and platform engineering across the board.

Yeah, it’s 

Amir Bormand: quite interesting, I think the business accelerator component you mentioned. And, and we were talking about roi, you’re talking about short, short win, you know, short term wins and, you know, [00:28:00] keep, keep the quarter by quarter view moving. It’s interesting because how, how mission critical the cloud is, and this what sits on share services to me seems distinctly mission critical and it almost seems that, that anything that’s being viewed on the roadmap, Should be dotted line back to shared services to make sure it’s going to be ready.

It’s gonna have the ability to, to manage, support, all those different components. Cuz building the X widget now is, is only a small part of the process. It, it 

Harish Parwani: absolutely is. And I think we, we often make mistakes in realizing, you know, how big of these dependencies are, how important they are and how they could.

The difference between, you know, releasing a product in a short order versus it being a, you know, multi quarter effort. And that’s something I think business leaders have, have now started [00:29:00] accepting and realizing is, is the reality of things. So just investing in those teams, investing in in the right processes, making sure you are, you’re, you know, from a cultural perspective you’ve built.

The right gates and expectations is, is equally important in those terms. 

Amir Bormand: Harish. Awesome man. I, I, I appreciate you being on the show. Sharing your, your, your views, your experiences. I think it’s been fantastic. I’d like to wrap up by asking each guest if, if they could ask the next guest to cover topic for them or, or, or cover a question that they may have.

What, what would you like to hear more? Sure. 

Harish Parwani: Absolutely. I mean, I would love to hear from, you know, fellow technologists, fellow leaders around, you know, diversity and, you know, how, how do they, you know, make conscious efforts in an industrial like arts, which is very heavily, I would say it’s very [00:30:00] non-diverse.

So there’s a lot of traditionally marginalized groups. We could, we could do more work with, in terms of getting better representation into our teams, and I would say shed services is probably a bigger culprit in the sub-sector of engineering and, and technical teams. I would love for a future guest to come talk about that.

Awesome. That’s, that’s, 

Amir Bormand: that’s a great topic because I think we, we always need to be making sure we’re covering that. What’s a good way of getting ahold of if, if somebody wants. Just reach out, pick your brain on anything you’ve mentioned on the podcast. What’s a good way of doing that? 

Harish Parwani: Absolutely. So, I’m pretty active on LinkedIn Harish Bari h a r i s h p a r w a n I.

Please feel free to reach out, just drop in a line saying you heard me talk at the podcast. You know, and I’ll be more than happy to connect with you. My emails, my first name, last name are Gmail. But definitely LinkedIn, I would say is, is a better place and I, you know, look forward to chatting with[00:31:00] whoever reaches at.

Amir Bormand: Awesome man. Thanks again for being on the show. I appreciate it. Thank you, Amer.

Latest Episodes

Sunil Mallya

VP of Engineering at OncoHealth

Eric Labourdette

Cloud Business Operation Consultant

Kelsey Steinbeck

Director Software Engineering @ Indigo

A community built by you
for you

Subscribe to Elevano Insights

By clicking Sign Up you’re confirming that you agree with our Terms and Conditions.