Description
As Salesforce environments grow in size and complexity, many teams struggle to maintain fast, predictable release cycles. Explore how you can build the foundations for secure, high-velocity Salesforce DevOps in this 30-minute value-led virtual fireside chat with Nikhil Reddy, Sr Technical Program Manager at Amazon and Mark Arneill, Customer Success Manager at Gearset.
Transcript
Hello everyone, and thank you very much for joining today's fireside chat. I'm Mark O'Neill, one of the Customer Success Managers here at Gearset. And I'm really delighted to be joined by Nick Reddy, a Senior Technical Program Manager at Salesforce Success Central at Amazon. I've been really enough lucky enough to to work with Nikhil for several years now, and I've watched him build and develop different teams, and implemented DevOps tools and processes as well.
So we're delighted to have Nikhil join us today. The focus of the conversation today is really on how enterprise organizations build strong Salesforce DevOps foundations as environments scale, particularly when release velocity, security, and governance all matter so much more than perhaps they've ever done before. Our goal is to be able to share some practical experience based on perspectives that that that that have worked over the over over years of what works and what doesn't work when scaling your Salesforce DevOps in complex technical environments. So a few things it will cover are things like some of the common challenges, the patterns of work, enterprise scale, how leading teams balance the degree of speed and control as well, and what that kind of performance and and and the the teams that are excelling actually actually do.
We'll leave a few minutes at the end for some questions. So do feel free to drop those into the Q&A, and I'll pick those up as we as we go through the session, and I'll pose them to to Nikhil at the end. So if you've got if there's some common themes, I'll sort of wrap up some questions together as well. So, Nikhil, thanks very much for joining us today.
Can we start off just with a quick introduction and talking about your role and what you're doing at Amazon at the moment? Sure. So as Mark mentioned, I'm a Sr TPM at the Salesforce Success Center team at Amazon here. Our team handles managed services for all Salesforce instances at Amazon and also security for all the Salesforce instance across the company.
My main focus in this this Salesforce implementation and the KDLO project, I'm the person most teams come to me when they need to implement a new solution or they want their systems to be optimized if they're already running. And I spend a lot of time helping the teams to get most value out of our Salesforce, and our internal tools. And over here, I'm really passionate about helping our team save money. Amazon is very frugal about how we invest in money and everywhere.
So a lot of the times our team sign up for the features in Salesforce they are not fully using. Part of my job is to make sure that they're leveraging almost everything that they signed up for and maximize the investment. The cool part, I work with teams across Amazon. Every project is different.
Every team is different. One week, I'll be working on a team that is doing pure sales. The next week, I'm working with a team who is core integrations into the one tools of all Amazon. Awesome.
And a hugely wide and varied role that you've got at Amazon. So I think the the next sort of twenty minutes of this fireside chat is gonna be is gonna be really interesting. So to get into kind of the the meat of it and and to kinda kick off, I guess, start us off with, like, from your perspective, what are the most common Salesforce DevOps challenges that you see in large enterprise organization like Amazon?.
So let me give you some context. I've been when many people get intimidated by the name of Amazon and AWS, and they think that it's one big monolithic organization with own with a very well defined process and everything like that. We do have more than 150 Salesforce orgs, and every org is working independently with each other. Only few orgs talk to each other, and they are at the different stages of maturity.
It's not a monolithic organization just like how everyone thinks about it. You get to see some teams that are just starting out. Some are, like, twenty fifteen years old, sixteen years old with different CI/CD process. You'll see from the most basic, CI/CD process of changes to the well implemented pipeline model from Gearset or a well implemented pipeline model through all the version controlling and, of code code mergers and everything like that.
And this is what I learned from an org like Amazon. The diversity, how we look like from a small to big is actually okay. The biggest challenge I see for a big enterprises like Amazon or any other company is picking the right tool. People think that picking the right tool is the one that we need to do, but it's not that.
It's the mindset shift. That's the thing that many of the teams that needs to understand that, hey. What is DevOps to my team? How does it sell my team?
How does it help my developers or admins or architects move to production smoothly without any bottlenecks? So I see this all the time where people have a mentality about we need to go through a common pipeline where they see on Internet or someone post this as a dev integration, UAT, preproduction staging, hard fix, whatever they wanna see it. But that is not realistic for every small org or every big org. Let's say if there's if there's a small org with one or two people, I would say, like, having a base model CI/CD with one environment in middle before production and having the right version control and move it to production is fine.
But if there is a big org where you need to have SOX compliance or any other compliance, having multiple items in the pipeline is also okay. So it's basically the mindset shift that people need to think about DevOps and the journey around it. It's not that it's a set process. So this is where most common challenges I see in enterprises, not just like Amazon and multiple other companies as well, is that what is the right process.
So it's adaptability is one thing that I see. It's really interesting. Like, I often talk to my customers as well around, like, the triangulation of people process and tooling, And it's bringing those three elements together that really, really makes success work.
So we've talked there about a little bit about kind of, like, what you see are the challenges from a large enterprise perspective. What do you see often where does it fail at scale? Like, is it is it processes tooling? Is it government governance?
Is it culture across the across the team and and how that works and and and people aren't, like, jelling together? They're working in silos rather than bringing the teams together. So, yeah, like, we're great to hear your thoughts on that. Absolutely.
Everything that you said, and there are a few other things that I'm gonna add on why DevOps will fail. The most key areas I see is, one, is process adoption. Adopting whatever process that they have already. Knowledge gaps on the technology, what they are getting it.
Second the the third thing is bureaucracy. Fourth is complexity is another one. How you're building a pipeline, some model about it. And the other one is going to be my favourite.
Why the hell do I need a DevOps process in my system? Like, this is, another mindset I see from the people as well. Why do I need it? I can I'll go with the best one that why do I need a DevOps thing?
I've I heard this from a lot of customers, stakeholders saying that. I can add picklist values in ten seconds in production. I can create a field in, like, one minute in, production directly. Why is it taking your dev team or your admin team so much time to move the changes or to add it into production.
So this is where, like, most of the teams fail on the DevOps process because there's no DevOps process at all over there. And this is how they end up in, like, the vulnerabilities you see on, like, wherever you see on the Internet right now. Exceptions are two AM production incidents because you added a pick list value.
Some of your validations of flows are failing. So these are the kind of things that I would say. This is the first thing I can talk about. The second thing I wanna talk about is, like, process adoption.
You can have the beautiful DevOps process built, but if no one is adopting the process because it might be, it can be going in tandem. Right? If the process adoption is not there, maybe there's complexity. You need to understand that one as well.
If people think change sets or any basic tool is easier compared to the one that you built, no matter what how fancy you build your pipeline or your DevOps process, you failed already. So this is the process option combined with complexities is one of the things that I see where most of the teams fail. The other thing I talk about is knowledge gaps. The main knowledge gaps, I would say, there might be some tools or there might be some custom implementation that teams build, which might be very much admin developer friendly, but not admin friendly or business analyst friendly, but who will be also doing the deployment.
Right? If that kind of tools or if that kinds of processes are there and if if if you need a PhD to understand the process that you built, you fail again over there. So these are the other things that that drive into the failure of DevOps. The other driving factor would be bureaucracy.
There will be someone who went somewhere, got in the conference, and learned the best DevOps process someone else built and try to implement to you. And people think it's one size fits all across all the teams, which is not true. And this is mostly creating churn and complexity for the people, and this is where they fail as well. So these are the different pieces along with what you said, Mark, will cause failure to DevOps process.
Yeah. I think it's interesting that, listening to you sort of bring that from a from an Amazon point of view as well. So you work with with multiple teams, so you're you're seeing this on a on a daily basis.
Actually, I've seen a lot of people saying, why do I need DevOps almost all the time? Yeah. And I think that's that's a question, like, even, like, customers and potential customers come to us and ask and, like, senior leadership of asking those guys as well. So, yeah, I guess kind of it'd be interesting just to get your take on that, though.
Like, when when do you get asked that question of, why do I need DevOps? What what's your of typical response to that? I mean, it annoys me, for sure, when people say that. But I also get it from a stakeholder perspective because they're not into the tooling.
They're not into the coding side of the world. They're mostly on the business side of the world. So we need to put ourselves in their shoe and then and explain them what will happen from their perspective. Let's say you don't have any business requirements, but you're trying to build something for that, you're gonna fail your business as well. So in the same way, we'll explain them.
So let's say you wanted to create a picklist value or a feel or whatever, and this is used in these many places. We're gonna show them, like, what are the things that's gonna break if you do it directly in production without a proper testing and proper sanity checks and everything like that. So that's how we work with the stakeholders. Initially, they don't get it, but eventually, when they go through the process and see see for themselves, they understand that, okay, this might fail right there.
And that is where we try to implement the processes with them. So in the pain points from a from a business perspective. Correct.
Yeah. So we've talked about some of the challenges there as well. What do you think, like, a strong DevOps foundation enterprise at large scale actually looks like in your experience?
That's a good question. And the answer is simpler than many people expect for sure. Strong, strong DevOps is how you make your life simple or how you make your process simple. The simplest process is, like, what is the DevOps process for you?
You're moving the changes from your development into your production where everyone is using. And how simple is that? That is the basic thing about a strong dev op. It's it's basically simple foundation around that.
But on the top of that foundation, the other things that I look into, 99% of the time needs to be there is a version control system to make sure that your changes are tracked, you have a backup of your code. It is not going to be optional. This has to be there so that I know people say, like, oh, no. We have audit trail, but audit trail doesn't track everything in Salesforce, and it's only six months.
But this is going to give you the history of everything. Second thing, visibility and alerts, like, what are the changes that are moving into your systems or, your sandboxes or even the branches and everything manually or either through a DevOps process. Third one would be automatic deployments. If you are a fast paced team or a startup culture, you want the things that you download and it meets some of the criteria with without errors or approval mechanism go directly into a place before production so that you skip multiple steps or multiple hours in wasting deployment over there where you can put your effort in developing that.
The fourth is a seamless branching strategy I would say. We talk about all the branches version control, but it also comes with the learning curve about Git and everything. So if you are a Salesforce person and trying to move the changes from Salesforce to Salesforce, the Git should work the branching should work behind the scenes on whatever you're doing through Sandbox to go through that. And the most important point is iterate.
It created a there was process. The process seems to be changing or the process if the process is not working, just reiterate on that one and work through that. And I've seen most of these things working, for example, automated deployments, visibility, and everything. You cannot have it in one tool or you can build it for yourself.
But I've also seen Gearset do all these things behind the scenes. The one thing I like about is I don't need to worry about what branches I'm merging into and everything because the pipelines take care of all of the deployments over there. Yeah. That's good.
That's really good insight. Thank you. And I think a few people may may have joined a bit later in in the call as well. So I'd like to encourage you just to put any questions that you have that you'd like me to ask to Nikhil or at the end of the conversation.
Just put them into the Q&A or drop them into the chat, and we'll do our best to to get those answered at the end of the call. So moving on then, we've spoken about the the challenges. We've spoken about some of the best practice in here as well.
How do you see the very best teams balance that velocity with security and auditability because, there are three really important factors now, particularly security. People are always afraid of of moving faster and and not as secure or, you know, because there's extra weight around security, it's slowing down the the down the workflow. So any any tips or advice in in in kind of, from that perspective? Absolutely.
This is where, most of the companies or most of the teams struggle as well because they don't put security and auditability as part of the regular sprints or regular workflows over there. And the reason why it is, like, yeah, got a small issue. Let me put it in the backlog. And the backlog piles up like a mountain, and no one looks into the under the mountain.
And, eventually, that's a path for failure for sure. So this is one of the thing that I've seen multiple places. And, again, I I agree that I also did some things on my side as well in the past where had to put it because we had to put customers first security behind at the point of time. But, you you learn a lesson after, like, after multiple iterations.
And I would say, Salesforce also have native tools, you need to look into every single time. Every sprint, need to plan 20% or, 10% of your time to see, what are the security things that you need to put in there. If your company doesn't have your own custom tool or Gearset, which tracks all the auditable metrics, you still have health checks, security center, optimizers, audit trials, event logs, human monitoring, and everything like that too. And, again, the reason why you need to have a unified tool to make sure, you have everything at one place is because in Salesforce, they are all at different places.
And that is why, I like the tools like you said because every every capability, like monitoring security checks, audit trials, deployment history, and is all at one place over there. And, again, as I mentioned, you need to plan security in your sprints, and this cannot be postponed for sure that I would say. But for Amazon, it's a little bit different. We have a security team which define the guardrails.
I think we have four hundred I'm not sure. It's, two hundred to four hundred or four hundred to six hundred different vulnerabilities that we look in every org, more than one fifty org. They scan every day. Think about, like, users with API only access, users with non SSO users or profiles with elevated permissions and their this is checked every single day.
And the team makes every org accountable to make sure that they are closed in a particular amount of time. So this is where, like, our we are security first company for sure. So we want all the security to be there for sure. And this centralized approach helped our entire organization to be very secure than most of the other Salesforce instances, and this is where our security comes first for our org.
But, again, it varies from different team to team. You need to build in your rhythm that, hey, For every sprint, these are the tech debts I have or, like, let's say your API versions are expiring, like, updating them into the new versions. Or if the code is very old with the old coding technology or whatever, you need to update in the new one. Yeah.
Super interesting. Yeah. Thank you. I guess kind of, like, moving on to some of the sort of more practical advice and things as well that, you know, we've we've got a number of large companies on the on the call today.
What advice do you give? Like, you obviously work with with teams of all sizes across I mean, there's some sort smaller teams, and then there's some some really big teams that you're working with as well. What advice do you talk most often give those those larger teams that are starting to look at strengthening their their sort of Salesforce DevOps processes? Absolutely.
The best advice I can say, and which is very pretty straightforward, is as I just mentioned, start small. Doesn't matter, like, you need to have a beautifully designed UI based pipeline with everything integrated on day one. Again, that's gonna cause failure because people don't understand everything around that time. So start small, like, either you start with a semiautomatic manual or fully automated process, but have a process on the DevOps side.
Have the government set up with your development team, and if you have a release team with the release team, or if you have a QA team with the QA team and to the production team over there. And once you just start small, that is where you need to do something, Adapt and reiterate. Adapt and iterate. This is the most critical piece when you're starting very small.
Let's say if you started semi automatically, how do you automate it? Or, the key is adoption over here. It's not how elegant it is, how beautiful it is, how best you are building the process for. And make amendments into every single process.
And this is where you need to see what are the things that are failing for you. Let's say you're using Gearset too. Let think about it. Even with that, there are issues when teams how to build the pipeline.
Let's say if you're trying to move changes from a dev environment to production, it took you ten iterations to move from dev to UAT to production. So that means either there is a gap in the process or either there is a gap in your setup. So you need to look into your filter criteria. You need to try to make sure, like, you need to make sure all the components are correctly selected, and that is where you need to update your SOXs to make sure how do you go from a development environment to production without any errors.
It cannot be perfect, even your build. So that is where you start small, iterate very fast, and let your experiences from your dev team drive that evolution of your process. And, eventually, I would say, sometimes some for some people, it might be day one, it's working perfectly, but I don't think that will happen for anyone. But some people, it might take a month.
Some people, it might take six months to get into this process and get a a perfect DevOps solution over there. Like, iterate, build, change, and then the whole like, a bit like how we mentioned it earlier in the call, which is around, you know, bringing the team with you, bringing the people with you, bringing like, changing that culture. That all takes a bit of time.
And to get everyone on board with that with that new process, you know, and and work in a in a more efficient way, you know, once you start getting that momentum, the the the snowball starts to roll bit quicker. Yep. It is just to start starting starting point is the first thing that I would say. Start small.
At least start with the process. Just start. But stake in the ground and start. Yep.
Cool. I guess no fireside chat in 2026 would be be justified if there wasn't a question that I've got around AI. So, you know, as AI capabilities mature and they're maturing quickly, where do you see some of the that sort of the biggest opportunity for the use of AI to improve, like, Salesforce DevOps workflows? For sure.
Everyone talks about AI, and that's a trending world right now. People honestly, people who who even think using ChatGPT thinks that the complete AI around that, they need to understand why and how before they start throwing the AI word at everything that's there. If you don't have a process, what are gonna use the AI for? If you don't have a working and adaptive adapt people are adopting the same tool or process, why do you need AI for that one?
Again, it's when you build and iterate through that, you can use the power of AI to make sure that you get a better solution or better system around that. Like, first thing I would say, let's say you have a best process already set in set up and everything is there. Maybe eventually you can use AI to get intelligent automatic deployments even to production to make sure that, hey. This past QA, this past integrations, this past all the tests, and this past everything, and everyone is approved.
Let me go ahead and deploy. So intelligent deployment, I mean, again, it's not there yet, but it will it might be eventually in the future. And the second one is auto suggesting the functionality. Even right now, like, I think Gearset would all always suggest that.
These are the warnings. These are the errors. These are the things that happen when you go to deployment. Maybe eventually, they can be auto suggesting the code saying that, hey.
This is the code that you have. You have a so called exception here. So this might be the fix for that using the AI can get through get you through that. And the next thing is predictive analysis.
It took ten deployments for you to ten times to go from, staging to or, like, from dev environment to production. How is my next branch going to go from dev to production? How many steps it might take and why? And how can I optimize it way ahead of time so that it goes in one go instead of ten iterations?
So it's basically to get the three sixty degree view of all the DevOps world at one place, warnings, issues, and everything. But, again, it won't work if you don't have a nice DevOps process. If you all you have is a flashy DevOps process, I don't think it's gonna work out. So it's again, you need to have the data.
You need to have the metrics. You need to have the process before you start throwing the AI words everywhere. Yeah. I think that's that's really insightful.
Everybody can jump on on that sort of AI bandwagon, I suppose. But, yeah, it has to be used in the right way, and it's actually be used in a way that's gonna benefit the the team and the process rather than than than anything else. Yeah. I I think I saw, like, a month ago or in the DevOps leadership where, like, you guys were demoing about automated deployments based on a criteria using AI.
So I think that would be interesting once that comes out. Yeah. We're we're starting to work a fair bit more in that field. We've got some interesting things coming out through through this year, which I'm sure everyone will join various marketing webinars and things on over the course of this 2026 as well.
Thank you, Nikhil, for all of that insight. I think everyone on the call would agree. It's been really interesting to hear your viewpoint on these different questions as well. Couple of questions that are coming in.
I'll kind of wrap wrap them up into kind of probably, like, one question here, which is just around, like, metrics and and measuring the health of Salesforce DevOps. We can look at DORA metrics. There's other metrics that are out there that other customers are about to use. But what's your what's your sort of take on on that kind of measuring the health of your Salesforce DevOps processes?
Yeah. I mean, again, just like we talked about how much what are the deployments, how many deployments you're doing, how many rollbacks you did, how many fixes you did, how many redeploys you made, the success rate, how much percentage of success that you're going from dev to production. Are there errors repeating and how you're fixing it? Checking your health every month and a quarter and to improve and reiterate your DevOps process that help.
Like, this all comes into the place together when you think about tracking this health of your sales for DevOps. That's where you iterate everything like that. So to summarize, like, I'm looking at deployment frequency, iteration counts, success rates, and everything like that. That's where, like, you can make your diverse process healthier by reiterating on that one or fixing the errors or how do you avoid the repeating errors around that.
Yeah. But, again, like, I think you all you guys already have. Seen the success rates and fail rates, the targets, deployments, and all those things. So I think it's we have you you guys are on the right path already to make sure that we we are being helped already on that one.
Yeah. Yeah. Thank you. Yeah. We do have biometrics available in in the platform platform already for for those customers that are using the automation tooling as well.
So I think it's just, like, insightful to see kind of what the next steps and stages of that are that we can that we can iterate on without with our customers as well. Thank you, Nikhil, so much for your time today. We really appreciate it. I guess kind of, like, to the audience, if you're evaluating how to strengthen your Salesforce DevOps processes in in your organization, we're obviously very happy to set up a a working session and explore what that could look like for you guys in in practice as well.
I'd encourage you to reach out and connect with Nikhil on LinkedIn. I'm sure he'll be open to more questions and things as well from the audience. So, yeah, please do sort of like, we like to be instigators of those connections as well. Thanks again, Nikhil, for your time.
Really appreciate it. I hope you have a fantastic rest of your day. And to the audience, I hope you have a great day as well. Thanks very much again.
Bye! Thanks a lot for joining..
