SPEAKER_00 0:01

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_04 0:28

Welcome to the CRM Success Show, where we deep dive into CRM success and failure, delivering real stories with real impact. I'm Dave Mastery, and I'm Kira Witze. And today we're talking with Anto Linderman, the former VP of CRM at Members for Us Credit Union. Welcome, Antu.

SPEAKER_01 0:45

Thank you for having me.

SPEAKER_03 0:47

So Antu, um we've known each other for a few years, but for those that maybe are hearing from you for the first time, give our listeners a bit of an overview about yourself, how long you've been in the Salesforce ecosystem, and what you typically do.

unknown 1:01

Sure.

SPEAKER_01 1:01

I've been in the Salesforce ecosystem since about 2008. Um I've usually been on the uh client side, so I've been uh end user of Salesforce managing the system, uh admin solution architect, salesforce leader, VP, you know, executive, whatever you want to call it, um, running implementations from the client side. I've also worked at Salesforce itself for a few years, um, and that was more consulting work.

SPEAKER_03 1:30

So nice. And so some of the companies that you've had the pleasure of supporting um as an FTE or during during your time at Salesforce?

SPEAKER_01 1:41

Um like I I was in uh two main areas, health and uh manufacturing, or in I did a little bit in like um um the financial services area, but which led to me later going into financial services um for members first. But yeah, um had a deep manufacturing background coming from Textron. Um but I pivoted into HealthCloud as that was a big growth area for Salesforce at the time. They wanted people to um really help them grow their health cloud expansion at the time. Uh so that was a totally unique experience for me. And I worked with several cancer companies that were using Salesforce to handle um their cancer patient intake and um scheduling reimbursement, all that sort of thing.

SPEAKER_03 2:36

So awesome. Um so I know one of the topics uh we're gonna cover today that you're passionate around is really defining what an actual implementation process looks like. But before we get into the nitty-gritty of that, do you want to just kind of give us an idea of perhaps where your passion around that topic comes from by just giving us an overview of maybe some of the frustrations you might have experienced along the way? Certainly.

SPEAKER_01 3:06

Um I would say out of all the implementations I've done, uh Textron, um when we did it at Textron Specialized Vehicles, which is a vehicle manufacturing, probably the largest golf car company in the world, um, that was the first time that we ever implemented a system where I felt ground groundwork was done. Um I was in place before negotiations ever occurred. Um and it really prevented a lot of the issues I would see later. So, for example, uh at Howard Hughes or at uh members first, I would be brought in long after that ship sailed. Um, you know, the things that that can cause is nobody understands the licensing model they signed up for, nobody understands the shelfware they have. Um, you know, just just let's let's talk about that. Poor licensing strategy. That that's your direct pocket. Uh that that hurts your pocket. Any company that doesn't have somebody who understands Salesforce licensing costs, the model, the licenses you need to use, what you'll consume. I mean, you're you're basically spending money that's just gonna sit there and rot. Uh also it's not gonna make the users happy to have things they they they they can't use, or we're told in an intro that they're gonna be able to use, but it never comes to fruition because you know it oh, you actually bought the starter and not the growth. The growth does that, the starter doesn't, you didn't understand that, you know, on and on. Um so things like that can heavily be mitigated by bringing in an expert as early as possible to do those things. So without that roadmap and that license understanding, uh I mean you you're you're starting to build a house, like I said earlier, uh, with without having an architect that knows how to design houses that you know, so whose fault is that?

SPEAKER_03 5:02

I know um we don't necessarily like to point fingers, but you know, we're feeling a little bit uh quirky today. So whose fault is that? Is that is that the sales is that Salesforce's fault? Is that the customer's fault for being too gullable and just trusting, you know, Salesforce? Is it is it a bit of both?

SPEAKER_01 5:20

Sure, 100%. Salesforce is attempting to push this narrative the whole time that this is super easy, which is a sales tactic, which makes sense. I I understand why they're doing that. Uh, but the the customer, which is the the you know, the company is somewhat to blame because they should know with all their other products they've ever bought and anything else they've ever implemented or anything they've ever built, you can't do that without some expertise. So trusting Salesforce to tell you this is gonna be so easy, it's gonna run itself, and you can have a few people do this part-time. I mean, it just look at the price tag. If you're spending under $300,000, like you're getting a small system, maybe that's true. But if you're doing a true, like if you know you got senior executives involved, and this is a five million, a two million dollar you know implementation plan. I mean, just think to yourself, would you launch a five million dollar product anywhere else and and believe it's gonna launch itself and you're only gonna need a few people and a small implementation partner to make this a success? No. So that fault is on both people for being gullible. And I and I honestly believe most executives I talked to, they didn't believe it, but they went with it because it made the business case solid to not put in a bunch of cost that they then figured out they needed later. But to me, that's you know, penny wise pound foolish. I mean, why why do something like that to yourselves? It it always causes undue burden and and and stress on everybody involved to do that.

SPEAKER_03 6:57

So do you think there's an element of uh FOMO for want of a better term? And you know, well, our competitor use Salesforce, so we must use Salesforce. I mean, look, we all made our career in Salesforce for the most part, right? Our recent career. So it's a great product, great people, and so on. But how much have you seen of that potentially, like, you know, well, our our biggest competitor, direct competitor, they're on Salesforce, they they're innovating, so we also better get ourselves on the platform.

SPEAKER_01 7:25

No, I mean, and that that is also a valid thing. I mean, um, I I know other credit unions. Um, once we got on Salesforce, would literally call and ask. I mean, we credit unions are probably one of the more um willing to share. Like if you're in the banking industry, banks don't talk to each other. It's dirty word cooperation, don't cooperate in any way or or talk. But credit unions actually are pretty cooperative uh group. And I was actually surprised by the amount our senior leadership was open to talk to other credit unions uh at a high level, and uh that FOMO is real, it's not just it's not just that business level, by the way. You'll see that same fear missing out within the company. So you're you're doing, let's just say you're building out right now for the leasing department or some financial services group. Pretty soon you're gonna have a line of, you know, even if you decide to start with a small group, you're gonna have a line of the other departments that feel they're missing out. Why am I not getting Salesforce? Uh why is my why is my department not on the list to get Salesforce? Um, so it's a powerful motivator. Um, and it's often valid. Now, sometimes you do get pure hype trains of of uh things, uh, and um sometimes you gotta watch out. So, you know, if somebody's pushing you to that they want a product that doesn't make sense, you're like, hey, this isn't really the roadmap. We have a roadmap built out, you know, you really need a powerful business case uh for just FOMO type uh anxiety to purchase a new product to go a new direction. Um, I mean, I have uh, for example, I experienced some of the same stuff with uh the AI. Uh, we didn't have uh clean data um for the use of an AI. I let them know that really we need to go on a data exercise first. And they really wanted to push um, we need data cloud, we need AI, we need to purchase this now, let's drop money and do that. And I'm like, let's let's build the foundation first before we get down that road. So sometimes you really have to, as a leader in Salesforce, push back on those ideas, um, you know, for their own sake.

SPEAKER_04 9:37

So to ask you about if you're working with an SI, right? Um, they're the experts you're bringing in. Um, a lot of people may not realize that often. It's Salesforce that brings them in, and then they have, let's say, a little bit of uh of uh pressure to keep Salesforce happy, particularly not disrupt your sales cycle. Yeah. Um so yeah, what are your thoughts on that? And let's say balancing working with an SI and having let's say an independent or an internal uh decision maker really driving that or doing your own research. Because, right again, when you're hiring an SI, you're like you're hiring them because they're they're the experts. Um any word of caution or advice on that?

SPEAKER_01 10:23

100%. So the biggest thing I could say is if you're trusting your SI partner 100% to make your decisions, which is what a lot of people think they can do, it is not a great idea. Um I'm not talking bad about us. I I love I love a lot of my partners I've worked with. Um often these deals are they'll they they come, I don't want to say pre-packaged with a partner already in mind that the a the AE gives you. That doesn't mean they're the best partner. You don't have to go with that a that that that SI just because they're the ones the you know the sales guy tells you is great. Oh, they've done they've done a hundred of these. This guy's excellent. No, you should always do multiple bids, talk to these people, figure out other customer reviews, because like you said, if they get too involved in the process, that they don't bring up certain things. Uh, I don't want to speak bad at SIs, but you know, they're in a business too. And while you're their customer, they're getting they're gonna get five more of these from the AE. So they can't really piss the AE off. You know, they got to be careful. So, you know, at some extent, you really have to make sure that your SI is truly beholden to you and not beholden to the exact sales executives. Now that can be hard, but that's why I like to as I like to have the deep expertise on my side as well, so I can be in that room when the SI says that's impossible, we can't do that. And I'm like, no, that's not true. You know that's not true. And they're like, Well, I mean it's hard. Well, you didn't say it was hard, you said it was impossible. Uh, you know, and that that's why I also I'm a huge fan of being able to read statements of work. I mean, so many of these executives they just sign off on these statements of work. For example, when I walked into members first and I actually read their SOW, I said, This has so many red flags that that this should just be the flag of China. I mean, this is there, there is eight months of work shoved into six, you know, less than six weeks. I was like, there is no way they can do these things. And you know, the eyes in the room, like, well, this now makes sense because we're X weeks behind, we haven't even finished sprint one, you know, da-da-da. Like you have to be able to read a statement of work and know what's possible yourself and go, well, this is how they're able to beat the other guy's price by six hundred thousand dollars. Is they're either a not planning on actually delivering, or delivering something pre-packaged and hoping you fit in it. Um, like if you see the word accelerators, um that means they've pre-built something, you they're hoping you just fit into it. Um, you know, so they may have flows pre-built or or uh you know something like that, and they're just hoping you can fit into their standard process, which sometimes works, sometimes doesn't. But you have to know what those triggering words are in a statement of work, or you find yourself in trouble.

SPEAKER_03 13:25

I think um the partner piece is super interesting, and we we we've we've covered it a little bit in previous episodes, but one question and or thought, I think, and I'd be interested to hear both your perspectives um because obviously man as you work very closely with SIs and onto, I know you've worked with dozens over the years. Um I think there is a general feeling in the marketplace today that it's become a bit of a popularity contest, right? Um, you know, it's not the best performer that is often picked, it's the one who shouts things winds and nines the most, right? Um and combine that with a lack of proper due diligence when letting somebody become a registered partner, right? Or credibility, uh just pay your fees, and you know, you become a partner and get X amount of service, you get different rankings, right? I feel like that model's broken, right? Um, and often when we speak to these customers, the it's on both sides. I think you nailed it by saying it's an equal responsibility, right, between everyone. The truth's always somewhere in the middle. Um, I'm a big believer in that, but I think there is a lack of standardization for partners at the moment, um, and where the A's are referring partners, right? What's your thoughts on on that? On two, and then Maz, if you want to chip chip in.

SPEAKER_01 14:50

Yeah, just to hit on that last part. So um, you know, not to spill the secret sauce, it it it almost feels like having been involved on again. I was uh I was on the delivery side, not this pre-sales, but it a lot often it seems like it's just an I don't want to say it's a random number generator deciding which partner's turn it is. Um but obviously there's some relationship built into that, uh, that they occur. And you know, if they have a specialty, they tend to recommend them. Um, but I'll tell you honestly, the partner doesn't, I mean, the partner matters, but it doesn't. Let's just say that. You could be Price Waterhouse Cooper or Deloitte, and somebody's gonna go, wow, I have the big boys on this project, it's gonna go great. They can still send you the C team. You're looking around for that architect that was there in the pre-sales meeting, and the, you know, and you're like, where's he at? Uh, you know, they they sent me four college grads um that you know, still trying to figure out what the setup menu is. You know, so it's it's not just about the partner. You can't just say because I have PWC or price, you know, or or Deloitte or Solemn or or any number of these great partners that exist out there and say, you're set. I can now trust things are gonna go well. Just let the train go to the end of the track, everything's gonna be good. Uh what I do is I vet the people they're gonna put on my team. I want I want to see the names, I want to see resumes. Uh, you know, obviously I'm not for all intents and words, I'm hiring them, but you know, I just gonna I'm gonna tell you if this architect you're sending me isn't gonna work for me. Uh you can tell me you're sending me your best, but I'm if I'm gonna sign a statement and work with you, I want to know who you're gonna sign to the project. And I know there's windows uh involved in that too. Like, so you know, they can tell me these are the four people, but if I drag my feet three more weeks, I'm not gonna get those four people. I I understand that, I know how to move fast. Uh that's a super important piece to me. But if I can't vet those people, I don't trust the partner. I mean, it's not about just trusting a partner, so it's about the people they put in the project, it's about knowing whether those people can deliver because ultimately at the end of the day, the best thing a partner gets you is the trust that they will make the effort for you to make things right. But the people at the end of the day are the people who are gonna make your your implementation or your system successful.

SPEAKER_04 17:17

Yeah, yeah. So to chime in on this, so um, I'm not super involved pre-sales. Um, as you know, I will say that I don't think that there's malice anywhere. Um, I think that Salesforce, the AEs, particularly the experienced ones, they tend to recommend partners who they know have done a good job in the past in a similar industry. I think that's their number one criteria. Um and they they do that because they want you to stay with Salesforce and get the recurring revenue, right? Because they get they get continued credit. Um, they also want a partner who's going to pitch a lot of Salesforce services, because then they make um a lot um there is sometimes a contention between you know the there are the disagreements, let's say, between the SI and Salesforce on what the product solution should be. Um, and the client may never see that. You know, they'll if figure out figure it out amongst themselves, I think, and then and then come back to unified story, but you will very rarely see them argue on your behalf to Salesforce. Um, it's almost an impossible thing to do. Um, so I think it's important to understand that relationship. I do think, particularly pre-sale, you're spot on onto, you have to do your diligence on the partner you're bringing in. Um, even if they literally are the best in what they do, if they don't fit with your culture or how you operate, right, they may not be the best for you. Right? Um, and your point with if the contract is low ball or a very low number, um, and you're looking at it as it can possibly be done. Uh again, I don't think that's necessarily malice where they're saying we just want to close the deal and then get them later. Um, I think that's usually a misunderstanding of what you guys need. Um, or a better phrase would say lack of understanding of the complexity of what you need, and they're thinking a simple solution will just work. Like, oh yeah, you can track activity, so that covers your activity needs when you know there's a lot more. So I I think that's a red flag that they don't understand the requirements usually or the or the complexities improper discovery build.

SPEAKER_01 19:31

Improper discovery.

SPEAKER_04 19:32

Well, it's free sale, right? I mean, keep in mind it it's somewhat it's somewhat free work. Um, it absolutely is. Like all of that work that the SI is doing pre-implementation is literally free work, and it's a it's a ton of value, um, even just seeing what goes into the SOW. Um, but at the end of the day, it it's a long sales cycle, sometimes months, and they're eating that cost. So um that's somewhat understandable.

SPEAKER_03 19:59

Um, Ansi, we just a quick last question on this topic before we go back to the original theme. Um, do you ever get pushback from SIs you've engaged with in the past around having to uh around insisting that you want to perhaps see actual profiles or maybe even interview them before accepting the statement of work? Because I know there's a difference between an SI and SNAF org. You know, obviously if you interview someone from an agency, if you get somebody from an agency, you're going to interview them, right? It's common sense, like you know, of course you are, but with an SI, sometimes it's like, well, you engage with a company and you kind of stuck with whoever, right? Whomever. So, do you do you how do you phrase that without insulting them that you don't trust them, but also making sure that you do your due diligence to get the right team in place?

SPEAKER_01 20:50

Yeah. Uh, so obviously, I don't need to interview everyone involved. I mean, you can have your general admins, you can have your analyst. Uh, I mean, again, the sophistication of those roles isn't it to the point where I need to, you know, take somebody's pulse and and get get a good beat on. But if you're selling me a technical architect or even a solution architect uh at those levels, 100% I need to talk to that person. I need to see you know the certifications, uh, the number of times I've been sold a technical architect, and the person has not been doing it long enough to to me to hold a technical architect certificate, or they're nowhere near uh techno architect level. Um, they're just either being passed off as that due to, I mean, obviously it's a huge price increase to be bumped up to it to a TA. But as you know, in this world, a TA is a is a truly um advanced uh position to have. Um you know, solution architect might be a little looser term that's bantered around. Um, but to me, I I just approach it from the position of I mean, these are very important roles, these are very strategic. They're going to determine the trajectory of our system for possibly the next few years. And if you get too much pushback, I mean, you got to make sure you've also structured your contract right. If they refuse to give you names, I mean, that's also indicative of how flexible they're going to be in the future overall. So, you know, to me, that's it's a great start. Like, where is this going to go? If they won't even let me have a name and in any of this information, um what kind of relationship are we really gonna have?

SPEAKER_03 22:38

So yeah, that's fair. It's a test at the end of the day. Um so so look, we talked a little bit about you know, one of the things you're passionate about is defining the implementation process. There's a lot of nuances that go into that. Uh, we just focused a little bit on the kind of AE partner dynamic, but uh I just want to take it back. Um, you know, something that you you you would put pretty high importance on uh is launching without clear objectives. Um we talked a little bit about that, but I know from our pre pre-brief call, you had a strong opinion and a fair valid opinion on IT being the only work stream at the table when it comes to CRM implementations. But your question was, well, why where are the business users? So expand, elaborate a little bit on that for us.

SPEAKER_01 23:29

Yeah. So I mean those two things are tied together. Um, you know, they can be often tied together. So full fully admit Salesforce is a technical system. Uh it's getting more technical all the time, it's getting wider, deeper, whatever you want to call it. Uh but ultimately the day, um, technology doesn't solve problems. So Salesforce is not going to solve your problem. You can't just put a bunch of technical folks in a room and tell them to build the best technical system, and it's gonna be the one that gets used the best, and it's gonna be the best for the business users. So, and now how that's tied to clear objectives is if you really don't have the business people there who have the objectives that end of the day are the money that you're attempting to build with the system. I mean, if you're building Salesforce just to solve a technical problem and you have no financial uh goal in mind, you probably have better tools out there. Salesforce should be making you money. I mean, Howard Hughes, I mean, we redesigned that Salesforce system so they would make it was making them like $650 million, you know, out of just Salesforce being used that they weren't that they were using in paper before that, and they were able to bring it online. So if you don't have those kind of goals where you have like a sales leader in there saying, Hey, it would be so great if I could do this, and you don't have you know your executives going, I need to be able to see my quarterly results by da-da-da. And you just have IT folks in there, you're gonna end up with a very strong, like they're gonna have you probably one of the best data models, and you're gonna understand your your uh branches for your for your uh sandboxes, and it's gonna it's gonna be one of the best technically run systems, and you're gonna have some you know some of the best uh you know code you you'd ever imagine. But if you didn't start with that first piece, that the sales objectives, the the reporting, you know, the the what's in it for them, getting the people that the system is actually meant for to use it just isn't gonna work. And I I just I just hate to see two groups laying tracks and not lining those up ahead of time.

SPEAKER_04 25:34

So yeah, so I mean that's a great point. One of the things when you're doing um early stage requirements or call it high-level requirements, um, there's a balance of I have a project sponsor, right? They're the ones let's say with the checkbook, and they have certain goals. Um, and often those goals, like you said, top-level reporting. I need to know how I'm doing for the quarter, is not something that's necessarily going to drive future adoption, right? It becomes okay, so now this one guy wants a report. So 400 people have to type in detailed notes on every call. You know what I'm saying? Like there's sometimes a disconnect between um the top-level management reporting plus the user functionality for the actual end user, giving them more work for the purpose of management reporting that let's say could negatively impact um user adoption, or at least make them not like it. Um, let's say.

SPEAKER_01 26:37

So uh any thoughts on that, on that kind of balance, or if you just disagree with it, let's say the with them or what's in it for them is the is still has to be front and center in your mind. So you you have to collect all these requirements, and then you have to figure out how you achieve as many of these requirements and these objectives and all these business goals for these executives while driving the most user value as you can. So if I'm presented with a problem where it's just a real world example, I'm presented with a problem where I have a leasing you know executive that wants these detailed notes right here. I'm gonna push back if I've already heard from the business that populating that much information is just isn't how the call works. I'm gonna push back, like, okay, do you do you actually have time to read six paragraphs of information from these calls? Are you actually gonna do that? No, I'm not gonna do that. Uh, I just want to do it once in a while when I click in there. Okay, so you clicking in once in a while to one of these calls and seeing those notes, is that gonna drive enough value for you now to create based on the user feedback? It's an hour extra work for a hundred people a week. Is it worth that? And if they say no, then we we can also look at solutions like, hey, well, I have this tool from Salesforce that will summarize maybe all this text for you, you know, and make it, you know, in a much smaller thing, it takes 800 of these and puts them all into like the general census is X, and they'll like, yeah, well, that costs X. Is that are you willing to pay for that? And if they say no, then that helps solve those kind of decisions. So I mean, Salesforce to me is at the level I I do it often, those kind of high-level discussions more than anything else, is talking about trade-on trade-offs, understanding the way the system works, the art of the possible, all that stuff. So uh at my level, you know, that's those are the conversations I'm having all the time. Because yeah, if if you don't know how to have those conversations and you just do what the executive told you, you end up with a system that may anger the entire user base because you just added an hour of work just for this one piece, who knows how many things else you've added? Uh, you know, so yeah, that that's a constant that that balance.

SPEAKER_03 29:03

So after seeing as many programs that you have over your uh career today, um what would you I'm sure there's more than three, but what are the top three mistakes you see companies make time and time again when when it comes to launching Salesforce and and um you know implementing Salesforce? Just kind of summarize top three top three for our listeners.

SPEAKER_01 29:26

Pre-planning. Uh they it's not done like in detail, like we talked about. Um not having a support model in place. So that's you could say that's pre-planning, but to me, not knowing how they're going to structure their Salesforce team. That could be onshore, offshore, near shore, SI mix, you know, how that's gonna look. And then the third is uh executive alignment. Um and maybe you could say these are all about planning, uh, but executive alignment is really important. I mean, at members first, for example, it started in um marketing and sales. Executive alignment was very aligned, it was a marketing and sales. Midway through, they switch it to IT. Changes everything to your your your executive alignment changes now that the ownership changes. Um, I've seen that in other companies as well. So if you switch mid-stream, it can cause you know ripples. So you just gotta do better planning.

SPEAKER_03 30:30

Love it. Okay, plan, plan, plan. Um, so second topic uh we're gonna focus a little bit of time on uh is around setting up new organization models. Um and we touched on that a little bit, um, but you know, you don't know what you don't know. Sometimes around customers that are doing net news Salesforce implementations or CRMM implementations for the first time. Um we talked a little bit about pre-vendor selection, um, how to negotiate licenses, but but just give us an idea and a little bit more around why a solution architect might be the first handler on an ultra that a business might want to consider. And a little bit about once the system goes live, what does that sustainable model look like? Um, assuming there's a partner dynamic in the equation, and give us just kind of some of your theoret theory around how um organizations should be set up.

SPEAKER_01 31:29

Yeah. For for me, it's a it's a huge piece about what are you about to build? Are you setting up a small org? Is this gonna be you know 500 users smaller? I mean, you're spending a half million dollars, are you spending a million? You're spending five. I mean, that that to me tells you your first hire. Okay. If if you're spending five, two, you know, two to five, you're definitely your first hire. May not be a solution architect, it may be an actual executive level Salesforce person. Um the the titles are often interchangeable. I mean, uh I've been called an architect, I've been called uh Salesforce Director, Salesforce Manager, Salesforce VP. I mean, the it the bigger your org, the higher level you want that person to be brought in sooner. Um, smaller orgs, I mean, if you're under 2 million, um a solution architect is a great first start. Uh they're gonna be able to help whatever executive you currently have aligned to that and help them avoid some of the pitfalls. Um the challenge with a solution architect is gonna be in most of the solution architects um may not be versed in some of the um contract statement of work uh type licensing pieces uh that may be important. Uh so you may have to lean into uh an SI for that expertise, uh, but they're gonna be able to give you um the data model piece, the the true design elements that are gonna prevent problems in the future. Um and to look for a good solution architect, you're looking for someone that already had, I mean, again, not to just speak in cert terms, but let's just boil it down. Like if you were just looking at hard certs and not experience, because that can be harder to measure. Uh, but they're gonna have their admin, their advanced admin, their data. Um, you know, they're they're gonna have probably around three to four certs at least. They're gonna be, to me, uh, they're gonna probably have between four to six years experience at least in the system with progressing roles. Uh, you want to see that progression and roles as well, along with those certs. So um, yeah, that's how I would say solution architect rolls out.

SPEAKER_03 33:43

So now you're somebody that has operated in a wide range of industries, yet we talked a little bit about maybe why companies might favor partners that have the industry experience. Um, where do you draw the balance between you know being an industry SME and you know not having any industry experience? I mean, some would argue well, Salesforce is Salesforce, but then others would say, well, where the implementation is truly complex, it's because of the nuances of maybe the industry or the company and so on, the processes, etc. Um, again, thinking about you know, how do these organizations build their teams around that, navigating that? What are your thoughts there?

SPEAKER_01 34:32

So, where I would say the SI with industry experience is like a requirement is when you're getting into these specialty clouds. Um, so if you're gonna if you're implementing health cloud, implementing financial services cloud, you want an SI that has expertise in that area. That uh because these data models are often different, they often come with tools that are special. Um you know, the I mean financial services has tools normally you would not have access to uh if you were buying a normal Salesforce license, even unlimited, you know, with all the bells and whistles. Uh so you know the the other side of having an industry expert SI is that they're gonna already know your business user's terminology. Um I was actually surprised by the level of um you know disconnect you could see in business users when you didn't use the terms they were used to. Um so to me, it it can be a big deal uh when you're using specialty clouds. Uh but I'm also heavy on the side of that first camp that says Salesforce is Salesforce. I I've uh the the concepts are the same for me. I mean I'm building an object. Um, I mean, I often will actually break this down in Excel terms for for my business users because they love Excel. An object is this, a row is that, a field is this on an Excel sheet. You know, basically we're just putting that here in this cloud. The cloud is other people's computers, you know, uh stuff like that. But ultimately, uh I tend to go specialty partner uh when it is a specialty cloud, um, and I tend to believe Salesforce is Salesforce at the highest level. So I mean, if I walked in and a one partner I just had the experience with, I mean, not to throw partners' names around, but like I had a great experience with a company named Atrium. Uh they're they were a top quality partner. If they came to me on a project and they were like, hey, we've never done um let's say we've never done a financial services cloud engagement, uh, but we really want a chance at this, I would totally give them a shot. So you've you've you build up relationships with people that will go beyond just the pure line of like you know, expert in this industry, not expert in this industry. But if you are getting into a specialty cloud, I still do caution you to look at those people who specialize in that group. So field services one of those.

SPEAKER_04 37:03

Just a disclaimer uh HRM is a client of Gluon, and they definitely do financial services cloud and financial services.

SPEAKER_01 37:11

I was just using an example.

SPEAKER_04 37:13

I actually use a some think that they don't, um that is an area of expertise for them. Um we usually shy away from calling out specific SIs, but uh particularly when something like that. Anyway, all good. Um, so um industry expertise. One of the big benefits I see is not just like the Salesforce config, like they're if they know the industry, they can think through the edge cases. Like, you know, they're telling you, okay, this is the you're telling them this are the requirements. So the requirement sessions will definitely be more um fruitful, I think. I think users also will get a little bit less frustrated because sometimes they they're very busy for their time. Uh, very rarely is a user who's working with somebody gathering requirements from them is given some kind of reprieve from their day job. It's usually just edit or um but I think there's definitely some efficiencies there. And then again, the big one I think is those edge cases that they they'll be able to call them out, like, oh, are you thinking about this, or maybe in the future you'd want to do XYD because that's common in your industry? Um, or could call the hiccup, or if they're familiar with regulatory compliance and um that kind of stuff. So that being said, if you had a superb partner that has no industry experience, you would go with them over, let's say, mediocre or decent partner, like like you like the technical expertise over the industry expertise. Like you think there would be a balance there where the technical expertise to the Jess would over overshadow?

SPEAKER_01 38:57

Yeah, so I I would um just based on my experience that a partner and a team that you've built trust with and and and have had great implementations with, um, I would take a risk with if they wanted to go down that road with me and they believed in themselves, I would definitely take that risk with that partner. Uh, if they've proven themselves over a track record, 100%. Um yeah, um, I've I've I've had uh let's just say other experiences with companies I won't say by name, that were supposedly the best in their industry and um you know highest recommendation from you know all the all the people and they couldn't deliver uh themselves out of a out of a situation that you know at all.

SPEAKER_03 39:49

So fair. Um look, I think at the end of the day it comes down to trust. Um, you know, if you if your backs up against the wall for whatever reason, even the best planned project can have its hiccups. Um, you know, who do you want in that in there with you, right, in that ring with you to to sort it out? So uh, you know, I think I think it it's um if you've got a known entity, there's a lot to be said about that, right? Someone that you you trust will will deliver. Um I want to talk a little bit about um kind of the deployment um post-go live um of teams. So let's say good experience with an SMI, but you know, a customer is trying to build their team in house. Um getting that right and the right mixture of onshore near shore or onshore offshore um blend contract versus full-time contract to Hammer, it's a lot, right? Um so what's your kind of like two cents on you know how to go about that? What have you found that works well? What have you found that was just a disaster, maybe to lean one one way or the other, onshore versus offshore, whatever. But what are your kind of general thoughts and philosophies around postgo live specifically, building your own team, getting that knowledge in-house, and so on?

SPEAKER_01 41:07

Yeah, so most important part is determining your budget. Um, so you're you're obviously gonna have negotiations with uh the CFO, probably whatever whoever also your executive sponsor is, uh, about you know the contribution level, the growth, uh, the roadmap, talk about what you need. You're gonna obviously present a use case on a budget number that you're gonna need. They're gonna come back with, you know, you you tell them you tell them $500,000, they come back with $5. You know, you have that back and forth for a bit, you figure out, you know, eventually you're gonna land on a number, that's when you can start designing your team. Now, some of this is gonna be to me, and this is the direction I go, at least at the executive level, is I need to know my budget first. Um, and then I need to know the company uh culture. So I I'm not gonna go offshore if the company culture is um we we we have to see a person. Uh so I've worked at companies where if if you have a person remote, nobody will interact with that person and nobody will ever you know talk to that person. That person just gets ghosted. So obviously, if I'm in a group like that, I tend to lean, I need to go on-site, folks. Uh, on-site is expensive, on-site can be um more difficult depending on your geographic location. Um, I've I I definitely engage with uh folks like yourself uh for for augmenting my staff and getting new people hired when it's difficult areas because you got to bring in expertise. Uh, a lot of companies will get actually caught up in that. That they want to hire everybody themselves. Uh, we can do it. And I'm like, this is a this is an often hard role to fill already. Uh, we're filling it in a difficult geographical area, and we need a specific person. We need an expertise. So that's obviously one of my big pushbacks early on is being able to use folks like yourself. Um, they they just of course HR always wants to crack at it, but um, you know, I I just I've often walked into like a CIO's office and thrown down here's five resumes that HR sent me, and here's three that somebody like yourself might send me. If you can you see a difference in this, like I'm gonna go through a hundred of these, it's gonna use this much of my time, or I could get these crafted uh resumes and quickly fill my role, and we could quickly be getting moving. Um, there's a cost associated with this. Uh, so again, this is learning some of your HR, but uh ultimately you start getting those people on board, you start determining whether you know, maybe I can have one person on site, I can then do uh a near shore person down here, and that'll save me X. Then I have enough money for a staff odd group out of you know, with this company here, and they'll be able to give me 25 hours uh a week um of This kind of dev or this architect, and then that allows me to do this and that. So that's the kind of work you're going to do. You're going to need to play a lot of Jenga and a lot of structuring. And it really takes expertise to know what you got to build because that will change. And I'm a big fan of building a core team. It might be, depending on the size of your org, it might be two, three folks. But you're also going to need typically some sort of AUG. Now, all that I like to call the keep the engine running bucket. If you have an aggressive roadmap, if you're green, especially if you're greenfield, you're going to have an aggressive roadmap of the new stuff they want to do. So if they want to be building massive new things, and I'm not talking just day-to-day, like normal product roadmap, we're going to do scrum sprints. But if they're wanting to do true new project, I call it the boulders versus pebbles. I mean, our my guys are out there breaking rocks down to pebbles, doing normal scrum work. But if people are bringing us new boulders all the time and saying, hey, we need to do this new AI implementation, we need to do new data cloud, we need to do uh you know all this other stuff. That's where I may go to that same staff group and I may ask them for SOWs on implementations. That's totally separate.

SPEAKER_03 45:14

So do you think that as we go into 2026, different trends will emerge around um not so much about you know return of the office and so on, don't necessarily want to take the conversation there, but around the balance of onshore and near shore? Um, you know, it's something I'm passionate about, something I I post a lot, I'm seeing big demand for near shore at the moment. Um, but do you think do you think from what you've seen, the conversations you've been in being at Salesforce and having kind of the inside eye and obviously Salesforce announced they're gonna put a billion dollars into Mexico, for example. Um, do you think we'll see a drastic shift to to to blended teams uh around the world, or do you think it'll be more of a gradual?

SPEAKER_01 46:03

Well, most of the teams I've had have been blended. Um, that maybe because I pushed them to go that way. Yeah, um, but I do see a lot of teams that that really do push against that. Uh and and I I think it's business driven, not IT driven. I think ID is fully ready. I mean, they've been ready past the last 10 years to be to be in that method. Uh, but right now a bit a lot of the business is still holding back on doing that. Um and I I think until you get the business to loosen the idea that they want a person to physically talk to in the office, as more of them become remote, then I think you'll you'll have that loosen up. Um I think everybody's comfortable with devs um being remote. It's when they get into their analysts, their architect, their business like architects, or or their um the people who are advanced admins and admins doing their work, they really want a person, some point of contact. And I think a lot of companies are figuring out you can have one point of contact um and have that person be the on-site person. Now, obviously that can change, but um I would say that's uh a trend I see in the from my friends is they a lot of people are still pushing for on-site. Um, I know members first was heavy and uh a heavy on-site company as well. A lot of like Howard Hughes was a heavy on-site company. Um Textron, heavy on-site company.

SPEAKER_04 47:31

So yeah, the on-site off-site uh could be a whole podcast in and of itself, honestly, particularly with um a lot of the cheating that's going on now with uh uh we with using AI during interviews or having someone else taking the interviews, and it's another reason to use someone like hero on uh on this kind of stuff. Uh it's get it's getting bad. Um, and then when you combine offshoring with it, um, and then managing are they actually working the hours that they're working? Are they you know, um it's it's it's rough. Um anyway, so going back to what you were talking about earlier, um, it's funny because because you're you had such a strong emphasis on pre-planning. I just kind of assumed you're a little bit more of a waterfall guy than an agile guy, and then now you're talking um scrum. So are are you are you suggesting agile over waterfall or just post-deployment? You're thinking agile becomes better.

SPEAKER_01 48:28

Yep. Post deployment, I'm agile. Um, you know, that's that's just how so many of the companies are set up that I've been in. Uh post-deployment, it it it's it's almost exclusively pushed that you have to be agile by the by the orgs that I've been with. Um so prior to it, to me, it's all planning and it's it's kind of a big bang. I mean, to me, Salesforce does not work on Greenfield implementations is an agile project. It's it's uh it's it's a big bang. It's it's here. Uh, you know, that what there was nothing and now there is everything. You know, it it you so on rollout, we are waterfall basically, and the planning is the biggest piece. Um uh like I said, you pre-plan, you roll out big, and then after that you start giving them you know the pebbles and rocks, and uh and then you start finding new boulders, and the boulders will again roll out as waterfall. Um now you may do parts of the project with your partner in again a scrum type setting where they break it down into micro work, but um without some sort of mix, uh you call it wagile too. I mean, I've I've heard a lot of terms where you mix waterfall and agile together, uh, but yeah.

SPEAKER_04 49:41

Yeah, those are really waterfall, though. All of those are because you're doing planning up front. Um, like you're planning all the sprints up front, you have tight deadlines, you have a tight scope because you have to meet the deadline, and you have a budget because you have a scope and you have right. So, yeah, that that's more a little bit more true. Uh true it's closer to waterfall than agile, I would say at least. Um, the other question I wanted to have ask you, um post-deployment, go live, right? You got your support model we talked a little bit about and staffing, but what about transitioning from the SI, right? These people aren't people like so what's your approach to that? Do you keep them around a little bit? Do you let them go all at once? And how do you deal with that knowledge transfer?

SPEAKER_01 50:24

Yeah, it depends on again my budget uh and what's going on and and what the culture is at the company. So some keep their implementation partners, whatever you want to call it, they're no longer implementation partner, they're partner forever because they don't want to hire a certain number of people because they don't want to transfer that risk fully in-house and have the full headcount uh hit. Uh, the way I'll say it from often a Salesforce executive standpoint, I'm told it's not about the number, it's about where that budget comes from and how that budget is um accounted for. So I've been told before you can't have a half million dollars for headcount, but I can give you 250,000 here and 600 over here for the. I'm like, well, that those two numbers actually are higher. And they're like, yeah, but the other number doesn't count the same way. So uh you have to learn the the the way your uh CFO works and the way all those executive interactions happen, and you find out whether consulting budgets are handled in a different light than the HR budgets are handled with the overhead that comes with that, and you may end up with a system where which you have permanent staff AUG from an implementation partner uh or just your partner at that point, uh, versus a fully on-site team. Um, I like to have a mix because the reason I always like to have that partner availability is I again it may be a low hour count, you know, let's call it 20 hours, whatever. If I've staffed my team purposely for the day-to-day maintenance of my system, I've probably very low staffed any kind of dev if if I have any dev at all on my team. Um my people are mainly building flows, you know, uh, you know, working as admin to advanced admin, okay. Um business analysts, stuff like that. So my dev work, I'm gonna be farming that out probably to the partner. Um, and that's typically how how we'd handle it. Or if I have that dev on staff, they're probably one of my near shore or one of my offshore resources. And I might use those same 20 hours uh from that partner to bring in a higher level uh person, um, you know, maybe uh uh architect or a you know, to do some sort of reviews, uh some kind of checks on system performance, um, you know, maybe some flow reviews, uh consolidation, stuff like that.

SPEAKER_03 52:58

So um just to round out the podcast, um, you spent three about three and a half years at Salesforce um as a senior business architect. Um so I just want to hear a little bit about uh you can imagine for folk in the Salesforce ecosystem, working at Salesforce is often considered um you know one of the end goals that everybody wants to experience. Um and you know, a few have. And um, you know, it's uh it's it I'm I'm I'm always told it's a good experience. But um, you know, just want to kind of you know talk through what was your process um and and and you know, what did your process look like to get hired, your general impressions working for the mothership? Did it live up to your expectations? Uh was it better? Was it was it different? Um, and just general kind of differences between working at Salesforce versus for the customer.

SPEAKER_01 53:48

Sure. So uh the I was actually working at Howard Hughes at the time. I was the director of Salesforce. I was approached by a person I knew um in the past uh about a job that was open at Salesforce, and they asked me to apply. So I I did. And um the rounds of interviews, um, there was four rounds that I could that that I was part of. The initial round was pretty uh I'd call it exploratory. Uh it was just like an HR um person telling me kind of the generalities of the position, how structured, um, some of the benefit stuff. Real real couldn't have been more than 30 minutes, in my opinion, um, if it was that. Then I talked to a hiring manager. Then I had a panel. The hiring manager again um was just wanting to go over my resume, you know, my certs, uh, projects I worked, you know, that sort of thing. Then the panel, they really got into more uh like example-based stuff. So they asked me, hey, if this was going on, what would you do? Um, you know, if this occurred, what would you do? Very you know, real-world examples. They wanted to see how you'd respond um you know to it. Pretty pretty standard stuff that I would also do with you know hiring, uh, just in a panel setting. And then the last was um somebody who's in delivery um in the actual role I would be taking. Um they wanted to ask me more technical questions. Um, so you know, they asked me um, you know, if this was doing this, what would you do? What level of debugging is that, you know, da da da. You know, it's much more technical based. And then that was uh it. I waited to hear uh back from them, uh got my offer and accepted, and you know, that's history.

SPEAKER_03 55:44

So I know uh often we we hear about the process being long. Uh, what was your process from start to finish? Obviously, they do the due diligence, multiple rounds, roughly how long did that whole process take, and do you feel like maybe it was accelerated because you had a strong recommendation?

SPEAKER_01 56:00

I think it was accelerated because I've heard people talk about it being longer than three months, and mine couldn't have taken 30 days, 45 days, uh, couldn't even have taken that long. Uh, because yeah, it it I was actually uh having to decide whether I was gonna move to Houston for the for my current Howard Hughes role at the time, and I decided against it because of the offer. Um, but yeah, it was it was pretty expedient. Um I mean a great experience. Uh I mean, like you said, working at Salesforce is a lot of people's goal. Was it was mine, uh, it was on my bucket list to check that off. Uh the one of the things I can say about working at Salesforce is you have unlimited resources, it feels like, at your disposal. The other side of that is nobody tells you where those are at. So they're all there. You just have to figure it all out. And that's the uh part that I also say is great for having worked there. You learn the correct product departments, you learn um, you know, the way the way the sausage is made, let's call it that. You you you learn um the terms that are used in these accounts and these contracts, you learn in depth of what the front-end licensing ties to the back end pieces uh in a lot of this, and that all just becomes so valuable later. Which which is how I know we didn't really talk about, we talked about in the pre-interview. That's how I caught that licensing mistake. Is I I probably would have never noticed if I had never worked at Salesforce, but I'm able to read an actual licensing agreement and uh a Salesforce setup menu and go, these two things uh this is trouble. The irony.

SPEAKER_03 57:44

Yeah. Any major difference between being Salesforce side uh then being customer side? Uh, did you feel like perhaps you do the answer?

SPEAKER_01 57:59

So obviously there's uh I mean it's the same with any consultancy, there's a lot of pressure for customer success uh being on uh the sales force side, and you're being built out at such a high level. I mean, I I don't know if you I don't know if there's a secret, Salesforce charges more than basically anybody else. Um and but to get that, they're promising you a higher level of service. I mean, if I was at PwC and I know folks that work at PwC and in Deloitte, that they don't have access necessarily to the product team every time. So they can't just drop a line to the product team and say, hey, this is not working the way I expect it to work. Whereas when you have an internal Salesforce consultant, I'm literally able to get in a Slack channel and go, hey, somebody from product answer me why the menu's working like this, and it I know according to the documentation, it's supposed to do this. And oh, some little thing that isn't in the documentation, somebody comes back with product to let you know about. And that was solved in an hour rather than I don't know if you've ever heard of some of these troubleshooting things, they could take days where nobody knows, and you know, something's so mini school um is the problem. So yeah, that that tie-in to product teams was was excellent. I mean, it can answer questions that normally take forever.

SPEAKER_04 59:18

Um I'm really holding back on making a comment about the new Agent Force help site. Um have you used it at all? We'll ask you.

SPEAKER_01 59:28

I've not. I'm not that that that stuff all got rolled out after I were, you know, left uh my position at members first. So I haven't really it was still people I could talk to. Um so I haven't had the full agent force experience there.

SPEAKER_04 59:43

So yeah, I haven't used it a ton either, um, but I I've heard uh mixed mixed things about it. Um so you were you were with the delivery team, so you were with the Salesforce professional services?

SPEAKER_02 59:57

Yeah.

SPEAKER_04 59:59

So um I haven't never worked with them. Are are they really better? Are they that good?

SPEAKER_01 1:00:07

I I thought so. Um, I mean, we were often put on red accounts. I mean, number one thing I can say that the issue I saw was almost every system we had to go in and help. Uh what we're being asked. I mean, again, if you're if you're asking Salesforce to fix your problem, you've had a really bad time. Uh they've almost exclusively went to three partners by this point, and nobody's been able to fix what's been done to them or fix it in a timely manner. And we're either being brought in as the primary partner or being brought in literally to watch the other partner. Like we are, you know, the the oh, you know, over site to whatever work is being done there. But almost exclusively the problems that you'll get are orgs that went with I mean, um went with a a full dev team. So they they have they hired nothing but devs. Everybody was a dev. Um and they built their system full code, and over time they didn't obey some of those normal rules, and they changed out another dev, they changed out another dev, the notation in the system isn't right, they they just can't figure out how anything works, things are breaking, the whole system is coming down daily. Uh, they can't process. Uh, and and this happened so many times, and it was uh consistently the same issue is fully devd orgs eventually fail when you have people transition. That that's the best way I could put it. And we were ripping out large amounts of code and refashioning things uh so that they would be flow-based, or where they were code, we were going through and figuring out hey, of this 7,000 lines of code or this 70,000 lines of code, how much is still used and how much do you deprecate, how much of this doesn't work anymore. Uh so sometimes folks like myself are working with more technical architects that are uh reviewing you know uh the Splunk side of things and figuring out you know where all the you know errors are at. And again, Salesforce has logs that they don't even share with customers that they're able to look through to see problems as well. Um, and you know, I get access to you know even information when I was there, um, you know, that normally, you know, you normally have to pay for as part of like maybe signature or even higher success plans, but because they've engaged us, I'm getting that data and able to share it with them. I mean, there's a lot of pluses. Um, you know, they even bring in program architects too. Uh I would I didn't do that, but uh yeah, I mean I I feel well the the stuff that I did there um was definitely worth uh the the cost. And I would say if somebody has a really problem org, uh that's probably gonna be where they go.

SPEAKER_03 1:03:02

It's the um multi-prong team expertise approach, right? Um the white glove service. Um, and again, you pay for that, right? You pay for what you get. I think we could sum up the whole partner space for uh with that motto. Um but um but but on to um very quickly uh to wrap up, um, what's next for you? What are you up to at the moment? And um, you know, what are you looking forward to next?

SPEAKER_01 1:03:28

Uh well at the moment I'm um just taking a break. Um I'm I'm uh I'm actually sailing the world uh for uh I've been doing so since uh about March or so. Um been on this this year, uh you know, again, about 80 days of of sailing so far. Um so you know for me, the what's next is if I find something exciting um that I'm interested in doing, I I really do like greenfield implementations. Uh I would love to get in on another greenfield implementation where I'm at the beginning doing the planning. Um don't necessarily like greenfield implementations where I'm brought in six months into it. Um but you know, some people can say, you know, um they they like that excitement too, and and maybe some part of me does uh like trying to steer the plane before it hits the ground. Uh but yeah, that that that's probably what's in for me next. I mean, um just kind of uh waiting around seeing if um I find anything that really attracts me back into the market.

SPEAKER_03 1:04:37

Cool. Well, um I hope to see you back in the market because um I know um it's a very small world, we've got shared contacts, and you know, everybody always says you do a great job as a as a people leader, uh, but also from a technical uh perspective as well. So um enjoy your sailing, but don't enjoy it too often too much would be um my my message. But um on on to um thank you thank you so much for uh spending time with us today to share your experiences uh in the Salesforce ecosystem to date. Um and um yeah, we just want to say thank you first and foremost. Yeah, thank you. Thank you. And uh for our listeners, uh, if you want to hear more stories uh like on to's please do not forget to subscribe to the CRM Success show for more episodes uh featuring leaders who are shaping the present and the future of the CRM. Thank you.