Closing the Salesforce DevOps skills gap

Share with

Transcript

On the panel today, we're joined by Stuart, VP of Trailhead and Ecosystem EMEA at Salesforce, Charlotte, editor in chief of Launchpad at GearSat, and Rob is coming back on to join us as well from GearSat.

So why don't we take, some time and have the three panelists introduce themselves?

I guess I can just go in that order. Let's let's start with Stuart.

Hello? Can you hear me? Sing me?

Okay. Good. I can't I can't see myself, which just means I've turned off my self view, doesn't it? So I was like suddenly kind of okay. Right.

Hello, everybody. Good to be good to to see everybody, and it's been an energetic last hour of listening into some incredible things. Really delighted to be here to this evening. It's, it's, it's getting dark, raining, cold, and very feels like horrible winter, but then, there you go.

Stuart Mills, vice president of Trailhead and Ecosystem, as you just said, Tony, and, delighted to in doing that role. I've had a long experience with Salesforce, my sixteenth year with in the ecosystem, and, the last couple of, five years have been at five and a half years have been at Salesforce. And the last couple of years has really been worrying about how do we help our customers and partners have access to the talent they need with the skills, experience, and diversity that will make them successful with our technology.

And, this is an incredible topic, talent in all sorts of ways, and I'm really fascinated by our discussion to come.

Thank you, Stewart. It was good to have you with us here today. Let's pass it on to Charlotte.

Hi, everyone. Really excited to be here with you all today. So my name is Charlotte Christofferson. I am editor in chief of DevOps Launchpad, which I think has been mentioned a couple of times in the summit already, which is great. So we are a platform. It's developed by Gearset, but it's a vendor neutral platform, aimed at upskilling everyone in the DevOps ecosystem.

So, it's completely free and, yeah, just something for everyone to be a part of. Myself, personally, I've got a background in education and research, newer to the Salesforce ecosystem than both Stuart and Rob, but really exciting ecosystem to be part of. And, one of the things I love about it is how, keen everybody is to learn. So, that's really nice, nice to be here.

Thanks, Charlie. You you can count on me being on Launchpad after this call.

Rob, kick it off to you really quick here.

Yep. It will be really quick, because I already introduced myself at the start of today's session. I'm I'm still the DevOps advocate at Gear Set.

But before that, I was a developer and architect on Salesforce for the last twelve years.

So much like Stuart, double digits in the ecosystem, and, you know, seen a lot of deployments in my time even before Gearset. So it's always good to, keep the learning journey going.

Yeah. I feel like that's that's a common theme here, right, with Salesforce and DevOps as well is start to continue. The learning's always continuing, and it never really stops.

So let me see here. I think this question is gonna be for Rob and Stuart. How do you identify the Salesforce DevOps skill gap?

I'm I'm happy to take a stab at that one, Stuart.

So I think Awesome.

I I I mean, I think a lot of folks, you know, recognize that on a day to day basis or or a sprint to sprint basis or whatever way they're actually kind of delivering change for Salesforce, I think it's reasonably well acknowledged now that change sets have had their day. I think, you know, they're they're not necessarily up to the same level of change, the same level of growth and evolution that the rest of the platform has had. And I think Salesforce in fairness, Salesforce themselves have recognized this also. You know, and they're making great strides on that both with the SFDX way of working, but also the new DevOps center way of working as well. So I think in terms of things being identified, as a gap in in Salesforce DevOps, I think it's it's definitely starting to become acknowledged a lot more.

I think in terms of the skills gap within the community and ecosystem, I think there's still a little ways to go. I think if you look at DevOps in the in the wider sense across sort of non Salesforce platforms, You know, there's a lot of advances and and technology and and process thought that's gone on before us. So we have the advantage of of being able to build and learn upon, that model and and the lessons learned by others.

But much like everything else in Salesforce, we have to kind of apply our our Salesforce filter to it. You know? A lot of the stuff like, you know, building containerless servers and all that other stuff that other platforms do, we don't need to worry about so much. But, equally, because of things like governor limits, because of the way that, you know, metadata is engineered, etcetera, there's unique constraints to our platform as well. And that's where I think the opportunity lies in the community and, you know, the the Salesforce admins and developers and architects and BAs out there. They know their Salesforce. And I think the opportunity now is to apply that knowledge in a DevOps sense and say, well, actually, how can we deliver this change more efficiently, more accurately?

Yeah. I think that's brilliant, Rob. I mean, I would perhaps just add. I was trying I was thinking about this coming in and thinking, well, we talk about digital skills gap and skills gap, which we all accept as, you know, massive within technology overall.

But actually, the specifics of this sort of take me right back to being being an engineer and just thinking, you know, the best solutions are well engineered to things and to some extent, the disciplines of architecting something well, designing something well, and then learning through iteration towards the outcome are critical. And so when I think of the gap here, I go back to some statements that I've used a few times, which I think sort of just summarize maybe what what you just said. It was that work in this space has got to be outcome led. It's always about solution.

You have to deliver it through agility, so you have to do it well, but you have to do things deliberately, intentionally by design. And so when I think of this gap, it's actually in sort of not a lot of the people we focus on the role type, we talk about admins and developers and architects and, etcetera, etcetera, etcetera, and even a DevOps specialist. Right? But in in this topic, for me, the big skill gap is good engineering skills that help you build things well that are robust and survive contact.

I'm an ex naval officer. So contact with the enemy. Right? And in a sense of I e, the customer who's using the product.

Right? The people who actually are using it. And when I started with Salesforce way back when, it was because it was a tool that I felt could grow with me as a business, and I could deliver things quickly for my user base, my sales team, my marketers, and, eventually, my customers, without the complexity of a lot of other platforms. And sometimes I think that if you look at the gap, we sort of say we've lost a little bit of sight of actually you just need to do good engineering skills.

So when I look at the gap, therefore, it's less about the technology skills. It's more about the good discipline. So I know few people have talked about shift left earlier today. Ian had a great session a little while ago, and and you just referenced it as well, but all of those sorts of things being embedded within the programs that exist.

And then I do think there's a place for specialists in this work, as well because by having people who are really the deep t, it gives you the the ability to the sort of to set the tone elsewhere. But I would want to emphasize it needs to be both. Like, every single person on this call, even if you're not, you know, if you're, an admin listening in, you need to know how good engineering and DevOps is applicable in your work and your space. So I think that gap is kind of how do we get back to good engineering, without getting drawn into the complexities that other technology platforms have got embroiled into as well.

So, you know, working from there.

Yeah. And if I can just kind of add on onto that, Stuart, you know, you you say about, you know, whether you're sort of an admin, a BA, an architect, you know, and we we we talk about sort of the different roles in the Salesforce ecosystem. You know? And I think Marco kind of referenced this quite a lot as well in that DevOps within the Salesforce space is is an equal opportunity skill set.

Right? It's it's an opportunity for everybody to kind of level up. You know? Whether you're deploying your your declarative flow because you're, you know, you're an admin, and you've you've built this beautiful functional performant flow, or whether you're a developer, you know, that's got some hardcore Apex or a lightning web component.

You know?

It all needs to move across between your environments. It all needs that same level of testing, of of accuracy, of making sure that you've checked your dependencies. So at the technical level, there's certainly in the DevOps side of things, there's very little that delineates those those roles.

So it is very sort of, you know, democratic and and and a great leveler, that allows you to grow your career regardless of what path you've chosen to get there.

It's something that comes up time and again, isn't it, about the importance of the the whole team being bought in and the whole team having those skills. And I think that that's something that the value of that can't be overestimated.

Everyone needs to be bought into to the process that they're adopting. Otherwise, at some point, it's gonna hit a roadblock.

So now that we we have established that, you know, there's there's a a skill gap, in the ecosystem and and and the trailblazers.

What recommendation will you guys give to like, where should people go to fill in those gap? Like, where do people go to skill up on those skills?

I think the really great thing about Salesforce as an ecosystem as a whole is that there are so such a plethora of resources available to people. So it's just a a case of find finding the resources that that suit you and suit your style of learning and suit your team.

So, obviously, Trailhead is an amazing resource, for for anyone anyone in in the Salesforce ecosystem.

Obviously, I'm gonna I'm gonna talk about DevOps Launchpad and the, the courses that we have there. But I think, it's more about taking the time to to actually carve out that time for you and your team. There's lots of value in in the doing, but I think having that baseline understanding, it it can't really be overestimated.

Yeah. I mean, I'm just. Thank you for plugging. I would plug your platform as well.

I mean, I think from what you showed me a few a month or so ago, it's, you know, amazing sort of add to all of this. And it is there's lots of different options. I think that that can you you know, we emphasize in Trailhead, it's continued learning. Like, I think that was referenced actually, Bob, in your introduction.

It was cool you're talking about continued learning. This is part of that. Right? You're continually evolving the platform to deliver better value.

So there's a continuity to keeping on top of things and, you know, being aware of it. I mean, Trailhead, we're trying to put sort of more sort of content that's relevant to this particular bit, but I would look at maybe some of the, some of the ways that I look at the building blocks, the Lego set that I look about in terms of bringing people into the ecosystem, perhaps to talk about that. So we, you know, we look at this as a power skill. You know, DevOps is a power skill, the ability to sort of think in the way that we're talking about here.

So So when I'm looking at programs and partners that we're working with to develop the ecosystem, and I could see a few peep friendly faces and friendly, chats in the, from MVPs and teams who are helping build community and building skills, We talk a lot about the power skills of doing stuff. And then, you know, Francis is admin to architect program. It's architect skills early. Right?

Those sorts of things. You know, I could see Steph on there. The Saturday's work is about bringing people together, talking about the way that we would do the right thing. Well, those are fundamental principles to good engineering.

And I think if you then think, well, we've got to do things in an iterative way and advance things quickly, then you do need to get into the final bit. This is the emphasizing with our customers, partners, you're talking about agility in the way that was described in the session just past, not because it's agile, but because it's about iteration. It's about learning and doing and diligencing it as you go. And, you know, the final bit for me is, I guess, DevOps is maturity.

I don't know if you talked about that, Rob, earlier, but that maturity curve of starting somewhere, you get the first iteration a little bit. And people have got to trust and be with with customers. I talk about this as sort of you've got to embrace this and go along the journey to get better and better and better. And the beauty thing thing about this is you upskill your team and and start to embrace the principles is the speed increases, which is a bit of a drug, honestly. If, you know, from what I see it, people, it's it's the sense of, wow. We are changing our organization.

And for the people who are in the middle of that in the terms of building, it is that continual learning. I'm learning more new, more new, more new, more new, wow, wow, wow, wow, wow, which is you know, we like to tell stories at Salesforce, of course, so we love people to be energetic, and I think there's something in that part of it as well.

And I think also, you you use I'm not sure. I I can't remember whether it was Juste or or or Charlotte. They used the magic t word there, trailblazer. Right?

One of the best resources for learning anything Salesforce related, whether that's, you know, the the platform itself or whether that's the DevOps aspect. You know? Your peers are your greatest learning resource out there. You know?

Everybody in the Salesforce community loves to help each other. Okay? And, you know, they share that knowledge. You know, there's the Trailblazer community groups.

There's the Trailblazer community online, you know, with all the the the various groups that are and and the, I'm I'm loathe to call them forums. I'm I'm searching for the right word there, but, you know, the the the sort of online groups as opposed to the in person groups as well, and social media just as much. I mean, you know, a lot of what I've learned over the years, on the Salesforce platform has been just from the connections I've made through the, you know, the Salesforce Twitter, space. So I think, you know, DevOps isn't immune to that either.

And I think, you know, working with your peers, you know, with with others either in your company or in your, your extended sort of online network, I think will pay dividends as well as a a learning resource for this as well.

I think that was a great example, Rob, of it not having to be a huge outlay of your time to to learn something new. You can pick up incremental bits here and there, and it's all this will help you get to that end goal. And the end goal is obviously always evolving and changing as as DevOps and Salesforce become more more mature and your organization increases in maturity as well.

Yeah. Yeah. I I maybe just would bring us back to one of the core things. I think, Charlotte, you mentioned it again as well is and maybe, Rob, you did.

It was the sense of the trouble is community within a squad. So, for example, within the project team, one of the most powerful examples I've seen of this is where peer to peer learning is happening and failure is acceptable. And then fixing is rewarded in a way that's so positive, and that's sort of you can see I'm trying to use I don't know if my screen's going, you know, round and round and round. It's everybody's learning from each other, but sometimes I I think we lose sight.

We we work in all these big community groups, but then we forget that the core product team or the, you know, the the project team, the scrum team, if you if you're doing for is the core of this. It is the little community group that's the peer to peer learning network that is the thing that's holding each other accountable, that empowerment circle, if you like, and, and making sure that we think of it like that. And then that's the community around that circle if if those sorts of things.

So now that we have, like, adapt the skill set and, you know, learn more about Salesforce DevOps, how do you know if it's successful or not? Like, what you are adopting? So how how how do you know, like, from the either from a team perspective or the individual?

Rob?

At at the risk of, repeating myself to to the point of extinction, metrics. Absolutely. Metrics are your are your secret weapon. Okay? So I I always encourage folks to to measure where they are today.

Okay? Because how how'd you know you're improving if you don't know where you started from? Right? So, you know, start looking at how long is it taking us to deploy?

How long you know, how many times do we have to sort of, you know, oh, you know, I forgot a field. I you know, or, oh, there's this dependency I've gotta go or or the pick list aren't doing because I forgot the the record type that tells me which pick list you know, all that all that fun stuff that, you know, some of our Salesforce veterans have been through in a in a deployment. You know? So really drilling into, actually, what is slowing us down today?

You know, what is the current state? And then start looking at, well, where do we actually want to be? You know, which metrics are most important to us? You know, is it the speed?

Is it the accuracy?

Ideally, both, which is kind of what I was was trying to convey earlier. But I think yeah. Absolutely. You know, the the way to, you know, gauge whether you are moving forwards is to know where you started and continually measure.

Every time you you change a process, every time you adopt a new technique, you know, whatever it is in in that kind of larger picture of DevOps because that isn't just the technologies as much about the the team cohesion as well. But every time that those changes come in, remeasure. Look to see, is this making a difference? Are we actually getting further up that maturity ladder just by virtue of, you know, small but steady changes?

And that's a really valuable way to get that buy in from everyone in the business as well. Because if you can prove the value that it's adding, at any stage, whether it's in the amount of time that it's taking to see your deployments or whether it's further down the chain, the the there's you can't really argue with metrics.

So Yeah.

No. I I'd perhaps would be just to add to what you both have just said in a sense of what I've always think one of the most powerful bits of an agile process that's working well and has got good DevOps sitting behind it and with it is the playback. Right? It's the sense of actually showing the the progress of a program to the business owner, the the eventual users, and making sure that that part of the of the whole system is really embedded and dealt dealt with well.

When I go into a team and look at what they're doing and look at their maturity, the the first place I'll start is in the playback and sort of go, right. I wanna see what we're doing, what we're working on, and I don't want to see requirement logs, and I don't want to actually even see the metrics to start with. I wanna see a playback of where we're at because the system is is for use. Right?

It is for the use cases. Very little of Salesforce is behind the scenes completely. So you kind of got that, ability to sort of lead from the front end up because it so that playback is is the piece of there. And then the the other bit that I'd add, once you look do that, then the metrics and all of the pieces is then what are people learning as they go through it all.

Is this sense of, am I learning from those measures that aren't changing? My speed is not improving. My, you know, deliverable outcome numbers are there. Because then as a leader in those, you can look at that and go, okay.

Well, actually, I don't have a confident, trusting team that is willing to show me the product, is not willing to show me the measures, and and is actually not spending any time bloody learning about excuse me. Learning what how to do it better.

And, you know, since you can those three things, look at those and then very, very quickly for me, you get a sense. Right? This is not a well capable, confident, team with the capacity to deliver. Right. How do we fix that?

I think one last thing that I'd like to touch on as well there, Tony, and I think, Stuart, you've you've certainly alluded to this as well is, you know, to emphasize the people element. Okay? So it's not you know, I I love a good metric. You know?

I I'm a techie at heart. I I I love the, you know, the the concrete facts. But I think the the human people element of of this is shouldn't be overlooked. Right?

So, you know, if your team is on board with the idea that, actually, deployments are horrible, we want them to get better because we don't want to be sort of, you know, staying late on whatever day of the week it is doing our deployment. Hopefully, not a Friday. Please don't do Friday deployments unless you have a good DevOps process.

But no. I mean, joking aside, you know, I I've seen DevOps teams, you know, even before joining Gear Sets, so an independent view. But I've seen the power of DevOps within development teams where once they realize that, actually, we can eliminate a lot of those pain points, we can deploy faster. We can not have to keep going back to the same thing, it failing review and coming back and just, you know, reducing that cycle time. Actually, people tend to align better to that that actually, you know, we are making an improvement here. It's not just improving our deliverables. It's not just improving the company's bottom line.

It's it's improving our, our work life balance. It's improving our, you know, our our well-being in so much. You know, I'm not saying DevOps is the savior of of all mental health, but it sure does help when you're not, you know, under the pressure of trying to get a delivery across the line. It's late at night.

Something's not working. You you don't know why. You know? It contributes to, you know, actually people regaining the joy of actually what they're doing because they can see the you know?

For example, you can see users actually adopting a new feature and and succeeding with it, and you say, hi, mate. I delivered that. You know? I contributed to the team that got that across the line. You know? There's no greater feeling.

That's the point on people as well. I think having a really clearly well defined DevOps process makes it so much easier for new people joining that team as well and just makes the whole team dynamic. It just drastically improves it if if there's this negative energy around deployments, then that that's just gonna feed onto anybody in the team and particularly new people coming into the team, and that just that just feeds throughout the organization. So it's the the tangible and the intangible benefits of just a positive team energy, I think, is really important, side effect of DevOps.

Yeah. And I think having that first initial win is is gonna be really important. Right? It's like once you get that feeling, like, that initial win, like, oh, yes. Now I can do this, and I can keep going.

I was so my question for you guys now would be, what one skill set you wish you had when you first start this journey?

Charlie, you can start first.

One skill set I wish I had. Well, I mean, I I came, as I've mentioned before, from, a very different background. I think that, still being relatively new to the ecosystem, I'm learning all the time. So, I think that I feel like I've got a really solid grounding in DevOps, and that's what I don't think anyone, would benefit from having that. So, yeah, I think everybody should take take that time to get the get the basics, get your foundation knowledge, and then from there, it's just a a a journey upwards.

Yeah. I think I'd go back to the point of sort of, this broad sense of good engineering. You know, good it's is this a robust thing that we're building, we're doing? It's a good process we're in.

Does it feel robust as it that it is? And then through that, you get confidence. You know, one thing that's weighing on my mind at the moment with the economic challenges that we're all, sort of living within at the moment is people become much more conservative during these sorts of times when they're more fearful for their job, for example, and things like that. Does that start to be a push to say we're gonna stop being confident in the thing we're building?

And it's actually good. Are we doing the right engineering, which, Charlotte, to your point is, in this particular case, the DevOps discipline's good. Are we good here? Right.

Well, let's be confident. Let's push that thing out. Let's go. You know, we've we've done what we should do to be confident it's gonna go there.

And if it break breaks something or something's well, we know that it was gonna happen.

But it was gonna happen anyway. So we might as well have got there quickly, which DevOps allows you to go to do when you're applying it properly. So, you know, I think for me, probably, I I mean, I wasn't I studied engineering, so I probably lost my way with with doing that as I did various other things. So I should have probably worked out. Actually, I did b six before, which probably is something for many of us is to remember that we've actually been quite good at things in the past.

So think about the disciplines that you did in a previous role, something completely different, and apply those to being good at this work in a way that you can feel confident that the process you're undertaking is is a solid one.

Yeah. And for for me, I think, you know, the the the one thing that potentially, you know, I I wish I'd known a lot earlier in my sort of journey with this is that, you know, if I had zeroed in on the, you know, getting the DevOps piece nailed and, you know, dialed in a lot earlier, I would have had much more time to do the, you know, the core stuff of, you know, the deep technical stuff of of, you know, the the complex challenges. You know, as I said, I was I was previously a developer and architect. I liked the hard challenges.

And I think sometimes, you know, I would get removed from those because I was tied up trying to actually deliver those changes.

And I think, you know, the the lesson that I've kinda learned out of the, you know, my DevOps journey, that that ultimately has kinda led me to to where I am today with Gearset, is that if I can remove the friction of delivering the changes, then I get more time to do the fun stuff of making the changes and and solving those hard problems. So I think, you know, it it took me a little while to, you know, to to kind of recognize that. But I think, you know, DevOps is is definitely an essential skill that I wish I'd kind of mastered a lot earlier. I came I came at it the long way, but that's just, you know, I I I went through a few approaches, you know, not just Salesforce itself evolved. You know, the the tooling that was available to us evolved as, as well, and I've kind of followed that path and, kinda reached my happy place now. But, yeah, I wish I'd have got there sooner.

Yeah. Thank you so much for that, guys. So for our final thoughts, this question will be for Charlotte and Stewart.

What the one thing, one thing only, you will recommend to the audience, to do to stay relevant to the skills that they're honing?

It won't be any surprise what my answer is. I would say make the most of all the free resources that you can. They're they're evolving all the time. We've got some exciting things in the pipeline, so I'd say definitely come and join us on DevOps Launchpad and and see what you can learn.

I don't like one thing that's not fair. I mean, bloody good job, Charlotte, though, on that. Right. Okay.

I for me, I think so Charlotte, double click. Totally that. Right? Second thing would be, I think it's unacceptable in this space to be living in a project that's delivering in months and not weeks in terms of changes going out. Like, literally, it is unacceptable. So for me, that's building the confidence to say, you should know that's not right, and you should ask for better processes.

And then you personally should upskill yourself to understand exactly what I mean by this. And the second thing would be you just need to start asking your leaders, why are we accepting months and not weeks?

Because there's so much value being left behind and so many organizations that aren't being successful because they're not doing things robustly, successfully, and to deliver the value that we talked about today. So so maybe that's I know there's a there's probably more in that than than you asked for, so I apologize for that. But it was sort of one thing, wasn't it? Ish. But it don't answer that.

No. That was great. No. I I just wanna say thank you again, you guys, for joining this panel. And we're gonna wrap things up here.