In Episode 9 of The inSide Scoop, we talk to Rav Dhaliwal  who describes himself as a “recovering software executive” with over 20 years of management and executive leadership experience in enterprise software. Let’s see what Rav has to say about CS constantly being at risk of becoming the ‘everything department’.

Don’t want to listen this time? We’ve got you—check out the handy transcript of this interview below. Don’t forget to follow The inSide Scoop over on Spotify!  

Show Notes + Links:

1. Connect with Rav on LinkedIn
2. Read Rav’s The ‘everything department’ article here
3. Read the eBook: The Technology Stack For Customer Success Teams
4. Rav’s ‘can’t live without’ tool: Calendly
   

Remco (00:00): I’m super happy to talk to Rav Dhaliwal today. He’s been on this podcast before. If you haven’t listened to that episode, then please do. And today he’s back for another episode that’s looking like it’s going to be a really, really interesting one. So hey, Rav, welcome again and thanks for joining me.

Rav Dhaliwal (00:17): Thanks so much for inviting me along, Remco. Excited to have a conversation today.

Remco (00:22): So am I. As always, we start with a little bit of guest background, or what makes you uniquely qualified to talk about these topics. So can you tell us a little bit about yourself and your background and what you’re currently doing?

Rav Dhaliwal (00:33): Sure. Whether I’m uniquely qualified, I guess we’ll leave that to the listeners. My background is I like to describe myself, Remco, as being a recovering software executive. So I spent about 25 years in enterprise software. Started my career with all the usual suspects, some giant corporations like IBM and Microsoft and Salesforce. And then for about the last 11 or 12 years, it’s been all sort of hyper growth startups. My career has been really focused on sort of sales and what we now call customer success, used to have different names before. And now I’m in the world of venture capital, specifically European venture capital. Helping to sort of find and fund sort of the next generation of sort of intelligent computing enterprise companies.

Remco (01:23): Awesome. And you make it sound like it’s an addiction there, just a little bit.

Rav Dhaliwal (01:28):Ah, maybe, yeah. I haven’t thought of it that way, there is something I’m sure as we go through the conversation, strangely compelling about working in the startup space. It’s exciting.

Remco (01:41): Yeah, it definitely is. So before we get into the topic, a quick full disclosure section. How do you know inSided?

Rav Dhaliwal (01:48): That’s a great question Remco. So I was introduced to inSided and specifically Robin van Lieshout, founder and CEO back at Gainsight’s Pulse event in Europe, I think, in 2019. Robin and I were introduced by Dan Steinman from Gainsight, who at the time was European GM, he’s now back in the States, I think as Gainsight’s chief evangelist. And Robin was really looking to engage with people like myself, like Dan, part of inSided’s move towards focusing much more on a CS buyer. And he very kindly invited me over to spend the day with the board and some of the leadership team including himself in February last year. That was in fact, my last international trip. Sorry February this year. The last international trip before obviously, the pandemic. We have maintained sort of contact ever since, you guys have been kind enough to invite me now twice onto the podcast. And we’ll talk a little bit about Robin and I worked on a little bit of a project earlier on the year, which I’m sure we’ll get into it later.

Remco (02:48): Yeah, absolutely. The new ebook. So we’ll definitely get into that a little bit later. But first, I wanted to talk to you about an article that you wrote back in November, it was published on the Scottish Equity Partners blog called, the everything department. Briefly, I think it touches on how SaaS companies scale and what that means, obviously, and also specifically how that reflects on a customer success team. Ultimately being at the risk of becoming an everything department. So if you will, can you briefly explain to our listeners what it is exactly that you mean when talking about an everything department?

Rav Dhaliwal (03:26): Yeah, it’s a great question. So first you should point out, and just a quick shout out and thank you to the team at Scottish Equity Partners, they’re a growth investment firm, highly respected, really understand tech, and they do a growth series. So they asked me to write this article as part of that growth series. So yeah, big thanks to them. The idea behind this idea of the everything department is that as, and I’m going to just talk specifically about software startups here. But as software startups, especially enterprise ones grow and scale, obviously focus on product and engineering. But then the focus starts to shift to sales and marketing. And this is perfectly normal and understandable. But if you’re not optimizing for thinking about the customer beyond sales and marketing, what can happen is, you’ll get to a certain size and complexity or volume of customer. And then lots of things you hadn’t anticipated happen or lots of needs that the customer had that you hadn’t thought about start to crop up.

Rav Dhaliwal (04:31): And they typically don’t have an organizational owner because they’re… You weren’t anticipating that these things would be needed. And so while you’re sort of scrambling around doing best efforts of grabbing people to help with these issues or needs that customers have that you haven’t thought about, you can suffer a lot of business problems. So you could have really slow deployments or you could actually have a lot of product issues causing the customer pain. You may even start to see some churn for example. And so their natural instinct then is to say, “Well, let’s just build a function or an organization to take care of that.” But given that they’ve built that organization, most people call it CS ends up not being built for productive reasons, it ends up being built as a reaction to these unanticipated needs and problems.

Rav Dhaliwal (05:21): And so the team ends up owning everything that didn’t have an organizational owner, and sometimes wasn’t wanted by other parts of the organization. And that’s kind of what we mean by the everything department. It’s a team that’s customer focused, but that grows out of a reaction to unanticipated issues or needs or challenges, and then either ends up owning everything that doesn’t fit or wasn’t wanted elsewhere in the organization.

Remco (05:47): Awesome. Okay, or actually, not really awesome.

Rav Dhaliwal (05:49):Not awesome, yeah.

Remco (05:49):So basically, they just end up doing everything that all other departments either don’t have the time or resources for. Or they end up just having to very reactively jump on every issue that you would find while scaling an organization.

Rav Dhaliwal (06:04): Exactly. The way I describe it sometimes is, if you think about a car production line, and you think about selling software and you have a go-to-market production line in software. So in cars, you’ve got raw materials, manufacturer, assembly, et cetera. In software, you’ll have your product, engineering, marketing, sales, SDR, BDR, et cetera, and success. And success tends to be at the very end of the production line. And really, what the everything department is, is like saying, well, if we were making cars, Remco, and you were right at the end of the production line, what I’m saying to you is, “Well, Remco, your job is to make sure this car we’ve built gets delivered to the customer on time, that’s your first priority, and then you need to teach them how to drive it, because our car is slightly different from other cars they may have driven. Whilst you’re doing that, could you also be responsible for ironing out any defects in manufacturing or assembly that happened further back in the production line? And while you’re doing that, can you try to convince them to maybe buy some add on features to the car or maybe a metallic colored paint, and then try and convince them to buy a new car next year?” So that’s essentially what an everything department is doing in a software company, if we were to use the analogy of a car production.

Remco (07:22): That’s a good one, probably me at least in that production line would end up with me burning out. Probably, I would guess.

Rav Dhaliwal (07:29): Yeah, correct. Yeah,

Remco (07:30): So maybe as a follow up question, I’m now wondering, do I also have an everything department at my company? Or at least how do I know? How do I find out?

Rav Dhaliwal (07:41): Yeah, it’s interesting. So as part of this growth series, we kind of presented this idea to a whole bunch of sort of leaders and founders. And we sort of tried to provide some guidance on like, how to maybe assess whether or not you have an everything department. And I think a couple of useful things, especially for the listeners to think about is to assess that, does your CS function actually have a defined mission? Does it have a very crisp definition of not only the value it’s adding to customers, but the value it’s adding to your company’s bottom line?

Rav Dhaliwal (08:14): So I think that’s the first thing and I’m sure through this conversation we’ll talk more and more about this lack of a common definition for CS. I have one that I’m very fond of, but there isn’t really an industry definition. And that’s because CS is very contextual to both the company, its product and the stage the company is in. So that’s the first thing I would say, is do you have a defined mission? And related to that is, does your CS function have materially important targets? So does it have a Northstar metric, or metrics it’s aiming for that are actually important to your company’s bottom line. So that’s not always revenue, revenue definitely plays a very strong part of that. But if you’re a very early stage company, even a… You may only have a handful of customers, some of the most important metrics to you are going to be around product and feature usage and adoption.

Rav Dhaliwal (09:06): So whatever stage you’re in, do you have a materially important target as a CS team? And I think another key thing is to] whether you’re in everything department or not. Do you actually have access to important data that helps inform your decision making? And this goes back to this idea of being reactive or proactive? What data helps you to do, is to look at patterns and look at where you need to make a proactive intervention. If you don’t have access to good data or any data, then you’re very likely an everything department. And I think the last couple of things are just around internal alignment, and specifically in alignment with sales and product. So do you have a hard handover from sales? Are you actually not part of the sales motion? Are you not integrated into the selling effort or even have visibility to the pipeline? And do you, the sales and CS have any common kind of alignment?

Get your copy of The Ultimate Guide to Community Management

Full of tips and tricks!

{{cta(‘2d792546-0f0a-433b-b2c5-4db95f97875f’)}}

Rav Dhaliwal (10:02): So if sales is aligned around industry vertical, but CS is aligned and segmented, say around employee size. That’s a mismatch in alignment. So you’re not working on a common set of customers. And I mentioned the product there, do you have a formal feedback mechanism with the product? You’re typically a CS closest to how people are using the product? Are you an island that doesn’t really interface with products? Or do you have a rolling mechanism to feedback what customers need and the challenges they’re having? So those are sort of five or six things that I think make a useful checklist. And I think if you have one or two of those where your answer is “No, I actually don’t have those.” That does tend to strongly indicate you might be in an everything department.

Remco (10:45): Wow, so many good things in there. So maybe a couple of questions from me. So first, you mentioned your definition around CS. So you did get me curious, a little. Do you have it top of mind?

Rav Dhaliwal (10:58): Yeah. So I think CS is really a group that is focused on accelerating the business value customers get from your product. So by value, we mean material bottom line value. But they focus on accelerating that faster than if the customer has left to their own devices. So we could sell something and leave the customer to it. But if we add CS into the mix, that definition I feel of what they do is we are here to accelerate the speed at which the customer sees value. And because their mission is to keep and grow that customer forever, they’re creating the conditions to keep them growing.

Rav Dhaliwal (11:36): And so that’s the definition I’m most fond of because it, I think, speaks to the value you add to the customer and the value you’re adding to your bottom line. And it talks in a non-specific way. Because CS is contextual, it will vary depending on the company about how you’re going to do it. So you’re going to do some sort of acceleration. That acceleration might be you bring certain deep technical skills to accelerate the customer’s value. It might mean you bring project and change management skills to help the customer accelerate value. You might bring consultative skills, that helps them to model their workflows in your product in the most efficient way. So the thing that you bring, or the things you bring to accelerate may be different. But the cool thing I think every good CS team is trying to do is speed up the time it takes for the customer to see value. In a year-long subscription, if it takes them 10 months to deploy the product and see value, that puts you in a very high risk situation. Maybe we can add CS to the mix, and they can help the customers to see value in 30, 60, 90 days.

Remco (12:40): Yeah, I love that. And I especially also love that definition. Because I think it’s a different kind of more visionary kind of mission, which is easier to get behind than the general things you usually hear around CS saying, “Okay, so no, no, we’re largely focused on only increasing product adoption on our largely focused-

Rav Dhaliwal (13:00): All outcomes, which is very generic.

Remco (13:02):Exactly. Yeah, that’s what you usually hear in CS world is, “Yeah, we’re responsible for these outcomes, if not all of them.” And I think this sort of neatly covers a bit of a visionary thing.

Rav Dhaliwal (13:13):I hope so. Yeah. I mean, it’s the idea that really we exist to help speed up the process by which the customer sees ROI, real business value, something that they can materially point to and say, “We can do this faster, cheaper, gaining or revenue.” Whatever it is that’s important to them, but that you can then circle back and go, “And actually, this is how we are adding to our bottom line. We’re driving net revenue retention.” For example, is a classic metric.

Remco (13:41):Exactly. It’s like driving the business forward versus managing a few metrics.

Rav Dhaliwal (13:47): Correct. Yeah. So this is the challenge going back to your original question in the premise of the article is, if you’re an everything department, you’re never going to get on the front foot of driving material value for the customer or for your own company. You might end up over indexing on doing lots of manual workarounds or filling in product gaps by working hard and doing manual things, that will help the customer, but it won’t necessarily add to your bottom line because it’s purely reactive.

Remco (14:20):Yeah, exactly. Yeah. I love that. And then maybe one final question before we move on. So you mentioned does CS make data informed decisions? I think that’s a super important point. And maybe we cover it a little later on, but I just wanted to mention it here as well.

Rav Dhaliwal (14:35):Yeah, sure. And just on that, the use of informed there is very deliberate. I know in tech, we like to say data driven decisions. I’m not a big believer in just using data to drive your decisions, especially in CS where there are so many softer skills at play. The data may be telling you something and it may make you have an intervention, but the type of intervention you make might be based on other factors like the stakeholder, the changes in political dynamics in the customer, what their business is going through something that the data can’t show you. So, I’m a really big believer that when we get to that topic around data, being informed by data is important. Using it as the only source by which you make decisions can be actually quite challenging.

Remco (15:19): Yeah and I was speaking to (will not name names) but to another VPs CS the other day. And they were basically explaining that they were struggling, because they weren’t actually the owners of certain types of data or data sources that they actually required to do their business well. Because they had to go to different types of departments. And they were basically owning the applications or the data. And they had to actually ask them to give them certain views

Rav Dhaliwal (15:50): And that’s a very, very common challenge, which is why I made a point of including it in the list of questions to ask yourself to determine if you have this sort of everything department.

Remco (16:00):We’ll definitely cover that later. I’m first now going to backtrack a little bit. So at the start of the article, you dip your toe into how SaaS companies scale through product and especially go-to market fit, could you explain that process a little? And maybe also how a customer success team then evolves along that journey?

Rav Dhaliwal (16:19):Yeah, sure. So certainly, now that I’m on the investing side of the fence, investors tend to toss around these phrases, product-market fit, go-to-market fit, and it can get a little bit confusing, people will have their own sort of spin on them. But essentially, and I’m just going to speak now, from my experience of being in a number of companies that sort of scaled quite rapidly. In the very early stages of a startup, you have a kind of a version of your product, you’re still iterating on it, you maybe have a handful of what I call friends and family sales. So you’ve sold to people through who you know, or through maybe your investors and your network have connected you to.

Rav Dhaliwal (17:00):And but really what you’re focusing on is trying to reach what we call product-market fit, which is how do I build the best product for the target buyer and the target user that generates the most value for them and for us, right? That’s the mission that you’re on. And so, where CS plays a part in that, a really important part in that is actually, we talked this idea about acceleration, is you may not have that many customers, but it’s important to have someone who’s working with them because you need to be able to feed back what you are learning to accelerate the product-market fit. Product people have hypotheses about what customers need and how they need that capability. And you need to have a really rapid cycle to test those hypotheses, accept the ones that fit and then discard the ones that don’t, because in the early stages it’s make or break.

Rav Dhaliwal (17:52): So even though your function may not be called CS, you need someone and sometimes it is a person in product who’s wearing the CS style hat, working with these early customers to help accelerate your product-market fit. Actually, there’s gaps here, when we put our product out in the real world. These are some gaps, or these are the things that are actually working well that we need to double down on. It’s just as important to understand which features aren’t adding value, as it is which ones are, so you can orient the roadmap around that to get product-market fit. Now, you could argue that a good SaaS company never reaches product-market fit, they’re always iterating. But they will get to a certain critical mass where actually the product, the sort of maturity and capability that’s currently reached really suits our target audience that we’re going after, and our target buyer really well. And we’re starting now to see, we’re landing more and more customers beyond the sort of friends and family and people we know. That’s normally the signal to start ramping up what’s called your go-to-market fit.

Rav Dhaliwal (18:54): And that is really building a sales marketing engine. What that really should be is a sales marketing success engine. Because at that stage, that’s where the risk of the everything department comes in. You focus on the sales and marketing piece, and you forget the customer piece. So you really want to do all three. And what CS should ideally be doing at that stage and focus on in that stage, is this idea of how do we accelerate time to value? How do we get this thing deployed, configured, users onboarded, up and running, in the quickest, most efficient way possible? Because that will then give us the opportunity to understand what else we can be doing with the customer, whether we can sell them more capability, getting them to consume more of the service. So that’s kind of at the beginning of the article. Why I framed the article in terms of that journey. So ,you have a hypothesis about a product, you strive for product-market fit and CS helps you accelerate that product market fit. When you get to a product-market fit at least in one sector or segment of customer, CS can really help accelerate the value that customer gets, so you can continue to iterate and learn more.

Remco (20:02): Thanks for that. So what I was thinking as you were explaining this is, so why do you think do we fall into this trap of basically saying, “Okay, let’s just figure out how we grow first and get all these customers on board, and then we’ll figure out how we’re going to deal with them later.” Why do we consistently fall into this trap?

Rav Dhaliwal (20:22): Yeah, it. I don’t think there’s any one answer. Some of it is historical, I think, Remco, in so much is not so long ago pretty much for anybody to get venture capital money, they would have had to come from sales or marketing, it’s very different now. Typically people who do get backed are product engineering tech people. In the first instance, in the olden days where it was basically sales and marketing people built companies, that’s what they knew, you optimize for sales and marketing. What happens now, where you have maybe more product lead founders, they’ve never run a business before, they’ve never been in sales before. They then rely on their ecosystem of investors and advisors to work out how they should build a company, and a lot of that ecosystem with the exception of people like Scottish Equity Partners and some of the other funds that I know who are very forward thinking and understand the importance and power of customer success. They’re not being told, actually, you need to think about sales marketing and success, you just got to optimize on top of funnel and keep the new revenue growing. And it’s really the forward thinking investors and the forward thinking advisors are saying, “Yes, you need to do that. But you also need to lay the foundation for net revenue retention. So we don’t want to be losing these customers in a year’s time.”

Rav Dhaliwal (21:35): So I think it’s a lot of it is historical. And I think actually, Remco, a lot of it goes back to the fact that we don’t have a crisp cogent agreed industry definition of what CS is. How would you know to build something if you don’t know what it is? Sales is very well understood by everyone. Everyone has had an experience with sales, you don’t need to define it for anybody. You pick up the phone and ask strangers for money, that’s your job. Marketing is very well understood. In tech, engineering and product is very well understood. Success is not. So if something isn’t understood and doesn’t have a clear definition, it’s quite natural for someone to not think about it.

Remco (22:14): Totally makes sense. I agree. Awesome. Thanks for that little bit of background there. I really like how you at some point in the article also mentioned that while a company and CS team scales, not only does the amount of customers and people and processes grow, but more importantly also the pace and frequency of which you do things grows rapidly or even exponentially. Could you elaborate a little bit on that?

Rav Dhaliwal (22:37):Yeah, sure. And this kind of goes back to a point you made earlier, Remco, about the addictive nature of this style of business. I think one of the reasons why startups are very seductive places to work in a lot of cases is the speed of change. So large organizations, global multinational organizations, they’re really structured and optimized for predictability and efficiency, because they’re just so big. And so they have to, whereas a startup is scrappier and nimble and is figuring things out. It’s all about building. And the thing is, people think that scaling a business is actually about adding people. And that’s kind of why I wanted to make the point in the article, that it’s people and pace. It’s two things, it’s not just adding people, it’s the pace at which you have to add them. It’s not just shipping features, it’s the pace at which you have to ship features. It’s not just onboarding customers, it’s the pace at which you have to onboard customers.

Rav Dhaliwal (23:33): And that is often overlooked. Because generally when you think about scaling, or people talk about scaling, what they’re really talking about is growing the headcount in the organization, and I just wanted to make that distinction because adding people can actually have the reverse effect of slowing everything down. Because it takes time to find them, hire them, onboard them. So you want to factor in the fact that scaling means everything that you do from building the product, marketing it, to selling it, to onboarding it, just starts to happen quicker.

Remco (24:01):Yeah, I think that’s a great point. And I think that’s also interesting, because arguably this is exactly, I think the one thing that people always forget while scaling. And this is also the one debate that we usually have when we talk to either customer success leaders or however the function is called at that point of smaller organizations. Where we really advocate you need to figure out your process also for and plan for a bigger company basically early on, versus actually trying to do that when, yeah, pardon my French, shit hits the fan. And you have no more resources and everything is basically locking up, then you’re too late.

Rav Dhaliwal (24:42):Yeah, exactly. It’s a very fine balancing act. And it’s a real timing act. If you get the timing wrong, if you start to scale too early that’s detrimental, and I’m putting my investor hat on here. You say you start scaling up you go-to-market fit before you have product-market fit, you’re going to burn a lot of money and probably end up having to a lot of people because the product wasn’t ready to sell and scale. Conversely, and normally the reverse is more often true. You wait too long to scale up your go-to-market effort. So you’ve got a great product, but you’re not doing well enough selling it and getting it out there and getting people to onboard it. So the timing of these things is really, really critical. And the timing sometimes will make or break a company.

Remco (25:23):Yeah, exactly. Which is an awesome bridge to the next section, which is about the bad side of scaling. So what typically breaks from a CS perspective, what gave you headaches as a former CS leader?

Rav Dhaliwal (25:36): Oh, that’s a really terrific question. So going back to the overall theme of the article in our discussion, I think one of the things that has typically giving me the most headaches is, well, my team and I are owning and doing things that actually don’t add any impact toward the customer or to the business. So we have to set about on a mission now to find those things at home, or stop doing them, or figure out a way to automate them. That’s a huge challenge. And that really leads to another big headache, which is we’re just reacting all the time, we don’t have maybe as you gave the example, the right data to make informed decisions, we haven’t disintermediate ourselves from these things that we just ended up inheriting that we shouldn’t have been doing.

Rav Dhaliwal (26:17):One of the other really big headaches. And this has been a common thread in my career is internally people not understanding what you do. And so if they don’t understand what you do, and you’re too busy just reacting and getting on with stuff, it makes the challenge of getting resources, people, tools, data that you need that much harder. So one of the big headaches is just the time and effort it takes on the internal change management effort. But I would always advocate that you do it, that will actually be materially more important to you and the company to get everybody to understand what it is that you do and why you need these resources. And I guess one of the biggest headache

By Remco de Vries