In Conversation with Matt Pieper

Share with

Description

Matt Pieper, Director of Business Systems Engineering at CareRev joined DevOps Advocate Jack McCurdy for a conversation exploring his team’s journey towards CI/CD. We discussed the challenges CareRev faced when using a traditional development process. Matt and his team turned to a DevOps solution in order to increase their efficiency and work more seamlessly across the organisation.

In this conversation, Matt shared how his team is using DevOps to elevate their Salesforce practice, and the changes to processes, culture, and tools that helped them achieve their goals. Watch the recording now to hear more about the team’s experience, along with Matt’s real-world tips for CI/CD implementation.

Learn more:

Related videos:

Transcript

So without further ado, I'm, I'm gonna gonna get into it. So, my name is Jack McCarty. I am one of Gearset's DevOps advocates, here, at Gearset. I've worked for Gearset for the last, three and a bit years or so. And over that time, we spent a lot of time with Salesforce customers that are looking to improve their release management and look to add a DevOps strategy to their Salesforce environment, giving the best price advice.

Worked with companies of all shapes and sizes, and it's been really fulfilling to work with companies, like CareRev and with people like Matt, that have been really dedicated to solving some of the biggest challenges on the Salesforce platform when it comes to those releases. So I'm really excited to be, to be joined by Matt today. I'm I'm gonna get rid of, get gonna get rid of the share screen here, for a minute because, we normally see this, see this image, for the rest of the call. But I'd love to love to hear, a little bit about yourself and, if why don't we give an instruction for everybody?

Sure. So I'm Matt Peeper, our director of business systems engineering here at CareRev. Carerev is a a health care marketplace that places professionals with, our facilities as well to to really help with the health care pooling and integration space here in in the US. I've been with CareRev since December of twenty twenty one, really, as our foundational team member to to really own our Salesforce process. Outside of CareRev, I've been in the Salesforce ecosystem for well over twelve years now in a variety of different industries and, you know, really get excited from the development and architecture piece of how we can enable businesses with, with with Salesforce and really get that best practice going and and reduce those swivel chairs and and clicks that we we see too often between different SaaS platforms.

Awesome. Thank you, Matt, and, I'm welcome to the call. So, really curious to know a little bit more about, about twelve years years or so. So, what's kinda led you to this point, and what's, what's kind of motivators for getting you to join CareRamp, which is a fairly recent transition for yourself?

Yeah. Absolutely. So, within the Salesforce world, I got started in Salesforce day one as an internship, about the second year of my MBA where, they had rolled out Salesforce. All the project managers, all of the the individual stakeholders had, you know, kind of vanished off the project.

In day one, they said, hey. This isn't what you signed up for, but here's your, you know, your your project moving forward. Congratulations. You you are owning all of our Salesforce for this ecosystem.

And so really came into the days before there was flows. Right? We were just rolling off of of, you know, s s flows. Right?

And a lot of everything was Apex and Trigger. So really dove in in classic and and got in, to the the weeds there and and really fell in love with it. Over the years, I've worked for lots of different organizations, some that did have Salesforce and some that didn't, but it really drove me into that business system space where I realized there's a lot of empowerment between rev ops, sales ops, and even the service and operation side of the house.

Coming from my last organization that didn't have Salesforce, I was itching to get back into that space and really be with a company that made a difference and and really had a mission driven that, you know, everyone can get behind. Because even if you have the worst days of of your your, you know, career, if you have a company that really has that mission and and drive, you know, it overlooks some of those as well. So, came on board at CareRev where they had implemented Salesforce about two years ago, but we had a little bit of a stalled implementation and really wanted that technology in house to to drive it forward. So came on board in, you know, in December and have been pushing the pedal ever since.

Yeah. It's absolutely awesome. So, I suppose that leads me quite nicely to to the question. So, I'd love to hear a little bit more about, what the current state of Salesforce is, at CareRev and what are kinda, like, the bigger objectives for CareRev as as you kinda grow and make, make use of that, amazing run of funding that you had recently.

Yeah. So CareRev's about four hundred fifty employees now. We're about forty, earlier this or or last year in twenty twenty one. And so with that came a lot of of acceleration and change management and change. With Salesforce itself, out of the four hundred fifty employees, we have about two hundred seventy of them on platform.

And we use that platform on the sales side to to bring in, new opportunities, right, with marketing, generate that traditional lead flow, lead generation, but also heavily on our operations side. So we bring in a lot of data from our applications, our web and mobile app on the facility and professional side, and we bring all of that into Salesforce so our client facing operations folks can can really empower and deliver that value to them. So whether that's outreaching to new professionals to to answer those questions that they have, verify their credentials, because as a health care professional, you have to have things like TB checks, your your nurse's license, all of those verified.

And then coming here soon, we're going to be rolling out service cloud to really start to get those KPIs and metrics of what are those requests that are coming into it.

Mixed into there as well, we're rolling out a huge MuleSoft initiative to bring that data from our from our platform and really start to solidify it. So as you can imagine, with all of that change management and change flow, there's about a team of seven that are constantly in the platform making changes to metadata or to to Apex triggers.

And we all wanna stay, you know, on the same page and make sure we don't overwrite people and have to dump into a Slack channel and say, hey. Did anyone make a change to x y z? It just broke everything. So, with with that being said, there's a lot of initiatives moving forward. And, you know, right now, we have a lot of one way data coming into Salesforce, and we're looking to to also have that, you know, web call apps from Salesforce to our apps to to really have that fully connected ecosystem.

Yeah.

There's certainly a lot going on a lot going on there, which I'm sure resonates with, with quite a few of the folks in the room here here as well.

You know, Salesforce has capabilities can kind of extend and go go way beyond when we start really looking at it and and what have you. So with all of that going on and, all of those considerations, new service cloud, MuleSoft, etcetera, etcetera, Tell us a little bit about what the release process and the change management process looked like at CareRev before you kinda started this journey that you've been on, towards a better DevOps process.

Yeah. Absolutely. So I'll say this, and I'm sure if I could see everyone's faces nodding, I think a lot of people have gone through this exact same situation, especially in the the SMB space. So when I came on in December, we had about two hundred or so users, and about sixty of those were system system administrator profiles because of one way or another changes happen. Right? And the easiest way to to, get to success, right, is have full access to the platform and and see everything.

So, we have, our two environments, our production and our integration environment tightly coupled to, our our bespoke applications as mentioned before.

And what was happening is, you know, people were making changes to restricted pick list that we had or individual, field level security, and it was breaking all of our data pipelines. We also didn't have parity between our lower environment and upper environments. Most of the changes were done, you know, within production, other than the the required changes that had to be done in a lower environment such as, you know, Apex, development.

And so this created a lot of tension between our engineers, who are managing our application and, everyone else because we were getting all those roll bar and and logging errors that that pieces were breaking. And so, you know, it was really hard to to track down who changed anything, and to the point where we even wrote our custom script that literally dumped into a Slack channel all of the changes that that occurred within Salesforce. So we had an easy auditable log going back and forth, and it could hunt those down. But, you know, be before we started looking at the DevOps pipeline, we are probably spending about ten hours a week, researching breaking changes and and why they occurred.

That is a significant time sink.

When you have a million million and one, other things going on. So so what were kinda when you realized all of this was happening, what was, like, your thought process, and how did you decide to do something about it, I guess?

Yeah. So when I came on, I knew instantly that we had to have a development pipeline of some sort. And instantly, you know, the my head went to, okay. You know, have lower in sandbox environments and and push things through change sets.

You know, no one loves change sets. I I think that's no no secret to to anyone out there. They're they're a necessary evil, but I think I've spent, you know, half my career migrating things just troubleshooting change sets and and why they broke and and shaking my fist into the air. And so I didn't wanna go that that route.

And so being in a technology company such as CareRev, I knew we had a DevOps team, for our application. I knew we were, you know, well very well versed in GitHub and and GitHub action. So I wanted to replicate that on the same side as the Salesforce team. Our the business systems team reports into our CTO.

We're embedded with engineering. So I wanted a team, to have those same tools where we could talk apples to apples with the rest of of our core folks. And that's when I realized, like, yeah, let's go find a DevOps tool, whether we're gonna build one through GitHub actions and Jenkins, and and kind of fight that way, or let's go find a a SaaS provider out on the market that provides more of that declarative change. And when I started thinking about how I wanted to staff my team, I realized I would have that mix of developers and admins.

And while, you know, those those traditional DevOps pipelines such as Jenkins work really well for our engineers, it really puts a burden on our admins. So I wanted to, you know, feel like they are part of that release process that they could, you know, ship out, you know, changes on their own without having to rely on an engineer or learn a completely different tool set. And so with that, you know, kind of started nerding out, right, and diving deep into to to medium and and, you know, even the Salesforce help articles, the DevOps launchpad to to really learn what I didn't know. And we made that decision.

Yeah. Let's go with the SaaS provider, that can that can bring value to our market.

Yeah. For sure.

It's such a such an interesting thing you mentioned there about trying to bring that cohesion between app and developers because that's often quite a big gulf that that we see or can be quite a big gulf that we see. And that kinda ties to something that you said just a moment ago about a a bit of tension between, you know, the promotion from the environment by Apex and and things like that. So I'm really interested kind of at the start of this process is what what were you considered about from or what were you considering from that kind of cultural change perspective? You know, was that something that you thought about from the beginning, or is that something that kinda came in later or as part of the expectation when you started to do a little bit more research?

Yeah. I knew, you know, having to staff a brand new team, I knew it would be hard to go out into the market and find people who, you know, all had experience with the same tool or, you know, individual methodology. And so, you know, definitely within the interview process, that was, like, my number one question of, you know, you know, why don't you do development work in production? Right?

How do you manage, you know, your your development pipelines and pushing that? So I wanted to instill a culture from the very beginning that we are going to use traditional best practices from a software development life cycle process. You know? We wanted to elevate our Salesforce practice to have parity with our software engineering teams.

And so having that cohesion, that change, that culture itself was was vital for us and something that I wanted to instill from the very beginning.

You know, I mentioned there were sixty system administrators when we came in, and we had to have those tough conversations of, you know, I know that you are an admin in your prior, you know, career. Right? And and this is very powerful for you to go, but here's what we're going towards. And I wanna build a team that supports you, and that we can push those changes, work through our pipelines versus you having to balance your your day to day delivering value to our clients and then also, you know, doing software development. And so having those conversations, you know, we're deep on about that. And I knew having a a DevOps process to actually rapidly introduce those changes were only gonna be the way that I can get, you know, rid of those sixty six, Salesforce admins down to six.

Yeah. For sure. For sure. You mentioned, the kind of culture and the cohesion and best practices that the, the software developers that were looking after the app, had as well. For you, what were the key things that they were doing, that you wanted to to replicate?

Yeah. I think it's the the ability, right, to have code review. You know, I think we can certainly push declarative changes through, but we might not have the best practice. Right?

Or we might remove a field or a record type, that could break somebody else's flow. And so having that ability for someone else to come back and look at your architecture and say, okay. Make some tweaks here. Make some tweaks here.

Everything looks good, I think is a a phenomenal best practice that we do in the software development world that, you know, sometimes gets overlooked on the the admin side of the house. So we also wanted to have protected branches, so within our pipeline. So we can merge everything in a lower environment, but in our higher environments, we want to make sure that we did have those code reviews. And so that way, we don't have rogue changes that might occur.

And then we'd have that that history as well, that source control to say, yep. This change was made on this state. It's tied into our, project management software to to to have that coupling and and have a little bit of that forensics and that get blamed to to look backwards.

I think it's also that ability and flexibility to have that hotfix deployment because sometimes changes do happen on a weekend that you don't wanna push all the way through that process. And so the best practice is, right, having automated testing, having monitoring that goes on in our environment nightly, and then having those changes that are well documented and have those stage gating. And that's been a phenomenal boost for us because even when changes do occur, we can go back and and look within the repo to go, okay. This is what happened. Maybe we need to roll that back and and and and and be able to fix it.

Yeah. For sure. Those are those are all excellent things and something that I think a lot of people get a little value from really quickly when they first kinda start on this path and accelerate their understanding of what what they can actually do with their Salesforce environments and their Salesforce set up structure.

But we talked we touched on branching and and Git, you know, concepts that are familiar with developers, but not necessarily with admins, which we've mentioned we have quite a lot of it in care as well. So how did can you tell me a little bit about that journey for for those folks that weren't so in tune with with those kind of best practices and those kind of operations?

Yeah. I think, the the the biggest challenge, I don't think, is necessarily source control. Right? I think, you know, branching, you you can draw that corollary between regular sandboxes.

Right? You're moving things up up a pipeline and, you know, you have your UAT and your staging, which I think traditionally most admins are familiar with even with change sets. I think what from a DevOps perspective, no matter what tool you use, is really how that metadata looks. You know, looking at XML versus looking at something in a UI is completely different.

We all know as admins, you know, what a profile is, what field level security is, but none of us have ever, you know, pulled back that that curtain and said, okay. This is a layered set. There's a lot of dependencies that come on this.

And when looking at tools, I wanted something that that, you know, could guide it through. And with gear set, we've been, you know, especially excited about that because we can look at those profiles and see what those dependencies are. We can pick out those individual components and push it through, which has been a tremendous culture shift for our admins because they don't have to understand every single, you know, nook and cranny. They can they can pick, go look at a problem analyzer, figure out they missed something, and go back. I think the the biggest cultural shift has been when we rolled out, our our initial DevOps, we were just doing org to org. I wanted our admins to just be comfortable with moving things from one Salesforce environment to another Salesforce environment, so to look at what those individual metadata components are and kind of the gotchas that you would have to to be familiar with the tool before we introduce the new concept.

And so that org to org side, while we figured out our pipelines and our source control strategy, really helped. And so when we did move to source control, it was teaching a little bit of git and what a PR is, but they kind of understood those underlying mechanisms of, okay. I'm just taking metadata and moving it to another place, but I'm using GitHub as really that intermediary between those two environments.

Yeah. For sure. That that that makes it that makes it that makes a lot of sense. And, for sure, it does help having having a vendor, a vendor help you help you with those things and can flatten a lot of that a lot of that learning curve, especially for for those less familiar. But something I wanted to talk about because you mentioned earlier that that you did decide to go, the SaaS vendor. Obviously, that vendor was GearSet, you know, full full disclosure for everybody here, which is, which is, which is obviously great.

But I'd love to love to love to hear your kind of experience about that actual journey. So when you decided to go with SaaS vendor, how did you go about picking a tool and picking a partner that that was best for you? Because there are a lot of options on the market there. If you don't decide to build something in house yourself, which, like you said, you considered and tried looked at replicating with what your software engineering team were doing. If you do go down that route, you know, what's kind of your advice to anybody that's looking down that path, and what are the main things that they should consider, based on your experience there?

Yeah. Absolutely. And I think I'd preface it right. There's a there's a lot of different options on the market, and I don't think any of them are necessarily, you know, horrible.

Right? I think as we we go through other SaaS platforms out there in the world, I can tell you, like, I'll stay clear from them. They're they're they're they're awful. But I think for us, our our strategy was we wanted something that didn't reinvent the wheel.

We knew that, you know, we we had familiarity with GitHub internally.

We wanted something that we could would still continue to use git you know, GitHub for our source control if we moved to, you know, you know, Git bucket or or any of them that we had that parity and we could easily shift. We didn't want some a tool that, you know, kind of reinvented the wheel with with repository management, within it. And even though, you know, we we also wanted to abstract that out of the Salesforce layer itself. We wanted a tool that stood by itself so that way we can have, in the future, those CLI hooks, right, be able to call out when we deploy something in Salesforce that we're calling unit test from our application, to make sure we didn't introduce any breaking changes.

Because as I mentioned earlier, we're tightly coupled. We have Heroku Connect in the the ecosystem. So we wanted to eventually build tests that says, before we move this to a next environment, call out to Heroku Connect's mappings and see if we're we're removing a mapping partner. Right?

Like, I don't like to buy software that we just purchased and it, you know, it works and we're off to the races. I wanted that where I can pick up customer service and it works and we're off to the races. I wanted that where I can pick up customer service and support and ask them that question. Right?

I want them to be able to to coach and mentor us us through it, and, you know, ask for our feedback for, you know, improvements to the platform.

And then I think the the proof in the pudding, right, that where we can pick up a trial and get up into running within that one week where we don't have to bring on an onboarding team to set up every single aspect of, the platform. We wanted to to get our hands dirty, and, you you know, we're all entrepreneurs here at CareRev and and really starting to poke and prod without having to wait for someone to to tell us what to do. And so to recap, right, it's you know, don't reinvent the wheel. Use the best practices that are already out there in the market because we can leverage their software development.

We wanted something that stayed outside of the Salesforce ecosystem just so in case Salesforce did go down, we could still, you know, perform some other, you know, functionality, and not introduce bloat with, you know, managed packages within our environment. And then having that that two way street, right, where, we can, you know, have that coaching support and also provide, you know, those product improvement feedback.

I think that's a really pragmatic way to to approach it and that especially, like, not reinventing the wheel. Like, a lot of a lot of what we do in the ecosystem, the wheel doesn't need reinventing. The wheel just needs improving or, you know, a few extra spokes or or whatever it may be to continue that kind of metaphor.

One of the challenges that we see a lot of folks face when they do come to wanting to improve these processes as well, and I'm not sure how much resistance that you got from this side of things either, but there can be some resistance from leadership or more senior stakeholders when it comes to, I wanna do x. I wanna change this process, and it may end up costing this or having x amount of time to do it. How did you kind of approach those conversations, and how did that form, for for you, Kara?

Yeah. I would say I'm pretty fortunate.

You know, I think I've been in some environments before where this would be a a very uphill, boulder push. But here, I have very empowered leadership who, you know, they they fully trust us to to run with a a vision and execute it. Now when it comes to budget, right, and and build versus buy, that's where, the the fun happens for me. Because as a heavy engineering shop, of course, you know, we could we could build it right.

We could shape our own UI, and then, the conversation I had with that is okay. We can either purchase, you know, or or or or acquire engineers to to build that and build our own tooling, or we can focus on our product and our core competencies. And that's how we we frame the conversation with build versus buy at CareRev is really, you know, is it a core competency of ours, and can we can we use that, you know, power to to deliver more value to our clients, our health care professionals and our facilities? Because that's who's the core of every decision we we make.

And so when I positioned this, because it was a budgetary spend, right, is this is how much time it's gonna save us. We mentioned that ten hours of of tracking down breaking changes earlier. That has an expense both from a a salary expense but an opportunity cost. What what features aren't we shipping out during those ten hours?

What's that technical debt that we could have been reducing, those bugs we could be helping with? Any kind of that documentation or or training we can deliver to our end users to to really push them forward and and, you know, make Salesforce a better experience for everyone. And so, you know, it was all about how can we focus core competencies, how can we, reduce our breaking changes, and how do we make sure that we, you know, build trust within the ecosystem that when we make a change, that we're not going to remove something from a page layout that somebody depended on, and then we have to go back and and fix it because we've been through all those cycles.

And so, you know, I think, when we when we talk DevOps, it's a it's an extra spend, but it's also reducing a lot of your productivity and efficiencies. And so that really balances out. You know? It's it's hard when you make a business case with anything to say this is a productivity gain because that doesn't really have dollars.

Right? It's that wishy answer. But, it's also developer happiness. Right? Like, I think, genuinely, once we had this in place and we had the trial, even our non Salesforce developers who were were helping out as support engineers could use the tool and and really push those changes through and and weren't frustrated.

They weren't finding change sets all day long.

That's such a fantastic story fantastic story, and, that developer happiness piece or happiness piece as a case may be in in a lot of cases is something that's so often underlooked. But the you mentioned the productivity. You know, it's a nice kind of wish wishy washy kinda kinda thing to mention, but can be so important when it comes to, you know, long term retention of employees and, you know, their buy into an organization and how they feel about the organization and the what the the desire to turn up to work and, you know, implement Service Cloud or implement whatever the next the next step is in the Salesforce journey is is for an organization. So it's great that that hasn't been overlooked by yourself, and, you know, it sounds like from your leadership team that you have something that's really nicely supported there as well.

Something that we've spoken about is a lot a lot already is you've had challenges that you wanted to solve, you know, immediately in terms of deployments profiles, you know, add a bit of tracking, not really having too much visibility in terms of what's what's been going on.

But I'd be really keen to hear a bit about now that you have started to address some of those problems, what what does kind of the road map look like for you, or what kind of possibilities is this now opening up for you now you've kinda solved those initial initial hurdles?

Yeah. I think the one piece that, you know, we're we're still looking for is is simplitizing what we do. Right? When we spin up a new sandbox, a new developer sandbox, how do we how do we use the tools within DevOps to to automate some of those changes?

So, you know, when we look through it, there's individual components that you have to to manually change in our sandbox. Right? We're a we're an HVS organization, so you have to, enable, you know, high velocity sales manually in each sandbox as we do it. But, you know, are we able to to build out an RPA hook that can, you know, log into those eventually?

You know, templatizing our our sandbox refreshes. We use, the data loader product, and that was something that we didn't realize how important it was when we started in this process to have that core data that we could write test against. I think we're still looking for more monitoring all the time. How do we how do we ensure changes that did get introduced into, in in the Salesforce and match?

You know, how do we build out that more reporting? I think, figuring out that that, you know, that velocity of of changes, you know, I I think Giro said talk dog foods it a lot, right, about the metrics that they have on on product releases, and we don't have that yet. Like, I can see it move through the pipeline. I'm excited that my admins are pushing changes, but I want to go back and and go to my chief revenue officer and say, okay.

Here's the changes that we pushed for you this quarter or this month, and and here's how long it took from ticket time. And and we have those metrics. We have something like DevOps. I think, you know, more of those unit tests that we have, being able to call external systems and and run those tests, and and those pieces.

I think also on the road map is is just leveling up my my admins. Right? It's I think, you know, the more technical expertise we can teach our admins and and and allow them to talk to developers, the the better off we are. And I think this provides that common language and that common platform to help us get there.

But I would say it's really that that interconnectivity within our our app process and and even hooking it up to, you know, our ALM and APM to be able to say, like, yep. We had some errors in this development process. We've already logged into Datadog. Now we can easily reactively go back to it versus, like, hovering over a a monitor and and making sure we click that button again.

Yeah. For sure. For sure. I wanna come back to the thing that you mentioned just there about, scaling up your admins and, you know, bringing them even more invested, into the process in in just a second. Obviously, the title of this webinar, was our journey to CICD. So, where are you right now in terms of automation and, automatic deployment of changes similar to GitHub actions or or what have you in other platforms?

Yeah. So we, as mentioned earlier, went from org to org into a source control, and we're fully up and running with pipelines now. So, you know, when it when developer pushes their change or when admin pushes their changes in the local sandbox, right, we're we're automatically pushing that up to our UAT environment.

They're doing their their testing there, and that's automatically because of of the way pipelines works, stage that PR automatically for for integration and so on and so forth. And it's really helped us in that feedback loop of, okay. You did push a change. Now go there and test it. Did it do what you actually expected it to do and have that automation?

You know, those CI jobs are running for us every night, you know, within our pipeline. I can see when those, when we have PRs that are they're stalling out in an environment. So that automation side, of course, you know, has a little bit of manual intervention because we don't wanna have those releases go automatically.

But, you know, we're we're not having to to worry about those, anymore or those manual, release changes. I think the biggest part for automation for us is those monitoring alerts every night where, you know, even last week, we had a a managed package gets got installed that immediately broke, some of our unit tests because of of the way the Apex is broke. And we knew that immediately. Like, almost immediately, we had a monitoring job trigger that, and so we could identify instantly that we had a change where before I mean, it probably would have took two weeks before we realized that when or longer once we actually had to release Apex to to realize we had a an issue there.

And so that monitoring and the ability to to push those changes with a a a few clicks versus, diving into things has has really, really helped us. I think, when we we talk about time saved, right, if we were in change sets, we would have had to go into UAT, build that change set, and we would have had to go into integration, build that change set.

And now that's all happening for us automatically through that, you know, the, I would say, the the magic, right, of of Git and branches and and PRs and having the ability to to review those as well.

That's that's that's amazing. And, you you know, I'm sure there's I'm sure there's some people in the room right now that are all too familiar, but there's kind of things happening and, you know, they can be an absolute pain in the backside when it does happen. So it's something that, that you've mentioned as part of quite quite a lot already during this this call. It's something that you cited quite a lot as the monitoring, but can also it's it's somewhat overlooked a little bit maybe. Would you would you say, like, in in when it comes to DevOps process, you know, the sexy bit, if you like, is the automation and the automatic deployments out to out to integration, UAT staging, production, what have you. But you've seen quite a lot of success and quite a lot of impact from that.

So that's so that's really, really interesting to hear. Is has there been any other surprises to you, or things that you weren't expecting to be as useful as they have or as useful as you were expecting or provided more value than you were expecting maybe, aside from those ultimate changes and and that monitoring you've already mentioned?

Yeah. I would say, you know, honestly, it's the ability I mentioned earlier with combining our our git commits and our PRs to our our stories.

You know, we use a a not Jira product, but our our stakeholders can now see, you know, on those tickets that changes have occurred. Right? Because we are using the source control in a DevOps process, when we push changes, you know, it's pushing those commits to that that story or that ticket. When that pull request goes through and it's in production, instantaneously, they can see that that that happens.

And if they're monitoring our project management, you know, Slack channel, they're also seeing that in real time. Same thing with the gear set, you know, deployment pushes because we have that set up for for Slack for for successful commits. And so I think having that transparency, not just for the the engineering team, but also the stakeholders to be able to say, yep. These changes have have pushed. We have a little bit of education to to help them, realize that that value is there without having to Slack us, but I think that's been one of the biggest surprises is is having that full connectivity and that full connective tissue to, you know, allow our stakeholders to to get that progress update and and realize where things are in the process.

I would also say, right, is, you know, we we use a single sign on, and providing, you know, opportunities to UAT where it's like, okay. We've pushed. We've updated the ticket. Now we've automatically have our stakeholders going in there and making sure that those changes are occurring versus in the past.

Right? It's you have to track people down, you know, email them, beg them to to to approve it. And now we have a lot more of of a connected activity and and and, a lot of speed there. And that that's been a a a big surprise.

That's that's really good to hear. I know for a fact there is at least at least one, maybe two VA, VAs in in the room right now. So that that connectivity thing, they're probably getting super excited about and something that that we see a lot of. And it's great to hear about, you know, that unexpected value that even from not not not just from your side in your role and the management of your team, but, you know, those stakeholders as well that might not have been as bought into, like, those kind of changes that you're looking to make, have some visibility into and really, and really, really look into. We've just had a question pop into the q and a.

Before I change tangent there, I wanna switch over just to the learning, in in just a second. But I got a question. Can we hear a little bit more about, what your UAT process looks like?

Yeah. I would say, it's evolving. We've went from a UAT process that had, you know, nothing at all to now for, you know, I I would say, you know, major releases a lot more. And so, you know, anything that touches a a flow automation or, a Pagely out, we we push through UAT.

Individual smaller field level security components, it's it's more of a, developer and code review process. But with flow, you know, we're we're a pretty our UAD process is is pretty flexible. Like, we haven't codified it yet, and that's something we're looking for this next, you know, two quarters as a as a new team. But, you know, traditionally, it's gonna be, building that success metrics out, ahead of time in our stories.

We're still working on on on better story writing as well. But having those success metrics and and pushing through any of those those automations is really our focus right now with our UAT process. So that's my rambling somewhat answer.

Something that you touched on, just there as well in a bit of a bit of trigger work that reminded me was, success metrics. So a little bit earlier, we were talking about you could see how long it took to build a feature, so, you know, that lead time that it takes from a feature to go from request to build. Is there anything else that you that you've started to monitor or do monitor to look at your level of success for your Salesforce delivery process and how you as a team are are, operating us.

Yeah. I would say set velocity. You know, my my CTO is growing right now because we try not to use velocity. We'll use estimation factor.

So we'll you know, how how quick are we pushing, features? You know, what's that time to resolution between, you know, backlog to spec ing to to complete? And so having that that piece go through. Something that we're we're trying to track and you know, it's harder to to measure down, right, are those merge conflicts.

How much time are we, you know, are we using merge conflicts because we're holding on to features versus shipping them, you know, early and often? I think that's a big cultural change, if you're used to change sets, right, is, okay, I'm going to build my entire feature and then release it. What happens? Right?

We all know it is, then we step on each other because we have if, you know, we're not a shop of one changes that have occurred, you know, in in those higher environments that we've pushed through. And so getting that ability to to shift smaller and and shift more often, is a big metric that we're looking at, and it is part of what I look at to say, you know, how how big are these deployments? If if they're over a hundred metadata items, you know, we're we've probably shipped to too long. Right?

It's probably too big of a feature, and then we should have broke it down a little bit.

Yeah. It's really inter it's interesting to have actually cognitive feedback from just the process as well, not just the not just the the statistic itself, but also the, that feedback from that that respect to say, okay. No. What can we do about that? And and look at the impact behind that change does or doesn't affect ongoing work or or the business in in the business in in totality.

So just just moving on from the actual doing the doing doing of the work, I'm curious to know because as as we move towards towards the end of the end of the webinar and our time here, how did you approach we you touched on this a little bit earlier, but I'm keen to know in a little bit more detail how you approached addressing the kind of learning gaps in the team and that culture change that was required to to build the successful process and change how Salesforce was delivered, for the business.

Yeah. I'm a big fan of of grassroots initiatives. You know, I can, as as a people leader, you know, share my vision and and tell people how to do things, but that's not that that the best way that, you know, work gets executed, right, or, you know, cultural initiatives change.

And so I like to set the vision and then empower, you know, individual team members to become subject matter experts. Right? Have that kind of train the trainer and mentorship relationship. And so when we rolled out, GearSet and then the CICD process, you know, I, you know, I leaned on one of our engineers to to really own it and train it.

Right? To become that expert, to to be that grassroots initiative, to to be that cheerleader amongst the team, to to really, you know, push that forward, to find those little anecdotes that says, yes. This is the one thing that's, like, super, you know, badass that saved me so much time and, you know, really cheerlead it. I I had the the luckiness to have Bryson on the team, right, who's been, screaming about DevOps in his prior roles before joining us.

And when we finally he was hired when I, purchased Gear Set and instantly screamed, like, yes. This is what I've been looking for for the past six years. And so having him as that that main cheerleader amongst his his peer group really, really helped.

And so, you know, they they lean on him for, you know, how do I how do I fix this, or how do I run into that issue? So it reduces that burden, right, of, like, I don't really understand this product, right, or I've ran into this issue. Now I'm gonna look, you know, silly in front of my my manager or my supervisor versus now they have a peer group that they can lean on each other and and and do that. You know, I also pushed really hard that, you know, this is a completely new skill set that everyone on the team's learning.

We don't expect you to learn at day zero. Right? We expect you to probably not be even that proficient with it till day sixty or ninety. Right?

When things happen in, like, in a GitHub merge, like, you're not expected to to be the solo expert at it. You know, that that muscle memory wasn't built. Right? Go back to when you first learned Salesforce.

You didn't understand everything. You're not gonna understand everything now. So just give it patience.

Give it time. Right? And no one's expecting perfect days day one.

Yeah. For sure. There's a lot of perfectionist in all of us as well, you know, that we wanna be we wanna be able to do that, you know, straight away or, you know, have something something nice and shiny. You know, pick up a guitar and you wanna play, wanna play something perfect for your first time. It's just not gonna happen, and and we see a lot of that. Have there any been you mentioned Launchpad already and a couple of other things, but have there been any other things that you find particularly useful for that learning curve and that journey that in terms of resources that you direct people to?

Yeah. I you know, selfishly, right, DevOps Launchpad has been phenomenal, and then the the just the help resources, breaking down GitHub, and then abstracting it from, you know, the the CLI, right, and rebasing and pulling and and Git merges and and forks. Right? I think having that ability to to abstract, you know, version control down to its basics. I would also say Trailhead's done a phenomenal job as well, you know, with with their git basic modules and and DevOps, especially as, as, you know, the the full ecosystem right now is hot with DevOps.

You know, there's some other peer blogs out there as well, and I think it's just the community. Like, every time I've asked a question either, you know, on LinkedIn or or Twitter, you know, people have been responsive. And I think that's my my biggest advice, right, is don't feel like you're stuck and and you're the only one trying to to solve this. There's lots of other people trying to do it, and and lots of people who who do wanna help out. But, yeah, I would say, you know, it's just a duck, duck, go search away for for the most part for most, of the resources I need.

That's awesome. So, we actually, before we, start to wrap up here, we got a we got a question from Chris. So, we've spoken a little bit about, your other engineering team, being connected to Salesforce, and they have get actions based CICD process.

And how similar how similar I guess the question the the real question here is how similar is that process to in the engineering team to what you are using now in Gear Set, and how was there anything that you were looking to mimic particularly?

Yeah. I'd say it it it's pretty close. So we use, we're a Heroku shop, so we use, you know, review apps for a lot of our stand up, and and actions there. And so and with the Git pipeline merging and development for that release.

I would say where we diverge, right, is, you know, from a CLI perspective, we're merging into, those branches and and get app actions to take on. I can certainly do that from a from a admin perspective. Right? I can go into GitHub and merge my PR, and and GearSat will take care of the rest.

But then I also have my admins who do use the UI and push through it. I would say that the biggest divergence is just going to be, you know, in that metadata perspective. Right? Like, we don't run as many as, checks on our our PRs in the Salesforce side as we do, you know, in on on the the the bespoke side, you know, and Ruby side.

You know, we're not running linters right now. We're not running any, you know, heavy automated, you know, UI test or or those pieces, but we're going to get there. Right? We're gonna push a little bit more of that that PWD linter on our our code base.

We're gonna make sure that, know, descriptions are placed in that, and that's one of those things we're looking at, right, are those best practice linters that that we've differed from our on a CICD pipeline.

Also, one thing I mentioned is we do run migrations in our our Rails app, and those do affect some of our Salesforce piece. Before we all of our support engineers were admins and would add those manual pick list. In the next sixty days or so, we're gonna teach them a little bit about how they can use Versus Code to actually make those pick list changes, you know, you know, within the metadata and then push that through GearSet where we're not having to provide those licenses for them. They can just use, you know, their development tools they normally use, without having a contact switch. And I think that's gonna be the the biggest blend we have between our our traditional developers and our our Salesforce developers.

Thank you very much. So kind of, kind of a last kind of tangent on the last kind of question question line from from Mima.

What would you say are your your top tips for anybody that is either starting out in this journey, towards CICD or, you know, maybe, maybe some some somewhere in that stage, but not quite there yet. What would kind of be your top tips for them? And is there anything that you wish you'd known before kind of starting this process that you can impart on, impart some of the some of the folks there, for them to consider?

Yeah. I would say my first two tips, right, are don't be intimidated by it. You know, there's you can break down those base components and really start to understand the the individual pieces. Like, don't think of it as an entire pipeline.

Think of it as, you know, one one platform to the next platform. Start really small. Figure out what you don't know, and what you do need to know, and and go from there. The second tip is, you know, I I mentioned earlier, you're not in it alone.

Right? There's there's lots of people on this this road map. Right? You know, with Salesforce really focusing on on DevOps this year, there's there's lots of people who are are really trying to figure out how to make their process more efficiently.

And and, you know, I would say also, you know, selfishly, like, don't forget that you have your software partner that's there. I think Gearset yells at me constantly to keep on telling me to to use the in chat bubble. Like, don't get stuck and timebox it and try to to fix it myself, but actually ask, you know, their support team on how to fix something. Right?

Same thing with our CSM. You know? They're like, hey. Like, you don't have to figure it out yourself.

Like, use us. And I think, as we mentioned earlier, perfectionist and and technologist. Right? Like, I wanna solve the the puzzle myself, but you don't have to.

Use use use the resources that are out there.

And then I would say, you know, it's you don't have to be perfect overnight. Right? Like, we we ran into several issues in the beginning that were just standard pieces, and we could have gotten intimidated and and thrown out the towel, but we realized, you know, it's it's that learning curve. Continue to to push at it.

Continue to to go, and and you'll get there. I mean, it's there there's there's things you don't understand, and it's okay. Like, keep on pushing on it and and reach out to those resources. And, you know, you don't have to automate everything overnight.

You can you can start small with just monitoring and alerts, right, or or just one environment, and and go from there. But I would say those are my biggest tips, right, is, you know, don't don't feel like you have to be an expert overnight. Don't be isolated and, you know, and just reach out.

Yeah. For sure. Sage Sage advice as well. You know? It's it's very easy to get inside our own heads, in this ecosystem sometimes even though there is a whole ecosystem that's out there to help us.

So, it's always a really great reminder when you've had a good experience. I don't know. So say that the help is out there. You know?

And if anybody else is, considering that, then just at at Matt on Twitter, and he'll help he'll help you out.

Alan's asked, if you'd gone down the do it yourself road instead of, working with a vendor, where do you think you would have been today?

That's great.

I would still probably be doing it. Like, I I I think, like, you know, I I I've used Jenkins, right, and Maven and all those fun tools in the past, you know, CircleCI. They're they're all phenomenal. But I think what would keep us from doing anything would be, the declarative side of the house.

Right? Like, our admins would would not be empowered. We would still be teaching them XML. I think the merge conflict rules and and deduping there, the the way the syntactic sugar pulls things out, those are all things that I could would still have to develop my myself that, you know, partners out of the ecosystem have have thrown lots of engineers and and lots of time out over over the years.

Yeah. We can get something up and running, but I think it would be at a a very simple baseline.

And I'd always be questioning myself, is it working? Like, is did it break because of of a Salesforce issue, or did it break because of a a me issue? And the only people I'd have to rely on would be myself and those open source communities.

I think it gives me that peace of mind overnight that, I can I can throw that that that rock over the the the fence, right, and say, hey? Can you fix this for me or or figure it out or versus, you know, I think I would still be be developing that myself, and I think that would also put our Salesforce development, behind the eight ball as well because I'd be I'd be taking an engineer, who's shipping features to to to build our CICD pipeline.

Cool. Alan, hopefully hopefully that answers your question. And, yeah, it's, a lot of people end up in that similar book if they do go the same way. It's another common story, you know, that maintenance maintenance side of things. Salesforce changing things under you, API versions, etcetera, are all common roadblocks that people that we see people run into a lot.

So, I mean, just XML reordering.

Right?

Like And while I'm that yeah.

Knowing that it is an is an actual change.

For sure.

Preeti, I've joined a new team, and I really want them to use Deltz tool, having issues with convincing them. How would I how do I do that? Matt, what's your advice for you there? How do you how do you get that buy in, for the team?

Yeah. So I guess, you know, clarification would be, you know, if is it a peer team or is it, you know, kind of a a a leadership piece? I would say, you know, the proof is in the pudding. Right? If you can get a trial for for a tool, and GearSet does a phenomenal trial, to to to really build that out and and show what those changes are. Show, you know, show a typical, you know, release that you would do that you get stuck in a change set, and you have to go and troubleshoot versus what you can do with a DevOps tool.

You know, highlight that you can templatize those, compares and deploys, and and select those individual pieces versus in a chain set having to to navigate each individual tree all the time, even the search features. Right? So I'm a big fan of, you know, the MVP or the proof of concept and and get that together and and show them because, you know, you can you can show people literature. You can show them, demos from other orgs.

But once you start showing them in your org, I think that makes all the difference. You can you can tell that story. You know, find an ally and and say, hey. Can you walk through this?

You know, do do this change set within this tool and see what happens.

Where I see people get pushed back a lot is, okay. Well, now we just are introducing more friction. It's gonna take longer. But if you can show that you can roll back those changes, that actually saves time.

Right? In your disaster recovery piece, you've saved time. Seeding new sandboxes, that saves time. And I I I think it's just that that persistent cheerleading and and pushing that that really gets you through and and over the hump with that with a peer group.

Yeah. For sure. Prissy's also added here that, that kind of leadership and competitive leadership is one of those big things. You know, we find, we find typically that having something that you can tie it back to, you know, those metric all those things that, that you've talked about matches there are time consuming and, you know, can, can lead to a bit of friction within the team and all of those kind of things.

So for for me, certainly, one of the biggest things we see, Brutee, is when you have, when you have significant significant reduction in in those kind of frictions and then significant time spent on doing activities that our time our our our waste of time is is gonna kind of make it impervious in terms of in terms of what we're doing. But if you can say, we saved x amount of time. Matt's sleeping earlier in the webinar about having ten hours saved, of challenges, kind of a week in terms of in terms of ROI. You know, how much can you spend how how could you spend those ten hours alternatively doing something else or building something that the business is gonna find more valuable?

Ten hours researching a new project that's gonna add something to the bottom line is kind of would kind of be my advice from leadership, Matt. I don't know if you have anything to add to that.

Yeah. I would say the one thing, right, is is being a leader too, right, is if you can tell me, like, like, what keeps you up at night, you don't fear, and I would say, rollbacks. Right?

So rollbacks, I think, is the easiest thing to convince leadership because if you say, you know, we have a a brand new junior admin who came on. Right? They're learning, a new tool. They push a breaking change into, up to production, and we instantly realize it.

You can roll it back within thirty seconds, you know, or maybe, you know, two minutes at the at the max. Right? But once you've identified it, you already know that that change got pushed. You identify it, and and you immediately roll it back.

In that way, you're not having to sit there and and manually comb through metadata or pick list or trying to figure out what it is. You've already documented exactly what's happened in your environment, and then you can narrow down exactly what introduced that breaking change and remediate it all within, you know, thirty minutes versus if you're doing that, you know, today with chain sets, like, it's, you know, it's it's a best guess, and and, you know, you're you're being Indiana Jones trying to to figure out what happened. Cool.

Matt, we've got one minute, one minute to answer one final question. How do you combat environments drifting due to Salesforce or managed packet releases, change components accidentally left out of the pipeline, etcetera?

Yeah.

I would say, you know, it it's that DevOps process. Right? And so having that, you know, come back in through it, you can easily compare which your your individual pipelines. Know, we have those PRs that go through.

We can easily compare, pass, and then we can merge, you know, merge our individual environments. So main back into, you know, UAT or prod, and that catches up. I would say those managed package pieces, right, it's it's just knowing which managed package you have out there. I think, this past week, I've I've had the fun of uninstalling the managed package, and, you know, I learned a lot there of figuring out those individual layers based on a a a page layout and and using something I could compare and commit to to just test to see what would happen, I think, is is the biggest thing that you can use to combat that.

Fantastic. Matt, thank you so much. Thank you so much for your time. We're we're kind of reaching reaching the end here. But, for everybody else, for everybody that's, that's here, can can you tell us where we can find out a little bit more about you or, or or anything that you'd like to like to leave the group here, here with?

Yeah. Absolutely. I'm pretty active on LinkedIn. You can find me by my name or Twitter peeps five zero two.

I also have a a blog out there, that's needs some more attention, in a second time, but matt fever dot com. You know, if you know somebody in the health care system or or that, you know, would you, you know, leverage CareRev, right, or or have that decision, please go to CareRev dot com. We're we're also, pretty active on on social. And then, of course, I'll plug.

Right? We're we're we're actively hiring. We're we're a rocket ship. If you're an engineer or, you know, in customer service or or one of those places, please reach out.

We'd love to have that conversation, and I would love to to tell you more about it as well.

Great stuff. Matt, thank you so much for your time. I really appreciate it, and thank you for sharing your your journey with, Home and Folks in the ecosystem. Really looking forward to hearing what you do from here and be hopefully, be have a chance to chat to you again a little bit further down the line and see what more awesome things you and Carerific do. And have a great rest of your day. Thanks.

Thank you very much for joining us. We'll catch you another time, and, hope you enjoyed the session, and, see you again soon. Thank you very much. Bye bye.