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