How to train a team in Salesforce DevOps

Every team is different, and each organization using Salesforce has unique requirements. Routes into Salesforce aren’t always straightforward, but many skills learned in other industries are highly transferable, and it’s one of the reasons that the ecosystem is so diverse. Salesforce attracts individuals from many different backgrounds, and gives opportunities for progression along a wide range of paths. But with so much variety, how do you make sure that you get the best out of people when looking at implementing new Salesforce development processes — like DevOps — in your company?

Some of the most skilled trainers have built up a wealth of valuable experience in different roles themselves, and Monica Thornton Hill, Solutions Architect at Fusion Risk Management and Gearset DevOps Leader, is no exception. After initially planning for a career in design, Monica entered the Salesforce world — upskilling via Trailhead before securing her first role as an admin. In this interview, we talk about the lessons she has learned along the way, and the advice she has for those implementing Salesforce DevOps in their organization.

Hi, Monica! Thanks for taking the time to chat to DevOps Launchpad today. I hear you came upon the Salesforce world almost by accident?

So I actually started with a design background. I went to school for creative direction within an advertising and brand strategy context, and I was a freelance designer out of college as an undergrad. I was looking for something with more stability, as well as an opportunity to learn something new, because freelancing was really challenging.

I forget who, but someone recommended Trailhead to me, which was accessible and totally free. I started doing Trails and within a month or two applied to a full-time Salesforce administrator position. Everything really took off from there! I ended up really enjoying it — it tapped into a lot of the same type of creative problem solving that design did, but with new challenges that were refreshing and interesting.

Eventually, I hit the point as an admin where I wanted to learn how to code and I didn’t realize that was something that I could do — or that all the learning tools were right there. I thought it would be something I’d have to go to school for or take classes on, but there were so many opportunities to learn: from resources online, and from my peers at the time. So I ended up learning how to code in a Salesforce context and became a Salesforce developer when I started using Gearset. That also really helped tap into a new curiosity for development and how metadata works — all these things I hadn’t really learned about when I was an admin doing declarative work. It just kept going from there, and now I’m a Solutions Architect.

A perfect example of those transferable skills that are so useful to the ecosystem! What do you think it takes for a team to be successful when implementing Salesforce DevOps?

I think a big part of teams being successful is having the right focus. Usually the advice I give is that when adopting any new tooling process — including DevOps — the focus should be on the change being a team effort, and coming from within the team, rather than on the tool itself. The team should have buy-in about why it’s important and they should also support each other, so nothing falls on one person.

It’s most successful when it doesn’t feel like a change is coming from external pressure, when there’s the sense of intrinsic motivation to do better and to get better, to make everyone’s lives easier. I feel like that’s a key theme to follow through different processes, where it still comes back to the team: “We can keep going, we’re on the same page, and we can handle the problems that get thrown at us”.

What are the most common things that Salesforce teams struggle with when adopting new processes?

For DevOps in particular, one of the most common challenges that I’ve seen is focusing too much on upgrading and investing in new tools and not on the process changes that have to come with it. Teams often don’t slow down to evaluate how the process is currently and what needs to be changed there first for the new tools to be worth it — both in terms of cost and the associated learning curve.

However, an even bigger issue is not creating an environment that allows for failure. I remember reading about resistance to change being a big problem — that everyone is going to have a problem with learning something new. While that can be true, I think there’s a reason for the hesitancy. If you’re used to doing something a certain way, even if you can see it’s taking more time or more steps, you’re familiar and comfortable with it and you know what the end result will be — even if it takes you all day, or all weekend. So I think it’s not so much a resistance to change, it’s more a fear of failure that’s going on within the team, which can potentially be a company culture problem.

If that’s something that impacts your team, the challenge is how to create an environment where it’s okay to mess up, and where you have a team plan for any issues. There should be a collaborative spirit around something going wrong, where you encourage your team to learn new skills and deal with the potential problems that are going to come with that learning curve, and make sure they feel supported.

Sometimes I feel like the focus is on the “resistance to change” problem that everyone seems to see, so the emphasis is on showing the team that the change is worth it — you can try to convince them and give all the evidence that you have for why all these experts agree that DevOps is worth it. But if your team is afraid to mess up, or to admit that they’ve messed up, that’s the real problem. It’s a challenge if the company culture doesn’t embrace that.

Why do you think organizations should prioritize Salesforce training?

It’s a reason to slow down and invest in your team. I think training should be treated as a sacred time to scale up your team and make sure everyone’s on the same page. There’s a clear contrast between that and just telling a new team member how to use a new tool or showing them a slide deck or a demo. Training in this context should be hands-on, iterative, and provide a chance for feedback and discussion about the changes that are coming — it shouldn’t just be a one-sided push.

It’s also important to stress that training is inevitably going to take time and that it’s okay to slow down. In fact, we often have to slow down to take the time to learn and iterate on a process and be aware of our capacities. DevOps is the same, and the time needed for training is going to vary depending on the team, but I think it’s really worth that investment.

Which topics do you think are most important to cover when training Salesforce DevOps teams?

Depending on the skill level of the team, I do think it’s important to cover DevOps concepts from the beginning, including why they exist outside of Salesforce and what best practice is today.

It’s worth covering all the expertise over the years that’s led to the company deciding that this is a good idea. I think it can be really empowering to learn about the push behind DevOps at an industry level, and what has been learned along the way, especially if you’re not familiar with it. Some people on the team might have a coding background, so may understand why it’s worth doing. But others won’t — I personally came at it from a place of no knowledge whatsoever. It’s empowering for individuals to develop skills that could apply to other contexts, even outside of Salesforce.

Another topic that I think is important to cover in training is the importance of testing. And I don’t just mean prod validation, but building QA into the process — what that could look like and areas for process improvement around that. I think a lot of teams aren’t testing early enough or often enough.

Are there any training areas that are typically neglected by teams? I feel like hands-on time is neglected. A lot of the time teams will be shown slides or demo videos, and team leads won’t understand why they’re not getting it. The people who are going to be using the new tooling and the new process ideally need to be using it or driving with someone there to guide them through it and answer questions — that’s when the most valuable feedback is going to come up.

Depending on the size of the team this can be tough, but I do think everyone needs an opportunity to get hands-on. For a larger team, maybe you could create a space with demo environments and sandboxes just like the way Trailhead does hands-on orgs. Maybe it’s using tools like DevOps Launchpad where you can go and learn outside of your work context and stuff isn’t going to break. Sandboxes are really useful for trying out new things without those risks.

Do you have any advice for how to manage different skill levels, role types or backgrounds when training a team in a new process or tool?

I think that’s actually a really good situation to be in if you have people on your team that are already skilled up, or who catch on really quickly. Leaning on them to help skill up the rest of the team is a huge opportunity to make it feel like a team effort, learning and dealing with the challenges of a new adoption process together. The more opportunities they have to get their questions answered and their concerns answered, the better they’ll do. So if you have people on the team who are already skilled or experienced, leaning on them to help others is going to be really important.

How can you support the success of new team members when a DevOps process is already established?

That comes back to the hands-on thing, I think shadowing peers, peer programming, and getting them right into the thick of it is important, as is learning from others in real time — seeing the challenges that they’re going to have to deal with and the established process.

People learn really well from troubleshooting, and even with the most perfect DevOps process and tooling there are still dependencies, validation challenges, unexpected bugs, or new releases. There’s always going to be something that the team’s going to need to work through together. Again, that’s not falling all on one person, it’s on the team. I’d recommend troubleshooting those deployment problems together, and getting new team members in right away to help because they’re going to have some valuable input — they’re going to be able to learn from everyone else and how they’re handling those challenges.

And finally, what advice would you give to any team that is about to embark on their own Salesforce DevOps journey?

My main piece of advice would be to start by evaluating your process, not your tools, and know that it’s okay to start small. You’re not going to change the way that you do things overnight, or even in one sprint and that’s okay. I also think that you should define the pace that you go at iteratively, together as a team finding out how fast you’re going to go. That pace can change, you can start slow and build up surprisingly quickly or you can start a little too fast and have to slow down, iterate, and scale back a bit on what your process looks like.

Forced pacing can be a big challenge — deciding on a plan and determining that in two weeks you’ll be here. It’s okay to have goals and a structure, and it’s okay to evaluate your team’s capacity and predict how it’s going to go. But I think just showing up with a rigid plan without any discussion with the team, taking a “you better learn fast” type of approach will just crash and burn, or at the very least hit some challenges that people weren’t anticipating.

I prefer an iterative approach with regular retrospectives, often asking a team “How’s it going? How is this for you? What if we try this?”. It’s about not being afraid to change the plan because of the way the team’s responding to it — a bit of an agile development approach to adopting a new process.

And finally, communication is key. It feels very obvious, but not having communication channels set up from the beginning, where everyone can give positive and negative feedback, can really hinder an adoption process. Communication is a key part of DevOps, but it’s also about the company culture. It’s having a space to feel comfortable communicating. It’s having the tooling to communicate easily — and not just to one person or one leader, to the whole team.

Every team is different, but if you have the right approach, team culture and communication channels that work for your team, whatever happens, you’ll eventually scale up to your end goal — and beyond.

Thanks so much for your time, Monica — what great advice for any team embarking on their Salesforce DevOps journey!

Looking for help on how to build, scale or train a Salesforce DevOps team? The Salesforce DevOps Leadership Certificate is full of helpful information to set you on the right path. You can also encourage your team to take the Salesforce DevOps Fundamentals Certificate for a solid grounding in DevOps concepts, to make your journey that bit smoother.