Continuous Salesforce delivery: how DevOps powered my career from developer to CEO

Share with

Description

Paul Battisson, Founder and CEO of Groundwork Apps, shares his inspiring journey in the Salesforce ecosystem and how DevOps has significantly influenced his career progression. Starting as a developer, he transitioned through various roles, including consulting and product architecture, ultimately founding his own Salesforce ISV. Paul emphasizes the importance of version control and CI/CD processes in enhancing workflow efficiency and team morale, while also highlighting the cultural aspects of DevOps. He advocates for gradual adoption of DevOps practices, encouraging teams to start small and focus on customer satisfaction. Throughout his talk, Paul provides valuable insights and resources for those looking to implement DevOps in their own careers. Learn more with these DevOps resources:

Transcript

So without further ado, I'm very excited to introduce you all to today's speaker, founder and CEO of Groundwork Apps, Salesforce MVP, and author, Paul Battisson. So if everyone is ready to get started, Paul, I shall hand over to you.

Thank you very much, Amy. So, yeah, good afternoon, everyone. Nice to see you all. Good morning or good evening, depending where you are in the world.

Very nice to be here, and thank you for the lovely introduction.

And, yeah, today, I'm here to share with you really a little bit about my journey in the Salesforce space, but how it relates alongside DevOps.

You know, I'm I'm really lucky. I've pretty much held almost every position I think you can do in the Salesforce space in terms of different roles, which we'll talk about in a minute. And over those fifteen odd years I've been working in Salesforce doing these different roles, it's given me a lot of insight into into kind of the different positions you might be in, the different job functions people might be doing. But one of the things that has pretty much stay consistent throughout that is is how I've used DevOps and have implemented DevOps and, you know, its predecessors in those roles to help kinda help my career grow. So just here today, we need to share that story with you. And hopefully after this, no matter what position you're in, what role you're in, you'll come away with, some thought about how DevOps and its related practices can really help improve your career and and boost your career along the way.

So, a little short introduction to me, as yeah. Amy's already done a good one. My name is Paul. I am a Salesforce MVP Hall of Fame member.

I hold twenty something called Salesforce certificates, and I've written two books on Apex programming. I have been working with Salesforce for about fifteen or so, probably a little bit longer now years, and, yeah, you'll hear a bit more about that in a minute. And I currently am the CEO and founder of Groundwork Apps. We're a Salesforce ISV.

I also run Cloud Bytes TV, which is, sort of educational, YouTube channel, podcast, LinkedIn kinda network to to help people learn a bit more about Salesforce. If you're interested in finding out more, I have quite a unique name. There is only one of me out there in the Salesforce space, at least I'm fairly easy to find.

So let's talk a little bit about my journey.

I started off as a developer in other languages. I was actually a dot net developer for a while. Before that, I was a developer using, kind of access. I've written things in Pearl and, yeah, very technology focused background. But about fifteen, sixteen years ago, I got a job as a developer for a very small starting out organization, called FinancialForce who are now known as Cettinia.

And one of the fun facts is I was FinancialForce's technically their first employee as everyone else that was working there had come across from their predecessor organization, Coda.

So I started off with FinancialForce all those years ago as a developer and from there after a while I was, you know, really interested in learning the platform. I got to work with some brilliant people such as Andy Fawcett was my boss. I got to work with him, got to work with Carolina Ruiz, Tony Scott, Steven Wilcott, lots of, yeah, Agustina Garcia, lots of very, very smart people.

But after a while, I decided I want to get a bit more client facing, so I went and I became a consultant.

One of the things that I quite like doing is actually getting face to face with customers. Even in my current role, I love speaking to customers about what they're actually doing with products and with ideas to really kind of figure out that nuance, that problem. And so did that for a period of time, until I ended up working in kind of a slightly different role as a product architect. So I worked as an organization where we had a series of products for governance, risk, and compliance on the platform.

And one of my jobs was to look after those products and to speak to customers and to architect them in a way that allowed us to scale and grow. So we had three products, but a number of different packages were interlocked together so that you can have this base package and other things hanging off of there and all sorts of clever stuff like that.

In that time, as I say, I I started doing a bit more architecture work as well. So not just, architecting our products, but also more broad technical architecture work I was doing for customers. So I got heavily involved with a couple of big customers. I worked on something such some projects such as the Olympic games when they were back in London in twenty twelve. Got to help out, with the projects around them.

And then after a while, yeah, I kind of realized I'd done a lot of the technical side of things and wanted to take on a role that was allowing me to stretch some of my other interests.

So as I've been doing that evolution, I've been working more and more with clients and getting more and more high level. But, one of the kind of things that I was doing at the time because Salesforce was a very growing ecosystem, was sort of wearing a lot of different hats since I was doing some product marketing. I was doing some partnership management. I was doing, you know, some sales. I was doing a lot of different things that aren't necessarily, you know, an architect's role, not necessarily a a product manager's role, not certainly a developer's role or consultant's role. And so I took an opportunity to be the chief operating officer for a start up SI partner here in the UK.

And I was there for a few years during which time, I did write two books on Apex and have released a couple of editions since.

I also did some training for Salesforce. So I, was a certified Salesforce instructor, delivered some of the training sessions there, as well as other training sessions, you know, alongside Salesforce for different products and for getting people kind of upskilled in the technology.

And then finally, little over two years ago, I, went and launched my own organization, Groundwork Apps, where Salesforce ISV with a couple of products on, the AppExchange and some more coming along the way. And, really, that was kind of that culmination of that journey. I'd I'd sort of learned how to develop. I'd learned how to consult and speak to people to understand their problems.

I've learned how to architect and build out products and structure them and, you know, kind of scale them. I've learned how to kind of run some of the operations side of our business, the finance, the the sales, the marketing, and pieces like that. And I had a pretty good idea of how to, you know, teach people and, you know, get a message out there. So I founded my own organization and it's, you know, it's kept me going for the past couple of years and long way it continued to grow.

But throughout all of this journey, I've actually kind of had some continuous continuous items that have stayed consistent throughout that and and that has really kind of mirrored mirrored the way that DevOps has evolved. When I started out, DevOps wasn't really a term that was there. We'll talk about that in a minute. But but as as I've seen kind of DevOps as a process mature, I've seen my career grow and my career mature, and the two are kinda mirrored together quite nicely and everything I've learned along the way has helped me now in my own organization have a real speedy delivery focused mindset that I can do because of all the tools and techniques I've learned along the way.

So I just wanna dive into some of these different roles and some of these different, setups I've had just to kind of share with you if you are in one of these roles or if you're looking to transition from one to the other, some of the practices and features you might be able to utilize to help you.

So first of all, as a developer, as I say when I started out, DevOps wasn't even a term. DevOps wasn't a term that was coined or widely spread when I started out as a developer, let alone as a Salesforce. Well, sorry, as a Salesforce, let alone when I started developing originally.

But we really had two options when you were working, as a Salesforce developer back in the day. You had Eclipse and you had the Apache Ant migration tool. And for those who haven't had to use these, you are very lucky, but they are, you know, slightly legacy ways of of working to kind of deploy metadata between things. Eclipse is a full fledged ID, but it's it's nowhere near as flexible or as nice as Versus Code is now or some of the other ID you can buy.

And ApacheM is a command line tool that is used to deploy, code. And they were quite slow. They were quite cumbersome. They were very focused on kind of an individual developer.

But we did, have, at the time of Visual SourceSafe repository, and so what we did is we built out some tools to kinda get some CI and CD processes going, so continuous integration and continuous delivery to try and build out that practice, because that was gonna help us as a team to learn more. And there are a few benefits we got from that. So the first was a lot less waiting around.

If you so, again, if you've ever worked years ago on the platform before the tooling API came out, having to sit there and deploy everything to run all your tests was really slow. And so by having that go and work away in the background when you did a a a a request that merged items into the main branch, it made it a lot quicker and a lot easier for you. You could, you know, not spend as much time sitting around waiting, sitting around and having to have these things run for you.

As a team, it gave us a lot more confidence at the time that what we were doing was was gonna work. So you're having that kind of continuous build process meant that when I made a commit, the team in Spain could feel confident that, the work I was going in had been checked, had been verified, had been reviewed, and also then had all its test run and and wasn't gonna break anything. Because when you've got a team working on that and when you don't have a lot of the more modern tooling around it, excuse me, it can become quite slow and quite cumbersome.

And it really you know, really quite honestly meant for me that I could focus on dev. One of the things that, I really struggled with when I first moved over to Salesforce at the time was I was used to kind of dot net where, you know, ninety five percent of my time was working in my ID, quick cycles, quick changes, and go back. And Salesforce was quite could be quite slow in terms of the refresh cycle to do that. And, yeah, especially when you're then running tests and doing merge runs and things like that, having the ability to do some CI and CD to make that quicker and easier really did speed up my workflow and the workflow was it meant that we could focus on development rather than sitting there and worrying about changes or breaking things or if tests weren't running, etcetera, etcetera.

So really basic things that a lot of us are probably doing now but take for take for advantage, but at the time were really kind of key practices.

And so when I then started working as a consultant sorry, as a product architect, I took these with me.

And so as I started running a team where I was architecting products and, you know, managing a a product team about seven or eight people as a development team, Yeah. There were a number of benefits I got from, you know, introducing these things to help us deliver our product that that really weren't available before. So for a starter, you know, it was a lot quicker to identify bugs. And so I have this big strong feeling that the number of bugs you catch, before something goes live should be celebrated.

I, it was it was a story when we first kinda set up this CICD process in this organization.

The first week, we captured five times the number of bugs that we would normally kind of see for a release of a new feature. And the CEO came to me and said, oh my life. This is this is terrible. This we got we got really buggy software.

What's going wrong? Why what, you know, why are we suddenly writing, creating more bugs? And as I pointed out to him, we're creating more bugs. We're just finding them quicker.

You know? By having a much quicker test and continuous testing cycle and review cycle, we were finding the bugs earlier. And every bug we found and we could fix in isolation nice and quickly was a bug that our customers didn't find. And so I'm I'm a big believer that, you know, identifying bugs is a key thing.

You know, the more tests you have, the more bugs you find early on, the better and better. So a really, really important thing there for the team.

Oops.

It meant that we could then get better hourly scheduling. So there's nothing worse as a as anyone involved in managing or working on a product, but specifically at that management end, when you sit there and you go, hey, Greg. I've planned things out. I think this is gonna be our date.

And then the week before, there's a severity one issue that comes out and just blows everything out of the water. And you already got your comms running. You've already got your marketing set up. You're already, you know, announcing it to customers.

You may even have, you know, notified customers about sandbox push, and then you have this kind of, you know, bug just appear from somewhere or a problem go wrong. By having this regular cadence, we could see how things are going through the pipeline. We could see where things were in the pipeline. Again, identify issues early, reduce the number of bugs we had.

And so release scheduling became a lot simpler, a lot more effective, and it meant that we could have confidence in telling our customers, hey. You're gonna get the newest update on this day. Yeah. There wasn't a problem with it.

There wasn't any concerns we had, and we had much more confidence in the actual release itself.

And the final kind of benefit that kind of, you know, implementing these processes gave me, at that time was, you know, a happier team.

And so the you know, with the identifying of bugs, the first couple of weeks, we implemented, you know, CICD and started to put in some of these DevOps processes.

We had a lot of unhappy developers because you get a little bit of the blame game, and it took a little bit of a mental shift in the team for them to realize that, actually, this isn't about blaming. This is about stopping there being the ability to blame. Yeah. People are naturally hesitant to have it pointed out that they've got test failing or things not working.

But by having these pipelines running the way they were, before, I think it was committed to the main, main branch. Nothing could get in there without having a passing bill, without having good tests, without having them reviewed and kind of the gates going through it. So it meant that the bill wasn't breaking. And so for developers having problems, they could work on it and they could iterate on it and have as many failing builds as they needed to get it right.

So for junior developers, we could really focus on that training and improvement.

But for the more senior team members that were able to push things through quicker and follow the best practices, they could get their work in knowing that the build was stable, knowing that they can make the updates, and know that they could then continue on. And, at the end of this presentation, I'm gonna mention a book by, in fact, a a member of the gear set team.

But one of the things I really wanna kinda just hit home on here and, you know, kinda make sure that people take home is that DevOps is is at its heart a technical, you know, series of technical practices and processes and associated changes around that, but it's really kind of a lot of people change.

And if you can get the technology part done, that's great. But if you can get the people side of DevOps working properly, that's when you're gonna see the really biggest benefits because happier people are more productive. And so really just wanted to kinda highlight that as a key item for us that, you know, was a real benefit.

I then moved into kind of a a sole architect role. I know I've just labeled this slide architect, but there was a number of different architect roles I've had. So be it a technical architect, be it a solution architect, be it an enterprise architect, or I'm looking over a group of other architects.

You know, they all kind of fall into the same bucket here. And the first kind of big benefit that, you know, implementing DevOps processes gave me and this was actually when I first started using Gearset, as as one of the the tools in my arsenal was the ability to have good change of view. So, there's a team I was working with. We had, I was one of I was one of seven architects in a a huge multi year, multimillion dollar program.

And, you know, there was a legacy system where they had their architect and there was Salesforce where I was the architect and kind of the the boundary of who was in control switched halfway through the project. And that was planned when more stuff was on Salesforce and less stuff was on the legacy system.

But having the ability to sit there and review changes confidently, see the test passing, see them all get reviewed and make sure that my team was doing the right thing gave the rest of the organization confidence that Salesforce side wasn't a problem. It was transparent that we could see it.

It meant that when I took on that broader role as well that I could stay informed here by implementing DevOps across all of the systems. So we had had Salesforce running and we had, some team members using Versus Code and pushing up via Git. We had some team members using GearSet to push things in, into Git. We had GearSet and other tools running to run this.

And then on the other solution platforms, we had other tools running that were kind of doing our deployment for sort of, you know, some of the Node. Js work and things like that. But by having these pipelines and integrating properly with our, issue management and kind of project management system, I could be very confident as to what was going on in all the different teams at different points. And if there was problems, I could review them and help them and try and unbuckle them.

Yeah. I wasn't able to solve a technical problem on if there was a technical problem with, I don't know, say, one of the one of the external teams who were working on some sort of integration. I couldn't necessarily solve that, but I could at least go and ask them what resources they needed, if there was someone that could help them just to try and unblock things.

And and the other big thing was release gates for us. As I mentioned, this was a multimillion pound, multiyear project. And one of the big things I think is very difficult for people to to get with Salesforce upfront is ROI.

I think when you're looking at buying Salesforce, it's great, and it's a fantastic product, but you're often, you know, in some instances being told you're buying it, and then you've got another six months before you're allowed to use it. And so I think having a process like this where you can get people in, you can have these releases earlier, and you can get people looking at what those release gates look like is really good, and you've got confidence in that pipeline backwards. So for us, it meant we weren't sat there saying to the customer you've got yes. You bought it, but it's gonna be twelve months until the first release.

We were sat there saying, okay. Great. It's gonna be three months for this release and then another three months and another three months. And then for us, there was a lot less churn going on, but we had confidence in those releases and what was in there.

So they started getting ROI a lot faster and people on board a lot faster rather than, you know, having to wait around. And so for bigger projects, that's a really, really big win, and a really, really big key thing both for us and for and for Salesforce as well who want you to be doing that.

In my role and so switching gears a little bit, I then moved excuse me. As I mentioned from that role of looking at yeah. Kind of being an architect and, you know, managing as an architect these big projects into kind of a role doing more sales and operations management.

And And at this point, you might think, yeah. Great. You've gone from gone from kind of the techy side of the world where that really matters to the, you know, some might say the dark side of the world, but other other people might just say, like, kind of that that less techy side where, you know, no one no one buys something because you've got a DevOps process. But it actually made it a lot easier for me to sell and one of the key things I used to always say to customers is, and that would give them confidence is that I I could tell them how long something was gonna take because there was a realistic chance I was gonna build it. You know, when I when I joined that startup SI partner, there were six people there.

If there was a project that needed me to go and do some work on it, I was doing some work on it. That is the nature of running those small companies and those beasts. And so it very much meant that there was, often a chance I was going in and telling someone, this is how much it's gonna cost, this is how long it's gonna take, and I can start on Monday doing it. And so there was a big level of confidence people got from that.

And so that timeline confidence though, I could as we grew as a team and we got more and more people on board, I could start to give that to customers even if I wasn't gonna be a you know, wasn't gonna be on the actual pumps myself because we were gonna show them, this is what you'll see. And we had a demo project set up where we had tickets, we have project statuses, we had a CI pipeline and everything so that when we were going through and doing sales to customers, we would sit there and say, look. This is what you'll see. This is how it works.

I'm gonna create a ticket now. Here's how it gets assigned. Here it moves through the process. You'll be able to see this build working and things like that.

And you could get some of these things built out really quickly and easily, but showing them to a customer and showing them that, look, this is how we're gonna manage it gives you that real confidence. And it also means that if you do have to make changes, you can make changes. They're not they're gonna be seen early and seen at the point where they're gonna cause the least amount of problem.

And that means that you can then show that progress visibility really easily. So it's not just, for me, as I going back to that point I made a minute ago about ROI and really giving ROI back as early as possible.

One of the big things I've always been a believer in is that, when I'm making a sale, I wanna give you the number and that's gonna be how much it costs. I don't wanna have to go in and keep on telling you it's gonna cost more. I don't it's not a conversation I like. I'd I don't like doing change requests.

I just think they're a failure of a failure of somewhere else in the process. And so having the confidence in your timelines and in the progress you're making through having these DevOps process in place that later see exactly where things are in your pipeline, exactly what their status is. If there's bugs and if there's issues, show them. It's gonna fill the customer with confidence that you can show them that and that you're willing to show them that.

And it gives you a far greater level of transparency with the customer and a far greater level of confidence. And it's really uncomfortable.

I'm not gonna sit here and say that it is not the most uncomfortable thing you can do. It really is.

No one likes sitting there and pointing out that look, we've made ten mistakes today and there are ten problems that need fixing. But being honest and transparent about that allows people to see how many mistakes there are and how many have been fixed and how early they've been fixed and where you are in that process.

And it was really, really a benefit in so many projects I I ran and sold and and delivered on. Being able to sit there and just show people, like, in especially in a bigger in a bigger project as well, you're gonna have, you know, a project sponsor. You might have a project board. You might have a you know, there might be just a hundred people involved in a project.

But being able to be very transparent as to where everything is and not hide it means that, yeah, Joe, there will be hiccups in any project. There always is. But if you're open and transparent about them, you can solve them as a team rather than having to try and, you know, fix your way around them. And it means you'll all work together to try and solve them properly.

And then finally, just to talk a little bit about, what it's been like for me as a founder. So, obviously, I'm running my own organization now and, yeah, we're we're still in the process of being a start up and and, you know, growing our customer base and building out our products and, you know, going from that MVP through. But everything I've learned and used and mentioned, I applied through today. So I do still have yeah.

Everything goes through our development pipelines. We have build pipelines. We have delivery pipelines. We have reporting.

We have everything that goes out so that we can see what's going on. If there's a bug or an error we get, we see and we go through that same process.

And so I've really spent a lot of time automating as much as I can do using kind of those DevOps principle and processes throughout the rest of the organization as well. So if there's a customer case that comes in, even if it's, you know, something not related, you know, the number of queries we get that aren't anything to do with our app. I had someone send me a query the other day about, how to build a report that had the number of contacts against an account on it. You have something really basic and they wanted to filter it.

Nothing to do with any of our apps at all, but that case could still come in, get classified, go through, and, you know, all the principles and processes around managing that are DevOps principles and processes. How do you go through and prioritize it? How do you ensure it's getting reviewed? How do you ensure it's getting triaged, delivered, updated, built through?

And so when you actually have a real customer issue, because they do occur, you can go through and actually do that same process and make sure you can see where it is and when it got fixed and where it is in that pipeline.

Again, automating as much as possible gives me a lot of release confidence.

I like to be able to tell people that they're getting something on this date and giving it to them. You know, go being able to go out there and have confidence in what we're releasing and when we're releasing it is a huge benefit and really kinda makes the difference in some com some conversations. I've had a conversation with, with a potential customer. They said, you know, we like the product, but this this one feature is missing from it.

And being able to go back and say, well, let me go and look at our, product road map. Let me go and look and see what it is in our kind of plans, being able to prioritize it and move it up the plans and be able to give them a date based upon everything I've known about what we're doing in our release cadence and delivery speed and all the principles and processes we've got in place around that. It's really good to be able to go out to the customer and say, great. We can't do that today, but we will be able to do it then.

And it will be tested, and you can be on the beta. You can help us review it. You can have some input to it. That gives them a great amount of confidence in you as an organization.

And from my side as well, it gives me a lot of confidence in that we can release that regularly and and it'd be stable.

And then kind of it all comes down to this. You know, everything that I've mentioned all the way through this is really about making a customer happy. Whether you're in sales, operations, and a product architect, technical architect, a developer, a consultant, a founder, you know, an admin, what whatever.

It's all at the end of the day about making sure that the customers are happy. Whether you're an internal admin or an internal developer and you're making your own end users happy or whether you're a consultant or a product person, you know, selling out to other people externally.

DevOps is a great way of kind of making sure that you can keep people happy through being transparent, through having that confidence, through being open out and through finding all these issues earlier on in that pipeline and having that rigor around it. It's just a very, very great way of being able to do so.

And so yeah. So that's that's hopefully giving you some ideas about how you might be able to apply DevOps to your own work lives and and where it might fit in. I've got a couple of resources here to show. Obviously, there's DevOps Launchpad, which has some great lessons on there as well as fantastic webinars with wonderful guests as we all can see.

The book I mentioned is Salesforce DevOps for Architects by Rob Cowell and Lars Malthus.

Rob is one of the developer evangelists at Gearset. The book is just it's one of those must reads I have for anyone who's interested in learning more about DevOps.

It is not Gearset specific. Rob writes a lot about how you can set things up, just generally. So it's a very agnostic tool as well, but focuses a lot on those people side of things as well, not just the not just the technology changes, but the cultural changes you're gonna need. And then finally, there's Trailhead, and Trailhead also has some good modules on CICD release mechanisms. And, obviously, you know, Salesforce has its DevOps center and other tools as well out there that you can have a look at for some of the basic setups.

So I hope you found that useful.

Again, if anyone wants to contact me after this, I am at p batterson everywhere other than LinkedIn where I think I'm Paul badterson. I'm very easy to find, and I think I've got the same picture there now everywhere after updating. But thank you very much.

I hope you've enjoyed it. And, yeah, if there's any questions, I'd love to answer them.

Awesome. Thank you so much, Paul. Yeah. I've linked your review your video review of Rob's book in the chat there for anyone who wants that as well.

Thank you.

No worries. So we have got a couple of questions that have come up. If, we're gonna run slightly over, but I think especially this first question, it's definitely worth the time.

So, first off, this question is from Aruna, and it's a fantastic question. She asks, how do you align dozens of admins, consultants, and stakeholders on a unified DevOps cadence? How do you get everyone bought into DevOps? How do you get the admins and developers working together and not fighting each other? What's your experience and your advice with that, Paul?

So it's it is a great question.

The honest answer is it's baby steps.

And people people need to see the benefit to them. It's all about the the what's in it for me.

What I normally very honestly, normally start doing with most projects is if I go into an organization where that is the case, I start off by getting developers who are normally very comfortable with Git and the command line and, you know, many of them have either hand rolled or know how to put their own CICD process together. Yep. Get someone get that team involved first and get them building out things.

The command, like getting the source control mechanism is a really important part of this. Whether you know, I'm gonna say git. You could use Subversion or, you know, any other flavor. You can use Visual SourceSafe still, I believe, if you really wish to.

But assuming it's Git and, yeah, it's one of the ninety nine percent of people using that, it's not unfathomably difficult for you to use as an admin. There's a really good, session that Peter Chittum used to do on the CLI for admins. I'm sure there's a git for admins that, Jack in fact might have done. Jack McCurdy, also of Gearset may have done. So have a look out for those. I'm sure there's links to them somewhere around.

But, yeah, start off start off small and start off with little increments and then just have very honest feedback about what was good and what was bad. One of the things that I think is often misunderstood is you don't have to have you don't have to have a worry about the release cadence all the way down the the chain. So, one of the things that, you know, I I would say is that if you're on a team of, say, ten or twenty of you, yeah, unless that that which is a fairly big sized team to have, is that really only one or two of you care about the release timeline. Everyone else needs to be doing their work, getting things deployed and checked in and making sure they're working properly and happy. But once they're through those gates and, you know, you've got a robust checking system in place, you should be able to continue on with the next piece of work and it's up to up to someone else as to when that cut gets made. So those are a couple of big things.

I'm gonna say as well, like, a tool like so if you are working with admins, one of the big reasons yeah. And this I'm saying this genuinely. I have not been asked or mentioned or nudged to say the store, but one of the genuine reasons that I used to buy gear set for all of my admin teams is the diff tool was is fantastic.

It's very easy to allow you to diff between an org and another org or an org and a, GitHub repository or Bitbucket repository.

And that used to save my admins and my functional consultants hours of time. That's all still saves me hours of time, and so, yeah, definitely worth looking at that. I know other providers also have their own tools as well that do the same thing, but something like that is also a really good way. So start a little, get the techy people to set things up and get involved and get them to kind of iron out some of their kinks in it first. And then for the kind of more functional team, join in, either learn to use Git, it's really not hard and happy to do so, and Visual Studio has a great kind of diff tool as well, or have a look at a tool that allows you to do that and then get get built into that process. And then, again, once you're getting really quality stuff through the pipeline and through the process, the release part of it takes care of itself because you can then decide when you're releasing it and how you bundle it through.

I used to have, one company I worked with where we didn't have a release date. It was every day. As as a ticket gets finished, it got released. It didn't matter whether it was a Monday or a Friday. Like, it got released through. So we would kind of have that nice kind of, you know, continuous delivery that everyone's always looking for.

No. That's fantastic advice, Paul. Thank you. I've popped a bunch of Git and version control blogs and few webinars from Rob, there as well, that will all have more information about, Paul's answer there for you if you want to find out more.

I think let's go for one final question, if that's alright with you, Paul. Yeah. So, this one here's from, Lauren. He's asked, you mentioned moving through seven different roles.

Which transition, so which role transition was the hardest for you, and how did DevOps help you with that?

Which role transition was the hardest, and how did it help?

So that's a really good question.

Lauren needs to start her own podcast and interview people with, with a good one for that.

I think I found the transition into being to going into some of the architect roles actually quite a bit difficult.

I've been architecting the you know, realistically, as soon as you touch Salesforce, you're an architect. Like, if you start touching the back end of Salesforce, creating a field, you're doing some form of architecture. Okay? So everyone in my mind actually is an architect.

But that said, when I started doing when I moved from going and just being an architect on kind of a Salesforce implementation of service cloud or something to being an architect on a multi stream two year program of work where it was, you know, multi millions of pounds and, there was one project I was on where there was about a hundred and eighty people involved.

And, yeah, my memory is not good enough to remember everyone's name, so it just became yeah. It was very difficult.

That jump to to that size and scale of things was quite tough.

The way that the honest way that DevOps helped me was was, a, keeping me rigorous in in the delivery side of things.

You know, I'm a big believer that, you know, you're always gonna come across and this is a bit more broad than the answer to the question, but I hope I hope it makes sense in a second. I'm a big believer that you're always gonna find situations in life where you find yourself out of your depth a little bit, and that's a good thing.

Out of your depth doesn't mean, you know, I've never swab before. I'm gonna jump and go off with a high diving board. It means, you know, I'm I'm okay, and I've done the five meter diving board. I'm now gonna go to the ten meter one or whatever. You know?

And when you find yourself out of your own depth, you a lot a lot of the time that the reaction is to panic and to worry. And the number of situations I've been in where I have someone sit there and ask me a question and, you know, there's that meme of, you're looking around for the adult in the room and suddenly realize that you're the adult or meant to be.

Going back to you the basic principles and what's worked for you beforehand is a really good way of doing it. And if you've got good practices in place, they're gonna help you no matter matter what. So sitting down and having a good practice of, okay, I know what my problem is, I know what I need to do to try and fix part of it, I know what I need to do in terms to test it to make sure it's right, I know what I need to do in terms of making sure it functions properly and it's documented well and having all of these principles around it. So your documentation, big I big part of, like, DevOps done properly.

Everyone's least favorite thing, but really, really important. But doing things like that really kinda helped structure that properly for me.

And, yeah, there was an example I just on on that big sort of huge project, one of the time, just before I was kind of as I was transitioning into that enterprise role, there was another system. It was actually Marketing Cloud that had its own architect and was kinda doing its thing. That had a that and the identity system, and another platform, none of them were not my core Salesforce platform, had a horrific timing error. I've actually read about this on LinkedIn where, they had, like, to to you press you press save and it would take something like nine seconds or something for you to get. I think it was even fifty at one point for you to get, like, a you've per your confirmations your your purchase has been confirmed, which is not good for an ecommerce site.

And, you know, I was asked to could I have a look at it? Could I help out? Because it was your priority number one flag. And so, yeah, I was like, well, I don't know any of these three systems.

I have no idea what's going on in them, but let me just go back to basics. And so I sat down with one of the developers and said, look, Could I just have, you know, half an hour with you? Let's go through this. We went back to basics, and we wrote everything out.

We documented it. And they said, great. Now I'm gonna make a change. And, you know, once we did all these things and tested it, we came out with a very solid plan and some numbers.

And it was like, right now, we can push this through the pipeline and test it at the next stage and do that and get there. And then we went back and improved the overall pipeline so that this didn't happen again because no one had thought to do, you know, speed testing or performance testing before, you know, the release day or something stupid like that. So it's a it's a really good example of, of how those just principles and processes and following them can help you. So DevOps DevOps is a good set of practices and a good set of processes, and a good way of thinking culturally that helped me in that kind of big transition from going from running one team and one project to running a much bigger thing and just making sure I could keep some sanity around you.

Okay. This is where things are and this is what's going on. You can't see it behind me, but, like, that whiteboard often just has a hand drawn Kanban board on it. I have I have Jira and all these other tools on there, but there's often, if I if I'm just feeling overwhelmed sometimes, I just need to stand there and go, like, alright.

Today or, you know, what are the fifty things that are going through my head and put them up on some cards and move them across? It's worth its weight in gold sometimes.

Awesome. No. Fantastic answer. Paul, some great advice in there.

That is all we've got time for today, folks. We've run over with some fantastic questions and fantastic, advice and answers from Paul. So thanks everyone for joining. If we didn't get around to answering your question or if you think of one later on and you'd like to have it, like to ask us, you can reach out to us at team at dev ops launchpad dot com, or you can reply to an email. I'll be sending out round about this time tomorrow, which will also have a recording of today's session. So if you've got any other, other questions, don't worry. You can ask then as well, and keep an eye out for that email in your inboxes.

Just a reminder, if you aren't currently a DevOps Launchpad user, you can go check out, as Paul mentioned, all of the Salesforce specific DevOps courses and certifications. We've got blogs, a bunch of learning resources. I've just popped a link in the chat, but, again, there'll be a link in tomorrow's email if you missed this one here.

Yeah. So thanks so much to everyone for joining. And once again, a huge thank you to our guest, Paul, today for presenting today's awesome session, answering all of your questions live. We really appreciate you joining us, Paul.

And Thank you.

To all our attendees.

We hope you find it super useful, and we hope to see you again in the next webinar very soon. So thanks so much everyone, and take care.

Thanks, everyone. Bye now.