Description
A panel of leading Salesforce experts discuss what you can do to get the most success out of managing your Salesforce implementation. This session recording from the 2021 Gearset DevOps Summit delves into the steps of a Salesforce implementation and the role of DevOps in guiding your strategy and tooling.
Ian Gotts, CEO and Founder of Elements.cloud is joined by: Stella Michael, Director of CRM, Spectrum Health; Lex Makuta, Senior Salesforce Admin, DoorDash; Emily McCowan, Salesforce Architect, Deloitte Digital; Geoffrey Bessereau, Senior Technical Architect, Persistent Systems.
Learn more:
Transcript
So it's now time to move on to our final session of the day, which is our live panel on successfully managing your Salesforce implementation hosted by our own.
Joining in are gonna be Stella, Lex, Emily, and Jeff. And I will let them introduce themselves properly in their own words. So I'll say hello, Ian. Welcome back. Over to you.
Hello. Things off.
Right. So welcome to this session. I think it's a great way of finishing off the DevOps summit, which is a chance to talk to some practitioners who spend their life worrying about DevOps. So I was just adding up.
I think there are fifty five years worth of, experience around the table. And we're covering, I know, Australia, America, India, France, Germany, and the UK in terms of experience. So I to make some introductions. So, Stella, give us a wave, Stella.
There we go. Stella spent eight years at Spectrum, where she was grew from an app, developed ground list all the way up to director of, CRM. So, again, inspiration for those of you who are starting your career in DevOps. Before that, she's obviously spent a number of years in in the development roles, mostly in India, but now she's based in, in the US. So Jeff Jeff?
Yep. Hi. Hi, Jeff. There we go. He, actually, any enviably is in Loire in France, so, very popular for French white wine there.
Just joined as a senior technical evangelist at Persistent Systems. But prior to that, he's actually spent a number of years as a consultant in running Salesforce implementations in both France and Germany. Other interesting note that he, he's been running the SFXD Discord group, which I went and joined this morning and then got suddenly started going, oh, there's more things to read about. So he's been running out for about five years. So, again, if you've not joined it as I haven't, I encourage you to go and join the SFXD, Discord group.
So then over to Emily. Give it Emily, give us a wave.
Hi, Emily. Emily is based in Australia. She's a Salesforce architect for Deloitte, but you're also, the women in tech leader for Brisbane. Interesting different background completely. Started life as a business analyst and, but it's bring brought a a ton of biz Salesforce implementation expertise coming that route. And then, last but certainly not least, Lex. Hi, Lex.
Lex is a senior Salesforce admin at DoorDash. So, obviously, the last couple of years have been, probably the busiest you've ever imagined in terms of the the growth of DoorDash.
But, again, another person who spent life as, as a consultant, with FinancialForce. So, again, he's not just seeing, DevOps from the perspective of DoorDash, but seeing it from from a client perspective. And, he, like I, are based in the Bay Area.
So great introduction some introductions there. You don't wanna hear from me. What you wanna hear is from them. So let's let's think of it. Let's start at the top and go, okay. I'm thinking about Salesforce implementation strategy.
So maybe Stella is sort of a director of CRM where you're taking a broader view. How do you think about your implementation strategy, and what do you what are some of the critical factors that that that come into it when you're devising that strategy?
Yeah. First of all, thanks for having me, and, really a pleasure joining with this amazing crowd here. So I think like any other initiative or project, it is critical to have, you know, an implementation strategy. And I go back to Carter's change model.
You need to have that guiding coalition that decides and says, okay, this is what success looks like. And so to gain that align alignment, you need to identify your problems first. The biggest thing that or the trap we fall into is we bring a solution, then define the problem. I would highly encourage to identify the problem first, the right problem, and then bring your solution to it.
With Salesforce, it's such a big platform and it has so many solutions. And so we get carried away in what we could do. We wanna make sure that, you know, we are aligning on those success metrics way in the beginning. And for those of you who are starting this newly, I would highly recommend that you go back to revisit that because a lot of implementations with Salesforce are, you know, long term on an extended period.
We learned so much during that journey, but we don't go back to measure what success looks like. So we do something during the process we implemented, but then it's not exactly what we wanted. So I would say, you know, it's really important to align on what success looks like, get that group together, and make sure that they are, you know, okay with what what, the implementation plan is and then move forward. The other thing I will say is we need to think about the short term and long term.
You compromise either or or you will fail. One simple example, you customize the heck out of your platform for your short term gains, but then you can't scale. You can't, you know, make the most of the upcoming upgrades. So I would highly recommend you to have the long term goals in your mind, but then I also plan for your short term wins in between.
Don't compromise on, you know, scalability and maintainability and sound architecture. So those are the things I would recommend, for those of you starting off and considering newer, implementations.
That's fantastic. I mean, I think some of the concepts of central excellence maybe come into this in terms of getting that vision and leadership, but none of this happens without people. So, maybe, Emily, can you can you talk about sort of how you how you align some of the teams around some of the goals that Stella just set out?
Yeah. For sure. I think probably the most important thing is just to communicate with your team. Right? You have to make sure they understand what the goals are. Why are they your goals, and are they shared goals? Have your team had any input into helping set these goals?
Having that, I guess, input where they get to to help shape the direction of the implementation and shape those measures of success will really get you, so much of that buy in. So maybe they'll even be able to set their personal goals that will help roll up, to ensure that your overall team and overall implementation, are gonna reach those kind of overarching goals that we've got.
So maybe even applying VT Mon So, I mean, that that VT model approach works everywhere in every team. So I guess it that is back to Stella's comment about, yeah, let's understand what success looks like. You're talking about Teams.
Jeff, I know that it we're still early days in terms of DevOps in terms of defining some of the metrics, but have you got some perspective on some of the measures we should be at considering when we look at the the the m of v two mom?
Well, for a specific v two mom implementation, I'm probably not exactly the right person to ask, because, well, you know, it is very specific to, specific to companies. But regarding success and implementation of DevOps, I think one of the major KPIs that can be followed and how you can actually measure your success is going to be, two things. First of all, the amount of time spent on deployment and second of and second of all, the amount of pain spent on deployment.
And I know, for a fact that there's a lot of people out there, consultants, admins, just like even architects that just dread going live for so many reasons. Right? Because of test failures, because of just the amount of time that you need to spend actually checking that everything is in there.
And DevOps is actually the solution to that because if you continue deploying in a way that you are sure things are going to end up where they're supposed to be because they do so all the time and it turns out that going live for you is literally just another cog in a big machine, and it's the final step in something that is for you just, like, basically just a Tuesday.
Well, all of a sudden, you you get those both issues solved because time to deployment is cut down. I mean, I wanna say by a factor of ten and just like pain is cut down to zero. Hell, I just went, like, with a deployment today, and I clicked the button deploy, and I went to get myself a coffee. And then I came back, and it was done in five minutes. Why? Because, well, I deployed it ten times before because I knew exactly what was gonna happen because, well, I automated everything.
Those for me are the two biggest KPIs, pain and time.
That that suggests it's not a three monthly deployment. It's something that you're doing more frequently, which is, I guess, what is what we're all aiming at, which is is is delivering smaller incremental releases. The the business users don't wanna wait three months for release. We don't wanna have a massive high risk release that's going out in three months. So I so you painted a picture of why DevOps is important.
So when is it is there a certain size organization or when's the right time to deploy DevOps or these sorts of DevOps approaches?
I think it depends on your profile. If you're internal to a company, it's only going to make sense after you hit a certain size. Like, if you if your deployments are just like ten fields in a report, obviously, just like DevOps is gonna be a waste of your time. Starting the moment where you actually get a few more things, in there, whether it's Apex, whether it's lightning web components, whether it's anything else, then it starts being a bit more sensible. Where you draw the actual line is probably something you wanna discuss with your manager, doing a cost benefit analysis about how much time you're gonna spend running the tool and how much time you're gonna save on deployments. Right? So this is gonna be very specific.
For consultants, so and for anybody out there that actually deals with multiple orgs, I wanna stress that I think that if you're not doing DevOps right now, if you're not starting to learn it, whatever your whatever the size of organization you're actually touching, you're already falling behind because the reality is that the future is going to be continuous development across all sizes of the boards. And if you do it for a very small client, that's basically just you getting your training wheels on and making sure that you can make it work with something that is low criticality.
And the clients shouldn't pay for that, of course. You can just, like, you know, get a bit of time on your own to actually implement this. But I think it is very much needed because at the end of the day, if you touch fifty orgs in a year, well, obviously, you don't want to have to go through the pain of knowing each org by heart before you can deploy. You just want it to happen. And for that to happen, you basically just need DevOps. It is a core skill, in my opinion, and one that most people should start building upon right now.
I think also with the timing, it's it's important to try not to have any major projects going on while you're also implementing DevOps. I think a lot of times people tend to think that this is something we're just gonna slide in, and it'll work with everything else. But if you have a a large project like CPQ go live or something like the stocks and client audit, which we had both happening during hours, it's you you might you can still do it and you can be successful, but you might have less adoption right away, and it's gonna take some time to really catch everybody back up.
And I think adding to that, I would say give yourself some grace and time to learn the process because I think a lot of the times, you don't know what you're trying to set up. And so what we did was, like, give ourselves some time to get a rhythm. You still need basic DevOps set up, but, you know, there will be a time when you're gonna put stakes in the ground and say, alright. This is how we're gonna do it. These are the roles and profiles you're restricted to, or here's the cadence on how frequently we wanna release. So all of that will come gradually.
Fail fast, learn from it, and and try to start putting some of those, you know, constraints or processes in place. So that way you're feeling like it's an incremental progress rather than a dump on your teams.
So what I'm hearing here is it's it's not just switch to switch. It's like, oh, we're now gonna do DevOps. I mean, we're all doing development. It's like but they actually you take you need to take some time to implement a change in the way you're working potentially, and any change project takes time. And therefore, it needs to be have a return on investment, be funded, and give yourself the space and the time to actually implement it rather than trying to, as Lex said, try and slide it in alongside everything else you're doing.
I think I would just add to that. Everyone's doing DevOps. You're doing it now. It's just are you doing it well or or are you not?
So I thanks, Emily. Ab absolutely. I think we're all if you're making any changes, you're doing DevOps. The point is actually, are you doing it repeatedly?
Can you do it fast? Can you do it as Jeff Jeff said? Can you do it without actually going and apologizing to the user? Because I'm sorry.
The system was down again. And, I mean, Facebook's six hour outage was a small config change, which went went which went badly wrong. And I think, people recognize that there's no such thing as a small change if it's not done in a repeatable way.
So let's let's move to the more positive rather than six hour outages.
So if we've if you there are people out there listening and going, we yeah. We do DevOps, but we don't actually have the sort of structure that you're talking about or that we've heard over the rest of this morning.
How do I get started? What are the first things I should be doing?
I know I know for at least when I think about DevOps right now, it it's really important to know where you wanna be. When you see a lot a lot of these. I'm sure you've seen a lot of the examples on here. Everyone has had really good PowerPoints and graphics, and you can probably piggyback on a lot of their success with your own company.
But the first place to start, I would say, is setting realistic goals and where and figuring out where you wanna be with the real world examples. There's a lot of other companies out there who've done it successful. You don't have to start from scratch. You don't have to start with no experience.
You have a lot of people out there.
And, I mean, important to start with what level of testing and how you plan on getting that testing done without blocking developers.
So, Stella, from your perspective, people will come to you with a budget going, if I I went to the I went to the summit, I I we need gear set. How do I buy it? How how do people come to you with a business case, or how would you construct the business case? That's the first question. And then I think the second question for the audio for for the panel is, is it bottom up developers do stuff, or is it top down in terms of driven change? So the first one is is let's pick up the business case.
Yeah. This is something I tell, like, as developers, we're not good salespeople, but I do tell them that you gotta wear your sales hat on and you need to talk money and value and time to market because that's the language that executives speak. So you should be able to translate that. And, I think with the pandemic, you probably have heard, you know, stakeholder capitalism is becoming more popular.
It's not just about shareholder capitalism, it's stakeholder capitalism, and we need to make sure that our developers are part of that stakeholder group. And so many companies are trying to, you know, increase employee engagement and productivity, and what better way than doing DevOps. Right? So I tell them to think big, and not be in the minor details, but also be able to translate that and say, hey.
These are the benefits you're getting built in quality. You're getting time to market. You're getting more frequent releases on demand if you need be, so on and so forth. So once we have that, we also quantify the number of hours you're trying to save in FTE.
So, for example, if it took us days to get one through the path to production, now it's just taking hours. You know, as, you know, Jeffrey just mentioned, it was just a click of a button. He had coffee and came back and it was done. Right?
So that's a big value add versus having to do a big long process. So that's something I highly recommend is as leaders, consultants, when we talk DevOps, we should be able to translate it in a language that executives can understand. And and mostly, I would say nine out of ten times, you usually get the buy in if you say the right things and make sure it's translated the right way.
The trick here is how how do you where do you get those numbers from? You took I mean, it's building a return on investment case. I mean, a a number of you here on have actually on the panel have actually had to go and build that and and worked out where those numbers come from. So some ideas for for people who are listening about how to construct that business case.
I think my suggestion would be started with your baseline. So what we did was and that's where I said, give yourself some time. When you do your couple of releases for a few months, you know how much time it's taking, then it's very easy to quantify and say, alright. If we do buy, for example, like you said, you know, kind of a tool and use it for deployment, here's what you get.
You know? What are some of the automated options that you can build in? What are some of the testing tools like selenium or whatnot that you can build in that can save those manual hours that we can be redeployed? So I would say have a baseline, look at general metrics, go back to your history and see how much time you've taken, what are some of the pain points you've had in quality, how many times you've had to roll back because your quality was poor, or do you even have an ability to roll back?
Right? There are a lot of those things that you could use, but you do not definitely need to start with a baseline or some kind of a historic reference. So then, you get the audience to listen to say, alright. We we see the we see you.
We hear you. And then then it'll be usually, you know, good to sign off on a lot of the, ask that we put forth. Yeah.
I think it's pretty hard to actually set KPIs for DevOps because a lot of what you do is in GitHub or with releases. And it is important to set KPIs in early so that you know how successful you are being to keep proving your point and proving the value of of your DevOps ROI.
I don't have too many KPIs available directly right now, but I I think it's it's per your business if you want the amount of tickets going live per quarter, the amount of the amount of bugs you've had, Roblox you've had to do. If you can really prove that and if you set those KPIs early, then it you can you might not it'll you'll be making your case as you go along even if even if people didn't believe in you right in the beginning on DevOps.
Emily, I mean, we talked about at the beginning about people, but there's a war for talent here. We we all know that a talented developer is ten times more effective than a than an even an average developer. So surely DevOps, there must be some view about improving the quality of the life of of our DevOps teams as well there. I mean, maybe it's intangible, but it actually it has an impact.
Yeah. Absolutely. And, that's a really good point that, finding the tech talent who has that experience not only in developing on the software that you are developing, in this case, obviously, the majority of us are developing on Salesforce, but can you operate the DevOps side as well? And I think that that's kind of a, an uplift that some of the more junior developers can can do to, stand out from the rest.
But I think, yeah, when you're thinking about how your team is engaging, how they do their day to day work, I think I saw a statistic.
I cannot back it up with a, a reference, but something like less than half of the people at work are fully engaged and invested in what they're doing in the day to day, which I think kinda calls back to, like, how how are they aligning with the DevOps strategy? Do they understand it? And is it making their lives better? Well, I mean, it probably is because it's gonna speed up their deploys. It's gonna simplify, how they deploy. It's gonna mean that they spend less time resolving bugs or panicking because there's been an outage that's been caused by something being missed.
But it's about, I guess, how do you how do you communicate that again? And when you're looking at the metrics, I think, yes, you need to be finding out what are the the issues that, I guess, DevOps could be solving, what are the, dollar amounts behind those because that's what your senior leaders are gonna wanna
