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 Mossri 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_01 0:28

Welcome to the CRM Success Show. Today we're talking with uh Eric Nelson, Director of Engineering at Sunshine Behavioral Health. Welcome, Eric. Hey Miles.

SPEAKER_03 0:37

Hey Carol, good to be with you.

SPEAKER_02 0:40

Great to have you here. Thanks for uh answering the call uh to get involved. Uh I know we've been connected for a while, but um good to um learn a lot more about you and your background. And uh it's a great story. So uh why don't we start with basics, Eric? Just as we always do, tell uh tell our listeners a little bit about you, both uh your personal journey, how you got into Salesforce, and then what your role in Sales at Sunshine and what do they do?

SPEAKER_03 1:06

Yeah, absolutely. So I've uh I've been in tech for for a long, long time. Uh but my my original background and all my educational background is actually organizational psychology. Um, so a little bit of an interesting blend there. Uh and I got into Salesforce just over 20 years ago, back before being an accidental admin was like actually a thing. I was an accidental admin. So uh my my company was switching CRM and uh we were looking at a lot of different options and landed with Salesforce, and I I had to learn how to do it and stand it up. And in the the time sense, I've uh done consulting and and worked directly for a lot of different industries. Um I've worked in gosh, SaaS, the entertainment industry, healthcare, uh, insurance, real estate, all sorts of different verticals, leveraging Salesforce pretty heavily for a lot of those. But you know, as time's gone on, pulling in a lot of more technologies, uh, pulling in stuff from AWS and and other vendors. So kind of getting broader and broader in the kinds of teams I even lead, going from just Salesforce to kind of full-on engineering with data engineering, front and back end development, uh, DevOps, all of those those fun kinds of things. Um so yeah, I've been been at it for a minute. Um and I'm still having fun.

SPEAKER_02 2:45

Good. More importantly, that's what it's all about. So glad glad to hear it. Uh, some of the industries that you've worked in over the years have have varied as well. You know, insurance, SaaS, healthcare, I think security back in the day. You work for a security firm of some some form. Um, any any particular favorite?

SPEAKER_03 3:04

Um, you know, I it's interesting. I think my favorite is actually learning new industries. Uh that's that's where I've sort of landed. I am somebody who uh I'm not daunted by coming into a new industry, and I love the challenge of being able to learn the new language and learn new rules and learn all of these different things uh that kind of bring it together and then pull things back from other industries. It's actually really interesting a lot of times in some of the verticals like healthcare or insurance, you know, you kind of have these things where you you sort of assume that that background is the most valuable thing, but it's amazing how often I can pull lessons from real estate or pull lessons from SaaS or those kinds of things into healthcare and kind of challenge like how we've done things in the past. So uh yeah, I I can't say that I explicitly have a favorite. I really sort of like being industry agnostic. Amazing.

SPEAKER_02 4:06

Well, it keeps things fresh, and maybe that's part of uh what's fueling the fire to continue to enjoy uh being in the Salesforce ecosystem, uh perhaps. So so you've been at Sunshine Behavioral Health now a year and a half almost, uh year and a half. Yeah, fantastic. Um I'll be honest, I hadn't heard of Sunshine before you moved there. So why don't you tell us a little bit about what do they do? Who are they? We're assuming they're in the healthcare space.

SPEAKER_03 4:36

Yeah, so Sunshine Behavioral Health basically operates uh substance abuse treatment centers and residential mental health treatment. So we've got seven uh facilities throughout the US and provide like residential care for substance abuse treatment, and then uh also for like mental health for somebody to come and get treatment for a prolonged period of time. So most of our clients come and stay with us for about 30 days for for treatment, and um yeah, so it is definitely very much in traditional healthcare, although there's some interesting things that you kind of find about this particular part of it that are are unique and different.

SPEAKER_02 5:22

Amazing. Um so how would a company like Sunshine use and leverage the Salesforce platform? I'm assuming they were already using it when when you joined, um, but correct correct us if we're wrong. Um give us a bit of context. How how long were they a Salesforce customer for? What does the org look like? What products do you use? How do you use it? Would a who in who interacts with Salesforce? Who's your custom who's your customer, I guess?

SPEAKER_03 5:49

Yeah, it's it's actually really interesting. So uh Sunshine and a lot of the behavioral health, um, especially treatment centers, uh, actually do have more of a sales function than a lot of other healthcare organizations. So our core use for Salesforce is as a traditional CRM with leads and opportunities and uh kind of working in that very traditional space, which kind of like I say, pulling from other industries, working in traditional sales orgs actually is really beneficial here. Um, so we that is kind of the single most important function of Salesforce for us. Um and our org is actually almost 10 years old. Uh, so it definitely had seen a lot of different things and a lot of different ideas. Um so basically, I was kind of brought in to help reinvent some of the functionality of how we're using Salesforce and how we're using our technology internally. Um we have an interesting thing, and this is something I've seen over the years with Salesforce, is that you know, most businesses have a collection of different technologies and we're no different. So we have Salesforce as our CRM, we have a medical record system, we have a medical billing system, and unlike Salesforce, a lot of these other systems are pretty rigid, and so you can only kind of follow the process that they line out or get a little bit of flexibility. And if your business differs too much, you have to get really creative. So you're kind of forced to either adhere to that process and structure your business around the tool, which I've always kind of struggled with that idea, or you you come up with creative ways to make it work for you. And one of the ways that we use Salesforce is to fill a lot of those gaps that we need some functionality and some process around stuff because we are uh a decent size for our industry. And so some of our processes are more complex, and we need to be able to track things and thing and and that. So uh we do have uh teams beyond our sales teams who are pretty heavily in Salesforce. We've got about 120 users across uh different departments, like uh our financial departments. So this would be like patient collections. Uh we do use tools within Salesforce that are custom built to help support our utilization reviews. So these are the people that are like calling insurance to get pre-authorization and and that kind of thing. Um, and then a lot of things that just tracking that back and forth with insurance. And and we've created some some really interesting tools and and and that with that in mind of of kind of filling gaps that our our other tools leave. So yeah, there's there's a lot there, and then there's a lot that uh the kind of the previous uh folks that own Salesforce have experimented with and uh kind of tried and abandoned, and so you you just end up with kind of a lot of really interesting things as in an org that that old.

SPEAKER_02 9:05

Um like uh Frankenstein piece together.

SPEAKER_03 9:09

Very much so, yeah, very much so. And some of it is the like the business evolves, and so there are a lot of things that were very much the right thing in that moment, and then the business evolved in a way that it was no longer the right thing. Um, so and you know what I've seen is that people, including myself, are traditionally bad about cleaning up once you're like, hey, we're not gonna use that thing anymore, and then it just kind of ends up in the Salesforce graveyard uh where you don't delete it, you don't get rid of it, um, but then you have these random triggers that don't work because you have surprise code that then goes downstream for a lot of that. So uh trying to focus on on building new things and and kind of redefining some old things and cleaning up some stuff that we just don't need anymore.

SPEAKER_02 9:57

Good. So one would assume from listening to what you just shared, are you on health cloud?

SPEAKER_03 10:06

We're not actually okay. Um interesting cloud, yeah. Despite all of the verticals that I've worked in, I don't actually, we've never used any of the cloud products, even in insurance. Uh a lot of what we were building, we were building before insurance cloud was a thing. And a lot of what they were building, they modeled exactly what we had built. So it was kind of like, well, that's good, I guess. Um, but yeah, it's uh it is sort of interesting that every time I've gone down the roads of the individual clouds, we're either too far along to make that work, um, or we're trying to build something uh a little bit more unique for that. So yeah.

SPEAKER_02 10:53

So sales cloud, um, I'm guessing enterprise edition, customized to suit the needs and practices of what you guys use it for, basically. It sounds like exactly fantastic. All right, well, we'll cover that in a little bit more detail um as we go on. Um so there's a couple of areas today we're gonna focus on. Both I I I know are things that you're passionate about and you have a good opinion on, and that's an opinion we want you to be as honest as you can be, um, and share kind of your experiences. The first topic we're gonna cover on is the is the idea of building engineering teams within different industries and what that looks like. So why don't you tell us a bit about when was the first time you had a team? Did you inherit it? Was it part of the the job description from day one? And just kind of share some of the experiences um that you've had, both positive and negative, uh, when it comes to building engineering teams, that potentially if somebody is uh making that segue into leadership for the first time, what were the things that maybe you wish you had known?

SPEAKER_03 12:03

Yeah, absolutely. Um so my first foray into leadership uh officially was I was probably in my mid-20s, and I took over the management of our technical support for a SaaS provider um at an age that I probably had no business doing so. Um, but uh it was so that was an interesting piece because I had done the job in kind of that traditional like if you're good at making widgets, you should lead people making widgets uh kind of scenario. And so I landed in leadership the very first time that way and had uh a team of some couple of layer supervisors and and a team of about 20. Um, and that was interesting, but I had no idea what I was doing and uh I was I was just trying to figure out as I went. So I wasn't very strategic about a lot of those things. Uh over time, uh I I definitely had times where it was myself and in one direct report kind of building out things at some smaller organizations. Um, and then I've led entire engineering teams uh of you know 40, 45, uh, like I say, across a lot of disciplines, not just Salesforce. So I I definitely have had the opportunity to have a lot of those different uh skill sets and things like that. One of the key things for me that was a challenge in leadership wasn't necessarily getting into leadership, because that was in that traditional way of like I went from doing the thing and having that role to leading people with that role. And so, you know, I I've been in a lot of positions in my life to to kind of just serve as a de facto leader, whether it's a group or or things like that. Um, I don't shy away from trying to create structure if there isn't any. Um but that sort of felt organic and and I could try different things and I could even, you know, hiring and interviewing, it was like, well, I already know all of these things. I think one of my bigger challenges became when I started leading teams that uh had people who could do things I couldn't. Um that's that's been one of the most interesting bits of my leadership journey is when I'm taking on uh roles that are experts in areas that I'm I've got some broad knowledge, um, but I'm I'm sort of learning from them. And in some of those cases, I have inherited those teams, which sort of made that a little easier to start. That I was very lucky to inherit some awesome people who were willing to teach me. And you know, like at Sunshine, uh I actually built our team from scratch. And while it's small, uh pretty much everybody that works for me is somebody that I've hand selected. Um so yeah, it's it's really uh an interesting sort of thing in that. Um just having some of those new challenges. And it has been a mix of people that I've inherited teams. Um, I've had the opportunity to build some teams from scratch. Um and so it really have had been very fortunate to get a lot of experience in a lot of different areas of that.

SPEAKER_02 15:33

What's your um yeah, I just want to quickly uh before we move on, what's your um you mentioned the the the the idea of like uh hiring uh individuals, leading individuals who perhaps know certain areas better than you do? Um which isn't a bad thing, right? So surround yours, you know, surrounding yourself with people who can ultimately ultimately make you a better leader and and be more successful. Um what what is it a fear of not knowing the technology as much as they do? Is it a feeling of being like an imposter syndrome, like you know, you're you're out your dealt depth a little bit? You know, talk us through that a little bit more because as people go through their career, like we have the mindset that you know if somebody's better than me at some some kind of area, I want to embrace that, but others might see that as a negative and pull away from that scenario, right? Um so tell us a bit more about that. Is it fear? Is it um is it anxiety, like not knowing, not being able to call them out on the BS from a technical standpoint because you don't know it? What where does that where does that come from?

SPEAKER_03 16:38

I mean, it's definitely an evolution, but the the first few times that I experienced it, there were a couple of opportunities I had to to lead some folks that were basically smarter than me in an area, right? And I I even shied away from it a little bit just because I felt like I couldn't effectively do it. And then, you know, saying imposter syndrome is exactly the the right feeling. There is this uh feeling of like ego and and that sort of stuff when you know you're doing something well and you refine your craft and and you can guide people and and share people or share skills and knowledge with people, but then you suddenly get into this place where you're like, how do I help you? How do I, how, who am I to say this is the right person for the job? How can I evaluate them effectively to say that like they're doing well or not? Uh, what if I hire all of the wrong people because I can't definitively say in an interview in in that kind of imperfect world that they're doing well? Or as time goes on, you know, how do I rely on the signals I get to tell me that from a technical side they're adequate or not? And you know, it it really is one of those things that it, you know, it's kind of that like career crisis for a bit. And so a lot of that just caused me to lean a little bit more into the things that I was confident in, which is kind of that people aspect and like getting people to talk to me and and teach me. And one of the interesting bits that I found, and this is kind of that psychological principle, is that uh you you can learn how to keep how to know when somebody's bullshitting you, right? And and so you may not know the thing that they know, but you can develop the skill to be able to see whether or not they know what they're talking about. And it's never perfect, but you can get better and better at that. And one of the ways to do that outside of an interview, so like people you've inherited, especially, is to make connections with them and talk to them. Be upfront and honest about like this is what I can bring you. And there's always something that I can bring in my experience, and that even if it's not showing them how to write this particular bit of code or do this particular thing, but having that better connection with them, what I have found is leaning into the fact that I don't know, being transparent about the fact that, like, hey, I recognize that you know things that I don't, I would love for you to teach me some of these things. I would love to have conversations about these things, and just being sort of like open and honest with the here's what I bring, here's what I don't know. And for me, that's been awesome because I've been able to learn so much more, but then the next conversation I have with somebody else in that discipline, so pick like uh DevOps, for example. Like I the first time I managed a DevOps team, I had no idea other than super high level what that was. And I was just very fortunate that the people that I had, there was a mix of them that as I interacted with them, I sort of figured out who knew what. And I figured out who was willing to have those conversations with me. And kind of over time, that a lot of that faded. Although sometimes uh it crops up, especially on small teams, when I don't have a lot of people with duplicate skills. When there is a huge problem, I'm like, all right, we're gonna get creative and how we figure out how to solve this together. And sometimes it's like, if you don't know and I don't know, uh I'll rubber duck it at the very least and and we'll figure it out together.

SPEAKER_01 20:33

So I mean, I mean, those are great, those are great questions, right? So how do you how do you differentiate between um how do I say someone who's very just confident and separate that out from actual skill if you're just like kind of doing a psychological profile of them to know if they're capable? There are plenty of people that are confident and don't know what they're doing.

SPEAKER_03 20:53

Yeah, so there's a there's a a really useful easy trick to that. Um people can confidently talk vaguely about a lot of things. One of the things that's hard to do vaguely is to teach. And so I often create scenarios where I want somebody to teach me something. And it does, I mean, if we think back to when we were in school and that, there were times that we probably all had teachers that maybe didn't really know the material themselves that they were teaching. And it stood out, even if we didn't know the material either. Um, so that's actually one of my shortcuts is to create scenarios where they're teaching me something and I'm asking questions. And that makes it hard to continue to be vague, and you have to be really, really specific. On the interview side, I do uh actually really like the the kind of behavioral questions that are sort of tell me about a time that you didn't. Did this or this or this. And one of the things that I always add on, which hopefully nobody I ever interview is listening to this, because then it'll just give it all away. One of the questions I ask is usually like, tell me about a project that you're really, really proud of and kind of what you did to do that. And a lot of people can BS their way through that and give you these like high-level sort of things because they were uh maybe on a team that did this thing, but they made no real contribution. But then a lot of the questions I kind of go into are what did you struggle with? Like, where were the pain points for that? What did you learn from that? What did you do? What would you do differently? And a lot of people who are confident but don't have that start to struggle more and more with each level of that. So none of those require me to actually know whether they're right or wrong, uh, to still have a sense of did you do that? Um, or are you just saying so surface level that it's just not valuable? So sometimes getting somebody to walk you through more and more detail, even if you don't know the answer, not many people are very good at coming up with like completely imaginary detail um that has through lines. So if you ask follow-up questions in that, like those stories tend to start to fall apart. And that's not, I mean, super psychological anything to be able to do that, but it is surprisingly effective.

SPEAKER_01 23:36

Yeah, I think I think Albert Einstein actually said that right. Um that if you can't teach it, you don't know it or you don't understand it. Um it's funny because I I use the exact same technique when evaluating experience to know if they really did it. I tell them, you know, tell me about a recent project you've worked on, um, and they're picking the project, and I expect them to know that project, like what were the goals, who were on the team, how it was structured, what were the problems they were facing, the timeline, the budget, right? I mean, depending on their role, right? Um those questions, they're like, Yeah, you just read some stuff online, um and trying to fluff your way through it. Um, I wanna I want to pivot back to uh your early career again. Um because you said you were in organizational psychology or at least studied organizational psychology. I don't know if you've actually worked in it, and then the next thing you knew you were a tech manager. How how how did you break into tech? Because breaking into tech is harder than breaking into management um in a lot of ways, particularly I don't know, it's always been hard, even now and back then too. Maybe it was a little easier back then.

SPEAKER_03 24:42

It was easier back then. Uh it was because nobody knew what it was. It wasn't like I have a career in tech, it was oh, there's things to do, and you're kind of good with computers, so I guess you can do it. Um yeah, it's I uh so I grew up in a situation um where I've had to work most of my life. Um, and even through school, I've always worked, and I've always been kind of adept at the technology side and computers. Uh so the way I actually broke into a lot of it was my last couple of years of school, I was a full-time student and working about 30 hours a week doing tech support and and that kind of thing. Um, and that's sort of how some of this evolved. So I was working tech support and then uh I got a I guess I did well enough uh that they uh the manager of the network operations center, which was kind of our tier two for tech support, said, why don't you come and work for us? And and so I I got to work in a knock and got to do a lot of the hands-on sort of stuff and break stuff and uh that so it was just a an invite through an open door. Uh, but again, like that was about the time that I was graduating with my undergrad. Uh, and my intent all along was I was actually pre-med and going to be a psychiatrist. So that was originally my path. And so it was kind of tech was always a means to an end. Um and then I just kind of kept working those jobs. I took a little break from school before getting a master's, and uh I I fully intended on on kind of going that path. By the time I finished my master's in organizational psych, uh I did the math and I went, wow, I'm gonna take a huge pay cut at this point. How badly do I want to do that as a career starting over when you know I just kind of continued to grow my career along with. So I was just doing all of those things simultaneously uh with a very different plan. Um I sort of realized that at least for my life, uh every time I take a really specific plan to do something, the universe always has a different idea. And you know, so far it's it's worked out. I uh I'm very, very lucky to have a lot of doors that opened at exactly the right moment to create an opportunity. And I like to think that uh historically my my skill has maybe been knowing which doors to walk through to to do something interesting and and that. Um like everybody, I'm still trying to figure out what I want to be when I grow up. Um my dad's still trying to figure out what he wants to be when he grows up, and he's been retired for 10 years. So, you know, we'll just keep at it. Um, so yeah, it's it's it is one of those of like I I fully had a different idea. Um and what I've been able to do is pull in so much of the psychology and especially organizational psychology, not only into management, but how I approach a lot of architecture and software development is deeply rooted in in the people side of it. I spend a lot of time and energy thinking about how do people interact with this, how do I build something that makes sense to a person, to a user? How do I strategically introduce friction or reduce friction to change adoption? How do I make it so that somebody can learn this quickly? Uh I use a lot of those things, and it's it's one of those like uh psych degrees or one of those that a lot of people have, and uh people claim that you never use, but at least for me, it's I didn't I'm not using it in the way that I maybe thought I would, but it's that entire background has been incredibly valuable.

SPEAKER_02 28:46

So I want to uh move the conversation on this topic a little bit to um 2026. Building teams in 2026 is very different than what it might have been in the past. Um, particularly I'm talking about the the emergence of the AI skill set. Now you you've mentioned, you know, originally when you started managing, it might have been Salesforce-only teams, now it's broader software engineering teams. So what do you what do you look for that's different when you hire a Salesforce developer versus a broader software engineer, AI agent engineer, um, full stack engineer? Are you doing anything different?

SPEAKER_03 29:26

I am. Yeah, I think the biggest evolution is that when I first started building teams about the the best uh thing that you could hope for was that somebody had a lot of experience and just inherent knowledge because if they didn't know something, there uh they could maybe you know be good at finding it on the internet, right? And that was its kind of its own skill. And but I I depended a lot on on technical interview and and things like that. And I I focused a lot more in my early teams on what do you actually know, and if you encounter something tomorrow, can you deal with it and fix it based on your skills and and knowledge and that and I I was a little bit more concerned with that, and and what I'm finding now is that I information is just so much more accessible, and so the skill now is not how well can I search the web and find what I want on Stack Exchange, it's more about how well can I prompt something or find the information and then very critically look at it and tell if it's the right information, which is a different skill than just searching for for something that it used to be. And I think the the sort of facts that I expect somebody to know today are different than and less, frankly, than the facts that I expected of somebody 10 years ago or more. Today, I want somebody who actually can use AI and tools and is really effective, but has enough of that core bench strength to be able to take what they find and apply it as kind of a super quick version of that. Uh, about a year ago, I was hiring an admin uh for my team at Sunshine, and uh I had a really interesting interview, and and I was asking, going through the technical questions that I do for a Salesforce admin. And the the person that I was interviewing said, I gotta be honest, like I don't know the answer to this. And I I took that as an opportunity. I said, Okay, well, what what do you do when you don't know the answer? So, what would you do if you encountered this uh scenario in real life? And uh they said, Well, I would I would probably use like Chat GPT to figure this out. And uh it might have been because it was the day before Christmas and I was feeling giving, but I went, okay, let's do that. Uh so go ahead and and use whatever tools you would like. Um, just talk me through what you're doing, talk me through what you're asking, talk me through what the response is. And that was a really interesting moment because it was like basically inputting my exact question into Chat GPT, getting an answer that to me made some sense. And I said, okay, well, now answer my question. And they couldn't. It was like, I still don't know. I even with this information that did actually contain the the correct what I was looking for, at least, they still couldn't actually apply that information. And and so it's like, yes, like the accessibility and all that has changed so much, but the skill now is really it's sifting through so much more information. And AI has created these gotchas of like sometimes it makes stuff up. If you're yeah, not to say that it wasn't before, but you have to be able to cipher through those things and understand what's made up, what's not, how do I apply this and how do I actually take action on it? And that's a new skill. That's it's not a new skill, it's just more important now than I think it's ever been. And so I do kind of over-index a little bit more on that of the like, great, how do you apply those things? I don't care if you remember a certain syntax for a formula or apex or whatever, if you can just look it up. I care about how you can apply it.

SPEAKER_02 33:50

So it sounds like you're open to the idea of uh AI being used in interviews. Um, this is a hot topic when it comes to the engineering uh market at the moment. I think most uh companies they they do separate interviews, right? Some where they enable AI to be used as part of the interview, other interviews where they're trying to understand what exactly is in the candidate's brain, right? Um where do you draw the line? Because obviously you still, you know, AI can get you to a point where maybe 70% of the code that it produces is fit for purpose, but you still need to understand that language to be able to know what's good and what's not, right? Even with all the best commands on into AI, etc. So what do you think in terms of striking the balance, you want these individuals who are coming through to interview to be AI savvy, but like we'll have some companies say, well, they're not allowed to use AI in their interviews. So it's like, but you want them to use AI on the job. So what's your opinion on that? And where do you draw the line?

SPEAKER_03 34:49

Yeah, I I honestly uh I these days I embrace it. It took me a minute to get there, but these days, most of my interview questions are things that are either explicitly hard for AI to answer. So on the non-technical side, about the like, tell me about a time you did this. Uh, AI today is not actually great at making uh fabricated stories either, uh, around this. Like you have to work really, really hard to prompt it. Uh so at least for the moment, uh, that sort of like the experiential piece is we're not to a place where AI is spectacular at that. On the technical pieces, uh a lot of times the way I'll do a technical interview, depending on the role, is uh something that it's gonna be a little bit more obvious if you're trying to use AI, because I don't tend to do the like, here's a blank sheet with a blinking cursor kind of exercise. So it's like if you want to use AI, you pretty much have to start copying and pasting and or taking photos or doing a lot of stuff, and it's gonna be clunky for you to do so. And so what I've run into is a few people who will freely admit like, like, I don't know the answer to this. And if you tell me that, I will say, how would you find the answer? Let's explore that. And when somebody says I would use AI, I usually embrace it and I say, Great, let's do that. Yeah, one of the things like beyond interviews, that even in my software budgets, I budget for AI tools for each of my team members. And at the moment, it's basically a here's your monthly budget. You can use whatever AI tools you want. Here's some constraints. Sorry, Eric. What tool are you using? Yeah, I don't care. You can switch every month if you want. Uh that's that's great. Teach me what you learn too. It's not going away, so fighting it doesn't feel like it makes a lot of sense to me.

SPEAKER_02 37:00

What tool are you using the most at the moment, Eric? I know listeners will be keen to uh to hear that. What are you advertising?

SPEAKER_03 37:07

Personally, uh I was using Chat GPT a lot. And again, my role these days is not writing a lot of code, uh, but I as as a leader, there's a lot of an architect, there's a lot of stuff I do, but I'm uh currently using Claude quite uh for probably 90%. Uh sometimes really challenging things that I know that are gonna be challenging. I will actually give ChatGPT, Claude, and Gemini all a go at it. And then I'll start kind of like combining and and using little bits and pieces if it's a particularly challenging uh like architecture or something like that that I want to be really, really sure about and uh that but yeah, right now Claude, but I am really pretty content to to move around. And uh once I figured out how to kind of share my memory across them and get them all to know me and know what I'm after, then it the stickiness of any particular one really goes away quick.

SPEAKER_02 38:17

So a couple of quick questions on this as we round out this topic. I'm gonna fire a couple of quick questions at you over the next couple of minutes. So um you mentioned skill sets you look for when you're hiring devs in today's market. You recently had your own experience of hiring, um, which we know uh had a positive outcome. But what was one thing that stood out uh recently to you that might have been different than in the past when you were looking to hire, for better or for worse? Maybe one example of each, something that was like, oh wow, like I wasn't expecting this on either side.

SPEAKER_03 38:52

I think the thing that's changed in the last few years is sort of the volume of resumes that all look identical. Um and I've had a few that uh I've got the resume, and I am the type of person that I actually don't have HR screen my resumes or anything like that. I read every single resume I get, and for better or worse. And I've had a few that I'm like, this is too perfect. Like that that just it feels too perfect. And I there was one in particular that I actually went all the way, I was like, I want to talk to this person because I don't think they're real. Um, and in some of the conversation, I was like, okay, it's a real person, but I think they're full of crap. Um, and it's like I don't there's something about it, and that is something that just used to happen a lot less. And in the particular market right now, there's just so many people who are are just trying to find trying to find work or new work and that and it's there's so much more noise in and trying to find the signal and the noise is much, much more challenging in today's hiring market. That's really the biggest thing.

SPEAKER_02 40:14

Um getting getting to the right person the quickest time with the AI tailored resumes looking too perfect against the job description and and and so on. Yeah, I think I think that resonates. That's one of the biggest challenges we see customers uh come across. Uh, another challenge that we see, um production ready developers with modern skill sets. You mentioned the AI piece, uh, let's say, even if it's a Salesforce developing developer being AI aware, the idea that the market's flooded with junior candidates that are looking for their first jump. Um, was that something you saw uh in in the applicants from an experience standpoint? Did you feel there was more junior level entry people trying to get their first break, or was it a balance?

SPEAKER_03 40:56

I I'm actually surprised by the number of people who have 10-15 years of experience who were applying for mid-level jobs.

SPEAKER_04 41:04

Yeah.

SPEAKER_03 41:05

That's the thing that surprises me the most is seeing the number of those who are very well qualified happily applying for jobs that are um more of a mid, and it's it's always kind of curious. Sometimes that actually does make sense because just your time in a role is not sufficient to to mean that you're a senior or more. Um, but no, I actually for the rules I've been hiring for, I don't see a lot of juniors. It's a I see people who have zero relevant experience, and there's definitely a pile there, um, or people with actually a good amount of of experience. It's just is that the right experience? And and one of the things that you know we talked about uh week or two ago was how what's different between different industries and different sizes. And one of the things that I'm finding for me is like it's no longer the technical skills that set people apart for me, and especially on smaller teams, there are so many really talented people for any given role available in today's market, and whether they're actively looking or not. Uh, sometimes you can find a lot of people who aren't actively looking, right? But what matters is the structure of your team and and what you're hiring for. That is is where more of the energy goes because you know culture is is a really big thing. And when you have a small team, one toxic person can completely derail everything you do. When you have a big team, you still don't want toxic people. And and one of the premises that I focus on, and it's small change in wording, but a lot of people talk about culture fit, right? So they they want somebody who fits the culture, and I don't I don't ever hire for people who fit the culture. I don't want a bunch of people who are identical. I look for people who add to my culture, and that is one thing in hiring that I am incredibly deliberate about is I hire people who grow the culture I have because small team, lots of hats that I wear, I don't have time or energy to micromanage every single thing. And so I develop teams that are focused around like the culture kind of manages the team more than I do. And my job is to support them and make them successful.

SPEAKER_01 43:53

Hey, I want to uh jump back to something you said. You said that a lot of really senior people on the market. Applying to kind of like mid-level jobs. Um, what do you do with those resumes? Do you do you talk to them? Do you say, you know, they're gonna quit as soon as I hire them, when they get something better? Like, how do you how do you approach that?

SPEAKER_03 44:13

I I actually do often have conversations, uh, at least an intro conversation. And one of the things I spend more time with those folks is what do you want? Like it and I I didn't tend to ask a lot of like anti-interview questions because I think a lot of traditional interview questions are are not super useful, but I spend a lot of time saying, like, you know, you give me a resume, you read the job description, you're trying to tell me why you're a good fit. I do like to dive into the like, why am I a good fit for you? Why is in this case sunshine a good fit for you? Uh what do you need to know if it is? And a lot of times that's when the the piece comes out. And sometimes it's not because they're gonna leave super quick. It's because they got to a level that just doesn't fit for them. It's like they want, they've gotten farther from the work, they've gotten farther from the things they enjoy. Uh, they don't really thrive in in some of the situations that they found themselves in or big teams or different things, and they want to go back to this sort of thing. Sometimes they'll tell me something and I'm like, we are absolutely the wrong fit for you. You will be so unhappy here. And I have told people that. Um, so it really varies. I there was a period probably about four or five years ago, that anybody applying for a role that was a mid and they were a senior, absolutely, it was a like, they're just looking for a job, they're gonna keep looking. I'm seeing a lot less of that right now, and I'm not sure why.

SPEAKER_01 45:55

A lot of people are there's a lot of layups going on. Um, a lot of people have been looking for a while, and they get a job, they're like, I just want to stop looking. And they they're very much appreciative. It's funny, I I think this is the first time since I've worked in tech that you you hire people and they're like genuinely appreciative just to have a job. It's it's it's somewhat weird, it's uh in a way sad. Um but but in a way, their their their motivation and their their like their ability to do their job and they're generally happy to do it, it's more pleasurable to work with them. It's it's just a weird dynamic. I agree. Um anyway, I want to move on. Um, your title director of engineering is obviously not director of CRM or director of Salesforce. One of the things we spoke about in our pre-interview was deciding where to build something. Salesforce is not the you know, end all be all. It's the right tool for the job. Um, so why don't you tell us a little bit about that? Some other systems that maybe won't. Um, or a couple of project examples when you said, okay, let's throw it on Salesforce. Maybe this is the right tool, maybe it's not. Um, and tell us about that, about tool selection, particularly when it comes um with regard to Salesforce, if it if when Salesforce is in consideration. Yeah, absolutely.

SPEAKER_03 47:10

Well, like I kind of hit on a little bit for for us, and in a lot of my roles, Salesforce kind of has a core function, which often is CRM-based, right? And then it is actually a really great tool to fill gaps for other things. Where I've gotten myself into trouble and I have inherited plenty of things as well, is when people try to make Salesforce do the thing that you could buy or that somebody else does a lot better, um, just because you can. Like it's like, can I make Salesforce do this? And it's really tempting because I am a big believer of having people uh be able to like stay in a system where they can. That is one of the nice things about Salesforce and being able to do integrations and that kind of thing, is reducing how many different systems somebody has to log into to do their job. And Salesforce is a great place to be able to consolidate some of those, but sometimes we end up building things in Salesforce that we really should either choose an off-the-shelf thing or in certain circumstances use other technologies. So uh for me these days, uh in in the healthcare space, like I said, we have a medical record system, we have a separate billing system, and for me, like that's right. We should have those things separate because there is inherent knowledge and things that my small team isn't going to have that we can leverage a vendor for. Um but I'm using uh in the past, I don't know, five or six plus years, have leaned a lot more into tools that we can gain through like AWS. Um we were using Azure for a bit. Um I really like the AWS ecosystem. And and again, as a smaller uh healthcare org, everything we have to do is HIPAA compliant. Uh, and then when you start using other vendors, you have to go through the contractual thing for a business associate agreement and that, and that creates a lot of like sudden expense when you look outside. So AWS actually provides a lot of really interesting tools for us that are covered under that without like those huge expenditures. And between Salesforce and a lot of the tools in AWS for us, there's a lot of things that it lets us try things in small scale just to see if like it does this feel like a viable, viable path. So uh yeah, right now uh leaning kind of of a lot of hybrid between AWS tools that are available there and in Salesforce and and creating tighter integrations between a lot of other things.

SPEAKER_01 49:58

So do you actually like put the things to the test? Do you like POC them out in sales performance in AWS? Yeah, sure.

SPEAKER_03 50:07

Yeah, like a good example um that I've played with in AWS specifically as a POC. Um, we have a lot of our vendors that support webhooks, um, but they don't document very well as far as like what they contain and what they do and what the when they're triggered. Uh and I basically created super quickly on AWS a listener for webhooks that I could just subscribe to and start using those to profile what kind of data I was getting, and then just using a lambda to basically start peeling out subsets of those and forwarding them on to like Salesforce. So uh some of that data I want in Salesforce. So an example would be somebody pay makes a payment with a credit card. I want my sales team to know that they paid as quickly as possible. Um, but there's so much noise that some of these vendors are producing that, you know, we know the limitations in Salesforce in terms of API limits and data and all of that. So being able to stand something up that took me probably two hours uh to have a proof of concept that was basically listening to those webhooks, filtering them down, and had a way for me to just pass them and forward them a subset along to Salesforce is hugely powerful. Um, and it makes an integration that it's like, yeah, I didn't have to spend a lot of time and energy to even get a proof of concept working.

SPEAKER_01 51:34

I mean, you never considered building that in Salesforce, though. I mean, that would be absurd.

SPEAKER_03 51:39

Uh these days, no, but there are times in my history, of course. Like I can build an API listener in Salesforce, and third-party vendors can send me information. Uh that sounds great. I I can just put my Salesforce endpoint as where that vendor is gonna send stuff. Not gonna deny that I've done that and have felt the consequences. And as time has gone on, a lot of these other outside tools have just gotten noisier, so it's gotten to be more of a bad idea. But yeah, having that those layers that can handle and process in a way that like Salesforce really is is not the ideal tool for.

SPEAKER_01 52:24

So uh is AWS your go-to SEC or so when I when I think in terms of yeah, I mean it's pretty solid.

SPEAKER_03 52:32

Uh I mean I've done we had Azure and we did a bunch of stuff with it. Uh it's not my personal favorite, but some of that just honestly comes down to what you've used and what you've used the most. And I've the the projects and teams that I've worked on that were using AWS, we were doing the most interesting things, and I really do like how easy it is to grab something off the shelf, and they have a huge inventory of things that you can you can use.

SPEAKER_01 52:59

Right. Um, yeah, so when I'm thinking, I'm usually thinking in terms of like build versus buy. So you can think of Salesforce, let's say on the buy side, but you already own it, so it's really customizing build in Salesforce, customizing build outside or buy a very specialized tool and integrate, which I tend to call the best to breed approach, right? I want the best tool for the job and then and then integrate. Um so yeah, so so how do you how do you weigh that? Um and just to make this question a little bit more complicated, particularly when you have tight deadlines, right? How do you deal with okay, do I want to test out 15 things on the market, or do I need to just go ahead and push forward with good enough?

SPEAKER_03 53:46

You know, I'm uh I'm always a big fan of the kind of MVP and iterate approach. Uh anytime I can leverage that and reduce the scope to get something that's inherently uh a step forward uh is always important. And and that's one of those things that you know one of my many hats over the years was project management. And you have deadlines and you basically have a budget, you have deadlines, and and you have a scope, and you can only pick two. So uh before I ever touch any of those things or start to decide, I'm always I'm I'm starting to negotiate of which of those do I get to to flex on. Um so that does influence it a little bit, is is which of the two that I I have to pick. From there, it is really important to think about the the capabilities you have as a team. So if I have four Salesforce devs and one person who can build things in AWS, that's gonna skew me to probably be a little more likely to build something in Salesforce between those two things. Or even if it's just resources that I have available in that moment, if I have a bunch of people on other projects, um, that that's probably gonna influence which direction I go a bit. Um but one of the things that really in that build versus buy isn't always the timeline, but I I've gotten better at asking the question, can I do it better? Uh, because you know, you mentioned one of the things that I have said so many times over my career, and I I continue to hear is the well, we already paid for Salesforce, so it's free if we build it in Salesforce. Uh, I added the it's free. You didn't say that. Um, but it it does, it feels free.

SPEAKER_01 55:39

Right. That's free.

SPEAKER_03 55:40

It feels free, and people don't cost anything uh to actually develop it.

SPEAKER_01 55:46

Um it's a sunk cost, man.

SPEAKER_03 55:48

Use the sunk cost, but what isn't is the opportunity cost to maintain it. So even if you say like it is a sunk cost because of the people and all of those things, which is a compelling argument in in some ways, what people generally fail to do is consider the maintenance cost of it. And so if I build it, I have to maintain it. And so that is a cost that I am then creating opportunity cost in the future to not be able to build and do and all of those other things. And I have almost never seen that in a project plan in terms of budget and what this is actually gonna cost. So I think that there's a really important thing to always be putting your thumb a little bit on the scale is is somebody else gonna support this? And does that actually enable me to do other things that are higher value? Um, and and one of the things is like, can a vendor do it better than I can because I lack the uh like the amount of time that it's gonna take me to design this complex thing versus there's an off-the-shelf version of it? A lot of times, like if it's complex enough for me to be doing that evaluation in the first place, there's probably some good reasons why somebody else has made an entire business by developing a product to do it. Um, so I should at least look seriously at that. And yeah, it is the can I do it better? Sometimes I I have made the solution or the decision to build versus buy because every buy is this like huge, bloated, expensive thing, and I need 10% of it. And in those cases, I'm like, yeah, I'll just build it because the 10% makes sense for me.

SPEAKER_01 57:35

Okay, awesome. I I think you mentioned also previously, um, again on the on the prior call, um, that at one point you built something in Salesforce and then pivoted out of it and ripped it out and then rebuilt it externally and integrated back in.

SPEAKER_03 57:48

Uh I actually didn't rip it out, uh, though I it kept me awake many nights after I left that job, wishing I I had just done it differently.

SPEAKER_01 57:57

Um after you left the job. Okay, I'm sorry.

SPEAKER_03 57:59

After I left the job, because I I left it with people who were like respect.

SPEAKER_02 58:03

How would you do it differently, Eric? Yeah, give us an idea.

SPEAKER_03 58:06

Yeah, so the the one that's probably the biggest uh that I would just approach, I would approach the entire problem a lot differently, was uh it was an asset management uh system or started as an asset management system for for really high dollar assets. Like everything was serialized and and worth like I think the cheapest thing was about $3,000 up to like $50,000 per per item, and shipping all over the world and and kind of keeping track of of leased equipment. Um and so that part wasn't so bad, but what it morphed into was this inventory control system in warehouses throughout the globe. And inventory management is a little bit different than being able to say, like, oh yeah, this thing with a serial number is in this location that we own. When it really got into the like we're shipping things, and some things actually now are like five dollar widgets and how many of those we have, and it was just a quantity, and it was one of those things that it just felt at the time that it so naturally morphed from one thing and and just expanded into something, but it was so hard to build a good, reliable inventory control system for warehouses in Salesforce. And again, this is probably about 10-ish years ago. So Salesforce has evolved a little bit, but some of the data structures just aren't super conducive to that. Uh, being able to reconcile and keep your inventory up to date. There's some different approaches to how you count things and how you uh actually keep track of that. And Salesforce isn't great when you have just like millions of records uh for something that's a low value to have a record. So there are a lot of things around that that I definitely that's a place where I would have probably taken some different approaches and made more of a hybrid of off uh offload some of the core functionality, even if I built it elsewhere, uh, and then connect it back into Salesforce uh as as a view. But that's that's one that I was just like, it took so many heroics just trying to get it right, and so many times that it was like inventory's wrong, inventory's wrong, inventory is wrong, that it it was a good indication that that probably wasn't the right direction to build it.

SPEAKER_02 1:00:35

What do you hopefully you don't have too many uh failed projects uh over the years, but was there a particular sign that obviously beyond the obvious that hey we're not gonna go go live on time or we're over budget, was there any other signs that you thought uh uh uh oh okay, we might not be on track here? Um or it was themed a failure? Is it just like adoption wasn't there or uh any other like factors that you'd go into it?

SPEAKER_03 1:01:03

I mean, there's always a lot of those things, like it's taking longer and it's more complex, but one of the things that I've learned in my career to view as a signal, and I mean I could give you more recent examples where I have started to go down a path and I've chosen to abandon that particular path before we ever launched it, because it's like, okay, there's a lot of creative things that you can do in Salesforce to overcome certain limitations. But when it feels like that's all you're doing is heroics, and it feels like you're trying to recreate a lot of things in just a slightly different way that are native functionality. There's a lot of signals there that now I've gotten better at listening to of the this isn't a feature so much as like I'm just doing heroics to work around a constant, like it's it's the here's the idea, yes, that'll work. Oh no, here's a roadblock for that. Now I'm gonna work around that, and I'm gonna work around that. And it's kind of like if I was paving a road, it would have like straight line bump, straight line bump, straight line bump going around like every tree and every different thing. And I'm like, that's really not a very good road. Right, right. So that's just sort of achieving it. It's like yeah, it's like one or two, you're like, okay, I can that's fine, but when it feels like every decision you make and every time you're having a conversation about it, you're like, well, I had to do this to overcome this limitation. When I was earlier in my career, that felt great because I was like, I'm so good at this, I'm overcoming all of these limitations. And now I look at it and I'm like, those were probably signals that I was doing it wrong.

SPEAKER_02 1:02:43

Yeah, should have planned ahead, maybe to avoid them in the first place. But hey, Eric, no one's perfect. So um two questions before before we wrap up. Um, two two quick questions I I want to uh ask you about. One, what is next uh for you in terms of Salesforce products? Are you exploring any at the moment? Um, your thoughts on Agent Force? Will we see a uh agent force use case inside uh your org uh sunshine?

SPEAKER_03 1:03:10

Uh wow, you sound like my uh Salesforce account manager all of a sudden. Yeah, I know. Um in this moment, uh my my focus is a lot of like stabilization and uh again, like I've I've been in this org for a year, but I'm I'm kind of reinventing a lot of things that that have been stagnant for for many years and and rebuilding things in different ways to make them work. Uh so a lot of my focus right now, both in and out of Salesforce, is around really making a robust foundation that I can fill gaps that we have and also drive us forward a lot, um, which means that I'm not necessarily looking within Salesforce to roll out any new Salesforce tools, um, though certainly third-party tools that I'm going to integrate and kind of make it make Salesforce run them. Uh, but yeah, an agent force uh uh I think it's cool. Uh I've played with a little bit, uh, especially in the healthcare space, there's a lot of pieces in that high compliance of the being absolutely confident and right and predictable, and then showing a paper trail of how you got there. Uh, it's a really big thing for being able to bill insurance in that as you have to say, like, this is how I did this. And at the moment, for me, some of the agent force pieces uh are appealing, except that paper trail is going to be uh a gap that I just haven't quite figured out how to fill.

SPEAKER_02 1:04:53

Well, still time to uh to follow. Now, last question uh is completely unrelated uh to Salesforce and to uh leadership to an extent, but it was something as we were uh waiting for Maz to join us earlier. Um we talked briefly about your favorite book, Think Again. In 60 seconds, Eric, why would you recommend that book uh to other people? I'll put it on the spot. This isn't this isn't pre-rehearse, you know.

SPEAKER_03 1:05:18

So No, no, no, that's that's great. I love it. Uh yeah, Think Again is is one of the uh books that I have read multiple times. Um Adam Grant is a phenomenal writer, he's also an organizational psychologist, so a little bit near and dear to my heart. Um, a lot of the things there have been just a lot of lessons from this and a lot of really kind of key things, and and you say it's not about leadership, but in some ways it is. Uh, one of the concepts that I I repeat a lot that has been really good for me, and we were talking about leading other teams and imposter syndrome and all of those things. And as we grow in our career, we're pressured to be right and know the answer in that. And one of the things that that sucks with or that has stuck with me about this book, um, one of the like I many ideas is that uh my paraphrase is basically when you're right, you don't really learn anything. Um, and in my career, I've I've spent so much time trying to learn and be more and more right more and more often. And uh some of the ideas in this book have have made me appreciate being wrong more in some cases than being right, because that is where I learn. And that's like some of my interview questions that that I ask are the what went wrong, what did you learn? Um, because I think that that is much more important about experiencing things and and that. And it's it's really shifted my approach to architecture and leadership and and just how I show up as a person is the a lot of the things that we just sort of go along thinking we're we're getting better day by day, um really do needed to take a pause and reevaluate and look from a different angle. Um, because there are just so many things that just looking at it differently, you you can get a hundred percent more out of an experience.

SPEAKER_02 1:07:22

Amazing. Love it. All right, a couple of books that are good, but this is my favorite. All right. Well, I'm sure uh the author appreciates the shout out. So um with that, Eric, we want to say thank you. Uh, we appreciate your time. Great, great session, great, great episode. Um, I think two very big topics uh that could have been podcasts in their own right, but we'd like to try and give you listeners a bit of diver diversity right. So um thank you for your time, um, and thanks to anybody that's listening to this episode uh as well. We appreciate you listening.

SPEAKER_04 1:07:54

Yeah, thank you guys.