I would welcome to another exciting episode of Adventures and DevOps that might be live. I'm not actually sure. We're using some new software today and it says I'm streaming, so if you're watching this live, cool. I hope I don't see anything stupid and foolish. I'm excited today to have as my guest Jack, Jack, welcome to the show. Would you tell us a little
bit about yourself and what you do? Yeah, Hey, Jonathan, pleasure to be here, maybe live or or maybe maybe, but yeah, pleasure to pleasure to be here, and thanks for having me on the podcast. My name is Jack McCarty. I am a DevOps advocate at a company called
gear Set. We are a DevOps platform for Salesforce. So my background over the last four and a half years is being helping Salesforce development teams streamline their release management practices at when it comes to Salesforce helpum work carecept for for four and a half years and doing exclusively that in the last year and a half
in my role as a DevOps advocate, and that involved producing content. I run my own podcast as well, which is called dev up Stories, and I present the whole wide range of Salesforce community events and Salesforce events that you that you find in that ecosystem. Cool. I'm looking forward to learning a little bit about Salesforce and DevOps. But before we dive into that, let's set the stage a little bit. I imagine that many of our audience know
as much or less than I do about Salesforce. So let me just sort of paint the picture what I understand Salesforce to be and my experience with it, and then you can sort of fill up the gaps. So yeah, not not not to start the show off on a bitter note, but I lost my job to Salesforce once. Oh no, it was okay, I was actually ready to leave the company anyway. But uh I was. I was managing an e commerce team. Uh, and we got the entire team
got basically outsourced to Salesforce. H now almost the entire team. My predecessor, no, sorry, my successor. Uh, he's still there actually and manages the company. Uh and and works with the Salesforce team. Uh. You know that that's mostly outsourced. It's mostly a consultancy, uh to of course update Salesforce and so on. But I don't really have a clear sense of what he does or what they do with Salesforce. I mean, I know that Salesforce is a CRM. I'm not a sales guy. I don't
really keep track of customer client relationships. So you know, a CRM is sort of a nebulous concept to me in the first place. And imagine many of our DevOps listeners kind of feel the same way. Like that's the thing that marketing guys talk about it the sales guys talk about, can you make it concrete? Like what is salesforce from a technical standpoint? And how do salesforce developers and DevOps engineers and so on interact with it? Yeah, that's
a great question. So you're right. So Salesforce primarily is a CRM, so a platform used for managing the relationships with our customers, managing how they market to them, how they store their data, how they use their data to enable other business functions. So that's where Salesforce kind of starts. And that's kind of a poor platform that a lot of companies use. Salesforceport is the management of those relationships. However, Salesforce isn't just a CRM anymore.
So Salesforce over the last over the last twenty years Starry founded twenty one twenty two years ago or so now has grown and the Salesforce suite of products now is huge. So you have solutions for for sales, for customer service, for e commerce, for marketing, for a whole bunch of things. Salesforce seem to bring out a new product or a new what they call cloud every it feels like every month, but it's not often nothing every every month,
but a different a different cloud that enables you to do different things. So what it is is ats core as unifying the customer experience for any business. But a lot of people will use it that commonly use it will be in in a sales team, in a marketing team, or a customer success or service team. So that's that's kind of the foundation of what Salesforce is now if we think about what Salesforce development teams do specifically and how that relates to
devils. So Salesforce is out and out of the book solution. So you can buy Salesforce, you can buy one of their their clouds and use that cloud to to start doing things for your customers. So you'll have a base product effectively, and Salesforce developers and Salesforce what we call admins or Salesforce administrators can configure their company's Salesforce instance to do any number of the spot functions or
execute the spoke business workflows. So, say a lead comes into your company and you want to nurture that lead and how your sales reps and service reps interact with that customer. You can design the spoke workflows based on what your company objectives and goals are and how you market to those people, et cetera. So that's the responsibility of a Salesforce administrator and then a Salesforce developer a
lot more. The Salesforce developers will write custom code and custom logic to match those business objectives and things like that, as well as to increase the extensibility of the platforms so that you can have custom websites for customers or customer experiences custom experiences for those customers as well. So that's the core function of the
Salesforce developer on the platform. When it comes to debus and traditional develops, traditional devils doesn't really apply to Salesforce because Salesforce posts host of the infrastructure, so things like things like standards, security, standard scalability, and all those things are actually taking care for you by Salesforce anyway as a platform as a
service. Now where debups comes into the mixes is all about the release management and how you can seamlessly ship new features and the functionality and that extensibility. That was just mentioning about the platform to your Salesforce end users. So debups is an integral part of the release management cadence. So developers may well used to be using verse control systems and they already have may have experience using CI
tooling and things like that, whereas Salesforce administrator doesn't. So a lot of Salesforce platform is clicks not code interface and clicks not code building rather than custom custom scripting or writing a text code, which is Salesforce's development language. And as a result, the methods of getting those customizations from a developer environment or what you call a sandbox in Salesforce, so this is like like a like
a testing environment or a staging environment if you will. Getting those changes out into a live production system in Salesforce can be challenging, and that's why companies like gear Set exists to help with that process and help you build automations to get it through However, many stages of handbooks as you have and out into a live environment. So Salesforce develops is a lottle bit atypical to to what the listeners of this podcast will be more familiar with when you think about develops.
Okay, fascinating. So it is the salesforce development similar to say, right, developing against a Google API or something like that. Or or is it more define like like imagine there's a pis that you can talk to with in Salesforce, but maybe it's more standbox or something like that. I don't know, maybe you can, yes, So yeah, if we think, if we if we think about a typical, typical piece of work that a development might do. So a request might come from the business and say we
want to execute this flow inside of our salesforce environment. When as a lead moves from this stage to this stage, this is a Salesforce developer salesforce appening. Sometimes depending on skill sets, et cetera, and what's actually required, we'll go, we'll pick up pick up that ticket and they will operate in a a sandbox environment which somewhat mimics the production environment in the real life environment.
What they'll do is they'll then add their customizations either directly in that developer
environment using the clicks of code interface that Salesforce has. If custom scripting is required, then the developer will be involved and they will they will build that and then they will test it and make sure it works in their developer environment, and then what they will do is they will then look to ship that and push that to a testing and usually another testing environment, so this will be an environment that is a lot closer to the live production environment, and
best practice is for most orders to have what they would call a UAT or staging or pre proud sometimes the naming convention varies, or or to org and then that will be then be tested against to make sure that those new customizations that you've added will then be able to work with everything else that already exists.
So it's very common for Salesforce to be integrated with other ERPs or billing systems and things like that, so making sure that any customization that happens doesn't break those integrations and integrations with other APIs before then shipping those changes up to production and for the end users to play with. How long that process takes varies widely from organizations to organizations. So a lot of the larger, larger
enterprise companies will will only release production every two weeks. For example. Smaller organizations or more agile organizations will be able to ship changes once a week and a couple of times a week or maybe every day, depending on how their debop process is set up and how fast they can run through the testing requirements that Salesforce has itself or their self and posed testing requirements or any user acceptance
testing that they might want to do as well. So, yeah, the Salesforce development happens all like within the Salesforce platform and Salesforce Salesforce gives you plenty of customizability. We can expand that customer ability customized ability with custom code and
then uh and and make make Salesforce what you want it to be. No two Salesforce are the same unless you happen to have two people to two organizations using just sales Cloud or Marketing Clouder service plant write out the box with no customizations. You can do that, but it's not recommended. It's probably not only going to be basically fit for purpose. Okay, I'm curious. Uh so you talked about some organizations or release every two weeks, some as frequently
as once a day, or or maybe multiplants per day. Is the the ideal of continuous delivery and deployment like in the sense that the developer makes a change and everything else from that point on is automatic, test run automatically. Everything's automatic and is deployed as soon as everything is green. Is that realistic within salesforce or uh? Or not? For for the for the reasons you are describing. That's a great question, and I might get myself in trouble
trouble with with the answer here, can you do it? Yes? Should you do it? Probably? Not? So everything everything up to everything from that initial development shipped to the first testing environment. Everything else theoretically can then
be automated and wait for every every dream check to go. If you have a robust process, and if you have if you have confidence in that process as well, if any of those checks failed, it could be a fallback to developer review and say all those green lights, all those green lights are green. Theoretically you could have the stage that automatically pushes pushes to a production environment. The problem with pushing salesforce production environment live is when that happens.
So when that happens without a button to say go to production. A lot of times you will want to deploy to salesforce production environment outside of user working hours or typical user working hours to make sure that something does go back wrong. You can invent your rollback strategy or things don't just change under under a user's speed. So the key thing about salesforces. Salesforce is in every organization
with tier one business critical applications. So if you accidentally take it down by having an opmated deployment process and something does go wrong, even if all the green lights pass, something doesn't work as anticipated, you know you skip, you skip a user acceptance testing in your new business logic doesn't quite work as anticipated. Confused as users you know take you take out your your core business application, which can be sometimes be one thousand, two thousand and three thousand,
four thousand and five thousand users prevents them from doing their job. So theoretically, theoretically, yes, it is possible, like a platform like gear Set or our confessors is out there should be able to enable that for you. However, in terms of best practice and the realistic vision for and what salesforce is used for in every organization that often makes it not practical. What you can do, however, is do all of those green light checks and
validate against production as well. So Salesforce is a function where you can validate a deployment package of new features to production and allow you to be able to then deploy that at a time of your choosing. So everything up until that last stage can be automated to some extent. Where the Salesforce development is again
is a typical. Often the less mature delivery teams won't use something like version control, so a lot of the listeners here will be used to working with version control, and that's your de fact that development method working in those branches. But because Salesforce is a lie is continually continually live environment, production can
actually be edited as as it is by a Salesforce administrator. If you have the permissions, it's you're not dealing with It's not we have an application and we're going to shift and up big to it, and then you get the
new version of the application and the application is always live. So so salesforces source of truth if you like, this is a big This is a big argument in in in the Salesforce developed world is what is your source of truth because technically, the source of truth is production as it is currently live. Whereas teams that teams that are developing in a source driven method, those your source driven method will always be a few steps ahead of production just by the
nature of development. But your source of truth technically is as it currently exists. Val So, how long have you been doing your podcast? So I've been doing my podcast for I started in November November, all right, so
a year approximately. Yeah, So that should give you a pretty good amount of time to answer my next question, which is going to be what are some of the biggest challenges that come up for whether it's a perception or technical challenges whatever, what are some of the biggest challenges that devlops people face when interacting with with salesforce and salesforce deployments and teams. Yes, I try and
pick just one. So I think the word that you used there was a perception, and the perception is for a lot of folks that salesforce step ups is quite difficult to be able to do salesforce stepmomps really well and really effectively. It does involve implementing version control. It does then extend to ultimating parts of that and the foundations tends to be verage control. I've mentioned already a couple of times Salesforce has a has a Clique NOTT code interface, and that's
how the majority of Salesforce development work is done. So Salesforce, if we look at the history of the platform and how a work traditionally traditionally went, it started with clicks not code, like that was all rage Salesforce. You then started to see folks move away from them, and the more bespoke business
processes were requested developers and coding became quite heavily important. So there there are Salesforce orbs out there that are so heavily customized with custom code that you know that those orbs can become fairly unmanageable, and that obviously increases the complexity of the devils process and all the checks and balances that need to happen and and
make make making sure that code is maintained. But over the last couple of years, Salesforce internally have been doing this really big push to use the law more of the native the native functionality that's built into the platform that they've built for you to refer to that with clicks not code, messaging so so as a result, a lot of the Salesforce ecosystem, I don't really want to put a figure on it, but I would say good sixty to seventy percent
of Salesforce administrators for developers, for example, don't have experience coding, which as a result makes that barrier to entry for adopting devilops best practice is quite difficult because version control, when you're trying to wrap your head around it is I remember when I when I first started a gear so I don't have a
tech background, like I'm not developing myself. When I came to Gearson four and a half years ago, I had to wrap my head around versus control and the what SALESFORCECTIC best practices look like in comparison to how our engineers were working. And version control is quite a scary concept, and that barrier to mentoring, that initial barrier to entry, I think is quite high, and that learning curve can be quite steep, and that's something that we've made quite
a concerted effort to do it. Gearsa is build a platform. So we have a learning platform related to Salesforce DevOps called DevOps launch Pad, which I like to burge control fundamentals have to get started to burgeon control for the salesforce and things like that. That barrier to entry can be can be quite high. The I think the other biggest challenge for any salesforce team looking to change
the way they're working is a cultural thing. So this is where so I have a gear set called rob He is a salesforce developer and architect by trade, and as the background, he's spread super technical, whereas a lot of my career I've focused a lot more on business change and culture change. And there is this in a lot of teams. This this pro sets in inertia.
You know, we've always done it this way, and we're so scared of this thing looks quite demops, looks quite hard and quite difficult to difficult to implement, and we've always done it this way. Yet it's pretty painful, but it works. It's not optimal, but it works. That we've always done it this way in mindset can be quite hard to change because typically a lot of teams tend to be risk averse. There's a lot of challenges
on the platform as it is, let's not mess with anything. So driving people to see and envision that there is a better way of doing things. It requires a little bit of upfront work and a bit of upfront effort to change, but it can be done, I think is one of the other other biggest, biggest challenges and drivers behind that. So yeah, that that cultural piece is absolutely absolutely huge, and it starts with it starts with the
people. But if you have the people there and you invest in the people in their learning journey, the importance, the importance of salesforce develops and the benefits else worse devellops and users getting features faster and things like that really start to come into the fold. If if that, if you have I guess
executive sponsorship is a big thing. The exec sponsor's got You've got to have somebody that says, yes, this is a good idea from a slightly higher level, and especially when there's larger teams, to say, hey, yeah, we do want to do this, we do want to improve everybody's lives and one of at the end of the day, improve our end users lives. And you know, adopting best practice debuts does change the salesforce delivery team's
lives. It was a common thing. So I used to I used to sell gear sets, products, I used to be an account executive and help build the sell a team at gear Set. Commonly, I would speak to salesforce teams and their developers and appmans will be would be up at two three am in the morning doing un deployment. It would take ten hours to do a production deployment because of how quirky and challenging the system is to deal with.
And then when they implement a solution like gear Set for example, or any of our any of our competitors, that brings it down to do it two hours and you know, being able to go home at seven pm on a Friday rather than eleven pre Those are very very real, real life stories that you hear pretty frequently in this space. So yeah, that was That was a bit of a rambling answer to what was a very simple questions. No, it wasn't a simple question. I mean a simple question, but
I expected a fair amount of nuance. I'm curious, Maybe I don't know how much you want to talk about your career, but I'm curious how you got interested in DevOps in sales sports. You know, how did you know we jump up being an account executive and you know, so you sounds like your career is taking a more of a technical turn at some point. How did that happen? Yeah, it's a really interesting, really interesting story,
I think. So. My background prior to prior to your set, well, I did find a bunch of different different things beforehand, but predominantly hugs In didn't retail sales. Did I didn't work for a local utilities company. I did, And the job that I have before Gearset was as a recruiter, so I specialized in building architecture and design, not architecture as we as I t people think about architecture. So I did that for for three years
and an opportunity came up to work at gear Set. In the early days, Gearset was thirty other people. When I joined the company in March of twenty nineteen, an opportunity came up, came up to be a recruiter, so I spoke to the CEO and went through that process and they ended up
going with somebody else for the recruiter role. And CEO turned to me and he said, given, if somebody else did a lot bit more experience based on what we need, we do, but we really liked you and think you could do a good job on ourself team, do you want to come
and do that instead? And at this point I was just like I was sold on gear Set because the company of the culture was amazing and I really want to be a part of and you know, and entry into a tech startup, you know, as what a lot of a lot of folks are striving for these days, you know, you know, tech startups seem to be seemed to be one of the places that a lot of people strive for,
especially coming out of college or university these days. Anyways, So so yeah, it's one of the take a shot, So kme Gearsett join joined the company. We're about thirty people back then. And when I say so, but like, don't don't turn off when I say sales, folks that are listening, you know, so we're not that scary of but sales and gear Set is a lot bit different different back then. So whilst my time was account executive, what we were really was an account executive and a solution
engineer kind of wrapped up into one. So we as account executives did the demos. So often, folks that you've ever been on a product demo for any of the other stuff where that you might be investigating. We're currently usual have an account executive that does a bit of a pitch and a bit of the sale, and then that would get taken over by a sales or a solution engineer which will then demo the product and talk to you about the technical
nuance at the tool and platform and the problems that you're solving. Big gear set, we work on executives and solution engineers all in them. So me and my colleague, a few of my colleagues were that and the sales so as a result of that, they got quite embedded into the technical issues that
folks face on the platform. You know, growing startup kind of wore different hats and customer success as well, so often in the early days I would be doing customer support as well when I had a spare minute and we needed support. So all of our support is done by an intercom, which is a chat widget in the app itself, so in the early days I'll be in there and helping debug issues with customers that they might be facing. So a lot of the early days of working for a start giving me a lot
of exposure to a lot of different things rather than just doing sales. So I hope you're the sales team there, helped implement different selling motions and things like that, And I was just like, there's some things that I like. There's there's some things that I really like about this this job and like what I do, and there's some things that I don't like. How how can I do all the things I like doing and try and abstract what I don't enjoy as much? And that's how I came to have the have the
job that I have now. So I enjoy educating, educating folks on DevOps that I enjoy presenting public speaking as has though it was terrifying in the beginning, it's something that I quite enjoy. And being able to interact with folks in this space has been really fun and it's really fun, and I think it's just it's one of those things that you embed yourself into into an environment that fosters these best practices and the like I say, I'm I have a
colleague robber. It is far more technical than I am can actually code that we have skills that compliment each others. So I have a lot more experience in pitching to pitching and speaking in a in a way that an executive will understand and translated to business value, as well as having enough enough technical knowledge that a developer or an architecture things like that well also also listen to me
and have a difference. So being able to have two different style of conversations to translate value, I guess for everybody involved, and that's kind of helped how it how it kind of developed. I still haven't tried to try to write script anything. Maybe that's something that I do in a bit of downtime, but I'm quite fortunate to be supported by my colleague Rob who who handles the more technical side of the topics that we cover, and a lot of
what I do is based on extracting value. So I mentioned earlier in the podcast, and Salesforces is a Tier one business application. The companies run their businesses on it at the end of the day, and being able to get the most value of that platform is hyper important to them. The selfware develops and good DevOps practices not only enables change faster, so digital digital transformation and
change management is you know, a huge, huge bausewords and DevOps. DevOps and poor DevOps is actually a really big innovator for that, inhibitor of that happening in our space of being able to speak to executives in that way to help them get the most business value out of what is an expensive platform like Salesforce isn't cheap. It's probably the biggest expenditure in any enterprise organization. So that is that that is super important and something that I'm passionate about is is
help. It is helping those folks being able to do their jobs happen faster, make their lives happier, and like, like again, the amount of stories I get told about that this is this was such pain or as such pain in us positive stress and sleickless nights, and you know, the implement a solution to remedy that pain and it really gets it gives quality of life back to people's jobs. So so that's kind of a bit the journey that
have been on, and we'll continue. Sleep driven development is a powerful motivator, isn't it. Coffee driven development. I think it's the most common type of development I see. So if our engineering team is anything to do by anyone, I'm curious to learn a little bit more about gear Set. I mean, obviously gear Set sells services related to the salesforce, but can you maybe elaborate on a little bit what what does gear set? Do you know who would hire gear set and port for Yes, so, so gear set
actually has has an interesting story. So gear Set as it exists right now, we are an all in one Salesforce Salesforce depuls platform for companies that use Salesforce. So, but when you're thinking about how do we protect our or how do we make sure it's backed up should we have like a production disaster or what have you, we have a backup service if you need to need to move data between environments for testing or for any other reason than we have
tooling to do that. We have c I tooling, automation tooling, pipeline, development pipelines like you would set up in in bit bocket, or an action similar to things like actions. We have tooling for for Salesforce specifically. But the gear Set, gear set, the gears term is really interesting because gear Set was founded by so Kevin and Matt. We're software engineers at a company called red Gate. And you might be familiar with Redgate or if it
sounds familiar. The reason for that is is because they are a company based out in Cambridge, UK, which is where gear sets headboard that create uh that have databased det ups, tooling for Microsoft tools, SEQ server and things like that. So when when Redgate we're looking at Salesforce and doing their own Salesforce implementation, they were just like, Oh, there must be a better way to do all of this than what Salesforce gives you out in the books.
And that's how you founded is founded by We're used to being able to do all these cool things for the Microsoft products that that we made tooling for, Let's see if we can do it for Salesforce. So bringing that that
engineering culture to Salesforce and Salesforce DevOps specifically is how Gears has founded. So one of one of Breadgate's flagship products is SQL compare, which allows you to compare compare side by side those those bases, and that's what where gear Sets started, being able to compare what's in a sandbox environment versus what's in a production environment, which can drift dramatically in Salesforce developments. That's that's kind of
the journey. And through so our CEO is and stuffware engineering background CPOs or engineup our background. Really our company has grown from software development best practices is Anyway, I think that's where Gear said is kind of set apart from our competitors in this place, is we are really best peraps engineering first and making lives Salesforce developers, Salesforce administrative, Salesforce architects, Salesforce DevOps engineers, all
those people's lives better. Awesome. Oh one other questions I have before I ask, well, getting ahead of myself, if anybody listening is interested in learning to do Salesforce development, do you have any suggestions or support or direction tips for them to consider. Yeah. So, the great thing about Salesforce and Salesforce development in particular is anybody can learn it, and anybody can learn it for free. So Salesforce have this amazing it's like an academy if you
like. So it's called Trailhead. So Trailhead is a learning platform for any Salesforce professional which will allow you to go and learn the basis of Salesforce, teach you how to code apex for Salesforce. You can, you can go and you can it's all self learning. Trailhead dot com create free account. You know that there's mascots and fund trails and they give you you get your own environments to build all of these things in and you can learn so much
about the platform. So if you're interested in Salesforce development from what Salesforce is used for and the hundreds of applications that you can that you can apply to to the business, then Trailhead is definitely the place to go. If you're interested in Salesforce DevOps and how that is different in comparing to to what you what you currently do or getting best development practices, then DevOps launchpad dot com is the place to go. So caveat that is a platform the gear Set
created as well as our learning platform. However, is it is agnostic, so it is all about Salesforce develops and the different different flavors of that and what's involved. Yes, of course there's your gear set courses on how to use a gear set product on there, but the learning journey is super agnostic when when it comes to learning versus control best practices and things like that for the platform. But yeah, trail anybody can go and learn, learn Salesforce
and develop on Salesforce with trail h platform. And it's often it's one of those things that Salesforce is an incredible, incredible platform because it's because because of that low barriers and entity to learn salesforce and that clicks not code mentality, so many people from every different background can can get involved. So folks from underrepresented groups and things like that have a free platform that they can use to
start a career in tech and like routinely changes changes people's life. So there's a number of great nonprofit organizations out there like pep up Tech or Maribus for for veterans that have learning programs dedicated to salesforce to give give people that that
leg up into technology salesforces. Salesforce is a guidance and guidance evaluation of thirty six billion or something that as a company for the for the next year, and the ecosystem around that will be many many, many, many many billions. So it's it's it's it's an industry where there there's a lot of money to be made and there's a lot a lot to go around, and you can start start a career in salesforce fairly easily. It will take will take
drive and determination if folks aren't aren't already in in that space. Because it is competitive and a lot of people career transitioning, they see it as this can see it as a golden ticket, I guess. But with bit of determination and hard work, all the resources out there, you just got to go and get it awesome. Is there anything else that I should ask you about or anything important that I that we should discuss that I that I haven't
before we move towards the end of the program. It's it's all. It's it's all important, I think. I think for the biggest thing for for folks either either looking at Salesforce and think about Salesforce, Salesforce develops like in
particular life, there is Salesforce DevOps is a challenge. So I would I would encourage anybody that's listening to the podcast or two to take a look at Salesforce DevOps and I think there is there is There is probably probably a gap for Salesforce DevOps specific engineers and people with a really good DevOps background two to go in and and learn a little bit more about Salesforce and then help help
the team transform transform that they're doing internally. With that little bit of understanding. There will be frustrations because of the way the Salesforce works and some of
some of the API limitations and things like that. However, that and the methodology wise, I think there there is generally a gap for in larger enterprises, you're going to see both with that kind of knowledge anyway, and a lot of like previously previously and working working here have done liaison with internal DevOps teams that don't understand why things have to be done a certain way in Salesforce, and you know that that relationship management is is really important when you think
about think about debuts for Salesforce, but like things like implementing robust testing, so not just not just the testing that Salesforce makes makes you do. Some Salesforce has uh testing, you have to test written for all your custom code
and have to code coverage about a certain percentage and things like that. So it's like managtory testing and Salesforce. But the more that you can do in terms of setting up a robust testing strategy for security and load testing and testing that make sure but you're functional testing and the user regression testing and things like that, those things and how that's importanated into the process and where those kind
of things start and you know best practices it can be taken from software development and applied to a Salesforce team. Can be really powerful, especially if you have this. It's not uncommon to see three or four teams working on salesforce and they all have different processes, so being able to unify and government processes is really important. So there is there are challenges in in the salesforce space I think can be solved by develops engineers from from a traditional background, if
you will. So it's really interesting. It's not great. It's not for everybody, not for everybody for sure, but there are a lot of interesting challenges and a lot of a lot of things that can be solved by quite driven, driven driven people in this place, for sure. Cool. Well, Jack, how can people are get in touch with you? Are you on social media? Obviously? Have a podcast? There's your chance to tell
us all the all the places where you live on the internet. Yes, sure, so you can hear more of my voice, actually probably slightly less less of my voice. I should let the guests do the talk, a lot of the talking. And it's just that the shoes been on the other foot today, which is which is quite strange. My podcast or gear sets podcast DevOps Stories, which my host is available on Spotify, Apple Podcasts. All those good places, exciting Times is a recently rehabb the format, and
then have done recorded a few video episodes on YouTube as well. You'll be able to see that on the Gearset YouTube channel. But yeah, debups ditories. I talk a lot about salesforce develops in particular with my guests, but I also have guests come on and talk about cultural changes and things like that as well, talking about their kind of career journeys and burnout, mental health and all those kind of things are featured on the podcast as well, all
the things that I think can contribute towards improving for sure. You can find me on on x or on Twitter if you like it so underscore j x C k n c C providing Elon hasn't burned it down in the next couple of weeks with its new valuation that came out today, which is how the Bloody bought it for and you can find me on LinkedIn as well, posted a lot on across Twitter and LinkedIn. Awesome, well, Jack, thanks for coming on. I feel like i' learned quite a bit. One last
thing before we in the program. On this show, we like to do picks, So I don't know if you have anything you want to pick. I have one thing I will pick. Uh, do you want to go first or do you want me too? You go first, I'll go first. Okay, So I'm going to pick a book. I listen to the audio format. It's called The Art of Action. How Leaders Close the gaps between plans, actions and results. And it was a really fascinating book.
It's it's about, well, how do I say what it's about. It's sort of some case studies dating back to pre World War One military operations and how they can apply to business with regard to sort of a bias for action or how we how we can interact, how we can well, as the subtitle says, bridge the gap between plans, actions and results. So it's it's kind of the antidote in a sense, or one possible antidote to the strict, top down hierarchy approach that you know, Taylorism may be promoted.
So it really ties in with, uh, the the ideology of agile and DevOps and all this sort of stuff, which is why I'm bringing up on the show. So it's it's a it's an interesting book. If you like history, uh andy like business, this is the perfect book because it really ties those two together for you. So that's my pick for the week. The Art of Action by Stephen Bungay. I think is how you say his
name, So that's my pick. Cool. I am gonna take a take a little bit of a different angles, So my pick is going to be actually, what I watched on Netflix last night. So I watched I watched Pain Hustlers on Netflix last night. I thought it was fantastic. So Pain Hustlers is based on the true story of a company's rise of rise whilst selling a Sentinel Sentinel spray and how their business practices contributed to the opioid crisis in
in the United States. I think the best way I can kind of describe it is it's a hone down version of the Wolf and Wall Street by the toneedown version of Wolf and Wall Street. But it's shot really well. The into interpersonal relationships in that in that movie you are fantastic and there's some really great acting. It's directed by David Yates. So if you're a Harry Potter
fan, I like what you did with that. This is a certainly more grounded and based version of of his his way of storytelling, which I thought was really excellent. So Yeah, Pain Hustlers on Netflix with t out of ten. I'll check it out. What's a good Thanks Jack, it's better a pleasure. Hope to chat to you again soon. Donan, thanks for having me. Thanks everybody, Yours