SPEAKER_00 0:02

Welcome! You are listening to the CRM Success Show, where you will hear from CRM executives who have overseen some of the most interesting and complex CRM implementations. Your hosts, David Mastri and Kiro Whitey, will be bringing you real stories, real insight. Follow along on social media for updates on new episode releases, exclusive content, and much more. Enjoy the show and thanks for listening.

SPEAKER_03 0:29

Welcome to the CRM Success Show, where we deep dive into CRM success and failure, delivering real stories with real impact. I'm Dave Masri.

SPEAKER_01 0:36

And I'm Kira Whitsi.

SPEAKER_03 0:38

And today we're talking with Pranav Lanal, Head of Business Technology and Enterprise Systems at Gusto. Welcome, Pranav.

SPEAKER_04 0:46

Thank you. Thanks, Death. Thanks, Kiro. Thank you for having me.

SPEAKER_01 0:50

Absolutely. Pleasure to have you here today, Pranav. Thank you. So we're going to start real nice and simple today. Just give our listeners an overview overview, Pranav, of uh your role as head of business technology and enterprise systems at Gusto. What does that really mean? And what did Gusto do?

SPEAKER_04 1:07

Sure. So yeah, to start with, Gusto is uh a payroll provider. We uh provide services to primarily SMB segment. So it's a very niche segment, and uh also within SMB, it's a much smaller size employees. So think of very small businesses which are really getting started, and that are uh that just enables a lot of equity amongst kind of small business owners here in US. Uh so Gusto provides payroll services, HR services, insurance, uh, and other support in terms of tax filing and support as companies do payroll. Um for my role here at Gusto, uh, so I lead our business technologies enterprise systems team, which is primarily all the tools that we use here to support our sales and CX teams. Uh, Salesforce is definitely at the front and center of it. It's the central tool uh which is used by about 2500 users here at Custo. And then telephony is also a big part of it because given the nature of our business, we have many, many clients uh and we get in a lot of inquiries on a day-to-day basis. So that's what I do here.

SPEAKER_01 2:31

Perfect. Um so to paint the picture a little bit, that will lead us into today's topic, uh, which is heavily focused around leadership and motivating teams and some of your beliefs um on leadership as well. Um, I think it's really important to kind of fast forward, rewind to 18 months ago um when you were joining Gusto, um, to just give us an idea of kind of what you inherited in terms of uh, you know, the team, the team size, some of the external kind of vendors uh and and size in the picture, and and and just kind of where the projects were at, what was the kind of mentality in the business around the projects? Were they successful? Were they not? Just paint a picture of kind of what you inherited.

SPEAKER_04 3:18

Sure, sure. Yeah. So when I joined Gusto about 18 months back, we were going through uh we were coming out of a rough implementation of our service cloud with one of the big uh GSI companies, right? So the go-i was pretty chaotic. It burnt out a lot of the team, it blurred boundaries between our tech teams and the business teams. Uh, and that led to attrition on the team. So we lost about seven uh team members within a span of six months, and that really had an impact on morale. People felt you know uh pretty burnt out trying to manage all the things. Um, doing a transformative project like uh of kind of redoing service cloud is a pretty big deal, especially for a company like ours, where we get so many cases and requests uh uh every day. Like we get on an average 100,000 to 200,000 cases a week. So that's a lot of volume. Uh so that did cause you know uh a lot of friction. Uh things overall were getting impacted in terms of delivery, and especially when people were not at their best, um, from a you know, from a productivity perspective, that had that had some impacts. Um so yeah, so the org that I inherited was it was pretty complex with heavy tech depth that we had incurred uh just because of not having good overall governance and role clarity between engineering teams and Salesforce teams. So we had an over overly uh complicated architecture than it needed to be. Uh, we would have a lot of SEV ones on a on a weekly or once every two weeks, which would impact productivity for our internal teams and it would impact some of our customers too. Uh, you know, if our Salesforce is impacted, that impacts a lot of our sellers, that impacts a lot of our uh CX team members. So that was a big thing. Uh so that's kind of what I inherited. Um, so definitely, you know, had a lot of stuff to kind of figure out and work through.

SPEAKER_01 5:45

So just to put it in perspective, um, you mentioned seven eight uh team members left in in a six-month period. Um for context, that was around 25% of the team, correct?

SPEAKER_04 5:57

Yeah, roughly around that, yes.

SPEAKER_01 5:59

And the and these were FTEs uh primarily?

SPEAKER_04 6:02

These were FTEs primarily, yeah. We do have a significant number of contractors also that support us given the number of things that we have going at any given time. But this specifically was just the FTE numbers.

SPEAKER_01 6:16

Yeah. What what um how much do you think the that number of um you know the number of resources that left, do you think it was a bit like a domino effect? Like one left and you know, another saw the right on the role on the on the wall and thought, you know what, Jeff has left now, now I'm gonna go. And then the next person was like Jeff and Sarah's left, now I'm going, you know, like with a with a team close because it was such an intense project. And do you think that had a domino effect? Or or um, you know, what are your thoughts around that?

SPEAKER_04 6:49

Yeah, I think partly it was that when folks one team member leaves, people ask, like, oh, why are they leaving and what's causing them to leave? And then like, oh, he's he or she's leaving. That was maybe a sign that I also should leave. Uh, and then part of it was uh we did not have leadership at from like a sales force level. We had senior roles, like uh we had VP roles, uh senior VP roles in place, but not someone who understood what happens in their world. So they did not have uh a lot of support directly from the senior management, which just made them feel like uh they were just exposed directly to the business, which isn't a bad thing, but when things are moving so quickly and the business needs like this stuff has to make. Obviously, our stakeholders don't have any uh uh malintent there. It's more of like uh we want this stuff done. So that just caused a lot of stress to the team where they're like, no matter how much hard work I put in, it just won't get recognized and it'll be a tough situation to come out of.

SPEAKER_01 8:00

Okay, I see. Um we're gonna talk about some of the solutions uh that you embedded later on, um, you know, to kind of mitigate this from continuing to be, you know, 50% of the team, right? And and kind of you know, uh put put a put a plaster on the on the situation, short-term uh changes you made and and longer-term uh changes. But before we move on, I uh I I guess just focusing on the uh GSI piece not working out, um, you know, not being the best fit. You mentioned chaotic go live, that impacted um morale. How so would you say?

SPEAKER_04 8:38

Yeah, I mean, I think when companies like those do come in, they need to be more uh understanding of culture, especially when it's when it's a startup, right? Startups are uh a team that are more kind of like closely knit, they have a certain way of doing things, they have a certain style of implementation. So, and then there are a lot of processes which are not fully baked in or not fully hashed out. So when GSIs come in, they assume certain level of maturity in in companies that they are working for. Whereas for startups, sometimes even things like processes are not defined or governance isn't defined. So um they did not go in deep in understanding what are the different personas, who all will this impact? Uh, have we ensured uh this the flow of it from sales to CX works? Um, so that did not happen. They were more of like, what are your requirements? And we will we will build it according to that. So it needed to be more of more discovery, more conversations uh that needed to happen. Uh, and then making sure that they looped in the right team members. So uh to my knowledge, a lot of the team members who were key in this were not in the decision-making process. The technical skills were not brought in at the right time. So that's kind of what led to um the launch not being very smooth and there were issues as we went live.

SPEAKER_03 10:22

Do you think that GSI took advantage of your lack of maturity? Or was it just simply non-intentional?

SPEAKER_04 10:31

Yeah, that's where I feel like they are more, they're not, they're more in the sense robotic of sorts. Like we this is this is stuff that we need to do. I have this stock and I'm gonna work towards it. People have said this is the final requirements talk, and I'm so they it's just more focused and they just want to come in, uh hash out the number of hours that they have kind of put in and get that work done. I don't assume any uh malicious intent there. It's just more of like that's how they operate, and they expect certain things to be in a certain way and not go, not go like the above and beyond route or try to do something, try to uncover more and more stick to what they've been given to.

SPEAKER_01 11:15

Yeah, I I guess the idea of uh you go into a dealership to buy a car and um you ask, you walk in and say, I want a red car, uh it needs to be this size, this shape. Giving you what you want an asphalt versus maybe presenting a blue car, a different model, which might have been a better, better purchase for you, um, you know, in in hindsight. Um it's a dis it's a difficult one, right? Because I think a lot of a lot of customers are price price sensitive. Um they want the best deal possible and they want the least amount of hours as a result, right? Um, how much time do you wait for um the uh statement of work for the requirement gathering, getting to know the business, you know, a culture alignment as part of a deliverable, I mean it sounds great, uh, but in theory, is it something a company's gonna pay for, right? To to get resources to allow them you know three, four weeks um to get to know the business and you know, billable versus non-billable. It's about it's a tough act to to balance, isn't it? So um, but but but I think to your point, it's um doing more without being asked, right?

SPEAKER_04 12:23

Yeah, yeah. I think it's more of like uh making sure like that knowing the different roles on the company, which you know, which developers have been building what, and just making sure have you checked with the key Salesforce dev lead on on an architecture, or are you just talking to a stakeholder, a business stakeholder, and making architectural decisions, right? So there needs to be a balance. Yeah, I fully agree. Like you can't have people just talking and talking and make that available hours for weeks, but uh just doing the due diligence. Like, do you have the full picture or do you have a partial picture?

SPEAKER_01 13:02

Yeah, Maz, I think you have a quick question. I have another question on the um the GSI front before we move on.

SPEAKER_03 13:09

Yeah, so generally, generally you would think that they would know the difference between a sophisticated buyer and a non-sophisticated buyer. The the uh auto dealership for sure knows, right? Uh they can tell in like 30 seconds. Um so it's surprising that they kind of push this one size fits all when if you were to go to more, let's say, a boutique shop, they definitely tailor it to the level of sophistication um of their of their client. Um so that that's why I asked a question if if you felt they take you know they were they were taking advantage of that. Um, it might just be that they don't care and they just tell you up front either your expectations.

unknown 13:53

Right?

SPEAKER_03 13:53

If you ever looked at these contracts, the the bigger the company, the more the expectation is on the client, it's almost right, it's like it's almost like who's this contract for? It's like it says what I'm doing, not what you're doing, right? Um, so that that was kind of the the source of my question. So yeah, so what are your your thoughts on that?

SPEAKER_04 14:14

Yeah, specifically when it comes to contractual language, yeah, it those contracts can be pretty hairy, like it just goes into very detailed of uh this is the level that they'll be involved in, and then they'll be hands-off. So and most of the time folks don't have enough time to even read through that. Um, so that that does make it more complicated for sure.

SPEAKER_01 14:38

My my uh last question on the uh the GSI front, um, and I think this is a question for for most uh partners in general, um, and and independent resources, contractors, right? In order to bridge that cultural alignment, you've got to see people in person. There's no substitute to being in person and doing it virtually, it's just not the same, right? Um, you know, so so I was curious during that that period, I know it kind of was pre-ur time, but how often, I know it's pandemic as well, um, bit of overlap there, maybe. Um, but but how often did they did they get a team on site to visit and and kind of embed themselves within the business?

SPEAKER_04 15:17

Yeah, to from what I've been told, that did not happen. It was all like all remote. Yeah, because there was no no no in-person, but yeah, I'd only also be like in-person interactions are definitely much more impactful and valuable. Yeah, couldn't agree more.

SPEAKER_03 15:36

Yeah, so yeah, let's talk about like at what point did you notice like if it's becoming a big morale issue? Um and then like what was your approach to I'd say dealing with it? I'm not sure if that's the right word, or or handling it, or coming up with some kind of yeah, lasting solution, right?

SPEAKER_04 16:01

Yeah. Uh yeah, I mean, once I joined the team, my main focus was uh I'm someone who likes to go deep and understanding what's happening, right? So just the first week in talking to people and then seeing some of the feedback coming from our stakeholders about my team. Um, so my first thing was okay, I'm hearing more, there's a lot of negativity where what I'm hearing. Let's just talk to the team and get get their perspective, right? So part of it was feedback from our stakeholders where they feel like uh our team is not being responsive enough or we're not delivering enough. Uh, and that just to me meant something is going on, right? Like there's something happening with the team where either are they not feeling supported, or we're just understaffed and we just need to set the right expectations with our stakeholders. So yeah, so the way I went about it is like just talking to people, having one-on-ones, and then just trying to understand more of like how are they doing from a work perspective, from a work-life balance perspective. Um, how is that going for them? Are they seeing enough growth for them? So that's when you uncover more, right? Like when you give a more safe environment where you tell people I'm just here to listen to you and understand what's happening and share some of my background, right? So I also have been in their shoes that I've I've been someone who's been a Salesforce developer, a solutions architect, an enterprise architect. So I get the system and how complex it can be and how difficult sometimes it's to explain, like why even adding a small feature will take two to three days, whereas the business expects it to be like, that should be just half a day thing, right? So just telling them why I understand those things and then come up with uh as a unified team on what our approach should be. So talking to people and getting some feedback was was some of the ways, you know, I went about like realizing, okay, something is off in terms of how we are delivering and how we're doing our work here.

SPEAKER_03 18:09

Okay, so I would classify that as I guess like expressing empathy and understanding, right?

unknown 18:16

Yeah.

SPEAKER_03 18:16

So you go these people say, okay, I understand what you're going through, I'm on your side. Um, but you still have that issue of right, okay, now what are you gonna do about it, right? Um, because right, it's great that you understand, you're not gonna hold it against them, they're not gonna be penalized, let's say, right? But right, how do you go about fixing it? And then how do you get them to guess to be patient enough so that they stick around right through the fix? Um, one last question before we jump to that. Um, did you conduct exit interviews as well?

SPEAKER_04 18:50

Uh exit interviews, I thankfully did not have a lot of folks leave the team after I joined. Uh it was mostly people who just had some uh you know personal things come up that had left. So since I joined, I did not like maybe I'm in in a way lucky that I not had to conduct a lot of exit interviews. Uh, but in my prior roles, I have done those.

SPEAKER_03 19:15

Okay, yeah. What do you what are your thoughts on them? Um yeah, I think that across are people honest in exit interviews?

SPEAKER_04 19:23

Yeah, I think people mostly then share more on like what was really bothering them, and then sometimes you just feel like it shouldn't have gone into that point, and you're hearing of it during the exit interviews, right? Like, um, yeah, most of the time it has to do with how supported they felt overall in their role. It's never about the uh kind of like their role specifically. To an extent, it can be about the pay, but mostly people just leave when they don't feel heard or supported uh by by their leadership.

unknown 20:00

Right.

SPEAKER_03 20:00

Okay, cool. Yeah, so it's uh back to my other question, just remind you, which was uh right, the path forward. How do you get people to stick around during the let's say healing process or the fixing process?

SPEAKER_04 20:11

Yeah, I think you then just show up as a leader where you set up some guardrails for them and uh kind of immediately set up uh ways of working, right? So we did not have a very well-defined intake process. Although Slack is great for collaboration, but sometimes it can just be not the right space of doing requests, right? So we just stopped this concept of taking requests over Slack. We had BSAs on the team, so we just encouraged, we should just formalize a more funneled intake process where we just have to work on things that are of priority for the business. So that gave us some breathing room. Uh, I got exec buy-in from uh my uh leadership and my CTO that you know, foundational health of Salesforce is important. We cannot build more when we don't have a sound architecture uh in place. So there was a lot of buy-in and support I got from the team where uh our CTO at Gusto was like, he's willing to go back and support me and tell our stakeholders that they need to hold off on some of these key uh business initiatives till we just make our foundations more stable because it wouldn't make sense to build more on foundations. So getting that exact buy-in was important for me, and I was grateful that I got that support from my leadership in getting that time. So then I use that effort to just go more deep in our foundational area, look at more out how are we doing our code reviews, how is how are we making sure that any new architectural changes have oversight? So just establishing all of these processes of like, do we have an architecture review process in place? When projects are happening, how are we doing our code reviews? And that led to more things, right? So happy to talk more about like we engaged with Salesforce's signature success services that brought in a lot of valuable information for us to really have focus on areas we need to improve on, and then uh slowly and surely moving to a better way of doing DevOps, which is implementing tools like Gearset that uh we implemented.

SPEAKER_03 22:30

So um what happened with the SI, right? Could you have the SI, I assume you had contracts in place, the project is in flight, so right there's a two-fold issue. One is a legal contractual issue, and then two is I assume there's some kind of knowledge transfer issue, and then you have right, you have to what you put the project on hold, then you go back, you refactor, and you need to do that in a way where I guess you don't lose any knowledge. So how do you tackle this kind of it's almost like a double pivot, right? It's a pause, pivot, fix, come back, pick up where you left off, um, and you have this contract mess in the middle. So how how did you how did you handle that? Or like what was your approach there?

SPEAKER_04 23:20

Yeah, I mean, by the time I had joined the global SI had pretty much uh they were pretty much gone. Like they were in a specific time period where they were, that's how they kind of operated from this time to this time is when we're going to be there. This is gonna be the transition period. Um, so they did do their knowledge transfers to certain team members, um, but then those team members had also left. So it was an interesting uh kind of position to be on. So that's where we just like made sure that we had documentation in place to understand how things are built. So it then just meant people going in deep into looking at the flows and then documenting what it's doing. So it was understanding what is our current state and then documenting it and then aligning with like our stakeholders. Is this what you guys really wanted? And then kind of iterating it from there. So it was kind of like we were kind of building the plane as it was flying of sorts, like uh it was a period where there was frustration, but then at the same time, people knew that we're trying to make this better, right? So I think just having those expectations up front with our stakeholders helped, and just having some grace and patience from their end as we figured this out because they knew we were coming from a team that needs to rebuild itself. So part of it was like unknown knowledge, and then people coming in and then taking the time to look at the apex code, look at all the classes, how they're connecting, how are the flows there, and then me making sure that just document this guys. Like, just let's make sure we uh put the time now to document stuff for people to understand how this is working.

SPEAKER_03 25:07

Okay. Uh any any uh fun discoveries during uh this process?

SPEAKER_04 25:12

Uh yeah, I mean, still like you you would be surprised by the code quality uh of some of these, you know, well reputed global SI companies. Like we just uncovered like their code was just not good. Like it was like written by someone who's like a few years of being a Salesforce engineer, and we were sold like we would get senior senior engineers, so uh just then like smaller things, just the naming conventions, how they did not go about creating helper classes, and then you know, a lot of things that are frowned upon, create even creating flow multiple flows uh if for like after save on different objects, right? So not following those best practices. Um, so that was like very hairy stuff that we uncovered there. We were trying to roll out specifically the omnichannel aspect of service cloud, uh, and then just uncovering it. They just had not used some of the more common best practices which anyone should have ideally used.

SPEAKER_01 26:15

Let me ask you a direct question, Pranav. Um you personally think GSIs have a place in startup environments. Uh, you've worked in a few, um pretty much all your career, right? So uh dating back from Slack. So um, do you do you think they have a place in startup environments?

SPEAKER_04 26:35

From my experience, unfortunately, I don't think they do. Like they they just don't gel well with startups. So they definitely need to do some sort of an overhaul on specifically startup environments. So in my in my 15 years of experience, having gone through this in multiple other companies, it's just always been, man, we wasted so much money, and this is the output that they gave us. Like, we could have just done this ourselves in a week with our specialist team and done something better, right? So in prior roles, they would come in and do an assessment of our implementation and tell us, you know, what we need to do. And then the reader was like, like, is this it? Like, did they just spend like three hours doing this and then gave us this after a month? Uh, so they just don't go deep enough. And because like startups are companies who are strapped on cash, they every dollar is important for them. So it can't be like, oh yeah, 500k, it's fine, it's nothing for startups. That's a lot of money, and we expect more from that level of uh investment.

SPEAKER_03 27:48

So so where do you think you draw the line? Like how how let's see, what size company do you think you should kind of switch over to uh to to GSI or or just a line, like a small company should use smaller SI, and the smaller the company, the smaller SI, and the bigger the company, the bigger the SI. They just try to line? Like how how do you yeah?

SPEAKER_04 28:09

I think companies that are very there comes a point when companies are reached a certain level of maturity, right? So um, like being an enterprise architect myself, every company is in a given maturity stage where the business, there's a business process maturity, there's a governance maturity, and all of that. So typically companies who go IPO, who work in a certain framework, have very specific roles and things defined. I think for those companies, they are more of a better fit because it just kind of then it becomes kind of like one size fits all for them because certain assumptions they make are already in place. So yeah, companies that have been IPO or they're more public have been doing that for a few years, is where I so just to follow up on this.

SPEAKER_03 29:06

Um you guys were a tech company, right? So I would assume your technology processes are pretty mature, right? Um, I I would think that the tech startups technology processes are more mature than like a mid-sort mid-sized, I don't know, SOC company.

SPEAKER_04 29:22

Um, you would assume that, but that's what sometimes with startups you do end up having tool proliferation, uh, right? When people who feel like, oh, this is a really nice, shiny app, and I need to get it. Uh so when you don't have more of that governance, like things like a COE or anything established, then this tool proliferation happens. And that's what ends up happening with startups, is like people just feel like I need to get this tool, this will do this for me, but they don't look at the overall tech stack and compatibility. So that does happen more in uh early stage startups where uh that if that governance doesn't exist, people end up buying more things than they need to. You know, you'd be amazed like some people just put their own personal credit cards and then get stuff done in in companies when when there is no certain level of governance in place.

SPEAKER_01 30:16

True scrappy startups. Um you gotta love it. Uh love hate, I think. Um I've got one question and then we're gonna move off the GSI piece. Um, but I'm curious to hear your thoughts. Um, why do you think so many startups use GSIs then? What is the appeal of using a GSI if we probably all agree maybe startups aren't the best place for a GSI? Um, why do you think so many keep going back to them?

SPEAKER_04 30:48

Um, it's at the end of the day, marketing, right? So we have a brand and they sell a vision to founders and CEOs where they're like, this is what we'll get done for you guys. So uh just the thought that a company can come in which is well reputed and can build things for me faster, and then they'll be done, and my things would be in place, and I wouldn't need to spend more money in uh hiring more people, right? So that's kind of what what gets sold to many of the startups. Um in some cases it may succeed, but in all my uh experiences I've had, it has not really gone so well. Uh, and that's where like me personally is like homegrown talent and then working with specific, like you know, more boutique, Salesforce shops, people who know what they're doing and are more passionate about helping startups uh succeed, are what's what's best worked well for me.

SPEAKER_01 31:49

Understood. You mentioned uh a few moments ago Salesforce signature success. Um, there might be listeners that don't know uh what Salesforce Signature Success is. My understanding is it's basically a 24-7 365 technical support, yeah, provider relationship engagement. Um, where they will, you know, you you guys will escalate issues, uh P1 issues to get resolved 15-20 minutes, something like that. It's quick ad hoc support. Is that is that the case?

SPEAKER_04 32:20

Yeah, uh it is a level higher than premium support that most customers now have. Um so yeah, signature success does offer that as a feature, but it also adds more many more things to it. So yeah, for companies, I I would say it's not recommended for all companies of all sizes. You need to be a company which has you know which has a lot of dependency on Salesforce, where it just cannot go down for any like with even for like five, 10 minutes. So you need to be at a certain level of you know where you are, how many processes are in Salesforce and how impactful Salesforce is for your company. Uh, for us, that was the case where we just did not have the luxury of uh our instance being down at any point of time. With signature success, you do get a kind of like an extended team member assigned to you who will ensure that if there is a SEVON, in all my experience with them, they've been able to get a Salesforce engineer within five minutes to it, uh, to a Zoom call added and then figuring out what needs to happen. So for a company where things are critical, that's invaluable, like that really adds a lot of value. It is a paid service, of course, but then you find the ROI when you have such things happen. But what many folks also don't know about signature success is they do a lot of what we call proactive alerting. So obviously, Salesforce has more access to information about our instance. So they do have more certain level of threshold alerting. For example, if you're going to reach a governor limit, instead of us getting a message when you've hit the governor limit, it can we can set thresholds. Like if I've consumed 75% of it, then it can trigger like a warning or critical alert. So that can then tell my team, like, oh man, we need to cut shut down some jobs or something. So then we can save a set one. So it can prevent set ones from happening. And then the best part, which I loved about signature success, is you get access to Salesforce architects for your initiatives. So you can have any N number of engagements, they are time boxed uh for like about uh four to five weeks, but they can come in, look at your process, look at what's happening, and then tell you hey, this is the best way of doing it. This is our deck. They create really good uh flow diagrams, lucid diagrams, uh, and help you understand where to go. So that that adds a lot of value if you utilize them the right way.

SPEAKER_01 34:57

I think the key there is utilizing the right way, right? Um for sure. Uh could be expensive if you're using them for basic admin uh troubleshooting, but used correctly. Um, I think they definitely have a value. Um sounds like your experience has been positive. Um, quickscale one to ten. How um how ten being absolutely I'd recommend them, one being pass. Um, how would you rate uh your experience with with them?

SPEAKER_04 35:24

Um given the stage a company like ours was in, I would say it would be a nine. Um and then as you become more more and more mature and you have more uh controls in place, then then it wouldn't be like a must-have, then it goes down. But as of now, for me, it's a nine.

SPEAKER_01 35:42

Fantastic. Well, if anyone uh is listening and goes with sales for signature success, let them know that you heard it here on the podcast. Um but um that that's uh good to know. Um switching slightly uh topic, um, talking a little bit about you know um the morale piece. I think this is a you know, your experience is not necessarily unique. Um, you know, it doesn't make it any easier to navigate by any means, but you know, a lot of people leaders come in um and they face a sim similar scenario. Um, you know, maybe it's not because of a GSI, maybe it's you know it could be a whole different bunch of reasons of acquisition, merger, um, you know, company performance in the market not doing as well, um, natural disasters, you know, whatever disasters like you know, pandemic impacting impacting things, right? Um so so just talking a little bit high level about some of your leadership beliefs, you you inherited this team, 25% of the team had left. Um how do you personally show up as a leader when morale is at a level low, um, all-time low? How how what do you do? Right? Um, because you know, you you might be thinking, you know, shit, have I taken on a job where maybe this is out my depth? They told me things were bad, but they didn't tell me this is bad, right? And I'm losing members left, right, and center. How do you show up in that environment?

SPEAKER_04 37:08

Yeah, uh, I show up by kind of one, like being empathetic of that situation because it's something I've also personally experienced. So I take it as like if I were in their shoes, what would I be feeling, right? So kind of like putting on the therapist hat to an extent, some of those sessions when you have with the team and you are have those one-on-ones. Uh, one is you know, trust is not something that can be taken, it has to be given. So you have to first come in with not come in as someone who's aggressive and like, I want you guys to do work in this way, I want you guys to do this, I want these results. It's more of like um, you know, approaching it in a in a more open and cordial way. We're trying to understand and share my prior experience. I would say, like, you know, when I was there in my prior role, this is what happened, and that kind of sucked, you know. I just did not have great managers who understood Salesforce and they would expect me to roll out functionalities. Uh, so that just helped people understand like they they can talk to me about a technical problem as well, and then at the same time say that like people don't understand how complex this is, it's not as straightforward as just deploy everything in one go and why does stuff take so long to do? It's them understanding like you guys can tell me what your problems are, and then we go from there. So just having that approach, uh, and then also talking to our stakeholders and like just setting the expectations there. Like, guys, you know, we are a company that's trying to do these many things. We have to have a certain level of maturity in our processes too, right? We have to define roles, we have to define boundaries and how our team operates. So it's also educating them. This is Salesforce teams, or it's like an engineering team. We have a certain way of doing things. We also need we need to be given you know requirements in a certain way. This is our process, QA is absolutely important, things need to be tested, and this is what it would be, right? So a lot of it is then being kind of again uh build the relationship with our stakeholders and telling, you know, this is my background, this is what we've done, and then a lot of talking for sure, a lot of conversations, and then then you need to walk the talk as well, right? You need to do things, you need to set up uh uh things in place. It's like we need to, we did not have architects back then. The concept of solution architects did not exist. So I brought in those roles, I created roles because it was all engineers, all developers, right? We did not have any senior admins, we did not have essays, so it's telling them like we need these roles, get the exact buy-in and then hire for those roles. And then as architects came in, people saw the value, right? So it did not change overnight. It's just initially, it was just asking the people to have their faith in me, give me some time, and just say that in three months this is where we'll be, in six months, this is where we'll be. And that showed in our surveys, right? Like initially, when we did the surveys, it was like the team just felt their workload was like 90% of the team felt like their workload was just not manageable. But then when we did the survey again after uh nine months, that was down to now 40% of the team felt that. So it was like people felt that things are improving, and as they said as we set the boundaries.

SPEAKER_01 40:35

How do you navigate the balancing act between giving employees a voice uh to air their concerns, frustrations, challenges without creating an environment for complaining?

SPEAKER_04 40:50

Yeah.

SPEAKER_01 40:52

For the sake of complaining, right? Complaining for the sake of complaining. Yeah.

SPEAKER_04 40:57

I mean, my philosophy is people who are in in this role, people who have joined us have a certain level of professionalism, right? Like I expect them to be professionals and work that needs to be done needs to be done. So there's no question about that. If there are things that are hindering them from talking, let's talk about those. But when you talk to people and you get some of those feedback, you can cut through what is like BS, and people just need to kind of either they need to grow up off so of sorts, right? So, in mostly, like I I treat people with like they expect you expect them to be at a certain level, you expect them to be professional in that sense and not just be in that complaining mode all the time, right? If people are those, then you just tell them, like just give them direct feedback. Like you're in this role, this is what's expected. Uh, and you have all the means to be successful, and this is what's been done. If you're still seeing issues, let's stop, but you know, then you have to be direct and upfront about those things.

SPEAKER_01 42:02

Are there any indicators that you keep track of uh or metrics that to keep a porch check on where is morale in the business? Right? I know it's something you you're priding yourself on keeping the levels high. Um what do you keep an eye out for?

SPEAKER_04 42:20

Yeah. Uh like smaller things, like are people participating in demos, right? Like, are people showing, talking about their work and coming into those meetings and doing a demo of their work? Um, and just how is their engagement in team meetings? Like, are they you know turning on their video and then being more active and kind of sharing some of those things? So those are indicators. Like, how is the team doing? Am I seeing folks sharing enough? Am I seeing enough comments come in Slack? Uh, am I seeing enough demos from them? So those are some things. Um we do track like PRs and all of those, but me personally don't believe like how many PRs submitted is actually a sign of uh how invested they are. It's just more of like the work that's getting done. So there's a difference there.

SPEAKER_01 43:15

And then I guess in terms of um defining success from a morale perspective, um, you know, morale, you mentioned surveys and redoing the surveys. Morale is not really a KPI people talk about, right? It's uh sales, it's retention of employees, which could be to an extent to do with morale. You do the surveys, um any any metrics that you look is it as simple as, you know, well, nobody's left, so our morale must be good. Um or are there other indicators and metrics that you you know you you check on a quarterly, yearly basis, maybe in your reviews to you with with your leader, right? That you're being discussed about in the one to one?

SPEAKER_04 43:57

Uh it's it's through peer feedback. And other stakeholder feedback, right? Like, for example, one of uh the feedback that I got from uh one of my team members in in prior roles was um whenever I wake up, I now feel motivated to work. Versus earlier, it just used to be a dreadful task of me opening the laptop and then kind of getting to work. So it's more of like that unstructured feedback on like how things are going. So internally we use a tool like Lattice to capture some of those feedbacks and then uh just the sense of like how are people showing up. So, for example, for certain admins, the feedback we would get from stakeholders was they were just so invested in making sure I was set up, you know, for success, where they just showed up more differently. So those are some of those kind of like not direct KPIs per se, but receiving feedback about your team on tools like Lattice, uh, and encouraging people to just share, you know, either private or public feedback about their team members, are some of those indicators that I've seen work well. At the end, it's more, it's it's no one size, like one solution for all of it. It's more of like you definitely need to have a pulse of it. So it's not very like I wouldn't say this is a fixed way of doing it. It's it's a mix of trusting your team and then seeing how they show up and then getting feedback from their stakeholders and how are they showing up? Like, do you see any improvement in their engagement, uh, any improvement in their communication and all of that?

SPEAKER_03 45:39

Um, you mind if I ask, is your team on-prem or remote? What's the on-prem remote mix?

SPEAKER_04 45:46

Uh, it is mixed. We do have an office in the uh San Francisco area, um, but it's spread out throughout the US. So as a team, we come into the office like uh once or twice a week. So it's kind of hybrid in nature. Uh every quarter, we do all of us meet in one location, so either in San Francisco or in Denver. Um, so we make it a point to have some FaceTime with each other, but primarily on a day-to-day basis, it's kind of like it's you'd say it's remote. But they're in the same city? So they're see they're coming in.

SPEAKER_03 46:31

Okay, so tying back to our topic, like how how does that pose a challenge with with like gauging morale? Because it's hard to know somebody who's not in the office if they're checked out, right? Obviously.

SPEAKER_02 46:45

Yeah.

SPEAKER_03 46:46

Um, and you can't do things like, hey, let's have a happy hour or you know, let's say a quick pat on the back and passing, even.

SPEAKER_04 46:54

Yeah, I mean, that's where those quarterly uh things would help to make sure everyone felt heard and kind of like you would treat them too, like you know, dinners and stuff. That's the smaller things, but then even like for very small things, people who are like on East Coast compared to folks around West Coast, it's like just update your Slack message and say what you're doing, or like dropping off, picking up kids from school so people know what's happening, right? So it's just doing small things of like half of the time, people are like, is this guy working or not? Again, you should just not have that at the back of her mind. You just expect them to be professionals and do the work that they're assigned. How they do it is up to them. When they are needed in meetings, you just make it absolutely clear that you're required in those meetings, try to be sensitive to their times. But if it's ad hoc, you just expect them to be in those meetings, even if it's off hours, and that is occasionally. Uh, use tools that you have, right? Like just update your Slack status, say I'm out or this time is personal time or others, and people then understand.

SPEAKER_03 47:55

Right. Um, the other point you made, which I think is um it's probably super I don't say misunderstood, but it's not recognized enough, which is which is positive feedback. Um, and the impact on morale, like people who feel their work and appreciated will like continue to do um better work and will definitely be happier uh doing it. Um, but that works well, assuming the business is really happy, right? Um so like in your case, the business was not happy, the system was let's say not that they expected, and then you told them we're gonna take a step back and stop making any kind of improvements and fix foundational stuff. Um, I can't imagine the business was thrilled with that, and even if they were accepting of it, they're not really gonna be giving you know positive feedback. Hey, your change made a massive improvement, right?

SPEAKER_04 48:52

So I mean, we did not fully shut off all stream of work, right? Again, it's again you are you are still building a plane that's flying, so it was more of instead of just half a person's time focused on foundation, we gave that more more support, like give four people assigned to it, but then you had still about eight team members that were focused on it, right? And that's why we went. Uh we do have a lot of contractors that work with us pretty much full-time to make sure that this stuff still gets done with oversight from tech leads to ensure they are not bringing something in our architecture. So we had to find that balance. The balance was not there was not a lot of focus on the foundation.

SPEAKER_03 49:40

We just had to get it, I get it, it's limited, but still the business wouldn't be right, let's say super but though getting back to that point. Like, did you talk to the business about providing positive reinforcement? Was that something that was proactive?

SPEAKER_04 49:58

Yeah, uh, like like I shared earlier, it was those conversations with our stakeholders and letting them know what's the plan. Because it no one likes surprises, right? So it is letting them know for the first three months this is what's going to happen. This is what we can commit to realistically. But other than that, this is what will take us to get to a more stabler state. And for your day-to-day stuff and not your big projects, we will ensure that gets done through our contractors and FTE support that's needed. But then bigger initiatives will just have to wait another six months till we stabilize this. So, again, like having your exec buy-in from roles like CTOs are key because then they are able to influence them, right? So a lot of it is in in businesses, in startups. There is an aspect of having uh the political alignment, making sure people trust each other, and then having exec buy-ins from CTOs definitely helps you with that. So basically asking for air cover and then uh getting that. So for the stakeholders that are like, do you guys want more sevens? Do you guys want to have uh customers trying to call you and not being able to reach your agents? Like, is that something you want to continue having? So them understanding, like, oh shit, like for 10 years we've been kind of doing stuff and no one has really taken this lens, and they would get it, right? They also get the the folks who've been doing in this space, they understand like how technology works, um, not thrilled about it, but then it's the nature of the role.

SPEAKER_03 51:37

Um, so going back to the mixed teams, right? So you're saying using a lot of contractors, does your approach change when dealing with let's say a full-timer versus a contractor? Your approach to managing the individuals.

SPEAKER_04 51:54

It does. Um FTEs, people who are actually with the company are definitely more they feel more attached to the company, right? They have more sense of ownership, uh, which in an ideal scenario you would like to have more FTEs, but the reality of it is like you cannot have N number of resources. But still, with contractors, also, you also expect them to be more involved and more engaged. And like, kind of like I saw a post which you know you had shared, Kiro, was like a lot and a lot of companies now in this year specifically are moving to that near shore option, mainly because of the fact that they want people to be in the same time zone and be in meetings so that they can have ownership. Offshore models work, but then if you have to wait for every Jira ticket comment to come back and then work just gets delayed there, it's a model that works, but again, having the right mix for the right roles, it makes sense. Uh, so for contractors, also, you need them to feel empowered that hey, you also have a manager. Uh, at Gusto, we call managers PE, which is people empowerers, uh, who can help you navigate whatever you guys want to do, uh, and also have one-on-one. So, my directive to my engineering manager is like have the one-on-ones with your contractors as well on a weekly basis to make sure they are doing well and they feel supported. Uh, it does obviously change when it's an FTE. If FTEs definitely get more focus uh on other things, but with contractors, we just don't like hire them and forget about them, right? There is an aspect that we make sure that we check in with them.

SPEAKER_03 53:42

Okay, cool. So um and what about like just general career planning? Any any tips on that for your employees? Like, how do you decide uh who you feel for better or worse needs to shift roles or get promoted, or if you want to bring a contractor uh in-house or bring someone offshore over, sponsor them? I don't know.

SPEAKER_04 54:10

Yeah. Uh yeah, career progression is something. So you need to map out what are the different roles in this ecosystem. So the main roles are a Salesforce admin, a senior admin. From there, you can become you can go towards a solution architect track or you can go towards the BSA track if you want to be more functional. So uh, and then you also have the developer tracks. Many admins can take on either of this uh career track as they become more senior. Typically, senior admins as they kind of evolve and are have been doing that for many years, try to become more on the solution architect side because they want to be more closer to the architecture and still be relatively hands-on. Uh, for developers, uh, senior developers can kind of continue that path, you know, after you see reach certain levels, uh they take on more of the responsibility of team leads and making sure there's proper oversight in terms of code quality. So just defining a lot of those, uh, then just making roles like technical architects also available for senior engineers that they can have a more broader scope of work. So, all of that is something you define, you put that in paper, set kind of like general guidance on like what it means and what we expect for these roles to be. Uh, at the end of the day, there also has to be like a business need for it. Um, contractors is more of like how much volume of work are we seeing from our business coming in, right? So just factoring in that, so that involves a lot of planning, budgeting, and all of that. So we try to get ahead of it when we just don't have hiring FTs takes time. So if something needs to be done ASAP or has a very short time frame, that's when we go with uh hiring contractors uh and and get that short-term work accomplished. Does that does that answer your question?

SPEAKER_01 56:10

Yeah, of course.

unknown 56:11

Yeah.

SPEAKER_01 56:12

So so Pranav, um your team's about 40 people, correct?

SPEAKER_04 56:16

Yeah, 40, including FTEs and contractors, yes.

SPEAKER_01 56:20

So uh we're definitely, you know, uh also just echo what you shared. Uh this year our con the contract demand has has increased significantly, and especially um an appetite for contractor hire as well as near sure uh as well. Um with a contractor, what at what point are you thinking it makes sense to keep this person in-house uh full-time? Um I get certain projects might require a certain skill set, and it might not be, you know, uh it might not make business sense to retain that resource if they have a niche skill set, um, or from a cost perspective, it might not make sense. But at some point, you know, I think you know, retaining the knowledge and somebody that already knows the business, fits in with the culture, the team is aligned with that individual, there are obvious benefits there. You know, every high is a risk, but if somebody's already into your in your org, um you know, it's a low risk, right? So what are some of the, you know, very quickly, what are some of the signals that you look out for uh if you're thinking contracts higher? What are the type of signals that you look out for? What are type of individual traits that you would be more inclined to convert someone to full-time?

SPEAKER_04 57:32

Um yeah, from specifically on the trades perspective, is the ownership mentality? Like how do they show up in meetings? How are they taking up the work? And then in terms of um like how do we decide someone needs to be like a contractor versus more of an FTE? It's like is the amount of work that's gonna be coming be continuous for like six months to a year? Like, how do we envision that work to be and if it's going to be continuous maintenance? And we know it's gonna be there for like at least a year, and we know we don't have budget for like hiring people, but we have budget for contractors because there's a separate budget for each of those categories. That's when like first preference is to hire FTEs, but then if you have contractors who uh are available and have been with us for longer and can potentially convert, then you just look for their communication skills, their ownership skills, how are they showing up in meetings, how are they collaborating with other team members and all of those kind of those skills?

SPEAKER_01 58:41

We're seeing a trend, as I mentioned, for Motorman for near shore, uh something we talked about uh pre pre-podcast and drawing. Uh, we just touched on it slightly. Um it's not something that's necessarily new to you. You've managed uh near shore and offshore teams. What have you found uh that works well and also what has been like a lesson learned that maybe something didn't work so well when managing teams across different time zones and in different geographic locations? And then the follow-up question to that is how do you create a culture of inclusion, uh, an ownership uh for offshore and near shore teams?

SPEAKER_04 59:17

Yeah. So for an offshore model to be successful, there needs to be also the relevant roles in an offshore uh for those offshore team members, right? Uh having an offshore engineering team only and not having anyone from product or BSA in offshore hours makes things more uh uh more frictional, right? It just adds more uh more time to tickets, more time to getting stuff done. So it's kind of like finding the right balance of how many offshore team members do you truly need? Should you have more heavier on offshore than near shore? So that decision comes in like what's our process of getting work done, right? So near shore works because then people can be in the same time zone, attend those meetings, and don't need more hand holding or specifically very well-drafted Jira tickets for them to work on. So that's where having near shore adds that value where they can have more velocity, more ownership. Um then to kind of for the offshore model to work, you need to have kind of like some level of team meetings which are more conducive to their hours, right? So having like okay on a monthly basis, having a 7:30 a.m. or an 8 a.m. meeting on Pacific time is something you can try to do, right? Like it's not something you can ask the team to kind of try your best to log in early, have some sort of a connect with those teams and see it. Umy offshore teams, which is kind of unfortunate, but they do mostly extend themselves and are available later in their nights. So if they are have a fixed schedule, then we just align on a time, which is like not crazy hours for them, but still a decent time for them to make sure they are in the standups. They can do those stand-ups with like talking versus just having Slack updates or Teams updates in them. So just making them more engaged, hearing them helps in that model. And then it just becomes on the type of work that's needed, and that'll help you in making the decision. Should this person be near shore or offshore?

SPEAKER_01 1:01:33

Yeah, it must be difficult with the PST piece. Um, obviously, MAS on East Coast and Um Central for you know customers, you know, it's it's it's a big, it's another two hours difference, right? It's it's difficult. Um very quickly, one one more question on the um onshore, near shore piece before before we wrap. Um, what roles do you think are best suited to be near shore offshore versus onshore? And what role should absolutely not be near shore offshore?

SPEAKER_04 1:02:03

Um roles like um product owners, product managers, BSAs should not be near shore offshore. In my opinion, they should be more closer to the stakeholders. Uh, those should definitely be, you know, where where the store stakeholders primarily are. Um roles like general help ticket triage, administrative help, like L1 type of support, those are good for being offshore, in my perspective. And then uh roles that just require a specific level of work where you have uh work clearly outlined as a Jira ticket where developer help is needed, those specific roles can are also good for offshore. When you need where, and this is again applicable to many startups where you have stuff that needs continuous iteration, things are changing, you have to be more agile. Uh, in that in that uh working model, having near shore is a better alternative because it's costly, it's from a cost perspective, it is definitely cheaper than having folks onshore. Um, and then onshore is when you're just having a really critical function, right? Like, for example, if you do not have anyone who's managing telephony and someone that is something that is needed definitely at that point of time, and you do not have any FTE support there, that's when you would get someone you know onshore as uh as a function, right? But depending on the criticality of the work that they have to do.

SPEAKER_03 1:03:46

Awesome. So uh we're just about at time, unfortunately. Um so last question. What's next for I guess for Gusto uh or yourself, anything within the the Salesforce uh industry or space you're super excited about or or big plans and implementation?

SPEAKER_04 1:04:06

Yeah, I mean, of course, uh AI is definitely impacting so many things, right? So even at Gusto, uh we are an AI-first company. So that will have overall impact, and I think that'll have a lot of impact in other companies as well, especially in this space of uh business systems, enterprise systems. So I see the future of uh a team like these becoming still more leaner, but still more impactful, right? So uh the pivot for someone in my role also is like we've been doing things in a certain way now that we have access to we have engineers in our org, we have access to you know uh AI technology. What does a new Salesforce implementation now look like? How can we not be um a huge team overall? Like not saying numbers really matter, but still like a leaner team, which then does more for the business and is more productive. And then you're part of like uh kind of the whole AI strategy, right? So it is it is definitely here. It's for everyone that I tell my team also is like we all cannot be just be complacent in where we are, things are evolving. We just need to then find the right overall skill sets. We need to know how LLMs work, we need to know how integrations work, how can we do more with less? Uh, I think that's the general theme that you'll be seeing happening a lot in our spaces, and we just all have to kind of embrace that and you know, just make sure you keep up your learning. Learning never stops. So that's something I always tell my dealing. You should never stop your learning process, and that should be a continuous journey. And that that applies to me as well. So that's kind of what we're you know, company like Custo is also headed towards is embracing AI in all of its areas from from you know uh from our customer perspective. Uh, if you've seen we've launched Gus, which is like an internal AI tool for Custo to help our customers, and then we're then embracing that on how we can do that more for our internal team members as well.

SPEAKER_01 1:06:28

Awesome, super exciting times. And uh, you know, for anyone that's gonna be at Dream Force, maybe they can hear a little bit more about that. Uh if they get the chance to uh come come and see you in person, uh, I'll be there. So uh we'll definitely uh pick up brains on how that's going. Um Pranav, that is that is a wrap. So we just want to say um a big thank you for uh joining us um and talking about uh your your experiences at Gusto over the last hour. Um thank you.

SPEAKER_04 1:06:55

Yeah, thank you so much for having me. It was really nice talking to you guys and yeah, great questions.

SPEAKER_01 1:07:00

Thank you. Um for our listeners, uh don't forget to subscribe to the CRM Success Show for more episodes featuring leaders like Prinav, um, who are truly shaping uh the present and the future of the Salesforce space. Um you can follow us along on LinkedIn or alternatively watch along on YouTube. Until next time.