Description
In this DevOps Launchpad “Careers in DevOps” webinar, Principal Engineer Kyle Bentsen shares the key moments and mindset shifts that defined his journey through the Salesforce ecosystem. He’ll walk through the moments that mattered — including the first time he saw a DevOps model in action — and explain how that experience transformed his approach to Salesforce delivery. To learn more about building your Salesforce DevOps skill set, visit DevOps Launchpad for free training, practical courses, and DevOps certifications.
Transcript
So without further ado, I'm very excited to introduce you all to today's speaker, Kyle Benson, principal Salesforce engineer. So if everyone is ready to get started, Kyle, I shall hand straight over to you.
Cool. Thanks, Amy. Hey, everyone. Thanks for joining today. So like Amy said, my name is Kyle Benson.
I've been a Salesforce professional for the better part of twelve years, most recently as a principal Salesforce engineer.
So let me jump into a quick agenda of what I'll be going through. So kinda taking a look at some of my, career progression from the early beginnings as an accidental admin to where I, most recently was a principal Salesforce engineer, and eventually how DevOps played a role, in in, as an important part of my career. And then I'll also, you know, give a few takeaways or pieces of advice, that I think, you know, made things successful for my career.
So my very first desk job, I was working as a customer service agent.
We were using, email to case, at the time.
And, when I started, I expressed some interest to do something more technical down the road, but, you know, I kinda understood I had to had to pay my dues first and, kinda do some groundwork for a little bit.
But sure enough, about six months in, the guy that was running the Salesforce, configuration for that email to case left, and they needed someone to take it over. So they, asked me if I'd be willing to step up to, to do it. And I, you know, I had no experience. I had no idea what Salesforce was, but I said sure.
Took it over, and, you know, kinda basically never looked back from there.
So I did do you know, I was doing pretty pretty rudimentary stuff, you know, for the first beginning. And then, eventually, I got to a point where I was trying to to do some calculation on case, you know, status time or something like that that, you know, I I was trying to figure it out, and I figured workflow couldn't do it. And so that's when I discovered Apex Triggers.
I had taken some coding classes online before, so I felt like I could probably take a stab at it.
Sure enough, you know, made the classic developed blunder putting, I think, DML in a loop or something in production.
I'll still never forget.
As soon as I deployed, I I remember someone, you know, they didn't yell, but I heard out loud, you know, a few desks down the road, like, what's wrong with Salesforce?
So, you know, I had to quickly, learn how to how to do rollback and and, resolve the issue and and all that, stuff. So, yeah. I was there for a few more months, and then, there was some new leadership brought in. They were they are a big consulting agency to look at our eco systems ecosystem. They were looking at things like Siebel, and I was like, I don't know if I like that.
You know, it's a trend transition away from Salesforce, but, didn't really matter anyways because we got acquired, and I got impacted and and was laid off.
My next role was a this was my first actual, like, Salesforce specific role. I was hired as a business systems analyst. So I was doing a little bit more, you know, stakeholder engagement, gathering requirements, creating some user stories. But, we did have a pretty small team, so I was still able to do some some build as well. And, and and that was in development market.
And there was another acquisition at this company, and, I was, again, impacted and and laid off.
So, this takes me to my next, position.
So by now, I felt pretty confident in my developer abilities. So I went for a developer specific role, and I was actually hired at a startup called Open ENS, to as a Salesforce developer to work on Zuora plug in, rules that required Apex development.
So that went pretty well. And then I'm probably always there for, like, eight months, and we got acquired by Cisco. And I'm thinking to myself, oh, no. Here we go again.
But it actually turned out to be further from the truth.
I actually went on to have a very, you know, fruitful career at Cisco. Really great career progression there.
So, yeah, that that was that was going really well.
We integrated with Cisco, not both, figuratively, but also literally, you know, we joined Cisco and and, you know, got part of their company culture and all that stuff. But we also literally integrated with, our, Salesforce instance at opening us to their purchasing platform. So that whenever a Cisco customer bought an OpenNAS product, we had an integration to our Salesforce that would provision the OpenNAS services to those customers in an automated fashion. And that was probably one of the, if not the coolest thing I've ever worked on in my career because it was, something that folks that so many people that Cisco had said they'd never seen before. I thought it was super cool.
And so, with that being said, you know, that we kinda got to keep running our own instance at, the open DNS instance at Cisco for, the foreseeable future.
But, you know, sure enough, you know, working for Cisco, it did sit well with everyone on the team. So lots of people, that I've been working with for a while started leaving.
I was about to leave myself, but the, leadership at the time, you know, asked if I wanted to step up and take over, to become a manager and rebuild that team. And I'd I'd thought about wanting to become a manager one day. So, you know, this is a perfect opportunity. So I I took it.
I rebuilt the team, you know, hiring a couple admins and developers.
One of the major things I ever saw as as team lead was, our CBQ implementation, on so we called it SaaS Connect, which is previously the opening as and since it was now called SaaS Connect.
And during that, that was my first exposure to a super awesome DevOps tool called Gearset. And if though for those of you who don't know what Gearset is, it's a tool that allows you to do, comparison metadata comparison not only between orgs, but also source control, automated deployment, automated unit testing, data backups.
There's a CPQ out and all all sorts of great features that that make, a lot of the things, for deploying to Salesforce, much easier.
So, yeah, I was doing, I was team lead for a while, but, I kinda started to miss, being a little more hands on with things.
And I also kinda wanted to go this route, eventually, but, I, like I said, I didn't self demoted myself to an individual contributor role as a as a technical architect.
And some of the things that I oversaw as a technical architect at at Cisco was, a multi technology design on the SaaS Connect platform, which, like we did with the OpenID NAS, we folded in a number of other products, to enable sales and auto provisioning of services, on our platform.
I did a, oversaw a territory, realignment service that managed how the OpenAS and similar sellers aligned to bigger Cisco territories. It was very it was a very complex structure, so, very tricky to, keep that up to date.
And, instituting a a flow first mentality for all of the automation we were building on SaaS Connect.
You know, flow does a lot of great things, did a lot of great things at the time, but still wasn't complete. So, obviously, saw to have some code here and there. So but, I found a way to kinda keep a happy medium between the two of, you know, using Flow and code together, and using invocables.
And then also just kinda overseeing cleaning up a bunch of technical dev on the SaaS Connect platform, some of which was, brought, you know, from myself when I first started. You know, I wrote some some overkill tech unit tests that need to be optimized, a lot of stuff. So, yeah. So I so in the technical architect role for a few years, and then, sure enough, you know, new executive, direction, kinda had some philosophical differences, so I decided to move on.
And then that led me to my most recent role as a principal Salesforce engineer at, Intercom. And this, you know, this is what I really wanted to do to be back hands on, like, day to day. You know, as a technical architect, you're definitely seeing things from a bigger picture perspective, not quite, you know, hands on keyboard as much when it comes to, like, code and and building flows and stuff. So, doing this really got to get me back, you know, in the weeds.
So first things first is I, took a took a overview of their code base. It was pretty, you know, it was it was, like, I I say over engineered. You know, they coded way too much. It didn't really need to be code, and, you know, it's kinda brings me back to the philosophy that I had previously. It was, you know, flow first.
In fact, I institute policy of automation.
All automation or sorry. No new code should be written unless, you know, you know, goes through me, approved, and, signed off on, by me. So everything should have been done, full first.
And then this was my first time working more directly, with Gearset, having a dedicated, customer success manager to really help guide me, getting Gearset, and and the DevOps process spun up for the team.
So using GitHub as source control and rolling out pull request process for feedback. And then, again, as Gearside kind of sitting in the middle of facilitating all that, for us in an automated fashion.
And then, also, using the, Gearside for CPQ, Adam, which the CPQ team billing team was absolutely thrilled with.
No longer did they have to manage if any of you used CPQ before, you know that all of the configuration lives as records. There's complex, relationships between all of them, and and deploying them could be a major pain. CPQ, you know, streamlines that process, and you don't have to manage everything through spreadsheets or, you know, random documents or whatever. It's all streamlined through yourself, which is super awesome.
And I also got to spend a little time learning some new tools, Recondo, Census. I've been writing down Datadog was another one.
Just kinda doing some, you know, work on some periphery tools outside of Salesforce that that, you know, do some some cool things.
So how does this all tie into DevOps?
So going back to my, beginnings at opening us, probably my first two weeks, you know, there was a there was an issue that the platform engineering team, so a different team than the the Salesforce business systems team had.
Something related to a query locator issue, they couldn't figure it out, so they asked me as the new developer to try to help them figure it out.
I wasn't quite sure either, but I was I joined their HipChat channel. Shout out to those that remember HipChat.
And, I so I was in that that HipChat channel and, kinda just never left. And I just kinda started to observe what they were doing in there.
And I saw some really cool things.
You know, they would have, automated pings for when pull request checks were passing or failing.
They would give feedback to each other, on each other's pull requests. You know, if they have comments or they would, you know, they would ping like, hey. Can someone check my pull request?
You know, build updates.
If a build failed, they would be able to, like, restart it to to auto deploy.
All all this cool stuff going on in this channel. Like, woah. This is awesome. I would love if we could have something like this for Salesforce. But this was, you know, quite a quite a while ago. I didn't don't know if gear set was around yet, or if it was, you know, it was probably pretty pretty nascent.
So I things I really only found were, Jenkins and CircleCI. And and looking at those, those are kind of outside the realm of my expertise at the time, and I didn't really feel like spending the time to to figure it out. So I kinda just, you know, put it to the wayside, and and I'll I'll come back to it someday.
And then, you know, flash forward a few years later, we get to, like I said, that CPU implementation, started looking at GearSat to help us with some of the deployments. And then, as I was looking at it, I realized, oh, yeah. That's that's some of that stuff that I'd seen from that previous team that could help facilitate, doing a lot of that automated deployment that, you know, Salesforce, in its native capacity is is still a little clunky with.
So, yeah, and then at at Intercom, I was really taking over the DevOps process and getting a lot more time on with Gearset.
You know, really got to to get that process rolling.
And, you know, I think one of the things that might scare some folks away from from, you know, DevOps on Salesforce and and using source control, you know, GitHub is that it's not just for code. It's, it you can use it for all metadata. At the end of the day, metadata is just XML.
It can be a little tricky to kind of decipher at first, but I like to make the joke that it's a lot like the matrix where it's a bunch of green and fallen texts.
But then one day, you just you just see it.
So there's no reason that, the XML for all the other metadata can't be managed out of, source control.
So, yeah, that that was my, my venture in in DevOps.
And, so they're kinda tied it all together with some of the things, takeaways, advice.
You know, stay humble, and acknowledge you don't always know everything.
There's always more to learn.
I think, you know, most recently as a principal engineer, I hadn't really known or I I've been aware of, mocking and stubbing for, unit tests and, but never really put it into practice. And then there was a consultant that that showed me how he did it, and I'm then I learned, oh, okay. This is how we can make use of it for for our use. So, I always think it's important to, you know, even as an advanced principal engineer, there's still always more to learn.
And, also, you know, be open and receptive to feedback.
I think sometimes folks can can feel, almost, like, insulted by by, you know, feedback when someone says, hey. Like, I think, you know, this this can be improved or done a little bit differently.
I've often found that some of those folks, that that didn't have a knee jerk reaction to, be defensive, tend to not be, you know, grow as quickly as some others. So always be open to that. You know? Feedback is positive.
Right? It's it's not meant to be, you know, criticized. You did a bad job or anything like that. So, and, you know, I I've mentioned a bunch before the flow first mentality, clicks every code, but, but, like, really, take it to heart.
Like, I think some developers still have this tendency to fall. You know, they just wanna jump right back into code, and they are trying to to solution something.
So I always challenge, you know, them. Like, hey. Like, did you exhaust all did you look at all options? You exhaust everything to make sure you don't need to write code for this.
And, you know, five time you know, nine times out of ten, they'll be like, oh, yeah. You know, we could do it this way, in a flow. So, you know, always always be learning. Keep up to date and fresh with your skills.
You know, Trailhead, first and foremost, I'm sure everyone's seeing all of the agent force, stuff that they're pushing on Trailhead.
You know? Follow some blogs. Salesforce Band is one of my favorites, especially when they release the the, you know, the the, maintenance or I'm sorry, the, release notes. And they, you know, they go through and they skip they pull out the best parts of it. And I always look out for the ones for for Flow, every, every release. Those are my favorite blog posts to see.
Plus one for everyone attending this webinar today. You know, attending webinars are your favorite, tools and products.
And if you haven't already, make sure you're registered on the DevOps, launchpad.
You know, push yourselves, push yourself outside your comfort zone.
Whether you're a new admin that's ever touched Flow before, you know, be willing to take a stab at it. If you never used GitHub before, you know, play around with it. There's tons of online documentation. Don't be scared to to download and stuff.
But just make sure that, you've properly tested anything before we push it to production, if it is going to fail.
And, you know, don't hesitate to ask for help. And that that's not only just your own team. You know, don't be afraid to ask for, help from outside teams. Like myself, when I was spinning up some of the the DevOps process and and GitHub pull request process. I was working with some of the, the tools and and product engineers, to see how they had had set things up before.
And so their help was, you know, super helpful. And they were they were more than happy to to, you know, spend the time to, help me out there.
And, you know, I think we all love Salesforce, but, there's all lots of other cool products and tools out there. Like I said, I've worked on, Census and Mercado, recently, and those actually opened my eyes to how much better those tools can do, like, data transfer between platforms and and services as well as, workflow integrations better than Salesforce can do.
So, you know, branch out, learn some new tools.
So I think that about wraps up what I have from my end.
I'll kick it back to you, Amy.
Awesome.
Thanks so much, Kyle. That was fantastic.
And as you can imagine, we have a ton of questions to get through.
So I'm gonna kick it off with, this question from Christa who wants to know, Kyle, did you have an IT background at all prior to your salesforce?
No.
I my my very first job, I was I worked at Target. I was the, the guy that ran around at the front to manage all the cashiers.
So that first desk job that I got where we were using Salesforce was, like, my first kind of, like, exposure to IT. But, like I said, I I, you know, had some some online courses that I'd taken and, learned some programming, but it was still very, you know, very basic at the time.
Yeah. No. Awesome. I think, Krista, you find that a lot with folks who fall into Salesforce ecosystem. Right? They come from all sorts of backgrounds.
Yeah.
Awesome. So another question here, from, Satish, who asks, I'm a functional consultant. I do not have any coding experience. Are there any resources you would suggest to learn or get hands on? And they specified to get hands on with GearSet and GitHub, here. But I imagine some of those, online coding stuff you did would be useful here as well, Carl.
Yeah. I mean, Trailhead. I can't I can't stress it enough.
I recently was working on, I think, like, the Apex specialist super badge, and there's tons of, like, hands on coding, exercises in there. So that's that's a great way to get exposure, to to learn.
And then so the the coding class that I've taken prior, they were just kind of, you know, general, practice type classes. I think we were do we were using Ruby, but they were really teaching us about, like, philosophies like, test driven development, you know, behavior driven design, things like that.
But then you also were you, taking the code that you were learning to apply some of that knowledge. So, honestly, at the end of the day, any, like, basic programming of Python, you know, that's that's a real simple language. So take some online Python courses that'll teach you, how to code. And then, or or Java because Apex is effectively Java. So if you take some Java five, you know, online classes, that that would be a good segue into Apex.
And then as far as the the gear set and and GitHub, that one, it's that's a tough one. I I don't know if the DevOps launchpad has some some, options in there, but, you know, get GitHub's open source. Just start looking at, you know, repositories.
Some of the just search like Apex trigger frameworks. You'll find I'm sure you'll there'll be plenty you find on GitHub, and just start looking through them, and you'll kinda start to to see, how things play out, and look on on GitHub.
Yeah. No. That's awesome. Great advice, Kyle. And yeah. And, Satish, we do have, a few courses on DevOps Launchpad that are gear set specific.
Also in things like introduction to version control, which is gonna help you out with, Git principles there. So you can check those out on DevOps Launchpad. Also, if you did wanna get super hands on with Gearset, Gearset do offer a free thirty day trial, so you can try out everything.
You can set up some, yeah, some trial Salesforce orgs and and plug those in and and have a play.
Awesome. So we've got a few more questions here, if that's alright with you, Carl.
So Yeah.
This one is from Lauren. And Lauren says, I'm currently working in a Salesforce admin role, but I'm looking to improve my technical knowledge, so I can collaborate better with my developer colleagues. Do you have any advice on navigating the transition from admin to developer and other more technical roles?
Yeah.
I mean, you know, I think one of the things I've been pushing hard on is is flow.
So I think that's a very natural progression from, you know, what a basic admin might do now, you know, because it's clicks. It's all it's all UI based.
But you can do some very powerful things with flow that almost lead you to to understand what a developer's mindset might have. So, for example, you know, if you building subflows is kind of, like, similar to having microservices in your in your Apex code base.
So just, yeah, starting to get in a flow will, I think, be a natural transition to to, hopefully, see how you could turn that into, working on code.
Yeah. Great advice.
So another question here from, Simon who asks, how did implementing some of those Git and DevOps practices into your Salesforce team go Yeah.
Face any tensions or challenges, and how did you navigate this and get why in? That's a great question.
Yeah. That definitely it was it was a challenge, initially.
You know, a a lot of the team never used GitHub before, so it was it was not, not it was a new tool for them.
So it was a little scary.
And, you know, like I said, a lot of configuration is XML, and it just doesn't make sense to look at.
But, you know, as someone that did understood it, I made myself, you know, available, to to help out, you know, as wise as needed.
Yeah. I I think let's see.
Oh, what else can I say? Yeah. I I just just make sure you have a a good, advisor. And like I said, there's lots of online documentation, for for GitHub.
It's it's it's a pretty easy tool. I think you folks can pick it up pretty quick. And so, eventually, the team got to, you know, be more comfortable with it, and, you know, they stopped having to come to me every time for having a question on, you know, what does this mean or how does this work in GitHub?
Yeah. No. Great advice. I think especially once people start seeing and using the tools and seeing how the tools can actually benefit them and they're like, oh, wait.
This is now much easier or much faster. I think that's when it really starts to change and and implementation yeah. You see see all the benefits, at that stage. Awesome.
So we have time for just one more question.
So this question is from Yolanda who's asked, yeah. So could you elaborate a little bit on your flow first mentality? You've mentioned it a few times. Have you ever found an instance where flows didn't meet your search. And you had to roll back to code?
Yeah. Yeah. Absolutely. Sorry. I I I should preface all this. Like, you know, development Apex development is not going anywhere. It's still an important, facet of a Salesforce team.
I think to to me, my my best, like, way to say this is a a strong, engineer developer is knows when, to not write code, instead of to write code. But, yeah, no flow. Still still you know? It's great.
It has a ways to go, before it can, you know, completely take over Apex. Probably never will. But, yeah, I think there was something recently we were working on, like, a, a scheduled job, and I'm like, oh, I think that could be done as a scheduled flow. But because of, like, volume limitations, we ended up having to not go with flow and and and and do, like, a scheduled a text job.
So, but the point was we exhausted the, you know, try to do it flow first. And then once we found out that wouldn't work, then we transitioned to, using code.
Yeah. Awesome. I think our attendees are trying to keep you on your toes here, Kyle. Yeah.
Awesome. Well, unfortunately, that is all we have time for today. If we didn't get around to answering your questions today, feel free to reach out to us at team at dev ops launchpad dot com, or you can, easily reply to the email we'll be sending out tomorrow with your webinar recording. So make sure you keep an eye out for that in your inbox.
And as Carl mentioned, if you aren't currently a DevOps Launchpad user, you can go check out our free Salesforce specific DevOps courses and certifications over at dev ops launchpad dot com. I've just popped the link in the chat for you.
Yeah. And you can sign up for free there with a ton of resources, as I mentioned earlier, to help you on your Salesforce DevOps journey. So thanks so much everyone for joining us. And once again, a huge thank you to Carl for presenting today's session and answering all your awesome questions.
Yeah, we hope you found it super insightful, and we'll see you all again very soon. So thanks so much, and take care, everyone.
Take care.
