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_03 0:29

Welcome to the CRM Success Show where we deep dive into CRM success and failure, delivering real stories with real impact. I am Dave Mastery. And I'm Kira Whitzi. And today we're talking with Nadita Lipson, who's a CRM Enterprise Architect with NetApp and also a Golden Hoodie recipient. Welcome, Nadina.

SPEAKER_01 0:47

Thank you for having me.

unknown 0:49

Thank you.

SPEAKER_02 0:50

So Nadina, um, I think let's start with um a bit of intro about yourself, please, in terms of you know, for our essential salescross career, you know, today and talk a little bit more about the golden hoodie uh recipient. That's a big deal. We're very honored to have you on the show, our first golden hoodie recipient. So uh, you know, give give those who might not be as familiar with what that stands for, uh, an idea of what that is, please.

SPEAKER_01 1:15

Yeah, so I'll start with the golden hoodie first. So I got my golden hoodie at Dream Force 23. The golden hoodie is a gift of gratitude that is given to you from uh all your work that you've done in the Salesforce community. I got mine from all the work that I do within the architect community and actually got it at the architect keynote. I was uh very surprised, and so it was a very honorable and humble moment.

SPEAKER_02 1:43

And you mentioned the the architect group. So um again, C or mule stock and um uh an architect ambassador for the for the ladies of the architects, correct? That's some of the work you you were mentioning.

SPEAKER_01 1:57

Yes, yes, I I do a lot in the Salesforce community, so I'll I can do a quick rundown. So I'm a Salesforce group leader for the Frederick Architect Group. I also used to be a uh developer group leader for the Austin User Group uh before I moved. I also am a Salesforce MVP, so um we can talk about that as well. And then Mule Soft Ambassador. I do a lot of work with Ladies B Architect and I do a lot of volunteering overall with the Salesforce community. I'm sure I'm missing something. I also um am a credential ambassador, so I have I do work with the credential team in terms of the super badges and some of the uh tests and exams.

SPEAKER_02 2:42

It's amazing you find time still for the search at the same time to be CTA. Yes. Um all right, great. Um so so currently Enterprise Architect at Neta, give give give us an overview of just kind of where you got your start in Salesforce and where it's taken you so far.

SPEAKER_01 2:59

Yeah, so I started my career at a ISB, very much a startup type company. Um, I started as a developer doing Salesforce. I was very new to Salesforce. I was right out, it was during when I was in college, actually doing my master's. I did an internship with this company and then joined. It was something where I had done a computer science degree, I was wrapping up a computational science degree, and I said, okay, let's try Salesforce. Someone told me it's like proprietary Java. It was definitely not the case. Very different, um, very much a different type of nuance, but overall it has been good. Throughout my career, as I progressed, so I was a developer, then a tech lead, then a Salesforce architect, Salesforce CTA, and now enterprise architect. I have always kept one thing in mind, which is learning the tech and ensuring that I'm looking at the platform holistically and not just from a developer perspective. I haven't held the role of, say, an admin or a business analyst, but I did spend a lot of my career understanding what each of those personas do within the community so that I could one, be able to do my work more meaningful, understanding both sides from the business and the tech, but then also understanding okay, as you're developing stories or as you're looking at the tech, it's very much driven by the business problems and the business use cases and the business KPIs. So being able to relate and tie it back to the business was very key for me.

SPEAKER_03 4:49

Um I'm sorry, I got distracted by my daughter because no worries. Yeah, so so tell us a little bit about uh that transition. You said, right, you went from uh from school or you had a job as a traditional developer and then moved into the sales course and then kind of went through various various uh stages I get through developer or architect. Um why don't you tell us about you know the differences between working at those levels and in those roles?

SPEAKER_01 5:21

Yeah, so let me start with the smaller ISV. I'll bucket that into more of a startup environment because it was everything and the kitchen sink. So I really like that um type of environment, not at the time, but now looking back, it definitely helped accelerate my career. Because from that perspective, you have a lot more responsibility. You're doing a lot, uh, it's not a lot of, let's say, layers that you're going through. So things uh that happen within the company, you have a very direct impact. So whether you're working on multiple clients or you're working with multiple teams, it's very much impactful because the company is so small. So everyone's wearing multiple hats and you get that exposure very quickly. Now, I'm very happy that I started my career that way because I think it really helped accelerate me in terms of I don't have to necessarily focus in on, okay, I'm doing development today. I might be sitting with a business analyst or a project manager and just understanding the work that they're doing at a very rapid pace and on different clients. Then I did a bit more, I would say, I went directly into enterprise at the time and then wrapped back around. So going from startup enterprise was it was like a shock because on an enterprise, things move very slow, but slow and methodically, because you're having SOPs, your standard operating procedures, you have different uh gate checks. So you're not worried about accidentally deploying things into productions. There are different steps that you have to take to ensure your quality. I'm not saying that the startup didn't have quality, but definitely things are moving very fast. So it was almost like bullet train versus slow moving train type of deal. And it was interesting for me there at that specific enterprise at the time because I got a lot of certificates. I used to finish my work actually very quickly because I was so used to that pace and so used to, yep, I understand this, let me get these requirements. I'm still an IC, so I was not necessarily in a managerial position at the time, but it was it was interesting for me because it was slower, but at the same time, I couldn't drop to that type of pace. So I spent a lot more time studying, a lot more time really honing uh my knowledge at that company. And then I went more to, let's say, small business, mid-tier type company, and that was a really good balance. Um, I did a couple of those companies. So I did one that was a gaming company, uh Kabam, that was very interesting, and then uh TradeShift as well. And I would say in a mid-tier company, it's very much of a sweet spot where you can focus in, go as deep as you need to, but you can also grow broad. So you're not locked into that specific um position. If you want more responsibility, no one is obviously going to stop you. But at the same time, there's just enough gate checks and just enough um, I would say, procedures to not feel like everything is moving too slow. And yeah, then I wrap back around to an enterprise um Neta. And I think it's different this time around because I know what to expect. I know the nuances of the enterprise, I know the nuances of how things need to go. And so I can set my pace of work to balance out um what I need to do, and there's always something to do on the enterprise, so you just have to go and look for it.

SPEAKER_03 9:06

So when you said you were at a tar at a startup, that was um a Salesforce SI, a partner?

SPEAKER_01 9:13

Or that was yes, and yeah, that was it was an SI, um a smaller partner. So at the time it was called uh rethink slash think tech labs. Um it has now changed name, and I don't know why I'm blinking on the name. So I'll come back to it once I remember, but yeah, I changed names now, but yes, definitely was an SI partner for real estate. So what we have was very interesting. We had two products on the app exchange, and we would do uh real estate implementation for real estate um companies, so companies like Keller Williams, companies like CBRE, so both commercial and residential.

SPEAKER_03 9:59

So you they had products in the app exchange. So a lot of a lot of SIs have products in the app exchange almost for like lead gen type, or with this like a real revenue driver.

SPEAKER_01 10:10

Yeah, this so this was think of a blank Salesforce implementation. We would put our package on, everything was built out for you, uh, turnkey for you to run your real estate business. So not really lead gen, but it was a full-blown, I would say, all the procedures, onboarding, everything you needed from a um start to finish real estate business.

SPEAKER_03 10:35

Okay, so it's like an accelerator, basically. Correct. Okay, awesome. And then you went to enterprise and just again for our litters, what does that mean? How big would you call an enterprise environment?

SPEAKER_01 10:48

Yeah, so um this was I want to say it was at least 14, 15,000 people at the time. It's more now because that company also got um acquired. So it was Luminex at the time. And yeah, it was uh it was a pretty big enterprise in terms of people. I don't think I've ever met everyone. Um, they had offices all over, so I was located in the Austin office at the time, and yeah, it was for me pretty big uh from an enterprise perspective. When I say enterprise, I say anything let's say above 10,000.

SPEAKER_03 11:27

So, yeah, so that's a fairly big company, probably publicly traded, publicly traded, yep. Okay, awesome. So, yeah, so so tell us about the culture shock. There must have been.

SPEAKER_01 11:39

I mean, you know, it's it's it's very different, right? Because you come in uh day one. I'm a very excited person when it's like my first day. My first day and my last day at a company is like the best days for me. So my first day, you know, it's in office at the time. I'm very dressed up, I wanted to look extra smart. Um, I brought a plant with me because you know I would have a little office. That was like a thing. Um, it's just like super excited. You're meeting all these people. I'm not remembering all their names because it's like so many people you meet on your first day. Some of them actually flew in, so I didn't see them again for like months. But yeah, first day it's like, hey, we have all these systems. Um, so just take your time to get familiar with them. And it was like, oh, okay, so there's the CRM, there's the system to do payroll, there's a system to do this. Again, at the startup, I mean, I think I was in Salesforce on like day one, right? Um from an enterprise perspective, I was still getting set up. I think it took a couple days to get access to all the systems that I had to understand. And then uh there was a glossary. So that's like a thing where it's like, here's all the terms or terminology we might be using. Here's some of the systems that we have. And so I'm going through like the glossary, going through the handbook that's like super thick. Um, and it it was just a very interesting day, one where it's like, I know Salesforce is here somewhere, but I don't think I I don't think I was in Salesforce until I think like later that week.

SPEAKER_03 13:13

Were you not on the Salesforce team?

SPEAKER_01 13:16

I was, but at an enterprise, it just it took some time to get the access to get the uh um provision, right? To get into the organization because I had to make sure that the um SSO system would take at least, I think, I think it took like 24 hours to pick up everything to provision me across those systems. And then it's meeting with the different folks, meeting with the different teams, making sure my HR paperwork was ready. And so, yeah, it just it's one of those things where it just takes some time, um, which again was like a shock for me because from a startup perspective, I was in from like day one. It's like, yep, just somebody set up Nadina's credentials, somebody just would do it. Whereas there's teams and systems doing all this work, so you're waiting for the provisioning, waiting for uh the time to get set up.

SPEAKER_03 14:06

Okay, and then how about let's say working with other teams? Like one of the things when I've been at at big enterprises, and it hadn't been that many years, but uh a few years that I spent there, um, did a lot of focus on like that's your role, stay in your box, you know?

SPEAKER_01 14:23

Any I yeah, I think in terms of enterprises, it depends. I think back then it definitely was like you're a Salesforce developer, so you should be focused on developer work. But at that company was interesting because there was a lot of cross-poplinating. So you would work with a developer, project manager, a business analyst, and then like overall that person for maybe the manager. So the input was taken. I would say that okay, what from a perspective, like what do you think? I think at the end of the day, the decision didn't um lie with me. So if I saw something that was, let's say, why are we doing this? It might have already been too late because somebody already decided it. So depending on what the project was, how early I was um engaged, because again, some of the projects didn't need a developer. So it would be something where I would have to be specifically engaged. But I could definitely see what you're talking about in terms of that is your role, you know, stay in your box. I'm definitely not that person. So I used to really make an effort to uh walk around the office again in office time to understand what other people were doing, what projects they were working on. I'm just a very uh curious person by nature.

SPEAKER_03 15:48

Yeah, so I'll give you an example from let's say my life. So it'd be like, okay, you're a developer. Don't talk about the project plan, don't talk about the timeline, just adhere to it. And if you're saying, but your thing is out of order, you essentially would have to go negotiate that with the project management, right? Team, um, and get them to file the dot. Like you couldn't make a change to the project plan. Um, right. And there was like almost no overlap in the role. So if you're talking about the requirements, you'd have to go back to the BA, you'd have to go back to the BA, and you say this is wrong, this doesn't make sense, right? Um, whereas in a you know, in a smaller shop, that almost happens on the fly. All of that happens on the fly. You'll be sitting in a meeting and it's like this is wrong, and then like, oh, okay, sorry. Right? Um so yeah, so that that kind of that kind of stuff. There's um, I would say to work in a big big organization, you almost have to be a politician, right? In some ways, or you need definitely higher level political skills. Um yeah, yeah. So how do how do you adjust to that kind of level of stuff without it getting you frustrated? Because it gets very frustrating.

SPEAKER_01 17:04

Yeah, I think, yeah, so let me answer it too is there was definitely a lot of that, right? Because everything was a standard operating procedure, everything had to be, you know, by the book. You couldn't um make changes. So, for example, if we had a go live, we had a no-go and like everything was set and someone saw a problem. I couldn't say, okay, stop the brakes right now. You had to go up the chain and make sure that you got everything I's dot t's cross. For me, at the time when I started as a developer, I understood what was going on from the project plan and the project timeline, but also it wasn't as frustrating for me in terms of, hey, we need to change this because you know, this is off or the timeline is off. I very much was at that time in my life very specific on yes, I'm going to do the development, yes, I'm going to raise the red flag, so to speak. But I'm not necessarily, I'm going to just use the word emotional. I'm not going to be like, oh, if this doesn't happen, like catastrophic is going to happen, right? It's going to break. Because for me, I think that was the difference, right? In a startup or a smaller shop, you felt it. You felt when you really messed up. So like something went into production, you felt it. Like the client was going to call you. Whereas in the bigger enterprises, they're calling you, but I wasn't necessarily going to be the person on the phone. I wasn't necessarily going to take the brunt of whatever was happening. There were people there to, let's say, do the air cover and be the politicians and really at that top level. What I was focused on is making sure my code had quality, making sure from my timeline perspective, the things I could control was within my wheelhouse. Now, were there days when I'm like, why are we even writing this trigger? Why are we doing this as a batchdrop? 100%. But I think, at least for me, I'm a very vocal person. So it was something where I would say things like, and I was very bold as well. I would say things like, yeah, we're doing this, but I think in like six months, the system's gonna have like degradation. So I'm gonna bring this up, and then in six months we can talk about it, or we can fix it now. And if we didn't fix it now, I would totally be like, Well, I wish we had fixed it because now in a few months we're gonna have to deal with this, but it wasn't something that would necessarily get me upset because I didn't feel like I had total ownership like I did when I was at a startup. Now, when I was at a startup and I had total ownership and I was managing platforms, I felt it when I would deploy code and it was maybe buggy in production. It it felt like, you know, to my heart, I was like really stressed out. It's like one of the things I learned to fix problems very quickly and identify problems quickly was from that startup because I was always, I could have done this better. So let me practice so that the next time this happens, it's you know, a more graceful fall or making sure I'm doing the best practices. Whereas at an enterprise at that time in my life, it was, you know, I don't have total ownership over this whole project. I don't have to live and die by projects anymore. What I have to focus on is my code quality. What I have to focus on is how can I be the best developer I can be for this team and this project. So if I finish my work early, let's say I got a requirement on Monday, somebody would scope it out for two weeks. I kind of would chuckle to myself actually, because it's like two weeks, this is like four days worth of work, but whatever. I would finish my work, make sure everything was good, test classes were written, make sure I could give the best quality and really spend time honing like, can I do this better? And so then if something happened where the timeline slipped or the project slipped, it wouldn't be because of me, but I wouldn't necessarily be like, oh, we should fix this now. I would say this is something that we need to address now so that we don't have problems later. Somebody would say, Oh, that's okay. We're we don't see any problems. That's okay. Six months later, when the problems would happen, I wouldn't be like, oh, I told you. So I would be like, okay, so this is the plan I wrote on how we could address this. And then going forward, this is what we need to do. And it was really about building that trust because I think from a political capital, especially as the new person, you have like zero trust. No one trusts you. It's like, where did you come from? I mean, again, I'm a IC, right? I'm not starting like at the top as like a CEO or C level. I'm like, I'm an individual contributor. What is she talking about? But my thing was it takes a lifetime to build trust. So I didn't take anything personally, but I always made sure that I could really focus in on how I can do this better. How can I control what I can control? But then also as things are moving forward, as I stayed longer at a company, people would come to me because it's like Nadina knows what she's talking about. She's lived these experiences. I lived many lives before. I would say that you know, from a previous company, we did multiple things, and this was the hiccup that we had, and it was a bad hiccup. I don't want that to happen here. Um, so yeah.

SPEAKER_02 22:27

The general theme that I'm hearing from you mentioning differences, right, is the proactiveness versus reactiveness. I get a sense that in the startups there's a lot of proactive thinking, thinking about issues and challenges that might occur if we do do things a certain way versus enterprise seems a little bit more band-aid on a problem, uh, and we'll worry about the operation at a future day, right? Uh, would you agree with that statement to an extent?

SPEAKER_01 23:01

Or yeah, I would I would definitely agree to it, right? Because again, from an enterprise perspective, you have how you've always operated. And being able to make that change and pivot on a dime is very hard for enterprises. So it almost has to be something that is battle-tested, something that they've really focused in on to say, okay, I'm going to change this process or I'm going to change this way of thinking. And even if on day one you say this, this is the new way we're going to operate, it takes time to do it at an enterprise. Whereas from a startup or a smaller shop, it's like, you know, you've done this thing twice and it's failed. You're like not going to keep doing it in perpetual motion because the uh the cycle, it's like a clock. The cycle is much quicker on a startup. It's almost like you're your second hand that's spinning very quickly. So you have to be rapid and you have to be proactive. Whereas like an enterprise, it's more like your hand. So it's moving very slowly. You're not seeing the change happen as quickly. And so it's hard to say, oh, I need to make this change very quickly. You know it's there, but we're gonna put a we're gonna put a temporary interim solution in place now, a band-aid, so to speak, and then we're gonna get to it eventually, but it's not something that's hitting us right now.

SPEAKER_02 24:17

Okay. What about from an expectation perspective? Did you feel your the expectations upon you in an enterprise were bigger or smaller than that of being a SB or a big mid-market customer?

SPEAKER_01 24:34

I think for me at that time, the expectations I would say at an enterprise were were smaller because the role was more defined. These are the things you should do. And you had these specific tasks. It's almost like a checklist, right? Whereas I would say at a SMB or a startup, you're wearing so many multiple hats that if I started doing something and I said, you know, today is the day like I can't do this anymore, people would be like, Nadina, what happened? Like, you're the person, you're you you you're the one. Like we have nobody else. Whereas at an enterprise, it's like, yep, you're a developer. These are the things that developers should do. There's that checklist, so you do it. Okay, great. If I started doing BA work, I think people would be like, Why are you not doing developer work? What is happening? Are you trying to be a BA? Is this a transition? What is happening here? You know?

SPEAKER_02 25:27

I think some people out there would argue that if more developers ask more BA-related questions in the discovery, then perhaps there'd be a better outcome. But perhaps a podcast idea for another time. I don't I don't know. But what are your thoughts there?

SPEAKER_01 25:42

Yeah, I think I think sometimes too, um, just going back to what um Dave was saying, it's kind of political as well because some people would feel threatened that you're stepping on their job. Again, I'm a very curious person. So I generally want to know what you're doing. Um, so if you ask a question and I'm in the room, I will ask a follow-up question because at the end of the day, you're writing the requirements for the work I have to do. And so one of the things um I always laugh about is that like people would start to use Salesforce words, but not mean Salesforce things. So they would say something like, you know, we need a trigger, but they're not talking about an apex trigger, they're just talking about a triggering point in a business, but no one is clarifying it on the call. And so the developers are leaving thinking, yep, we we could definitely do a trigger. They're thinking before and after. The business is thinking, close one, what are we trying to do here? But no one has actually solidified on what is it that you're actually trying to do? Is it more of a triggering point so that you can actually have an apex trigger, or is it a triggering point where you need something as simple as or small, like a validation rule? Um, and so that was that was something again where I wasn't afraid to be the person to say, when you say a trigger, what do you mean in this point? A triggering point for when an action is supposed to happen, or is more solutioning right now? Because that would happen a lot in an enterprise where people would start solutioning when we should be gathering business requirements and it could derail the calls.

SPEAKER_02 27:18

Okay. I want to talk a little bit about your strategic decisions to take certain opportunities when they came about uh in your career today. So we we first met just over three and a half years ago, um, had a bit of conversation back then, and you know, I recall even then there was this kind of proactiveness on on your part around only being interested in certain types of opportunities, being very selective about the certain career path that you were gonna take. Um, some of that was decided on sides of the company, some of it was industry focused. You're someone that I met that again talking about proactive and reactive, proactive in the decisions that you're making versus someone reaches out about an opportunity, I'll take it kind of thing. So your your career so far, every couple of years, two to three years, you you you know, you take that next step to learn something. We know there's a reason behind that, but do you want to share that listeners your philosophy on self-force careers and and trying new things?

SPEAKER_03 28:30

Yeah, so back on to Kira's question. How much of that was planned as opposed to happen since? It's like, oh, I guess we need to know Milsoff now, so I guess I'll learn it.

SPEAKER_01 28:40

Yeah, I think I think for me with my career, what I learned very early on is you're always gonna have managers. Um, I'll say this, right? I I haven't had a good string of managers throughout my career, so that was definitely one of my driving forces. It was something where very early on in my career, people always seemed busy. Um, they're looking out for themselves, not necessarily looking out for me. And so I decided very early on what I want to do and what I where I see my career, I have to drive my career. I have to be in the driver's seat of it. And it was something where it was like a light bulb moment. I can spend a lot of time where I'm learning this bit and this bit, but I really need to have this long-term plan. And I'm naturally a long-term planner where I plan these like decades of planning things that I want to do in the next five years, 10 years. But it wasn't always focused on, oh yeah, I'll be at this company in five years. It was more of this is where I want my career to be in five years. And that was a big distinguishing, um, I would say, light bulb moment for me, because I think when people think about careers, especially even where I'm from in the British Virgin Islands, you think of longevity of a company. And so even when I'm explaining to my family, yes, I'm switching jobs, they would be like, I didn't know what happened. Like, did you get fired? It's like, oh no, no, I just see more career growth at this other company. So I'm going to this company versus staying here where I see that my career growth has become stagnant. And it's it's one of the things in my career where I focused on two things. I focused on driving my career and really being proactive. What is it that you're trying to learn within this next few years? But then also being open to opportunities. I'm very much a believer of your opportunities will always come back to you, but it won't come back necessarily within, let's say, the next few months. It might be the next few years, but you should always get ready and be ready. And so be in that preparation mode. And for me, as I was looking at my career, looking at what I wanted to be, I knew I wasn't going to be a developer forever. It was something I had to come to grips with very early on. And I really had to ask myself, do you want to write production code? Is this something you want to do within your career? Um, I thought I was a pretty good developer. I really spent a lot of time honing my skills. It wasn't about, you know, counting lines of codes and things like that, but just really having people who can understand the code, whether they are developers or not. So could they read, could they, could I document the code in such a way that even if you didn't write code, you could understand it? So that was like a key um milestone for me, my developer career. Once I checked that box, I wanted to learn more. What else is around Salesforce as a platform? Can I launch this platform holistically? Uh, that was a big undertaking at the time. I think it's even bigger now when you tell people like, yeah, I'm jumping into Salesforce, where should I start? For me, I looked at it as I'm going to learn the outer edges of Salesforce. I want to learn all the different um technologies as they bring them on, not necessarily to the depth of being a specialist within each area, but more as a generalist. I see myself even as a Salesforce CTA, as a generalist on the platform, because I spent the time saying, okay, I've learned the back end of Salesforce. What is it that the admins are doing? What is the clicks? What is the low-code, pro code? Where are they merging? How can I ensure that I'm making decisions so that an admin's life is better, a business analyst's life is better, a solution architect's life is better. As I looked at my career, again, just from a technical perspective, because I was so technical from what I've done in school, from what I'm doing now, I leaned a lot on the technical side. So I went more from developer tech lead to technical architect, but it was something where I wasn't necessarily chasing the role, but I was chasing the what is the opportunity that I could have. So I didn't focus in on a specific industry early on. I went from real estate to medical to gaming to financial to high-tech. So bunch of different um industries. Some people might say, you know, you can focus in on one industry, just do financial and then do Salesforce within the financial space. But for me, I liked understanding what are the different business problems that each of these industries are doing. Okay, how can I extrapolate that now and apply Salesforce to it? Because Salesforce was the common denominator in my thinking. If I understand Salesforce from a vanilla perspective, from a real estate perspective, from a financial perspective, you start to get key themes in terms of regulations, you start to understand the nuances of the platform, but then you're getting this broad stroke across these different businesses. So you're not thinking about how do I solve a problem for the real estate market? It's more of where have I seen this problem solved in other industries and how can I now apply it to the real estate market? So that was uh one of the things that I also looked at. And it was something that was, I would say, as I was doing it, very different from what I saw my pairs doing. A lot of people at the time, you know, they would be at that company, they would be very focused on this is my role, this is my job, and I will focus in on that for three, four, five years. Whereas for me, it's like once I checked that mental checkbox that I had in my mind, the this is what I think I need to be successful in this role, it'd be like, okay, what's next? Now, I would say from the MuleSoft perspective, that was very interesting. I when I found out and learned about MuleSoft, it literally was one of those things where I had started at a company as a sales source architect. We were doing an integration problem. Uh, yeah, we were doing an integration uh problem that turned into a massive project. And it was something where, yep, Nadina, we have bought MuleSoft. You will be undertaking this um project using MuleSoft as the integration platform. And to say I was excited would be uh would be a lie. I very much was very nervous at the time because I had nothing, I had not known about the MuleSoft community. I hadn't gotten across to that part of the Salesforce platform as yet. And I was very worried, like, okay, yeah, we're gonna have an SI that's working, but I really don't know MuleSoft. So I then and there decided I'm going to definitely spend some more time learning MuleSoft, understanding the integration approach, understanding the APIs. Am I trying to be the best, the best MuleSoft developer? Definitely not. That was not the goal. But am I going to understand it enough so that I can communicate with the developers, the SIs, and make sure that my company and the project were successful? That was definitely the goal. And so throughout that journey, it wasn't something I was necessarily like, oh, I should pick up MuleSoft today. But it was more of, well, I've been studying a lot on integrations. I really focus on integrations right now. So it's a natural fit, a natural opportunity that is, yeah, let's explore this, let's be curious, and let's look at it from that lens versus a, oh my gosh, I'm gonna mess up this project. I'm so fearful, right? And that's that's something I try to focus on as well when I'm driving my career, that these things will come in, these opportunities, depending on depending on the day, I might not see it as an opportunity, but I definitely am not closed-minded to it. It's something where, as it's happening, yes, I'm gonna be nervous and I'm gonna give it that space to be, yeah, it's okay to be nervous. But at the same time, this is really fascinating. And I don't know of many people who are getting this opportunity right now. I think this is specifically just for me. So let's look at it from a more curious and more open approach and an open mindset.

SPEAKER_02 37:20

We don't want to give too much away on the MuleSoft side because I know Matthew's gonna cover that next. But just before we dive into that MuleSoft project in a little bit more detail, a couple of questions on the career perspective. The first is a question you can imagine I get asked by a lot of people do you specialise or do you become a generalist? So the first question would be knowing what you know about today's market, today's ecosystem, the maturity of you know, the amount of resources in the space, etc. If you were, let's say, a couple years into your career today, would you still take the decision to be more of a generalist, or would you perhaps stick in one industry and master that industry would be known as like a go-to resource for financial services, for example?

SPEAKER_01 38:10

Yeah, I think I think that's a very interesting question. I think for me, the one dimension that I would add to that is where are you within your life? Because early on when I started and I took on this journey, it was in a time of my life where I wanted the excitement, I wanted the energy, the late nights. It didn't bother me. I would say now I'm more grounded and more focused on I can hyper focus on one thing and then step out and have that overarching approach. Um, as you know, I don't work with just Salesforce anymore, I work with a lot of different other CRMs across the enterprise and looking at other enterprise applications as well. And so someone listening today, if they're early in their journey, I would say depends on where you are in your life. If you are at a point in your life where you can dedicate the time to honing the skill of focusing in on something like financial services and being that financial services um go-to person, you should definitely do it. But I know that as people look at careers, one of the things that I think make people, let's say, jump out of tech or jump out of Salesforce or go to other technologies is I'm doing this work and I'm focusing in, but I don't feel like I'm moving anywhere. And that's because when you're honing in, when you're really focusing in on an industry or you're focusing in on that specific skill, whether it's by persona of admin developer architect, you're going to be the last person to see the results. It takes a few years. Everyone will start to notice it and start to come to you and you become that go-to person. But I feel like you take some time to see that result. So if you know and you can say, you know, this is something that might take me five to seven years to master, I'll use the word mastery, and you're spending time mastering that part of the platform, then it's okay that as you're focusing in and as you're looking at where things are changing, that you're not feeling like left behind, or I should be doing this next big thing. I think sometimes people are like, I'll use AI for example. AI is out, agent force is out, everyone is getting scaled up on it. And you might be saying, Well, I spent all my time focusing in on financial services. Can I now pivot to AI? Because I didn't focus in on AI early on. I would say, now you're adding AI on top of something that you've already mastered. So someone starting net new would have to do both. Whereas you're doing the diff of, okay, how can I apply AI to a space that I specifically know? Bread and butter, like the back of my hand. I know financial services, I know the nuances of it. Now, if you're more, let's say, mature in your career where you know life is happening, you have a family, things like that. If you're looking at the generalist path and you're more of a jack of all trades, master of none type thing, I think that's okay as well, too, because you can say, I've done all these different industries, I understand these high-level business problems. I can work on both the business side or the tech side. So you give yourself the opportunity to have more opportunities, but it's something that you have to constantly, I think, nurture as well because the platform is changing. Um, saying that, okay, I'm going to start as a Salesforce admin might not be the thing I would say today. It might be where do you see yourself fitting in within the Salesforce ecosystem? There's Tableau admins now, meal soft admins, right? And so as you look at what an admin is across the platform, depending on the company, it might mean multiple different things. If you work at an enterprise, you might be able to say, like, yes, I'm just a I'm just doing MuleSoft administration. I just do Mule Soft architecture. Whereas if you're working at maybe a smaller boutique company, they might need someone who is more of a generalist. I'm an integration specialist, so I'm working with MuleSoft, I'm working to integrate data cloud. So long story short, I would say as things are changing, as we're seeing the different resources, as we're seeing where the platform is going right now, you don't necessarily have to focus in on one or the other, generalist versus specialty, but you should make sure that you're at a time in your life where you can give the devotion to both.

SPEAKER_02 42:54

Okay. In terms of other products, whether it's Salesforce related in the Salesforce family or external to that, there is a fair statement fact that the Salesforce market has become a little saturated, especially for newcomers in the market that are struggling to get their first break, their first opportunity. You mentioned yourself, you mentioned Tableau. Thinking outside of the Salesforce family of products, any other suggestions where, from what you've seen in your career, there might be a parallel product to start with, i.e., some other CRM, to then enter the Salesforce ecosystem with more of that business and technical acumen versus just kind of you know interviewing for entry level Salesforce happening roles alongside 100 people and it being a numbers game.

SPEAKER_01 43:50

Yeah, I think yeah, I think it's interesting that you say the market is saturated. I felt like the market was saturated when I first started as well getting that first role. I would say something to really focus on or look at is some of the other roles that might not necessarily go noticed within Salesforce or might not have, let me say it like this, might not have Salesforce within the title. So things like technical project manager, technical product manager, where you're working with not just Salesforce, but you're working with other technologies. I think it's somewhere where you can start as well. Um, I hear this a lot too because I I have a developer background. So people would come to me, you know, the developer market looks saturated. I don't know if I want to start learning code at this time of my life. And I would say, okay, that's great. There's other things that you can look at. There is um low code that you can look at from the Salesforce perspective, but what are you trying to do with your Salesforce career? Let's let's focus on that part first. Are you trying to be more of a technologist? Are you trying to be more on the business side as a technologist? Where are you seeing yourself? Are you seeing yourself working at a partner where you're more on the consultant role? Are you seeing yourself working as a customer where you're doing a specific job title and specific requirements? Because I think even that has a role to play with where you get in in terms of a company. If you start at a partner, you start in, you're starting at a consultant. I would say those skills are still relative where you're more of not necessarily a generalist, but you can really focus in on I'm going to be a consultant for I'll do the financial sector again. So I'll be a consultant for the financial force, or I'll be a consultant for your financial um your financial information that you're doing. So it might be more of a BA role, it might be from the implementation role, it might be where you're doing more of the project management um type role, but you're still under this umbrella of that partner where you're a resource, you're driving that implementation. Whereas at a customer, you might work in the technology side of the company, you might work more in the business side of the company.

SPEAKER_03 46:23

Yeah, so to tack on, um, I like to think in terms, and I this is advice I give to junior people all the time, it think in terms of complementary skill sets. So I have a have a core skill set. What other skills can I bring on that not only are a good skill in and of itself, but enhance my current skill set, right? So if I'm a solid developer, let's say I want good BA skills, because that's going to make me a better developer. And the BA skills are valuable in and of itself, maybe some project management skills because if I'm organized, I can use that project management, teach me organizational skills, that makes me a better development. I can plan, that makes me a better BA, right? Um, to put that towards industry, right? Um right, if you know an industry real well, that makes you a better developer within that industry. So you want to think in terms of complementary skill sets so that you add skills that not only are valuable in themselves, but really grow you or grow all your other skills to kind of at the same time. Um that's how I tend to pin it down. Um the other thing I would just say that the softer skills and the industry skills seem to be a lot more resilient to market fluctuations than the hardcore type skills. Um and then if you have enough of them combined, right, it becomes easy to pivot you know, away from let's say a particular BI platform. So I need to move from Power BI to Tableau, and all my other skills are in place, and then you you kind of the risk of getting hit all at once and finding yourself unemployable, right? Um I've it's happened to me multiple times in my career um where I just had a core skill that just went completely obsolete. Um the product died, the language died, whatever it is, and you have enough skills around that, it's not so difficult to kind of replace it or even have that at a low-level skill and then still um you know get another job.

SPEAKER_02 48:26

But that's not specific. So I think it's really important you mention that because um, you know, both both it's a it's a theme both of both of you talk about, right? Um we talk about before soft, we talk about Tableau. Let's think outside of Salesforce, what are especially being in thinking enterprise environments as well, right? Um, where naturally the volume of opportunities will be with enterprise because they employ more people. So, what are those skill sets? Um, like Net Suite, for example, or ServiceNow, what what are the what are the systems that people should be looking into to mitigate? Obviously, Salesforce isn't going to disappear overnight, right? But what are the other areas, any any particular kind of recurring systems that you guys are seeing that you'd recommend?

SPEAKER_01 49:16

Yeah, I would say um workday is another one from the HR perspective. Um, and again, you know, with enterprises, there's a lot of, like you said, there's a lot of systems that you can look at. Um, but to Dave's point as well, I think having and focusing in on some of your softer skills as well will help you. So things like executive presence, where you're able to articulate what you're trying to explain, whether you're talking to your developers or you're talking to your C-suites, is important. Having great communication skills, listening not just to respond, but listening to understand what's not being said is a very um very important skill when it comes to even gathering requirements. But from a system perspective, there's there's no shy of systems on enterprises. And when it comes to enterprises, whether it's through MA acquisition or just the growth of the company, there's always going to be uh multiple systems that come in. So multiple CRMs, you have like your SAPs of the world, even your sugar CRMs, and then there's always someone's role, someone's job to help consolidate those capabilities. I would also say to you know, knowledge management systems are also in place, learning management systems, anything where I would say end-to-end, an enterprise needs to be functional to be able to do and conduct business, even your survey systems, your Qualtrics of the world. Um, it's one of those things where there's no shot of systems in any enterprise or any company. But really, when it comes to how do you pivot your skill, um, so I'll say this hopefully knock on what it doesn't happen, right? It's essay uh if Salesforce drops out of the sky today. Let's say Salesforce is gone. There's no more Salesforce, there's no more Salesforce as a CRM. Can you pivot your skills to another CRM? Will you switch technologies completely? I think those are the things that at least I think about when I was driving my career. I didn't know where Salesforce was going. I didn't want to put all my eggs in one basket. Um, even when I when I had a role like now where I don't have Salesforce in my title, I know for some people it can be very um, I don't want to use the word scary, but it's like, well, will they know me as a Salesforce person if I don't have Salesforce in my role? I think for me, it was more of how can I make sure my uh I'm versatile? So if Salesforce happens to go away or Salesforce is no longer there, can I pick up another CRM? Is there another technology that I can go to where I don't feel like I pigeonholed myself in Salesforce? But I also have friends who came from other CRMs and then came into Salesforce, and it was a natural compliment for them because from a CRM functionality, they understand CRM. So now you're just learning the nuances of Salesforce. So as folks are looking at their careers, as they're looking at outside of Salesforce, and they're looking at all the different technologies that you know enterprise companies will have, they can look at other technologies, they can look at the softer skills that they need, the complementary skills, as Dave mentioned. Um, but again, no one necessarily will help you put this entire puzzle together. Um, so you really have to know what you're trying to do, know what you're trying to pivot on, and you know, seek guidance if you're still in, well, what should I do? How can I take these skills that I've learned now and make them complementary to another industry or another company?

SPEAKER_03 53:16

Yeah. Um, just to clear up a small misconception for our users, because this is something that makes me crazy. Um, people talk about like Salesforce is not just gonna disappear. Um, and that's true, it won't. But what could easily happen is people stop investing in it enough that when people start losing their jobs, the job market is very competitive. People aren't hiring, they're just maintaining the people that they are. And that can happen with a small 10-15% you know reduction, let's say, um, and it becomes very hard to get a new job in that space. It doesn't have to just you know blow up. And again, I've been through this twice already. Um industry or whatever the technology was on just blew up. And to this day, like you're talking 15 years later, I sometimes um get an old client call me, help, can you come help me transition off this legacy system that you helped us build 20 years ago? Um and again, it it there's no work in that, but there but you just can't get a job in it, even though the systems tend to be around forever.

SPEAKER_02 54:25

So um, thank you so much, Nadina, for joining us today. Um, it's an absolute pleasure. And you know, I know for us, super beneficial. I have no doubt for our listeners, um, they're gonna really enjoy this episode. So thank you for your time.

SPEAKER_01 54:40

Thank you so much for having me.

SPEAKER_02 54:42

Um, so for for our listeners, don't forget you can follow us on LinkedIn uh for exclusive content, uh, some behind the scenes clips with Nadina. Um, and you know, we appreciate your support and continue to download and subscribe to the CRM to accept show. Thank you.