Description
Catch up on this webinar with Maritina Tsembelis (Strategic Partnerships Manager at Gearset), Ian Gotts (Founder and CEO at Elements.cloud), Susannah St-Germain (Architect Relations at Salesforce), Rob Cowell (now DevOps Advocate at Gearset) and Jack McCurdy (DevOps Advocate at Gearset), as they discuss how to get started with Salesforce DevOps, the challenges and opportunities it presents, and the future of DevOps in the Salesforce ecosystem.
Learn more:
Transcript
Up next, we have our panel session where our experts will be discussing key challenges, opportunities, and trends within the Salesforce DevOps space. Moderating the session, I'm pleased to announce is Ian Gotz, the founder and CEO of Elements Cloud.
Ian, hopefully, you've been able to join us.
I can see Rob is joining as well.
There's Ian. Welcome to the summit, Ian, Susanna, Rob, and over to you.
Thank you so much. I'm delighted to be able to host a panel session. I think, the the sessions you hear over the the course of this, summit are great, but, actually, having the interaction between people who live and think about technical architecture or and and how that fits with the whole DevOps cycle is really important. So first of all, let me just introduce the panel.
So like I said, my name is Ian Gox. I'm the founder and CEO of ElementStarCloud with an ISP helping people accelerate, the Salesforce changes and implementations. But you don't wanna hear about me. You wanna hear about the rest of the panel. So Susanna Sur Germain, she actually has spent a huge over ten years in the Salesforce ecosystem, working her way through as being, working with customers. She was a citizen school, the management science for health, and then was the technical architect of Boston Scientific.
And after that, she then took a step into Odesiva, which is the, the French backup and compliance company. So she saw life as an ISV, but then got, headhunted into Salesforce where she is a lead evangelist in the architect relations program.
Again, really important in terms of just setting the whole scene for how we the whole dev ops cycle.
That program, again, really, really important and very high profile where Parker Harris, the cofounder, actually is, really as the sponsor and the support of that. So, again, Susanna brings three different dimensions, the view from inside Salesforce, the view as an ISP, but also a number of years working actually in the in the heart of of companies making this stuff work.
Moving on to Rob. Rob, fellow Brits, Rob spent more than twenty five years in technology and, grew up as many of us did as developers and all the way through to managing managing big systems as both business and analyst, but also as a technical architect.
So he's he's seen that whole cycle, working with companies like Ticketmaster, Western Union, Bank of Montreal. But now he is a director at a consulting firm. So, again, bringing another another perspective as working with multiple customers, and I see him posting on, why admin is doing quite a lot. So he's actually got probably some some really good really good examples of how to do it well, but also how to, what needs to be improved.
And then finally, Jack McCurdy is a DevOps advocate at Gear Sets. He's been at Gear Sets a number of years both as a, as an account executive, but now he's actually stepped in to be the evangelist spending time, talking about DevOps, trying to encourage us all to adopt great DevOps practices, but also move from almost heroics as we see a lot of DevOps all the way through to excellence, which is where we all need to get to.
So let's let's go let's go to the panel. So the the first question and the the questions are gonna be structured around what are the challenges, what are the opportunities. But then I think for most people, it's how do I get started. So, first of all, what do we think are some of the main obstacles? So, Susanna, can I start with you? In your time at Boston Scientific, big teams, what were the the real obstacles for getting started with DevOps?
Yes. Absolutely. So I think one of the the big challenges, especially at large enterprise companies, is all around change management.
So folks, you know, likely already have a process for deploying their changes. And as if the project is complex, usually, that process, especially if they're not using, DevOps and CICD already, the process is likely complex, and it has lots of different steps. There's, you know, predeployment deployment processes. There's post deployment steps that need to happen.
And oftentimes, this process can be both complex and a little bit brittle as well. So I think there is a lot of resistance around changing what maybe might not be working perfectly, but is working to take the leap into the big unknown, right, of of DevOps, for folks. So that I know that was a challenge for us, at Boston Scientific. It was, you know, changing that that mindset, changing the culture, and changing how we thought about our releases.
You know, lots, yeah, lots of scripting in DevOps.
I think that number one, change management. I'll leave it at that.
So, Rob, I mean, you've you've been a you're now it was a life of a consultant. So you are now goading and coaching and guiding. So, again, change of obstacles, or do you see some of the obstacles being technology as well?
Yeah. I think a lot of the challenges are gonna vary depending on, you know, the environment you're in, you know, in terms of, you know, small client, big enterprise client. You know, they they all bring their own sets of challenges. So, you know, I have clients across that spectrum. You know, the big enterprises tend to be actually the the hardest minds to convince. You know, there's that classic analogy of, you know, trying to to steer an oil tanker.
But I think, you know, there is a very much one of the biggest obstacles I've noticed in in organizations of all sizes is the that's the way we've always done it mentality. You know, it's that resistance to changing all its forms, not just in DevOps.
And it's it's trying to kind of educate and educate and encourage, perhaps, that, you know, if only you could see the potential savings of of time, effort, and the gains in productivity, you know, sort of side by side, you know, you'd be more inclined to to want to change, really. So it's the technology piece that you know, despite being a a hardened technologist at heart myself, I find that actually the technology is the easiest barrier to to knock over. The the most difficult one is is just the, you know, the persuading folks to want to actually change. That's that seems to be the biggest barrier.
So that may be the DevOps teams. So is it a lack of support at senior executive level to say to see the benefits?
There's a little of that.
Yeah. And and, again, you know, I'd I'd kind of sort of circle back to, you know, that's the way we've always done it mentality. You know? Some of the the ops teams that I work for, you know, so they're not necessarily dev ops teams yet.
They're they're more sort of, you know, committed ops teams. You know? They have to manage a raft of systems, so not just Salesforce. You know?
One of my clients is a is a big bank. You know, they're looking after front office trading systems, databases, you know, Microsoft stack, you know, mainframes, all sorts of things, including Salesforce. So, you know, to to get them to sort of change that model so that there's a a one size fits all is is kind of what they want. But, unfortunately, you know, there isn't always a one size fits all for DevOps at the technology level.
The process level, absolutely, you know, we can we can win hearts and minds and just say, well, you know, here's a process we can adopt. It's just the technology that changes to fit the platform.
So, Jax, presumably, that's a lot of what you're spending time doing now as as as evangelists is trying to actually paint a picture about what the future could look like.
Yeah. Absolutely. And, Susanna and Rob have have said it all really is, and it is it is about helping, helping the teams that are on the ground. And throughout my experience, it's always been those end users.
They understand that they want things. And, yes, that might be because it wants it helps them operate faster. It helps them do their day to day jobs and makes their day to day jobs a little bit easier. But, translating that into the cost of what if we do nothing to the executives is traditionally quite hard.
And a large, large portion of, portion of my job has been is helping helping those teams try and show some of that value ahead of it, ahead of it happening. And there's and there is now, great stories coming out of the ecosystem, of it happening, some real tangible results that Renee will be able to put in front of, those executives and say, hey. Look. If we do this, then, we're gonna be successful, and it could be valuable.
So, so for sure, I would definitely echo, Susanna and Rob's comments.
But but what are the if we think about DevOps, you tend to think of, oh, it's the development managers. But presumably, there's more than that. So, I mean, again, I'll I'll get us to think for Susanna. First of all, I mean, at Boston Scientific, you had huge huge set of users, huge teams. So who are the different people? Who do we need to get onboard first? And then after that, is there a sequence, or who who which are the groups we need to get onboard?
Definitely. So I think, normally, what we've seen is that the product teams, like we're hurting heard hearing about before, the product teams who might include a technical lead and developers and admins, there's they need to get on board. But I think oftentimes, we start there, and I think that that that's a hard place to start. I think sometimes the problem bubbles up there because just as an example, you know, developers have, multiple teams are overriding each other's code, and that's a a problem that is black and white that needs to be solved. That's a, you know, that's, an issue at hand that's immediate to to people in the product product or project teams.
But I think in addition to that, two important roles that maybe should be thought of first in from a planning perspective.
One is a release manager. So making sure that there's someone who really owns the not just the tool, not just the technology, whether it be gear set or another tool, but who owns that tool and the processes and who's making sure that people adhere to those processes and is really a champion, within the team who can help enforce that all of the project teams are using the right process and using the right tools in the right way. But I think we already alluded to it. The other very important role that, in my opinion, needs to be one of the first, the first people to get by and is an executive stakeholder to be a true champion of the the this project to move to a DevOps structure.
And I and I think for me, in order to get by and I know that we will probably talk about how to get buy in from those groups. One of the ways to get buy in from an executive leader is to to reframe sort of who we think of as the end user. So we we think, like, as a, you know, former developer admin sort of architect, we think of our end user as the folks who are using the system. But I think we need to remind ourselves that the ultimate end user is our customer and is the reason why we're using Salesforce in the first place.
And I think if we frame sort of the the benefit, that our customer is going to get from us moving faster, from us having less bugs, from us, being able to release new features at an increased rate. I think that is a message that, can can resonate more with executives than necessarily it'll save our developers time or it will, you know, make sure that we are releasing faster. Like, why does that matter? I think we need to dig into why all the why do we need to make sure our developers are more efficient?
Why do we need to move faster? And at the end of the day, that's the customer.
So That's great.
Let let let me just drill in a bit more, which is you're now an architect in the architect relations team. Is the architect an important part of this, or are they how does that fit?
Yeah. I would say an architect's an absolute important part of this, especially from that. Once we get the buy in to move forward and maybe purchase a tool or agree to change our process, the architect is often going to be, a key stakeholder and sort of spearhead that, initiative of adopting a tool, of setting the strategy, of of helping to define with the larger team, you know, what does our branching strategy look like? What does our what does our org strategy look like? Those are all conversations that the architect is definitely going to facilitate and help to lead and guide the team depending on, the requirements of the the projects that are happening in the Salesforce, landscape at the organization.
And, also, we got the business analyst in this. Excuse me. We need to make sure we're building the right things. There's no point in DevOps building it really quickly if we're actually building the wrong thing. So I think we talked to the beginning about it's not don't think of DevOps as how do I get from, user story or work item to release. It's actually how do we go around the entire implementation life cycle.
And I think the architect is pivotal in all of that Absolutely. To make that work.
So let let's let's move on and just start thinking about what what are the critical components we think of a DevOps strategy. So maybe maybe, Jack, I mean, you're you're spending time talking about this all the time.
Can you can you lay out some of the things which need to be in place to actually make sure that we deliver the right the right applications more quickly?
Yeah. For sure. So, we've spoken a spoken a bit already about, about the buy in of key key parties. And, Susanna mentioned having a champion, first of all, the technical level and the executive level.
I think, first and foremost, fundamentally, if you don't have those, then, then you're gonna you're gonna set yourself up for failure. I think the number one reason, that we see implementations not take off or hereby implementations not taking off, as as intended from from the start is because of that championing and then being able to filter that excitement down, down through through the rest of the team. So that really needs to be a solid baseline for, for setting yourself up for success. And I think what's what's important is what a lot of people don't think about is is the end is is or think too much about is the end vision.
So they think, oh, we wanna get to here where we are releasing once a week or two times a week or whatever whatever your really good looks like. They always think about that. But they don't think about the milestones and the incremental steps that you need to take to get to that point.
And where we we see the most success of implementing teams implementing these processes is to have an idea of what they already do and think, okay. How do we get to that point either over the next year, over the next eighteen months, two years, however however long the timeline is that you want to put on that and say, okay. Well, how much incremental improvement can we can we see? And often that incremental improvement in the first first kind of six months is is significant, and then it's tweaks and changes that they make on top of that, on they can take on top of that.
So I think I think a sensible road map to success is, is the other number two imperative thing that you need to need to have. The that's realistic as well. I think there's there's a danger and there's an excitement sometimes in this ecosystem of running before we can walk. We all know the benefits of other applications out there, you know, velocity CPQ, but they often involve lengthy implementation times already.
So same thing applies to DevOps. Let's set our road map, of how we can get to that angle and think about how we can strategically attack it.
So what I'm hearing here is that it's it DevOps, implementing DevOps is actually a project in its own right.
Fine. You might have a you might have a a catalyst which says we wanna implement CPQ or influence a new cloud, but actually we've actually gotta take time aside to implement DevOps, rethink the processes, reengage the the teams, set some milestones and so on. So are we are we again, question to all of you. Are we seeing projects out there which are just implement DevOps projects or is it DevOps is meant to be we'll implement it alongside whatever else you're doing?
From my opinion oh. Sorry. Sorry. Go ahead.
Go ahead.
I'm just gonna jump in. I think it absolutely needs to be thought of as a project, whether it's a a technical debt project that you take on, or just a project in its own right. You know, just the the matter of testing and making sure you set a vision, and making sure that you're, gathering all the right requirements to set up your DevOps process the way it needs to for to be set up for your organization. You know, it's not, like you said, it's not a silver bullet.
It's also not a one size fits all structure. There's lots of decision points that you need to make. So I I do think, definitely a project, not a, we'll do this, you know, on the weekend and then get back up and running. It's it's, definitely, there's a a maturity model.
I know that your set has their own maturity model, but, there's a definitely, this is an item that you should think about having a maturity model around, making sure that you manage your expectations and sort of, you know, walk, run, or crawl, run, walk, crawl, walk, run. That's it.
And do that the proper order to make sure that you're, you know, setting yourself up for success in the long term.
Rob, what are you saying?
Yeah. I mean, I've I mean, obviously, I I'm seeing a a broad spectrum of maturity for for DevOps, you know, from sort of, you know, one admin running the entire org and and no developers, you know, all the way up to sort of mature organizations. But one thing I do see in common is that, you know, developers wanna develop and to an extent ops want to op. You know?
So I think, you know, the the greatest kind of tool that I've had was kind of convincing, clients to start going DevOps is is actually kind of the converse of of building from the the the rank and file up. So starting at the coalface of the folks that actually are hitting the pain points. So, you know, case in point, you know, a developer or an admin that's kind of running an entire org, you know, they have a a backlog of work that they need to do, and they have to factor in so much time, you know, for deploying that change rather than actually making that change. And I think, you know, one of the greatest, kind of persuasion arguments that I've had with with various clients is, well, actually, you know, if you don't end up spending, like, you know, half an hour, an hour, or even greater, you know, to get your change out the door, you know, even if that's just for sandbox for testing, you know, we're not necessarily talking production here.
You know? Those incremental changes of, you know, where are you spending most of your time outside of development, you know, are wins for that business.
So, you know, absolutely agree that, yes, you need, you know, high level stakeholders as as part of an overall program, you know, and kind of to to adopt DevOps as a project. But also, you know, to find the quick wins and, you know, and work from the bottom up is also kind of a a great tactic for incrementing that change is that, you know, I can deliver more of these Jira stories that you've given me if I spend less time building change sets, you know, that type of thing.
But are you seeing that then turning into okay. We will actually set up a a project with allocated budget to rethink our processes and really implement DevOps properly, or are we layering some different tools on top of broken processes?
I see a mixture of both at the moment. So, you know, my my larger clients have a a stronger appetite for process change. And in fact, you know, I I find ironically that, you know, some of the larger clients actually love a bit of process, and they they don't actually like implementation quite as much. You know, who knew?
But whereas the smaller clients, they just want results. Right? They they just want to how can we how can we make this faster? How can we make this better?
How can we spend less time on ops and more time on dev? Because, you know, we have one person doing two roles here. You know? I I completely get, you know, Suzanna's point about, you know, a release manager, about ownership.
My smaller clients just don't have the HR resource for that. You know? They don't have the budget for dedicated headcount for that. And so, you know, with the clients that I'm seeing that that want to get on board to make their life easier, you know, it becomes more of a technology question is, okay.
We don't have the resource for this in terms of people. You know, what tooling can we have that actually saves us greater amounts of time. So it it's always a trade off, right, between between process and technology. We've always known that across anything IT related.
But I think it is very much a sliding scale that almost mirrors to the the scale of the of the customer themselves.
I think it was an interesting point you made there about, oh, we we don't have budget. We don't have the headcount.
Oh, and, again, I I host central excellence round tables, and there are thirteen pillars of the center of excellence. They go, well, I haven't got thirteen people. And, okay, you're missing the point. You're focused on center, not excellence.
I think there's an interesting angle here, which is, like, you have a release manager. You just don't realize who it is. It may be part of your role. So we've actually got to up the fact that all these skills need to be applied.
It may be one person, but you still need to understand what those are. And therefore, I think even with small organizations, we've gotta get people out of a chain set mindset into a deploying through a pipeline mindset.
So maybe I'm getting on your sandbox, Jack, and then and shouting for that. We've got to move to that. So so let's move move the conversation on, which is people tend to focus on metrics. So what how do we measure that level of success? So let's let's start with you, Jack, and everyone else can jump in after that. How how will I measure success going through that maturity of from heroics through to excellence?
Yeah. I think, as we mentioned at the keynote earlier, I think, obviously obviously, velocity of change and change failure rate are the are the two big ones when it when it comes to, you know, hard metrics, that that you want to look at.
What I am a big advocate of and a large a large part of my job and large the most gratification I get from my job is actually seeing the happiness of the teams that we're working with. So not yes. You've got the hard metrics. Everybody can pour over the hard metrics, and everybody does does do that. That's what we want to see. That's what we want to see, is that, as is is that figured value.
However, I I think there is something to be said for team morale and the actual visual, the visual feedback that you get from a customer that is having is having a process that is really engaged, where everybody understands their role, where everybody is able to deliver, on a day to day basis happy. And, you know, we're in in my job, and I've been lucky enough to see results where, staff don't have to stay until eleven PM, one AM, three AM. You know, that that still happens, in in this ecosystem, and sometimes it's sure out of our process that that we can help fix, and sometimes it's absolutely needless. And I think those those those wins that get overshadowed by the metrics and the statistics that you churn out on dashboards, and those are the real that we we deal with people all day every day, but at the end of the day and I think those people results are the real ones, that you can probably reflect on the most and probably take greater satisfaction out of as a leader.
I love that. I love the the quality of life sort of metric for our release managers and admins and and developers not having to, you know, work, till eleven PM on a weekend or whatever because you have a a process and a toolset that works for you. I think the other measure that I've seen, so working, at Boston Scientific was, definitely the amount of how how little downtime can you have after a release. So making sure that, you know, you've tightened up those post deployment tasks. You've automated them where you can.
You've done your integrated testing so that, you know, you're not releasing things that you need to smoke test and then find issues with. It's minimizing those issues after release and making sure that you don't need to lock out as as an example, you don't need to lock out users for, you know, however long you can they can continue to do their work as as you release, all of those. And maybe they're not metrics, but I think, health indicators of your of your DevOps process and quality of life metrics like we already mentioned.
So so, Robert, let's ask the question from a different perspective, Rob. How many people who, when you go to as a as a customer actually have a good handle on those metrics to start with?
Oh, that's a good one. To be honest, I I think very few.
I think, you know, when we talk about a metric you know, or any of those metrics around sort of, stability, you know, breaking changes and or stability after a release, I think what you'll find regardless of the process is people always remember the horror stories. No one ever remembers the successes. Right? So if you've done a great job, nobody knows about it. If you've done a terrible job, everybody knows about it. And I think, you know, that that's kind of the sort of implied metric that we we often see. But, you know, to your question, I think only those that actually have a mature DevOps process tend to see those metrics.
You know, I think that's kind of one of the keys to, you know, onboarding a a DevOps process is what is the problem that we're trying to solve or or more, you know, how bad is the problem that we're trying to solve?
You know? If if actually, you know, we our process is great and it's just our tooling that needs an uplift, then that's where we focus. If it's more holistic than that and actually our process is causing a lot of these challenges, you know, due to, for example, you know, insufficient peer review of changes, you know, everything I'd generally bucket under moving too fast without the right checks and balances. You know, they're they're probably the the areas that you'd want to focus on. So, you know, every org's gonna have its its own, challenges, but I think, you know, it's to to your point, you know, the the metrics is is kind of where you start from.
You know, how bad it are things and, you know, what is the worst thing and what and how can we solve, you know, how can we solve for that?
That's fantastic because you've got us into I know. How how do I get started? So, I mean, this I could talk to the rest of you for for the rest of the afternoon. I'm sure you've all got busy day jobs. But we've got a few minutes left. Can we can you just reflect for for the audience about if someone's gonna get started, what's the one thing that that if they if you knew just one thing you should focus on, one thing they should take away from the session, what would that be?
I think for for me, I'll go first is is to get started, I think is is is is ultimately it.
There's so many so many times that I and, and we as a company have spoken to people, who've who've tried to get started by speaking to us and then don't take it any further. And it's just like, okay. You've come to us. You've come to this with this and not not got started. So above above all else, get is get started. It sounds like a cop out answer, I guess, but, just get going.
I'd I'd jump, and a quick follow-up of that is, to get started and, also, it's okay to start small.
I think when we were when I was starting, I thought, well, okay. This is right around the time when, like, unlocked packages were announced. So I was like, okay. So first, I need to get everything into packages, and then I need to, like, start working with version control.
And what do I need to do? It's like, no. You can start small, start understanding the concepts, and like Rob said, identify the problem that you're trying to solve with DevOps so that you stay, I think your your your attention stays on that goal and not on all of the other. Because there's a lot of technology.
There's a lot of partners. There's a lot of things moving around, but staying focused on the problem you're trying to solve and starting small, would be my two pieces of advice.
No. I'd absolutely echo that that starting small thing. I I generally get people on board, with okay. Let's let's look at deployment.
Forget pipelines. Forget Git integration. Let's just move away from change sets. Let's just have a look at one of the tools available.
Let's look at, you know, how can we identify what's changed between our our development environment and our target environment in an easy way. Let's, you know we've all done change sets in a time and, you know, and it's click, click, click, and then you move to the next page and it's forgotten all your clicks. You know? Let's look at some tools that that save that time.
You know? I I spoke to, one of my client's admins that was using change sets for deployment, and, you know, he spent the best part of the afternoon putting that together. You know? So let's let's kind of, you know, start small.
Start on how can I deploy faster, and then I can get to the cool, sexy stuff that that DevOps can bring to the table? So, yeah, absolutely. You know, small and slow is is the way forward.
So let me add my two cents on this, which is and I'm I've I've spent the whole life thinking about process. And I think unless you understand what that process is, then it's it's very difficult to improve something which you don't understand. But it's it you get back to Jack's comment, which is just get started. You go, well, it will that process mapping is gonna take forever.
Well, actually, it kinda doesn't. It actually can be you get the people around the virtual whiteboard and go, okay. What is it we actually do? And you get everyone on the same page.
And I just wanna record one other point, which is, I I I remember writing a article called happier people are more productive.
And, actually, it's not so, yeah, in it seems that way, but, actually, there's a bunch of data that says that happier people are more productive. So if we can actually get people doing a process which actually feels rewarding, get some quick wins, keep things going. So I'm trying to pull some of the strands together from what I've heard, but get get some quick wins, get happier people. That you can then feed off that, and that's the energy that actually takes you to the next level, the next level.
So I'm gonna hand back to Maritina. Thank you so much for, for the three of you for joining me on the panel today. Again, we could talk for the rest of the afternoon. I'm sure that if you've got questions, then reach out to any of the individuals, you can find them on LinkedIn.
I'm sure they'll be happy to answer the questions or go back to Gearset because, again, they've got their their maturity index, ton of experience there. So thank you so much for joining us all.
