Lightning Talks

Watch this set of Lightning Talks from DevOps Dreamin’.

You can see talks from the following:

Anna Wałach-Dudzic ( Engineering Director CWE) and Evgeny Vladimirov (Engineering Manager) at Aquiva Labsshowcase their code AI checker tool for pull requests. A tool built using Bitbucket, AWS and OpenAI that automatically reviews pull requests, detects issues and provides recommendations on how to resolve the issues.
Adrian King (CTO & Founder at Elements.cloud) talks about the numbers around CRM projects, the financial impact of these digital transformation projects and what businesses can do to make these projects successful.
Sam Chappell (Chief Technical Officer at Performa IT) discusses how DevOps can be used to improve efficiencies, governance and team cohesion – even in SMEs.
Stuart Grieve (Senior Consultant) and Lynette Lim (Senior Delivery Principal) at Slalom talk about how large-scale clinical trials can be enabled with unlocked packages.
Samuel Arroyo Acuña (VP, Product & Technology) at Provar discusses where Provar are planning to go in the future with their end-to-end testing solution for Salesforce to improve the overall quality of releases.

Learn more:

Hello, everyone. My name is Anna Valak Dutis. I'm engineering manager and sorry engineering director. There was a change recently at Akiva Labs.

And today I want to I present you with tool that was developed by Evgeny vladimiro, engineering manager and excellent quality assurance engineer, DevOps engineer in our company. This is something which is called AI checker, and let me tell you more about it. So if you are developer, if you are involved in the development life cycle, you probably know about pull requests. You probably know about reviewing each other's code.

And you know that when you do it manually, it is slow. It is time consuming, and it's easy to miss issues. And we have a lot of nice tools that are doing some of the checking for us, but some of the checking is not possible with these tools. So we have this vote, about what if we have this really terrible code that is not that we are not able to check with existing tools.

So on yours, on the slides, on the screen, you can see a terrible code. You can see terrible code with multiple mistakes, issues that sometimes were able to be detected by the existing scanners but sometimes just need to be detected manually because that's how scanners works. So we felt like, hey, guys. We have this chat JPT thing.

Right? We have this chat GPT thing. So if there was someone with my knowledge, like chat GPT, who could just do all of this manual work, this manual pull request we review instead of me. That would save me a lot of time.

So we thought about it, and Evgeni started creating an app, which basically works with Bitbucket or with a GitHub And it basically connects with the AWS application. We have nice Docker container, which has everything on it. We deploy it. And this magical container, this magical application connects with open AI.

With the version that is paid, with the version that protects our data and hopefully is not sold anywhere. And, basically, the open AI digest what is in the pull request, digest all the code that has changed, and provide us with recommendations.

And we, adjusted it. We did did some prompt engineering. We did some engineering on the levels on how, you know, we wanted to describe it. And now thanks to this, when we are creating, comments in Aquival apps, when we are working with code, when we are opening pull request, this AI checker, is going there, and it's detecting the issues that may have been detected by the classic scanner, but usually are detected by the senior engineers or mid level engineers who are just going into the code, digesting what is happening there and figuring out, like, Wait.

Wait. Wait. This is wrong. And, you know, this really speed up a lot. The process for us.

I'm not sure about your process, but for us, the poor request review was always something that was dragging, dragging down the time, to deliver the task. And with the word of AI checker, in the word of AI checker, we were managed to do the pull request review faster.

Now it's easy to focus on important stuff. So we can focus, for example, on business logic in our pull request and not just, you know, on the staff that could be easily detected by more or less, advanced tools. So, this is what I want to to, show you today. This is the the small thing that we figure out at Equifax.

You can meet us at the booth, and we have two presentations today in the breach room. Robert Sussman will open the day in the bridge room, and I will be happy to close with some interesting type of topics. Thank you very much for your attention. You can ask me any questions later, and have a great day. Thank you.

Cool. Thank you very much. Next.

Mister Adrian King. Do you want the podium in my car? You do.

Do you all hear me okay?

Hi. Yeah. Welcome. I'm a Adrian King. I'm one of the founders and responsible for sort of product direction and technology at elements dot cloud. Just wanna talk about some numbers in our industry. We spent quite a bit of time recently, doing a bunch of sort of internal survey work, basically meta meta work, looking at a whole bunch surveys.

And oh, going the wrong way.

And I just want to wait, you know, some of the numbers out there. So for successful CRM projects, not Salesforce projects, but across CRM, the best projects deliver at least ten x in terms of ROI, you know, a thousand percent ROI. That's the number even my CFO would probably get quite interested in.

And Actually, the average successful CRM project was delivering four point seven x in terms of return on investments.

The real challenge, however, is that thirty percent of projects fail entirely, and eighty five percent of projects don't meet their stated objectives. So the first numbers are great if you're in the fifteen percent, but an enormous number of projects don't get anywhere near delivering these type of numbers. And actually, some of them just deliver absolutely nothing. And to be honest, in my career, I have worked on one or two of those projects.

Let's put this into financial context, generally, in half a business review and, study in twenty eighteen, there was one point one trillion dollars spent on business transformation, digital transformations. That is an enormous amount of money. And the view at that point was at least five hundred billion of that was wasted. And actually nine hundred billion of it was probably less than well spent, but at least even half a trillion dollars of wasted money in our industry. Now this isn't around Salesforce, but I'm pretty convinced Salesforce is no difference from the general trend here.

And actually, by twenty twenty five, they estimated that we're gonna be spending three point three trillion dollars a year. Globally on digital transformations. And if you extrapolate that, you're looking at basically one and a half trillion dollars of waste in our industry. It's pretty shocking, actually. You think about how, you know, after fifty, sixty years, we still cannot get a lot of this right.

So why? The two top reasons and where many reasons are fundamentally lack of stakeholder engagement and lack of planning.

The interesting thing if you think about that is that, basically, these projects have failed before a single line of code has been written. So it doesn't matter how good your dev ops process is. It doesn't matter how well you've implemented great tooling. If you actually don't get this right, the chances of failure are quite noticeable.

So here are elements. We've been very, very focused on two things. You need to build the right thing. It's pointless building the thing right. If you're not building the right thing, and so many of the problems, so much of the waste in our industry is because people rush into building stuff without actually having sort of that why they're building it what they're building, and do they really need to build it? So, I basically want to finish this, this very quick lightning talk with.

At elements, we're very focused on helping you build the right thing. If you wanna understand about how you make sure that what you put into your world class dev ops process is actually gonna add value. Come and see us upstairs, Richard Toby, Liana, upstairs, will be very happy to talk you through how we can help you avoid being part of that five hundred billion of waste. Thank you very much.

Excellent. Alright.

Good. So I can fix through to the final slide. I've got everything set because name Marco.

Awesome. Thank you so much, Adrian.

Deb ops and agile development.

Come on down.

Hi, everyone.

I'm Sam from PerformorIT, and I want to talk about DevOps and Agile Development today.

So very quickly, just a little bit about me, I'm the chief technical officer at FormerIT.

So my role is looking after the quality of everything that comes out as a Salesforce partner.

And I've been in the streith or roughly about the last eight years, and been through from a developer consultant moving through, and hence sort of my journey through and learning about DevOps.

So the first thing I want to talk about is how agile development works alongside DevOps. And the key focus that I have want to to talk about here is culture.

As, we've spoken about actually in the last slide, culture is one of the most important things to making sure that agile development works, but also that develops works, continuous feedback, continuous improvement, and making sure that everyone is engaged across the business.

Making sure from stakeholders all the way through to end users that teams aren't disparate they're working together and working towards a goal for a project.

It's just a nice nice quote there.

So, what is Agile development? So there are five key functions of Agile up here on screen, and they link very nicely with the five pillars of DevOps, in the ways that I look at them. So the first one, that I've spoken about, which is, actually mentioned multiple times, is around collaboration feedback, continuous feedback cross functional teams, you can see how they marry up really nicely.

The two, next key points are obviously increment all releases, continuous improvement, and automation, they all link up really nicely. If you think about as an agile development process, we want to be working in sprints, deploying regularly, biweekly, biweekly, and that works really well with, automated testing, continuous, CICD processes, pulling everything together, you can start small, but the focus that we want to look at here again is making sure that everyone is aligned pushing towards a single goal.

So how does this look in practice? So if we think about a typical waterfall project, you're gonna be looking at large deployments, huge amounts of, requirements gathering done upfront, then a large piece of development, then a testing window, and typically there's not a whole load of stakeholder engagement moving in through all those stages, what you get at the start is not necessarily, or what you ask for at the start is not necessarily what you want at the end. And you might not actually want what you asked for at the start. We're looking at year long project, two year long projects, something like that.

So if we move to more agile iterative development cycles, we will then be focused on making sure that we've got that continuous improvement. We're sharing talking to stakeholders, talking to collaborators every week, constantly making sure that the vision is always there. We're constantly releasing value to the business as well in that we're building small functional pieces that can be deployed little and often, and that it can be governed as it's moved through.

So, the one key takeaway that I want everyone to have here is that, across enterprise, medium sized businesses, SMEs, if we focus on making sure that we start from the right culture, making sure that we know what the objective is that we're looking through and making sure that we start small, build up as we go, dev ops can start from just putting version control in, which I know a lot of people don't have, at the start. It's quite nice and simple to get in to get onto that road. That starts to build the mentality of everyone collaborating together and moving forward. Thank you.

Alright. Thank you so much.

Okay.

Next up.

You need podium or do you want this one?

This one will work. Yeah. This one will do. This one will go. Yeah. We're gonna speak a little.

There's your clicker. Awesome. Perfect.

I go. You're close.

Hello?

Okay.

Hello, morning, everybody. Right.

Okay. I hope you can hear me and in my awkward position. So my name is Lynette Lim. We're from flower, and this is, Stuart grief.

So today, we are not selling any product, but actually just illustrating the use of dev ops and using an example of a client judicial case, the use of unlock packages to manage and enable large clinical trials.

Sorry. You can't see.

Alright. So So how do we find ourselves? Sorry. How do we find ourselves here?

So we are actually, collaborating with a large organization that is trying to remove remove the barriers to, develop better treatments for common diseases.

For for for people, by actually transforming the technology that's underpinning the running of clinical trials. So two things What do we mean by, barriers and also later? What do we mean by transforming the technology underpinning it? So barriers are, for example, One typical cardiovascular clinical trial is around one billion US dollars to run.

So imagine the amount of investment that is needed to actually help to trial run, groundbreaking treatments in order to to address, common diseases like cardiovascular diseases, even cancers, and, also, vaccines for, outbreaks, for example. So this is how how we found ourselves here. And, the technology underpinning this clinical trial is clinical trial running is actually very old and dated. So here we are in right now helping them to transform that technology with the use of actually DevOps, which is quite, at for this, conference, DevOps in a way such that, one or the organization running the clinical trials have been running trials since nineteen nineties, which means they have noticed that there is eighty percent of re reusability in clinical else and probably twenty percent of twenty percent of the variety when it comes to the various treatments needed and various operations needed run trials.

So this is where DevOps comes in. Of course, what the previous presenters by Adrian and pro form pro form a has mentioned you need, the right planning as well as the right culture and the right tool in order to do all these things.

So we've unlocked packages we picked for this particular project.

And program is a reusable, scalable, and modularize solution to run multi massive clinical trials for them in a multi arc trial landscape.

So what does that mean? A lot packages if if if any of you is sure that's fine. We don't really have a lot of time, but you can find us at the booth later. So it basically helps us to enforce package based dependencies validation.

When we try to roll out massive solutions across multiple different organizations running different type of trials.

Okay.

So next slide. Okay. I'm not sure I'm using this this thing when a computer is just here.

Okay. So how do we find ourselves here? Next slide, we will have a base package when I mentioned earlier there's a eighty twenty template the eighty percent of the solution is actually in a core unlock package. We roll out to well, this in this example, we only have three trials, three trials, in an actual environment, in an actual realistic setting is gonna be twenty to hundred different trials. Each trial is multi million pound program.

So with the base package installed and and roll out and update it like a Salesforce release kind of way, will have a twenty percent remaining of configuration for each different clinical trial. And also there is a dependency force by nature in unlock packages, and this is where you can use that type of, attribute and properties to enforce dependencies, for example, you may have, let's say, Salesforce release, winter twenty four in one environment, for example, and unlock package. You have version one or version in one environment.

And if you have a configuration package in clinical trial two, for example, that is dependent on package call package three. Will know that you cannot install the configuration package without the correct version of the base package coming into the environment. So it is already by nature rule rule out human errors when it comes to rolling out solutions for different clinical trials.

So this is where we get to.

And then, of course, the one year of tears and effort and grumbling is, what have we learned? Why have we learned throughout our twelve months plus of implementation. So I'll hand it over to Stuart to tell you more about it.

So as Lynette said, you know, there's been a year of tears and late nights trying to get this thing ticking away. Alliance to obviously the clients, visioned what they're trying to achieve.

We haven't got much time, but obviously, we've learned a lot. So I'm gonna go pretty rapid fire.

Firstly, you're gonna make some decisions about your deployment approach. And once you've got your package created, sure you're gonna be package installing rather than doing source deployments, as a question, how often are you going to create your package?

Bank version creation is in line with the size of your project and the amount to spend the packages that you've got.

And, you know, very quickly you need to make a decision about how often you're gonna do that, as I say. For us, the packet migration time was huge, so we didn't have the option to bake it into the CR process. So instead, we opted for traditional source deployments to our initial QA environment.

But beware, once you've got an org with your projects installed by a packaging, traditional deployments, unresponsive by, like, typical metadata deployments.

Anyone using run local tests on our projects. Push your hands, travel's wake. There we go. It's a few.

So obviously these are great. But if you're gonna venture into packaging, unfortunately, trying to invoke your tests in your projects this way, in an org when those tests are owned by a package, it's not gonna touch it. So instead, you're gonna have to opt for using something that runs specified tests and being able to script getting your tests from your project. Obviously, naming conventions is probably critical here to have like underscore test or something.

Some of you may have heard about scratch or snapshots.

If you haven't, it's similar to org shapes, except it includes metadata in packages, not just the features and settings.

And I mentioned package creation time is highly dependent on, the kind of dependent packages that you have related to it, with snapshots, given all of this is baked in from the moment your scratch up is available, it has absolutely huge impacts.

I'm gonna be as quick as I can, but there's a lot to cover.

So it's not the first time you're gonna hear, and the last time you're gonna hear limitations.

Global value sets, I'm gonna try and be super quick.

Standard pickless fields are supported, but you can't maintain them. Instead, you're gonna have to ditch them for global value sets, which means you're gonna basically have thousands and thousands of them.

Vertical solutions, not fully compatible. On the studio sits outside of our package. We use extensively.

It's quite cumbersome. The gap is closing, but, you know, you you have to kind of be a bit, natural with the stuff.

Lots of metadata parks aren't supportive, for just like normal source deployments, unlocked packages, that list is even bigger. So get used to having to have a bit of a hybrid approach. You have the hybrid approach, it's gonna create a bit of a spider's web of dependencies between uninstallations, are real pain and rear.

And last but not least, as the project grows in complexity, things like governance and VA become more important. So you're gonna have to have, a very kind of, methodized way of understanding where new complex features are gonna sit in your paper hierarchy.

If you don't, things become a bit of a mess and, you know, release notes as well, we found we're integral for driving collaboration between developers we have lots of owners and different teams to different packages, you're understanding that alignment of what's changed from a dependent package, and it's gonna be, influencing what I built in my package, can become a bit of a web.

From the time that I rushed through all of that, I'm hoping that I've missed out a hundred more things and you have lots of questions Lannette and I would love to speak for hours about this project because it's been super exciting, to come see us in steps.

Okay.

Alright. Last but not least, Prova. Come on down.

Not gonna get tired of that stay at all.

There you go. Do you want one of these, or you can use buggy? One of these, then it should clicker.

Yeah. I'm the only one with no slides. They say it was a lightning talk. Like, do I need lights for that then? But then he's like, oh, I need to memorize the whole thing. So I'll try my best. I'm Samuel Royo, I'm VP of product at Provar, who knows anything about Provar.

Okay. So you probably know us because of our test automation capabilities. Yeah?

Today, I'm gonna talk about a bit more of what we're trying to do at the moment.

So we've had this company for, like, ten years. We've, developed our test automation product that works very well to test Salesforce.

But we are now, since maybe one year ago, pivoting to thinking about the broader space, and that means everything around quality.

So what we're doing right now is trying to get away from just offering a product or test automation and getting into a partnership with our customers in their journey to better software quality.

So I don't know if any of these stages will represent you, but usually customers go in a journey.

They start from not doing not knowing what they're doing. Let's say the chosen Salesforce to begin with to implement the CRM, The first thing you need to do is get organized.

The way that teams usually do that is by, choosing a tool like Jira as you're the boss, basically, they need to have a way of organizing the project, what they're gonna build with their user stories, how they're gonna group that into epics, and how they're gonna manage the releases, the sprints, and so on.

Once they've organized themselves, something that many people don't think about is that testers also need to get organized.

And sometimes, there is like, okay, Here's the user story, developers, you go on your own, and test it. You go on your own. But a test that actually has a lot more work to do that needs to be organized And we also provide, a product for that called Prova Manager. So Prova Manager helps you not only with your release management, in case you don't have Jira, whereas your dev ops, we provide a a module for basic release management, but important bit is also test management.

As a tester, you gotta use a story and you need to start thinking about test scenarios, you need to start documenting those so that you may have to do some manual testing afterwards. So you have your test case without test steps, but before that, you have to do on planning, you have to do some thinking. So you have test plans for your document, well, how are you gonna go about testing this project, what types of tests are you gonna do? Are you gonna do, like, end to end testing, just manual testing, automated testing, functional testing, there's so many kinds of testing.

Okay. Now we have a test case, we have a test steps, and let's just do it manually. It's a a company where, they do testing manually. It's probably quite immature in the journey, but at least organized. So if you're not helping your quality teams, your QAs, your testers, or whoever's playing that role, get organized. There's a gap in there. Don't just assume that Jira is enough.

They need a way of organizing everything they do about testing. Once you're organized, the next step is feel the pain of having to manually run your tests every day all the time.

The the developer comes back and say, this is done. The tester comes manually checks everything. It is not done. Here's a bug.

Here's another bug. Developer says, fix the bag, test it again, manually go again and again, and again. It doesn't scale. It it's just repeat as I've repeat.

If you ask the tester, they probably does everything they know. They're tired of it. The next step in your maturity journey is to automate that. Automate as much as you can and automate as soon as you can.

The moment you give a tester an automation tool, ideally, instead of write in a test case with steps and manually repeating that script.

Every time you tell them to, they will automate as soon as possible when the developer says the bug is fixed, I just click run. It is not fixed. Here's the bug.

Run, run. Just click a button, automate the whole thing.

If you wanna go deeper than that, you plug QA into dev ops. So you're able to trigger the execution of those those tests as part of your, maybe, your pull request or any other process that you want. And the higher you go on that pipeline, the more you want to test to make sure that you're not breaking something else.

Finally, after you've organized your team, your tests you've able you've been able to automate your test. The last thing is to scale it.

Your end users will be using Windows, they may be using Mac, even Linux. They will be using Chrome, Edge, who knows what?

If you don't have the right tools and the right process, you won't be able to test every journey, every script into all of those combinations.

The last thing is to scale how do you run those tests into all the different combinations so that you are sure that your end users will not complain.

So in summary, what we can help you to do is to assess where you are in your journey, in your quality journey, and see how we can help you to get organized to automate your tests and to scale in the cloud with parallel testing. Thank you.

Thank you so much to all of our lightning talk speakers. Let's do another one of random pause for everybody involved. Thank you so much.

Okay. In just a couple of minutes, we are gonna have our first keynote.

So, whilst we get everything prepared for that, and get so if you're up on stage, maybe introduce yourself to the person to your left or to your right, if that is somebody not familiar, or even if it's one of your colleagues, just say hi and have a chat. Okay? We'll be with you in a well, just a moment.

Go ahead and go away with this click on.

Alright. Warmmin here. Isn't it?

Oh, yeah. That would be cool because I just got one of those tops that occasionally own protection. You never Bye.

Hello, everybody. Hello. Hello. Hello.

Oh. I got a bit of a traffic jam down the bottom here. Think we're okay though.

It is my absolute pleasure, to introduce the first keynote, of DevOps streaming today.

We are gonna be joined by the Marvelous Sophie Crosby.

Sophie Crosby has an illustrious career and is gonna be telling us about managing complex teams Sophie was Senior Vice President of products, for Marketing Cloud, in the UK. Yeah. So it is a pleasure to have her here and sharing her wisdom with us about managing those teams, Sophie. It is all yours. Thank you very much. Thank you.

Thank you.

Okay.

Yeah, I was I was, senior vice president for outbound product at Marketing Cloud. If I'd actually had real clout and senior vice president of marketing at Marketing Cloud, I might have fixed a few things time zones, and some of the deployment package manager like things. Okay. Let's move on.

So this is me. I'm Sophie Crosby, Paso consulting, we create memorable and shareable content and ideas to help tech companies connect with largely marketing leaders because, you know, need to teach them right about technology. I'm a marketer. I've had to learn a lot in my life. So I love thinking about business change, which is driven by technology and data, and my personal mission is to inspire marketing leaders, particularly on the why, the what, and the how of data transformation to drive better marketing and customer experience.

So I'm very excited to be here with you today, and I'm very grateful to Rob Powell, who's sitting at the back there. Hello, Rob.

DevOps evangelistic gear set for inviting me. He's probably feeling a little bit nervous now in case I completely can I swear?

Okay. In case I completely fuck this up. Okay.

And I'm very nervous because, frankly, what on earth can a marketer like me tell a room full of dev ops experts like you. So let let's see, shall we? Hopefully at least I'll be a bit of light relief before you get into detailed stuff about, you know, running packages and things like that. So I'm gonna share my, experience in managing complex teams, actually at Ticketmaster. The job before Salesforce, different kind of gig, where I was on the other side of the fence. Before we start a little bit, meet, more about my favorite subjects, Me.

But about my background in marketing and technologies because it's kind of fun. My career can be summed up largely music, data, people. So that's fun, right? If it's not fun, by the way, if you're having a miserable time at work, find another got another gig, really. It's just life is too short to be miserable just wanted to say that.

Technology and specifically the ability to store process handle action data with increasing speed has really been the hallmark of the sort of latter half of my career.

But before that, I started in music And, my first job was, whisper it in EMI at nineteen ninety three. It wasn't my first job. That is why I'm saying whisper it wasn't my first in nineteen ninety three at EMI, but I was the only person with a computer on my desk on the fifth floor. And, I lied and I said I knew Wordstar. So I spent most of the most of the day with a huge book on my on my lap underneath the desk trying to work out how do things.

Anyway, then I worked at chrysalis, v two, Sony. At v two, I worked with a lotus notes developer. Remember lotus notes anybody or nobody quite old enough okay to create an international workflow process to manufacture and release records in different regions and markets.

I tell you what I learned. Understanding the business aim is one thing.

Building the software and the tech technology capability is another, but bringing people along with you across markets, driving adoption that's the hard part. And I think what's interesting in this room is you're all about operationalizing really interesting and transformative technology for your companies, but they only get the benefit if not only you can operate it, but operationalize means people use it. Right? So you're at that crux, that interface, I think, of business technology and the outcomes that they seek.

Right? So very interesting. So V2 and Sony were lots of fun. I was ended up being a marketing product manager for UK marketing manager and an international marketing manager for a real real mix of, artists.

Leonard, I did a Leonard Cohen album, ten songs, great album, actually Johnny Cash album David Bowie, the Headen album, system of a down, very cool toxicity, if you're into that sort of thing, great album, Mercury Rev of my favorite bands and Ricky Martin with sound loaded. Get loaded with Ricky Martin. So that was kind of fun. So I was a marketing manager.

And largely, don't want to downplay it too much, but it was kind of hats posters stickers and knickers. You know, it was the old days. Do you know what I mean?

Digital marketing was a bit out there.

So I then spent fifteen years of my career at Clear Channel Live Nation and Ticketmaster really moving my gaze to retail and selling it's for live events and marketing for that.

We got very excited in late two thousand and five. We built about forty websites clear channel for different festival websites. We built our own festival CMS, Fido, festival information data organizer. Had a little dog as the logo.

In late two thousand and five, we got very excited. We were gonna build a video upload system for fans of the heavy metal festival download upload their video content and do stuff, and then YouTube launched. And we went, oh, oh, well, we'll just use a plugin for that. Which shows you that in tech as in life, timing is everything, but it also maybe highlights this build versus buy argument, you know, because a lot of what you're doing is your company bought in technology and you're figuring out how to how to make it sing within your company and on your data and in your teams.

Okay.

I think enough about that. In a little while, I'm gonna talk about my time at Ticketmaster, but most recently, as SVP for outbound product for marketing cloud at Salesforce.

I met hundreds of leaders in business who were really struggling.

They were struggling to get the very best out of the investments that they had made in their technology, not just Salesforce, but in all sorts of things. And I think again, this is where, you know, you sit in the in the crucible of that kind of crossroads of getting the best out of our tech investments.

So, and I think I've learned that, whilst silos of teams and divisions and regions are really important way for big organizations to kind of box up and control their organizations and measure and manage them. The very best organizations have really great ways for teams to collaborate and work cross functionally. People in Linchpin and leadership roles who can do that.

To work non partisan to deliver the big ticket vision items. And again, I think that speaks to DevOps in many ways. Okay.

That's that bit. That's me. I did go bang on a bit. It was kind of fun, right?

There's a little bit of rock and roll in there. I didn't talk about any of the really bad stuff. Ask me later. What's going on?

What's going on right now?

If I can make the clicker work, something will. So dev ops.

I was thinking about this all week. I was like, oh my god, there were dev ops. They're all super clever. They know stuff I do. They can look at rows of code and understand it. I can't.

For me, you guys sit at the heart of the business that using new technology to innovate. So I've said that And I think with Salesforce's mantra of clicks not code, a non technical person might go, well, how hard? How can that be? What you do?

So click's not code? So I'll But for any of us and all of us living in the real world, it's, you know, the new users, the new functionality, the fields, the markets, the teams, the necessary change can choices on boarding new data sources, testing automations, deploying new features, getting use of feedback, and making shit work and getting people to use that shit. Right? It's Huge is huge.

Simply put DevOps is incredibly important for every company who wants to thrive, and even I suggest to survive moving forward. So you guys are it. You're at the center of it all. Okay.

Mortator all the time. Every team across the business, is facing a proliferation of data, customer supply chain, manufacturing workforce, whatever it is. People have now got passes that check them in and out of the building, you know, that post COVID tell them what toilet they're allowed to use, you know, things like that. Like, there's crazy shit going on. The amounts of data are mad, and business has become more technical every year. And I think that teams want to use tools that they can use without relying on tech teams to help them literally every day do their work.

I met with some huge companies when I was at Salesforce who were complaining to me that Mark Marketing Cloud doesn't do what it's meant to. And then I would find out that they were going to their tech team and asking them, giving them the parameters to segment an audience and then waiting two weeks for that audience to come back. And then they were loading that in as a singular file. And I was like, oh my god. You know, you're driving the Ferrari with a you're putting turnips in the can, and you're you're you're pulling it with a donkey. Right? Like, you can't you're not using the car, right, the way it should.

And I think that's really difficult. And what we see is that especially marketing leaders buy into the vision of doing things, you know, amazing things, and they have increasingly over the last ten years been buying a lot of tech technology tools but maybe not really able to orchestrate them.

I think meanwhile, CTOs on CIOs are looking to retake control right? They want to retake the reins of all of these technology components. They want to orchestrate these technology top technology components that really drive the business, you know, cloud ops, cloud cloud tech, Martech, process automation, real time data, and I think that this will only work when those technology and IT functions are really able to work cross functionally with the with the business And with the teams in the business that they serve, and again, I think DevOps sits at the heart of that. I'm a really strong believer, basically, in collaboration, shared KPIs, shared roadmaps, alignment, shared resourcing and priorities.

I think, unfortunately, the way big companies are set up is that teams and divisions are almost warring with each other for budget, and so that makes that quite difficult. We're not used to that. It's quite a competitive sort of landscape.

Anyway, the pressure is on.

Otherwise, a few song titles hidden in my, in my thing. So if you if you recognize them tell me. Some of them are more obvious than others.

So the pressure is on, everybody's being asked to do more with less, including you.

And I think there are three reasons companies invest in technology, sell more, do it more efficiently, and mitigate risk. I'm trying to see how I'm doing for time. Okay.

There's no way of avoiding the economic downturn that's coming. I mean, it's coming. Right? Like, I'm not gonna go into that because, like, it's a downer.

It's a total downer. But the four horsemen of the apocalypse are racing over the horizon. The skies are dark with the wings of pigeons coming home to roost backset. And lots of other things beside, right?

So you are gonna have to do more with less. But again, the promise of technology and the technologies that you work is for companies to be able to do just that.

So as I say, I keep saying it. What you do is very important It's to get more out of what you've already invested in tech to get the return on investment you seek, what marketers want. It's all about me. I told you this presentation is all about me.

Is it okay so far? Enjoying. Is it okay? Yeah. Kind of engaging. There's more technical stuff later on for you to get your chops into.

I'm just I'm the warmer pack, not the flapper, the warmer pack. Okay. What marketers want. I've got a completely blank sheet here.

So let's move on.

This is the Salesforce Marketing lady. I don't know if they're using her anymore, but I thought I'd use her just nostalgium. She was on everything, wasn't she? She's so nice as I really want to meet her and hang out with her because I feel like I know I've done so many presentations with the Salesbosmo. I'm happy lady in a stripy shirt.

Marketers are thinking about a lot of things. I know you think it's all, like dilbert says it's all liquor and guessing.

There there is a lot of guessing in marketing. There is because, you know, a market has got data in, you know, think about attribution. You know, you know, which was the drink that got me that gave me the hangover this morning. Right?

Which was the drink last night that gave me the the hangover this morning? That's attribution. It the champagne at the start? Was it the port at the end?

Was it the beer and wine in the middle? I don't know all of them. Right?

But that's the thing with in March you want to be able to attribute, but everybody over attributes, right? Because, on on digital advertising, it's you'll attribute, a purchase within three weeks of having seen the advert, you know, but I might have also opened the email. So everybody's saying, oh, you know, that sale is that conversion comes from this email or that ad virtual listing like the other thing. Really hard for marketers to do much more than guesswork, actually, especially when they tend not to have technical teams to help them manage and figure out this stuff. And they've got a lot on their mind, right? It's their job to to make sure to see how your company shows up in the world. It's their it's their job to make sure that the right messages gets the right people at the right time.

It's their job in an increasingly difficult world to manage costs and return on investment. Customer acquisition costs are utterly spiraling. I mean, for digital marketing is like two point two times what it was about five years ago. It's insane and they're losing third party cookie information.

Right? So it's all going off. There's a lot going on. I haven't put affiliates down here.

I haven't put and and what's keeping her up at night now is I meant to be using AI to be a better person and do everything better, you know, I'm doing all of this and I've gotta do that too.

But I think mostly they're concerned about data and how they can get actionable data in their hands so that they can do the marketing that they want and need to do.

My my googie, I just, talked about this. Google have been kicking it into the long grass for ages, they keep kicking it down the road because about eighty percent, of course, if their revenues come from advertising, so, you know, it's a big one. Flocks didn't fly, ledges didn't fly.

So we're still waiting. I can't remember. Does anybody know what the date is when they're definitively meant to go according to Google, which has been changed four times already? Is it next year sometime?

Third party cookies. Many marketers are using third party cookie data that if they still have it on their DMP, and it is disappearing. It's leaving, but they're using that to help them stitch together and understand audiences and particularly to make better sense of their online advertising spend. You know, once we saw I took on crux at Ticketmaster and the the com the companies that that used crux, the DMV that then became Salesforce, What was it called?

What's cracks called when they one sells? I'll I'll remember. Before the end, I'll remember I've had a senior moment there. But companies that use third party cookies are tending to see about a thirty percent improvement on their digital advertising spend, right, so what they're gonna lose.

And when you spend thirty billion if you're diageo on advertising, that's a big hit in terms of your advertising effectiveness. Which is why over the last three to five years, you've seen lots of companies saying twenty percent off if you give us your email. Right? They are desperate to build their first party datasets.

Okay.

So, there's, you know, marketers have got lots of different datasets. Often they've gone off and got hootsuite or brow or little bits and pieces and they've kind of deployed them themselves. Some of them, they've had help from their technology team. Some of it, they've done it themselves and they've got customer data across all of this.

This is just a marketing stack. I literally picked it off the stackies. Right? I mean, I was it just had a couple of Salesforce clouds in.

So apologies to whoever that was. Bottom line is Salesforce Marketing Cloud themselves. The Salesforce state of marketing report predicted twenty twenty five marketers would be using up to forty five data sources on average, which is kind of insane. Right? I mean, that's not their gig. Right, marketers really, but it is increasingly thinking about complex teams.

So with so many different data sources and dozens of tools, marks pacing an identity crisis, not their own, but just keeping up with the customer across all these different channels.

Tech and marketing, I think, have never been more intertwined. So although some of you may be doing stuff for sales teams or operations teams or workforce teams or deploying and working with other teams, some of you will be working with marketing teams. And, you know, actually this story is probably not too much for lots of other types of divisions in the company. Right? I'm just using this as the example because it's my background.

So I think that modern CMOs to act a bit more like functional CTS. They've got to understand emerging technology. They've got to understand the data that drives their business and that's used in their tools. So I'm gonna talk now a little bit about Ticketmaster, and I'm hoping I'm kind of on time.

I'm gonna have to race through a bit, just about teams there. So, in twenty twelve, my team was kinda looking more or less like this, and it was already, I suppose, a relatively complex team, for marketing team. You know, we had a data scientist is Zoltan Faraci, fantastic guy, double PhD from Hungary, you know, not the sort of person you would have thought ten years before that that would be in a marketing team. BI analyst CRM managers front end front end designers, content campaigns people who knew about video editing, you know, programmatic trader, technical SEO manager, quite complex.

This was a centralized HQ marketing team, and I had dotted lines into eighteen markets, marketing teams as well. But this was the kind of core team where we were really developing the brand's tools, the advice, the technology, the support, and the tools for all of those countries to do their marketing.

And then what happened in the end of twenty twelve was a bit crazy because the head of IT left, and I had been a very difficult and very demanding customer internally of the technology team because I wanted my customer data and I wanted it in good order and I wanted to action on it, and I couldn't.

And a friend of mine on the executive team, a fantastic project manager, he's amazing called Jerry Mc I think he's actually maybe, you know, if you need a great PMO guy, Jerry's your guy, he was on the exec team, and he said to the president of the company of of at Ticketmaster International, why don't you give Sophie that data team? Because she is never gonna stop fetching and moaning and bitching, and she's gonna be a real pain.

She can become her own supplier, and you she'll go quiet.

And, can you quite say like that? Maybe he did. But it was an extraordinary opportunity for me. A terrifying scenario for all these people. Can you imagine? Me?

They were like, Jesus.

So I had to, so we had architects. We had, actually, when I started in twenty twelve, we didn't have cloud engineers. It was all DB. It was a kind of, you know, earthbound infrastructure.

I mean, I think in the first week, one of these guys came to me and said, you know, that the SSD discs were wearing out. I was like, what? What are you talking about? They told me about the hardware refresh we were gonna have to do in a year and a half.

I was like, what? How much?

So, you know, I learned a lot. You know, and I had to spend that first week. I had first off a half hour meeting with every single person and just said, you know, tell me what you're doing. Tell me what we should keep doing.

Tell me what we should stop doing. What we should start doing. Tell me what you do, and I had to explain to them one thing about me. First of all, I had to keep zipped and listened.

Really hard for me.

But I had to tell them I'm an extrovert and you think out loud and I say, all sorts are crazy. She I spit ball out loud. And I will say things. That doesn't mean I think you should go off and do it.

If you think it's a shit idea, just tell me. You know, I know you're Maybe not all of them, but some of them were very introverted, thought very deeply. And when they said things, it was like drops of gold. Right?

And, I had to listen hard So I think, to me, there's always been a friction and attention at, in many companies, particularly between the engineering, technology, and marketing departments because, you know, culturally and personality wise, and I I'm making it kind of fun. I'm talking about that division in a in a very broad way. Of course, there are extrovert engineers, of course, introvert marxist. But you know what I mean? Right? I think historically there's been a tension there. And I think it's really important for both sized to try and figure out and have skin in the game on each other's outcomes.

I don't know what's on this slide. Let's see. Oh, yeah.

Loads of companies, all the companies you're working in and working for have shit tons of data, and more and more like every second. Right? I mean, it's just growing exponentially. And most of us are able to do quite a lot of analysis on that data and from that analysis.

Most of us are able to get insights now for me in marketing that be what content is working the best, which customers are most likely to churn, what what kind of thing are you most likely to buy from me next, you know, opera or football, you know, whatever, and the problem was, can't do anything with it. I wanted to be able to take action on those insights. And I think it's not just marketing. That's the same for every division, you know, huge amounts of data, lots of analysis, quite a lot of insight, and then this difficulty of taking action.

And again, technology teams that a lot of you are deploying about the ability to take action on data, I think.

So actionable insights key.

A ticketmaster, when I started this work, we had been very acquisitive across Europe acquired lots of different ticketing companies that were on different platforms that stored data in different ways that had obviously been, often minimum for quite a long time. Multi market, multi platform, multi client, questions around data ownership consent. There was lots of, like, just heavy digging to do to kind of even start to get things in the right order before we'd had data warehousing. But the vision really, you know, vision is a having a vision, communicating it, agreeing it, aligning on it, thinking about a strategy and the tactics, and then really aligning and getting your road maps with both technology and business teams aligned. This of high level vision, there was an even higher level vision about people going to an event and having a great time. I won't show you that because it was really marketing, you know, but they kind of boiled down to, okay, let's do three things.

On the marketing side, we also did quite a lot of stuff on B2B and client stuff on this on B2C.

So capture and leverage found data data warehousing across eighteen markets, propensity scores, profiling, give actionable insight across the business, give it back. Right? Automate things journeys, one to one real time on open at scale, emails, coordinate all of these different channels, and then kind of acquisition and and fan products.

So for the time that I was there, really, there was quite a lot going on because it wasn't Salesforce that I studied with. It was exact target, and in fact, anyone, any anyone do Salesforce Mark cloud in the room. Gotta might be speaking. Yeah.

Okay. So it still says this still says exact target in the URL. Yeah. Yeah. Time zone?

No.

So there was a lot going on. And, there was some kind of, you know, I put in the Olympics of because there was a lot of other big stuff that we were dealing with as well.

And along the top was the markets that we were still acquiring and having to onboard into our systems. There was what's going on.

And I just show this not because I'm super proud, of everything on here, all I am, but it's just to say, I don't know what stage you're at stage your company is that if you're dealing with a data team or you're looking at this sort of thing, I like to think if I'd started this work now with some of the tooling that's out there, maybe Snowflake, zero copy data, all sorts, you know, new ways of doing things that we could have done this a bit quicker.

Because, you know, we were doing ETLs on lots of different platforms and lots of different data and checking compliance and doing stuff and kind of building it in. And then at the same actually in the background moving to the cloud as well.

So you can sort of see, you know, by year two, we don't we were only nine percent of our emails were going out via exact target. You know, it took across eighteen markets, but it's it took a really long time, and I want to be really honest about that. You know, we got to seventy seven percent after a couple of years and a hundred percent Then, and by that point, we were doing triggers and journey builders and SMS testing, and then we were doing welcome programs and push tests, and we were putting in affinities, and we were using audience builder to them max to the max.

So really interesting, really fun. And I think, you know, below the vision, you've got to be thinking about people first people. It's it's culture and people, you know, being supported in doing what they're doing, given the resources to do what they're expected to but also thinking about how they're gonna collaborate and help operationalize and get drive adoption across the company, tools you know, really some very expensive decisions there. So that was really, really important, and of course underpinning all of it data.

We had very detailed roadmaps, agreed across all of the teams. So we kind of had every year we did about it stretched across about eight weeks and eight weeks sort of I know it sounds crazy strategy playing. We didn't use, you know, elapsed, not total.

But it's across eight weeks, we would kind of start off our strategy process every year and do a and redo a three year strat plan. And then we would create a one year strap plan. So for the CRM team, so in head office, I had, you know, four people in the CRM team who were helping drive and support CRM across all of our markets, these were the four things they wanted to do, get more data, send more stuff, develop scores to do it better, and then share their insight across the organization, and then it broke down into tactics. Okay. What does get more data look like? Okay. We're gonna do these things.

What does automate more send more look like? Okay. We're gonna migrate the alerts. We're gonna launch a band in basketball.

We're gonna do journey build. We're gonna do sales cycle. We're gonna do life cycle. We're gonna AP CRM, we're going to do browse, which this is what automate more send more looks like, and we're going to roll it out across eighteen markets.

What this kind of list of tactics allowed us to do and this sort of detailed list. Oh, yeah, a lot more detail than this, but allowed all of the teams to work together and look at their dependencies. So CRM team could go and sit with all of the guys in the technology teams and even in the design teams because you had to design email templates and all sorts of things and roll them out, get the Dave to make sure that they were put in the Salesforce instance, that it all worked, to really make sure everybody understood when they were expecting to do things break it down into quarters, see who they had a dependency on. Go and negotiate.

If you saw that four teams had a dependency on one thing here, we'd maybe promote that up the queue. Right? So it really helps us collaborate across, marketing and technology.

And, you know, you have to test and learn and drive live. This was, you know, I just like this live because we did quite a lot of stuff and it's got a lot of green ticks. That's not the only reason I share it.

My brother has been staying with me recently. He said he should show this slide. And I was like, it's really boring, and it's really tiny. So I don't really know where I'm showing it, but This quarter by quarter, is on the technology side.

We I also did reporting as well as marketing. So, So so customer b b to b reports how many tickets have I sold in the last ten seconds on the front row type of thing for a promoter.

So move those to mobile reports and stuff. I had a team out in Belgrade for that. But it just sort of shows you this, you know, how we would be, you know, Blue was the engineers we had was the engineers we didn't have, right, and how we were kind of, you know, driving through. By this point, we've been going for about, four years, five years on on the on the data project. And so we were really start starting to motor. But, you know, so, you know, we have to deprecate a big piece of SAP, and there's always, I think once marketing or or the business starts to work more with technology and understands what the technology road So you can start to be alive to some of the things that were invisible to you before and start to give up some of your roadmap time and start to be more understanding about what has to happen in order to get good results in order to get durable resilient results.

Okay.

So I think also another thing was just about I I I did a lot of communicating visually like this, you know, so that the CRM team knew what they were doing, but I wanted to be able to share this with everybody in the the organization so they knew what things we'd done what things we were working on and what was coming next. You know, here's our sales cycle cycle life cycle communications. Here's what we're doing. So I think communicating visually and really kind of working on that is is really important.

I know it's kind of death by decks kind of thing, but it's worth it. Am I doing on time? Gotta move on. Okay.

We delivered powerful insight on demand. We delivered supercharged segmentation through audience builder, probably gonna be taken over by data cloud, but we put all of this data into the hands of marketers in eighteen markets. It was it was great, and they're still using it. Fantastic.

Now I did a thing called kind of, wasn't Freedom Fridays. I can't remember what it was called. Probably, I fuck around Fridays or something, but Friday afternoons, I said, right. Everybody knows what we're doing. Everybody knows what the vision is. Everyone knows where we're going.

Friday afternoons, we're gonna have four hours. I'm gonna do beer and pizza at the end of it. And you can keep doing your day job, or you can work with anybody else across marketing and technology, pair up with them. You know what we're doing, you know what the goal is, thinks something up, surprise me. So the first few priorities have really got very excited and buzzed around and chatted and thought up crazy ideas. I know. We could, you know, whatever.

Jump in a swimming pool and do this. And, but in the end, it boiled down to about five people. So a data scientist, a designer, a data engineer, a BI analyst, and they started working weekends on it. I mean, I didn't ask them to, but they loved it so much.

And they just came up with stuff that I didn't know I wanted needed, but the company loved. So this was great, very highly engaging interactive. I haven't got a live version of it, but you would click on something, put in a target artist. It was across sixteen markets.

You could see what the affinity artists were. The size of the ball was how many customers we had contactable customers who were in that affinity ball and the closeness was how closely they were finna they were they had an affinity to the target artist. Lots of fun.

Really useful for promoters who were booking festivals, really baseball for sponsorship to talk about and understand things. Right? So, we put this behind our our company, Octa, single sign on, and made it available to everyone. Because it's aggregated in an almost data with lots of fun.

Same with mapping. We did a similar thing, distance venue, bit of a killer app in, selling retail tickets for events.

So that's the end of the Ticketmaster story. So lots of changes.

All of you in this room are involved with helping change your business, whether that's to reshape your back customer value proposition, whether it's to transform operation, whether it's to streamline and automate processes, do things better. Right?

You're using technology and SaaS technology to drive that meaningful engagement and interaction across your business.

So I just wanna talk about the changes. I think old marketing this is the, you know, back in my hat stickers and knickers days. You know, you'd put out a campaign and wait to see how it did. Now your multi orient testing in the campaign and doing things all the time, right?

Silos, you've got to be collaborative, and the talent has really moved from very old fashioned traditional talent to quite modern mixed teams of people who are analysts, who are videographers, who know about SEO technical stuff and more. And I think but I'd love to hear in the coffee break that also IT and technology teams have changed as well from sort of fixed jobs maybe more to sort of tasks, which are more fluid, from functions to projects and from a hierarchical way of working, maybe to a matrix way of working. That's my thinking, anyway, I'd love to share that, hear what you think. Here we go.

We're gonna race through this, right? Because everybody wants a cup of tea, coffee, drink, don't know. Seven point plan to manage complex teams. One, start with a clear vision and strategy.

Make sure you're very clear as leaders, what the goals of the company or team are setting the norms or how people collaborate and communicate. In case he didn't know who he was, I put his name on his t shirt for you, sat in a dinner.

Two. Cross functional teams and shared KPIs. Guys, it's a team sport.

Transformation is not a lone endeavor with a singular hero. Anything that's really worth doing and that hasn't been done so far is probably because it is difficult, because it is complex, and because it does cross different teams. And you may not be the SVP or the CEO, but it is your job. You are leaders in your fields to really try and drive that collaboration.

Long term pro plans and short term projects depends what kind of, you know, company you're in, where you're up to on your on your data and your transformation.

I think a long term road map for the big rocks of your data and digital strategy is key, but smaller projects pebbles, let's call them in our jar of life, you know, the rocks pebbles and sand. We all know that one. I think pick one of those if you're, you know, and to to really do a cross functional cross team to sort of light the way and show how it can be done.

Communicate prodigiously town halls, team meetings, country visits, lunch, and learn, strategy j's hackathons, whatever you can do, do that because you often think that everybody in the company knows what you're doing, and they don't.

Right? And you might be quite quiet and you might be super clever and you might be doing amazing work.

Find somebody in your team who wants to go out and shout about it and try to start shouting it yourself. You know, maybe lunch and learns is the way to start, but do, empower your team. They will surprise you. You know, don't micromanage them once they know what they're meant to do and once governance and the rules are very clear, people are extraordinary, and they will blow your socks off. So if you're leading a team, really think about that make sure, of course, they have the means and the, you know, that they need to to succeed.

Lots of different ways, you know, rag report, rag status reports, project management. I think, you know, great project managers are often in short supply. They're not here to tell people what to do. They really are here to kind of hold the project to account in a blame free way.

Right? Okay. So why did we get blocked? What is happening? Let's let's be honest about what's going on here.

So I did it by sharing often in in weekly, four ninety, and monthly, and quarterly reports, god it never ended at Ticketmaster.

I think you have to be flexible and adaptable. Things don't always go to plan.

Celebrate success along the way. Get some smaller milestones and have fun. If it's not fun, what is are we doing it for if you're not gonna have some fun, right? You spend an enormous proportion of your day at work, you know, not seeing your dog or your kids or whatever it is that you'd really rather we're doing pottery.

I like pottery. It's very good for me. It's like basket weaving for the criminally insane. Anyway, celebrate success along the way.

If you're not having fun, there's no fun. Race for the prize.

So business is typically hierarchical, right, executives want control and predictability, but the way things are going right now, that's not how it is.

Employees need to own a change of vision and be, you know, empowered to deliver it. Cross functional teams deliver value quicker. A really well directed and empowered organization can move mountains.

What is my next one? Yeah.

This is kind of a bit existential.

Honestly, I do I do. I think you're at the crux of everything. Right?

This is really existential, you know, actually making these moves.

And some of the most impactful leaders and people that I have come across, they're not actually leaders. They weren't SVPs or CEOs or senior directors.

They were just incredible people, maybe someone incredible in my dev ops team or in the infrastructure team who you know, they they led the charge on collaboration. They led the charge on teaching me. They led the charge on organizing lunch and lunch and connecting across teams. Oh, I've been down to this team and I've spoken to them. We're gonna have a regular meeting every other week, you know, and really get this going. So, you know, and here's two people that were never voted in to be anything.

You know, they didn't have leadership positions and yet they're leaders. This is taken three years ago. Greta, his looking a bit younger. She's seventeen here and I think Milan's about twenty one. I always cry in a presentation. This is where I cry.

So look, I think that the call is you are leaders as well. If you look, if if you're working in a terrible organization that's no fun and there's no action, and there's no good vision, and there's no good plan, get another job.

If you're working in place that has a good plan, and overall you're happy with it and you know that you can deliver, figure out how you can deliver more, figure out how you can be a leader because I think all of you in this room are exceptional.

And, you know, on behalf of your companies. Thank you for the work you're doing, and thanks very much for having me today. Thank you.

Okay.

Thank you so much.

Thanks so much, Sophie. Thank you.

I think we need to get one of those explicit content warning labels and, you know, for your presentations in the past. You know, just like those records you used to plug.

We have a short break now, folks. So feel free to run away and grab a coffee that's upstairs. In the river room, we will reconvene at ten twenty five in here, for the last talk for all the wider workshop sessions and things like that off. So ten twenty five back in here, coffees in the river room upstairs.

And if you have any questions, there's a whole bunch of folks at the back over there that can help you out. Thank you.

One of the Look my down.

Spime with him.

It's my feeling, will, women, and I want home. I have chosen the benefits.

Otherwise, it's not papers.

But there's time she needs to rest the kids are playing upstairs.

This is saying in her sleep.

There's only something happening, and it's usually right now.

She's a house crowd.

In the middle of our streets, my house.

The kids are playing on downstairs, Thank you for coming for today.

But a slow, long dream, that your fear seems to That's They don't understand. And so we're running this expensive weekend.

Hello.

Hello, everybody. Welcome welcome back. I hope we're all refueled, a little bit refreshed, there are coffees, teas, waters, etcetera.

What morning has been so far.

Gonna try and keep some of that energy up from Sophie. I'm not sure if I'm gonna be able to match it though. So I hope you've enjoyed the first keynote, this morning, and they're looking forward to the rest of the day.

Gonna talk a little bit to you now, today. You're gonna, you're gonna have me, me for a session.

We're gonna talk a little bit about the Salesforce DevOps year in review. So a little bit about me I've worked for Geerset for nearly five years now.

Across that time, I have worked with teams of all shapes and sizes, everybody from solo administrators swirling away on their own to the larger enterprise teams, that are more complex and have varying degrees of release management and ups requirements.

It's been an amazing journey in the last year and a half, I've spent doing my current role, which a dev ops advocate where I spend a lot of time in the community talking to folks such as yourself and getting an understanding of of the challenges and some of the things that you would like to see improvements on in your Salesforce DevOps processes. So in this talk, I'm gonna talk a little bit about that and some of the insights that I've gained from the community over the last year or so. But we're also gonna be talking about the state of sales devots report, which Geerset releases every year. So last year, when we ran this survey, we had twelve hundred respondents, which an absolutely incredible number, and that gives us a really, really rich data set that we are able to draw a lot of insight from.

We add our expert analysis too.

And the results of which become more comprehensive and really, really more interesting each and every year that we run it. So let's go over what we learned from last year's survey, and we're gonna dive into a little bit about if what we found in the survey from all the respondents last year held true to this point today.

So we can't talk DevOps without talking a little bit about Salesforce and the platform itself. So In news that it's probably gonna be a shock to absolutely nobody in this room, ninety seven percent of respondents in this report said that their use of Salesforce has evolved, over the last year. Now, that's unsurprising because your business does not buy Salesforce just it to do a few things and, you know, let it stagnate. The whole reason that we love our jobs is that we get to change the system. We get to develop the system based on growing business needs.

And also unsurprisingly, sales and service cloud are popping the charts in terms of the most used clouds.

That's typically, typically where we see see the most Salesforce users, service, but what we've also seen in the continuing drive for digital transformation is that businesses and companies are investing more in experience cloud as well. So we've seen a significant uptick in customers trying to do more for their customers.

With Experience Cloud. And we've also seen an uptick in the revenue cloud and CPQ as well, which is something that gives has been very conscious to keep on top of by developing our own solutions to keep on top of that growing demand and the complexity, of deploying on those platforms.

So that's a little bit about the platform and a little bit about where people, are going, with their usage.

So let's just hit let's let's just get it out of the way. The big big buzzwords, this is not an AI conference, but I think it would be slightly irresponsible not to talk a little bit. About AI. So unless you've been living under a rock, you'll have noticed that Salesforce are all in on AI.

Look at look at Dreamforce. You trailblazers is the thing. Trail AI blazers. I don't know how to pronounce that if anybody's got a better way.

Please tell me.

They're all in. So we've got Stein GPT, cell service GPT, big announcements for the Einstein one platform and the co pilot studio as well. So we're definitely gonna be seeing this talked about a little bit more.

But a lot of questions remain about the effectiveness of AI itself because data underpins it. And that's probably why it's also unsurprising to see Salesforce investment in Data Cloud, which will hopefully set the sound foundations for us to be able to AI effectively in our business processes.

But what we're also seeing, AI, yes, whilst all the rage GPT, large language models, etcetera, being used for, our sales reps, our service reps, etcetera. That's not quite translating yet. To DevOps. We haven't seen as much interest to bake AI into into those processes.

There might be some people in change intelligence here that agree with me, on that point, but AI hasn't quite got there in DevOps just yet.

Lots of skepticism around AI which is not unfounded.

Lots of memes, lots of jokes, there's still a bit of, a taboo subject but Salesforce's generative AI survey. They surveyed four thousand people, and they told us that they told us that their biggest concern was the potential to introduce security risks.

Seventy three percent of those four thousand people said introducing security risks was the biggest issue with AI itself. Now whilst that is no actually going to be a challenge, and by having great DevOps processes underpinning the safe adoption of AI, we should be able to adopt it effectively if we can you to invest in, security, data backup and things like that. Something I'm gonna talk about, in a little bit. But this is the main contention, and the biggest area of conflict between CIOs in your business or higher up leadership, CTOs, etcetera, they want to have a handle on emerging tech technology. They wanna drive digital transformation. They wanna drive their growth, and they wanna be ahead of the curve and not out to customers, but that is a trade off as we're looking at AI as a subject right now.

In the same report, these are the major factors that employees have come knees said hindered their ability or their confidence in adopting AI as well. So there's, significant challenge is in human oversight. So if we think about even a dev ops process, we want to have some level of human oversight to understand that everything is operating as it should. Who's used GPT, OpenAI or or whatever? Okay. So a few of you. How many people use GPT and just slow the results high into the world without checking them.

None of you. There you go. So that gives you some level of indication that human verification and human oversight is gonna be the big thing to make sure that we can harness these tools and technologies effectively.

Especially in the Salesforce environment, if we're using its underlying data structure and using that data to inform what, GPT or, other AI competencies will come through.

So enough about AI. Still cloud DevOps and DevOps adoption. So this is the key approach, and the key, key thing that we're looking achieve when we release this survey. So we want to highlight DevOps adoptions and the trends around it. So teams of all shapes and sizes. So I mentioned I worked with subtle admins and everybody up to the larger complex teams, and every team is realizing the benefits of deploying faster, the improved collaboration benefits that a good DevOps process brings, as well as the quality features that are breaching their end users now.

So in the report, we take a look at Some of the key facets of DevOps that teams are approaching.

So we can see here the breakdown of what teams currently use, what they're planning to use, and what they have no plans to use. And to me, it's highly unsurprising and we've already talked about this a little bit in those lightning talks, but CICD is topping the list, for respondents, thirty nine cent of respondents said that this year, they wanted to adopt CICD practices.

So have they?

Yes. Yes, they have. So fortunately being a deluxe platform ourselves, we're able to look into our user base, and we've seen that there has been a twenty eight percent increase in the number of Salesforce teams using CICD right now compared to last year. So that months and that intention to pick up those practices are definitely coming through as it relates to CICD.

Gonna back to security again.

That continues to be a three theme and will be a theme, as we move through the rest of this talk, and data protection falls soundly in to that. So you can see, in the middle here, we've got data backup. So just over fifty percent of teams last year when they were surveyed used data backup products.

To me, that is widely unacceptable for for a number of reasons.

You know, you don't want to risk your your data going out the window, and really start to damage some of that trust with your customers.

And just over thirty percent said that they were looking to adopt, better data security through having backup solutions, and we've seen a thirty seven percent increase in customers using data backup. So well done, everybody that's great news.

So if we take a look at the DevOps performance now, so, it's all well and good having all these, having all these great things, CICD, data backup, automated testing, and all those things, but how does that relate to performance?

So the way that we measure performance primarily, in DevOps is via the Dora metrics. So that stands for the DevOps research and assessment. Metrics, and they're from Google. These are the industry standard metrics that we use to determine, DevOps effectiveness.

So deployment and our lead time for change speak to the release pipelines velocity, and the mean time to recover, and the change failure speak to the stability of the pipeline. So velocity and stability are the two things that we care about most in DevOps. And whilst I'm not going to cover all of these areas in in my new detail, tell, we are gonna look at the key one, as it relates to the previous insight of teams looking to adopt CICD practices.

So we've seen steady improvement over certainly in the last five years that I've worked for gear set.

The deployment frequency is increasing.

Long on other days where we would wrestle with change sets, to do a release once a Who's who still does that? Does anybody still do that once a month deployments?

Oh, all the hands are down. Yes.

The state of Salesforce DevOps survey found last year that most teams are releasing multiple times a month, which is fantastic. Whether that's still with change sets and you're still wrestling with them or whether you're using a deployment solution or deploying through a command line interface. So if you stack that up with what we have seen in gear set over the last year to this point.

There's there's two figures here. So we've got a median figure.

The median figure for gear set customers that are running deployments, they release multiple times a day as part of their CICD processes. And that's what CICD can enable.

If we look at the mean of those teams, they are releasing hundreds of times a month. The most elite teams can release hundred times a month through their pipeline. And that is testament not only to the investment that folks are making into adopting CICD best practices. It also means you're doing something right at the start in means that you're building features in a smaller fashion, smaller chunks that are more individually deployable, and you can start to see the impact of those smaller features our users faster, which is really great to see.

DevOps training, so training is an integral part of any business.

So we asked the survey respondents what training they've received and how it translated their DevOps performance.

Again, and surprisingly, I'm gonna say a lot, unsurprisingly a lot. Maybe it's surprising to you folks. Unsurprisingly, those who train experienced healthier levels of collaboration between their team in terms of communication and getting work done, and were outperforming those teams that weren't doing any training at all. So with that hands up, who's had specific Salesforce develops training this year.

Okay. Now everybody raise your hands.

Everybody. Everybody. You're all here today. So, yes, you have.

The fact that you are here today is testament to you and is testament to your organizations that they are taking learning into their own hands so that you can be more effective at your jobs. And that's what DevOps is really looking to to achieve.

You're also building valuable connections here today, a a community event, those conversations that you might have at lunch or during the breaks, and we're just sitting next to the person next to you right now is really valuable, versus more formal training. So It's awesome to see you all here.

If we look at a breakdown of training and what folks are actually learning, looking to learn more about, again, CICD is topping that list, and that just goes to show that real drive and that real desire to adopt the best technologies and the best ways of releasing on the Salesforce platform.

Now we said just now that the teams that are undertaking DevOps training or adopt DevOps practices have healthier collaboration and better teamwork. But interestingly, the report found that forty four percent of teams were interested in learning how to collaborate and gel with their teams better. Now that's really interesting because with the core, the core of DevOps is is about improving, improving those, those lines of communication, being able to collaborate better, iterate on feedback. But it looks like folks are still looking for ways that they can that, and better ways to do that.

This is a strong indicator to, if you're a team lead or a manager in here, you might work with your L and D department, or if you are, responsible for that yourself, you wanna invest in that and maybe do think about things that are slightly softer, rather than the technical skills involved in DevOps.

And we also see that forty percent of folks are looking to understand better business value of DevOps. So what I see a lot is, is prospective gear set customers, or people come up to the events and go, we really want to buy gear set, or we won't really want to do X tool, we want to do Y tool, and they struggle to articulate that you back to their senior stakeholders, and they go, we haven't got budget for that. So that's really important, and hopefully by attending today, and diving into that a little bit deeper, you're able to have those conversations to articulate that value, back up the chain.

We are very fortunate to have DevOps launchpad. So, you'll see DevOps launchpad up upstairs today. Go and have a chat with Charlotte, and Holly. Demo's launchpad is a online training platform that is not to Trailhead, but it's DevOps agnostic. So you can go on to DevOps launchpad and learn about plethora of DevOps topics.

Virger Control ICD backup, you name it, it is all there.

DevOps launchpad has seen a ninety percent increase in users this year, which, again, is backing up everything that the report is saying. And it's actually, again, testament to folks like you sitting in the room that you really want to get a handle on these things. You want get a handle on it, and that's really commendable.

And what's also interesting is thirty eight percent of those people that have signed up to Devox launchpad, Salesforce developers, twenty one percent are admins.

Now, this is quite reflective of a fallacy that I see a lot, even still, that DevOps is for developers or DevOps is for people who can code, and that is just not true. Good DevOps should involve everybody through the development life cycle, you should be empowered to be able to deliver your changes from end to end, if you're an admin, if you're a developer, or if you're an architect working on those solutions.

So we'd really like to still do some work to, educate admins that they can be a part of this process and remove maybe some of the fear around the DevOps word.

Most popular courses on DevOps launch pads intro to Salesforce DevOps encouraging that folks to taking that first step. And then what we're seeing as well is, the DevOps's fundamental certificate, who doesn't love a certificate, in Salesforce.

So they're signing on to do the full course that gets them that certificate too, which is also really encouraging. What we've also seen on the platform as well is that a lot of folks are signing up to do the introduction to Salesforce development, meaning that those admins that are coming to the platform are looking to broaden their knowledge and broaden their skills, which is also really encouraging to send them down that path to slightly more technical topics, setting that groundwork for future learning in development.

Now, there's plenty of, training, abounds, lots and lots and lots and lots resources that you can leverage from the community.

DevOps launchpad itself, I've been talking about that a lot. Salesforce Ben have courses. There's a courses on plural site. Apex hours have courses and informative blogs.

Trailhead isn't up here. Whoops. Anybody from Salesforce I'm sorry about that.

You've got community events like this.

If you haven't already, I really suggest you attend London's calling. Any of the organizers here? Whoo. Yes. Go find Todd and Francis. I can see hiding over there as well.

London's calling is a great community event with plethora of topics and you like to talk about DevOps too. You're gonna hear from Francis after me. So those community events, Salesforce Saturdays and user groups as well, a whole fountain of knowledge from those places as well, where you're able to connect on a more intimate level with those folks. So look up those, in your area.

I told you we'd come back to security and compliance.

Security and compliance is a huge, huge topic, and it's not going away. It's more important than ever, and that is for very good reason.

Now often what we've seen despite, like, even five years ago, back at the start of my Salesforce DevOps journey, continuous monitoring automated security checks were once perceived as optional.

That is no longer the case, those things are should and are standard in most business.

And that transition in mindset is crucial to the reduction of vulnerabilities and increasing the level of data protection and security that your orgs have.

If you bolster the trust in your team by having a robust data backup solution, robust a recovery plan, that will also enable you to adopt better fast moving debit practices.

In the adages, move fast, break things, which is fine, providing that you have the security to do so, that you can roll back, that should something go wrong, you can it to a previous state.

To highlight that, let's dive into a couple of instances from just this year alone. So in April twenty three, news broke that several companies, and I'm not talking, Glazier's whole ink. I'm talking major banks, major health care companies were leaking data from Salesforce, to, to customer that we're looking to, log into their platforms via digital experiences and communities.

So like we saw in the first slide, the adoption of the Salesforce form is continuing to increase, especially as we look to drive transformation and put more useful things in the hands of our customers.

However, there's danger around that if we don't fully understand the implications of the permissions and the security models that we are introducing.

This can be prevented by testing, scanning vulnerability testing, having a security mindset through the whole release cycle.

And then once an issue is spotted not only being alerted to that there is an issue, but being able to fix it quickly is imperative so that you do not damage the trust of your customers, and therefore, damage your whole company's reputation.

So trying to avoid that is essential.

If we look at quiz company, sporcle. So, anybody done a sporcle quiz? Any Harry Potter fans like me nerd out on there? Nope. Just me. Cool.

This was a issue for sporcle. So, if you've never done a sporcle quiz, I highly recommend you go over there, whatever TV trivia, etcetera, you're into go and check it out. They are knowing they introduced a production bug that impacted five hundred live event hosts at one time. They had no rollback strategy.

They had to find a quick fix. And when they found that fix, they couldn't then deploy that fix because of other work items that were stuck in their process. And you can see the quote from the CEO here, saying that that is absolutely an unacceptable business outcome, and I agree with him. You know, you have five hundred people using your platform and your platform breaks and you can't ship a fix, that's bad news.

So situations like this are more common that you think.

Yes, like, not all of us will work for a company that is publicly facing a sporcle. But think about your users five hundred of your Salesforce end users not being able to carry on with their jobs in impact the business that that's going to have.

Fortunately, they are now gear set customers and backup data backup, etcetera. So you're interested in, in that, come check them out.

In another issue, Salesforce themselves as we're aware, aren't immune from their own issues.

Few instance in the past few years are probably springing to a mind for a few with you. But earlier this year, they broke a permission for their AWS instance. And as a result, that impacted data accessibility for their customers. Now whilst that in itself is obviously disruptive, there's a compliance issue here too.

Some regulation state that you have to maintain access to your data at all time. And this is why data backup solutions are imperative to your step stack, and data backup solutions that don't live inside Salesforce. You're still one of the folks that rely on Salesforce for your backups. I suggest that you take take a look at, some of the other providers out there to give yourself more robust security.

So in that report, we found that third one percent of the respondents thought that enhanced security is a key benefit of DevOps, and that absolutely is ringing true. A robust and well tested disaster recovery plan, or DRP will also be beneficial in the long run should you run into any of these issues.

If you need help designing a disaster recovery plan. There's QR code up here as well.

That will link to a webinar that we ran on how you can design a road recovery plan, should you, run into an issues?

Any phone still up I talked about a range of those regulations that we have to comply with, to maintain robust data security and there's a range range of regulations. Most folks in here, GDPR is probably gonna be the big one that you're most concerned with.

If you have US counterpart businesses, parent companies, etcetera, you might also be impacted by the CCPA.

Socks, if your parent is public be traded, or HIPAA regulations if you operate in healthcare and also in the US, and their requirements are absolutely unyielding.

And these are the questions that you need to be asking throughout your development process and the life cycle.

And those questions might seem like hurdles. They might seem like hurdles, they might slow us down. They could be, potential issues that impact that all important release velocity.

But if you need to evaluate every step of the way, I want to reassure you that you can do so whilst maintaining that velocity and striving that continuous delivery that we are also evidently passionate about from the results in this survey.

So it's important to note why is this important? Whilst we are an all not on the scale of meta, meta was fined one point two billion euros this year for their breaches relating to GDPR. So that's just how important these things are. And we can't risk, potential breach and security risks, throughout our development life cycle for those reasons.

You're gonna talk I said I was gonna stop talking about AI. I won't.

AI presents plenty of opportunity for us in this space as well, but we may be opening Pandora's box if we are giving it access to custom data that we might use to drive data driven, AI insights. So something to consider, especially if you are looking to adopt that AI journey, you need to be secure in doing so.

The business benefits, DevOps are huge.

Those who are opting best practices are seeing the ROI that they need. Leaders and decision makers want to know the impact to the bottom line, and they also want to know if it will scale as well.

So digital transformation is ultimately the name of the game. I've mentioned that a couple of times and a result, people will often push DevOps as a project off to the side. Oh, we'll do that once we've completed our digital transformation.

The transformation needs to be be complete. However, if time is carved out to start looking at some of your practices, your deployment practices, and adopting some DevOps best practices, that is what's going to be able to enable that at digital transformation quicker. So it's a bit of a catch-twenty two. You need to set aside, need to deliver, but you also to improve your processes. Let's carve aside time for both, start to set some realistic expectations.

Larger teams have been leading the charge in their return on investments. So fifty percent of larger teams that we surveyed adopted all of the practices that we asked about. Over forty percent of those teams are receiving ROI over over twenty thousand dollars a month, and eleven percent of those teams are seeing ROI of over a hundred thousand dollars a month. Now there's a pretty insane statistics, but when you start to break it down, if you think about the amount of time saved for developers and admins, how that can be better utilized, how much quicker a business critical features reaches users. If that reaches them three months faster, that's three months of business impacts that you can start to quantify.

So if we look at Violia, Violia adopted best practice dev ops earlier this year, and their deployment time is now through the floor. They save a hundred hours every two weeks through their deployment process. Now think about what you can do with that. You can go and learn about AI.

Can go and learn CPQ. You can go and invest some knowledge and some learning in another area, the platform that is going to drive change and drive your business growth. Their ROI for just this year is estimated over five hundred percent, just this year alone. It doesn't happen overnight, but it achievable.

Hopefully, that's given you a bit of insight, into what has a memorable year for DevOps, certainly we are seeing, the upwards into the right trend continuing. Not only are folks aware of the benefits And the concepts, they also want more. Learning's taken into your own hands. AI is getting people curious.

What can we do with AI? Let's secure ourselves before we run down that rabbit hole. So I can't wait to see what the results of the next survey will bring. You might see these orange cards, sitting on sitting on your chairs.

If you have time today, scan the QR code, fill out the survey, for your chance to win, do you see a thousand dollars as an gift card, your insights are really appreciated, and your responses are really helpful in gaining these insights of what we should teach you next.

Thank you for much.

Slide down questions if you've got here.

And we need to get France, so Thank you.

Fox, thank you very much. I am gonna leave you in the very capable hands, of Francis Pindar, who's gonna be telling us about the ten habits of highly successful Salesforce DevOps engineers, Francis, take that away.

Everybody.

Great. I'm gonna chuck this down here.

So, yeah, my name is Francis Finder, and I'm here to talk to you about the ten habits of highly successful DevOps engineers.

Because I'm on a bit of a mission to empower the next generation of Salesforce admins and developers to become successful architects, and I've trained over a hundred and thirty thousand people now in a hundred sixty countries Salesforce.

And this is really this kind of my dev ops journey. I don't know if anybody I talked last year.

I kind of started off my dev ops journey quite a while ago, kind of trying to learn it from scratch pretty much, and since then, I've wanted to learn more and more and more about the Salesforce platform and best practices and everything else. And I very selfishly set up the Salesforce posse, podcast. So I can get people and ask them questions and really pick their brains on stuff, and you'll probably notice a couple of for long here. Somebody on here, as well, about learning about dev ops and best practices and stuff like that. And just recently, we've been, talking about the state of Salesforce implementations, and how it's changed or not, over recently.

And because it's been quite a shift, I would say, recently in the market, know, lots of things happening, layoffs, and, things like that.

And but I think that dev ops has been a bit of that shining light, right? Because everybody's wanting to do more with less. And that is the dealhouse of DevOps, right? And I think it's been a bit of the saving grace of Salesforce because, Salesforce also getting more complicated. They're getting more complicate complex.

The honeymoon of Salesforce, I think, is over, right? It's a lot less new is adopting Salesforce. It's just existing orgs that are getting more and more complex.

And so this is where obviously DevOps comes in. Now, let's just reset a little bit and take a look at DevOps, because I think and it's come up later in the previous talk as well. DevOps isn't just a engineering type role. It is now gone wider. If we think of the affinity curve of monitoring, deploying, planning, verifying, and releasing All of this doesn't necessarily mean just scripting and building change.

And putting in another git repo or changing our branching strategy is actually seeing the value we're giving all the way through the process.

So it's than just an engineer, really now.

So my ten habits of highly successful DevOps admin slash architects slash other.

So the first one, I think, is this, eating cake. No. Thinking in layers.

And the approach to actually you're adding value you. I think DevOps is a bit of sometimes it can be quite close, and it's quite hard to show the value you're giving. Right? Unless you're kind of really kind of showing it to the business, and understanding. So kind of thinking in this layered approach of, well, how am I gonna describe this and and really kind of maximise this investment in DevOps, and how can I demonstrate that across everybody in the organization?

Oh, there you go. Thinking layers. And Salesforce does this as well. Like, you know, who's seen this?

Right? Yeah. Exactly. And the reason they show this is because their target audience is the C level execs.

Right? They wanna get buy in at this level, and everything else. So how can how this is how I do it when I'm trying demonstrate the value of DevOps might not be the right way or wrong way, but I kind of go, well, actually, what is our organization's goals, right, overall goals for the organization?

And it can these, it could be something different. And I know if you do, you know, there's some business value drivers and benefits that are coming out of what they're trying to achieve. And a lot of these are what you have in the Salesforce project. Are we gonna improve the sales processes and all this kind of jazz? But for me, I wanna really pull out the ones that are relevant for DevOps and actually show that we're adding value as the same way as making changes in Salesforce in our dev ops world. So I can really demonstrate that we're on the same, you know, going to the same team on the same team and achieving the same goals.

But then after that, obviously, we come down to measures and KPIs, that obviously in the Salesforce world, we have win rates, we have lead conversion rates, and all this, and we're to, you know, increase or decrease, these. And then finally, we've got the functional capabilities, but we've got the functional capabilities of Salesforce plus we've got our own dev ops world and what capabilities are we using to harness to measure to then show the value so then everybody kind of can see the benefit of what DevOps is having in the organization.

Make sense? Yep.

Brilliant.

So I've kind left these blank, because obviously, the next thing is about being data driven. And I think this is a kind of, A bit of a multi layered thing, right?

The first thing is actually understanding your kind of DevOps value stream.

So, this I kind of showed last year, but this is how I kinda looked at, okay, when that requirement comes into the system, how is it flowing through? Which systems are being used and where how many people are going to be, you know, working on this piece of work. And you can notice here, like, I had fifteen people signing off a deployment.

It was like, this is crazy.

But I think being data driven and understanding, you know, the metrics coming row, you can really understand, okay, where do we need to focus on?

And obviously, there's the door metrics, right? As everybody heard of the door metrics I'm hoping. Yeah. But also, I kinda think this dev ops role is kind of getting wider not just looking at how we push change through the kind of dev ops beast and and the work for it.

It's also kind of, well, actually what value of the things that we're doing is actually giving value to the organization as well. Are we doing the right things and marrying the two up together? That. And so, yeah, this is taken from gear set.

Sorry, gear set, but it's straight from your deck. So, yeah, it's important. If you're not if we go back.

Yeah. Lead time adding value and understanding where the bottlenecks are in the process is, I think it's really important because you need to then focus.

On that. Okay.

My next one, I have no idea how long I'm doing. How quickly I'm going through this.

Should be cool. Right. Okay. Next one.

Asking why I'm listening, right? I think listening is the talent for devsecops organization, especially when you have those confronting, you know, the teams that are kind of a little challenged, I suppose, I think of security and security architects and in a highly regulated organization that I can work in. And it's like, no, we need to lock everything down, but there's a pragmatic way of understanding actually what are the risks they are actually trying to and also kind of showing them actually, you know, this is what we can do better and more efficiently, and bringing in the dev teams, the business. So and I'm really understanding what's going on. So it's almost like that kind of customer centric mindset of going. These are the developers that are in the system, you know, what is, you know, the user interface or the most crucial, crucial elements for you and being more empathic, about listening, which I'm terrible at.

So yeah, and asking why a hell of a lot to understand actually why are we doing this, and can we change it, and can we make it more efficient?

And and then it's obviously been great communicator. So once you've list and broad all that, and you can communicate it out. And this is where the layers come in as well. It's actually you're communicating at the right layer level. For the audience you're talking to. So, for, you know, I'm not talking to a c level exec about how changing the branching strategy in git, because he probably doesn't care. But he is he does wanna know how those business value drivers are changing, the organization and how DevOps is actually giving value back to that organization, which is kind of, a little tricky, but also how having that kind of, that big picture vision and that detail orientation as well, so that you can kind of understand and work on the delivery of that kind of dev ops, improvement process, as well as kind of communicating that well across the organization, and to the develop and to the developers, as well as operations.

Okay. Who who what do you think this one is?

Harry Potter. No.

Well, I suppose the glasses. Yeah.

My one came to fame as I was in Harry Potter, but yeah, I was Fred Weasly stunt double. That's another story.

Yeah, So having a learning mindset.

Now I asked this question yes last year and one person put their hand up. So I'm hoping more people will put their hand up this year, baby.

Who's read this book?

Oh, yes. Brilliant.

Is it a good book? Do you like it? Yeah. I I love it. Brilliant book.

For me, this was this really kind of got, basically was my starting journey almost with Salesforce. It was all in DevOps. It's basically a storybook, a novel on DevOps, right?

And the first hundred page is is just complete disaster after disaster. Right? This story, I think the very first page is how this public company share prices gone down because they've missed their earnings targets again due to this delayed project, the Phoenix project, which has most revolutionized the company. And as you're reading it, you're going, oh, yeah.

That character's Jeff insecurity.

Whatever it is. So it's really relatable. But but it's re it's a really great book. Really and whenever I do a work on a DevOps project, whatever I'm handing this book out to people, right? Because it it I think it's brilliant. Now, the one after that is unicorn project. Anybody read that?

Yeah. Not quite good as I don't Yeah. Quite not quite as good as as as a video photo, but yeah, still pretty good. And also there's the DevOps handbook that kind of is all part to kind of the same series.

But one of the key things that I kind of really learned from that is is is the the silent killer.

Anybody know what the silent killer is in Devox?

If we reach you know this, hopefully this will come out. Oh, no. It's not. The slides are broken. Okay.

Whip. What in progress is the silent killer in any Salesforce project.

Already DevOps really.

It's this build up of work at different work stations. You know, you want to get that optimal process all the way through, and get work pushed through kind of quickly tested automated and through the system.

And so, yeah, and this and the the Phoenix body really originated from this book, the goal, which was all around manufacturing techniques and stuff like that. And this is really kind of the key tenant of it, improvements to any part of the system other than the constraint will not yield any significant benefit. So for example, this work in progress at some point through our kind of value chain of ops, if we're having a build up of work and progress, say, at a constraint. So it might be testing, and we're building up, you know, some a lot of whip, then it we improve the development process, well, we're just increasing the work, you know, the work in progress behind testing. It's not improved thing. And if we improve everything after testing, well, then they're starved of work because it's all built up at testing. So making sure we focus us down on the actual constraints and the key constraints that are slowing down the whole process is really important.

Everybody know the theory of constraints.

Anybody?

Okay. I'll go through it. So this is all around. Okay. I've understand how work throws through the system. I know there's different work tasks that are happening through my process, and I've now done the analysis, and I've identified that actually there's certain constraints that are slowing work down.

And there's essentially a a step process of first just observing that constraint, understanding, well, how are they doing things? What is happening at this, the constraints? We can understand it better. The next one is really just exploiting that constraint, like understanding, okay, what can we do better with that constrates so they work more efficiently. Right?

So they can work better. And it might be that fails, right? And you're still getting lots of work going in. And the next one is subordinate, which is basically the whole of the everybody else in that in the work basically realigns to support that, constraint.

So it might be that the user stories coming through the testing aren't clear enough, and they keep on being bounced back to find out more information before they can go back into testing again to actually test it properly. And actually, they were just being written wrong in the first place, or they weren't clear enough in the first place. And so, therefore, actually, let's focus on this. Getting those user stories well.

Wet good, making sure the acceptance criteria is all there, that we can kind of have a smoother ride through that, constraint.

And then if that fails, then it's looking at how do we elevate that constraint? Do we bring in more automated testing? Do we actually give them training. Do we put more resources on there?

Do we just have more EC two instances to run out an automated or whatever, however you're doing it. And so, you know, this is key for me. Oh, yeah. And then once you've finished, it's what's the next constraint.

I think when you initially start, you can probably find the big constraints pretty quickly, right? But then as you're iterating through, improving and improving, these constraints get harder and harder to find.

But yeah, continue we do, to improve everything. Does that make sense?

Yeah. Cool. How much time are I'm whizzing through? Brilliant.

Okay. So, next one, the slam dunk, iterative automotive mindset.

So obviously, an automotive an automation focus is the key to DevOps, right?

Makes sense. Okay. We're trying to automate a lot of the manual processes we want to increase efficiency, reduce errors, free up time for that kind of more complex and iterative work.

But I think it's also being that having that iterative mindset of going, look, let's let's fix the big things we can fix easily and iterate and learn from it, and having that continuous feedback on algae was it successful. And do it, you know, think big but start small, which I think Sophie said, I know in the earlier call, earlier session.

So, yeah, and I and and that's all the I think, you know, all the agile processes and everything else. It's kind of all comes part and parcel of that.

And all that. So that that makes sense. All good.

And now this and now the learning tree.

Which I think with dev ops, you I I kind of think of it as like this t shaped technical knowledge. Right? It's having that proficiency in or even, you know, having that very knowledge of all the tools that are available to you, and all the things you could do so that kind of bring it down to actually what's useful for the organization, but also kind of going deep into areas maybe of like scripting or DX packaging and things like this so that you can actually kind of connect the these systems together.

So, you know, CICD tools, you know, gear set tools, elements cloud, all these things that could eventually improve that process. Having an understanding of them, but then putting that kind of real world measures of actually, is this gonna have benefit for our organization if I bring them in?

Yeah. So, yeah, if we think of the dev ops process, there's a lot of tools.

Right out there that could support it. Some have better capabilities than others. Some we can support you in, you know, backing up, or obviously gear set, and all the kind of open source tools versus, you know, cloud tools and paid for tools. But also there's a number of open source tools that are used quite a lot. Does anybody use HardIS in Visual Studio?

No. Okay. That's one I use.

A logger.

Another. Oh, yeah. Cool. Brilliant. So that's for, as a great logging tool for logging Apex, lightning web components, flows, and having a framework to manage errors, or messaging that you want in the platform, which I find really useful.

I don't know why that's missing. Is that Oh, no. Oh, no. It's gone that image.

Okay. So, SF DX Delta. Anybody use that? So that's giving a delta. Yeah. So quarter of your git repost, you're only deploying the changes.

And I think it is on here.

Oh, no. It's disappeared. I don't know where that one went. Okay.

But yeah, so there's a whole range of tools, right, out there, but it's making sure that you've got that Marway knowledge of what's available to you and then picking the right one, but having may, you know, a deep knowledge insert an areas, because it is a multi, you know, I think as a DevOps engineer, you're either a lone wolf working on the project or you're kind of got a handle in something else as well, and it all depends on obviously the scale of the project. So having that my world and being deep in a certain area of it is always good.

So now my little Yoda for the next one, being a trusted and vital, adviser.

So I kind of think of this as when you're starting out, you're very functional. Right? You're being told, oh, we need to improve the way we do dev ops. Okay.

We haven't got a git repo. I'll get a git repo in. Okay. What's the such strategy.

Okay. I'll go off and find it. Oh, shoot. This is okay, right? And I'm very functional in doing the work, right, based on being requested.

But then that kind of shifts into this trusted advisor where actually people ask you, what what the best thing we should be doing next? Where should we be looking? But also, I find that when we're shifting to this world that actually you're hearing more information that you might not necessarily here as being functional. And for me, that's kind of really important.

Like, actually the testing team isn't great, and we're looking at outsourcing it. Right? But that's not something you, you know, they want public knowledge of, right? And then you can advise the back if that is a good or bad, bad idea.

But being in that trusted advisor, I think, really important because you're not gonna be to that information, and it's it's kinda hard to get to. But then after that is becoming vital, and This is really good for you really bad for the company, right? Because you are the single point of failure Right? Cause you are vital for the business.

But for you running your dev ops empire, it's brilliant because you can basically ask for more money, you can have holiday that isn't in the holiday rules, right, whenever you want. Because they see that your value to the organization is or perceived value is this high. And therefore, you know, the rules don't quite apply to you. So getting to this is brilliant for you, but not so great for maybe the organization.

So I'm kind of thinking, okay, when I'm working for an organization, am I still being thought of as a functional person. Am I have I moved into this kind of trusted advisor world? Or I'm actually now vital, and I am getting all the information from all the different teams and advice on things, being in that hub of the collaboration and communication so I know what's going on because they want my advice on things, which helps me out build better solutions. Right?

Okay. And this is my what time how long have I got left?

Oh, ten minutes or something?

Oh, god. Laves of time. Okay. Cool.

So then there's this, which is is the futurist and designing for change, which I think is always like tricky. It's kinda like you're trying to build for the future without knowing what it is, but you can bring in, you know, modularization, loosely coupled integrations within that DevOps pipeline.

Kind of bringing that to the making sure you're doing it so that if things do change over time, a company goes bankrupt that you happen using. You can swap it out quite easily, easily ish, but also it's it's it's, Another way of kind of like, well, why are you even here? Right? You could go into chat GPT and just ask, what are the ten habits? Highly successful dev ops, engineers, right? And you could probably do it for all the other talks here as well.

I think AI is gonna change the way DevOps works, right? Maybe not here. There's a lot of, you know, hype around it. But it's doing about using things. Now, this is why I go off the fairway and into the long grass a little bit. Right?

So things like this, it's an iris, right?

But is it male or female? No doctor can tell you but AI can. You can say it's female. Right? Okay?

You've got net for medical research and stuff, it's just crazy things happening.

Where, images can, can detect.

Yeah. Yeah. Can work out the better ways. But this is the thing think is most amazing. And this is look at this, this is from December last year, it's like a year ago. Okay? And that using AI, the NHS, has increased the recoverability of stroke victims three times tripling the number, you know, your recoverability.

That is bonkers, right? It's just mind boggling. I I don't get it. And has anybody stuck sign up to our future health.

Yeah? Oh, brilliant. Do it. Sign it up. It's gonna be the biggest medical search project in on the globe, I think.

And it's basically saying, white, share your data anonymously, but to allow us to plan and work out all these things, like recover, you know, stroke victims and stuff like this to make medicine better. Right? And obviously AI needs a huge amount of data, the more data it has, the better. Therefore, hence, this, you know, program started, which I think is really exciting.

But also, people are saying, oh my god, yeah, he's gonna transform the world. Tomorrow, the world's gonna explode and everything else because it's gonna change so quickly. And I'm like, well, it's not new, right? These innovations and changes.

Like, here's a picture in New walk. And can you see there? That is a picture of a car, right? And then you got horse drawn carps everywhere else.

And this is nineteen hundred. Okay?

Thirteen years later, all cars, one single horse drawn car in New York. Right?

It's just thirteen years, right? But that whole industry transformed overnight, but we bring it back to tech and look, well, actually this is the adoption rates of different technologies over the years. And you can see they're getting sharper and sharper and sharper. An AI is gonna be the same, right? I think.

But we are in this world of narrow AI. Oh, Some of the laptops have gone.

Okay. We're in this world of narrow AI where everything is very silo. Okay? So we've got, Einstein GBT, for example, on the Salesforce platform.

Great. I've got chat BTs to do my kind of things in that mid journey, did all my images in my deck for me, right? From Yoda to the people sitting down, in the conference center. It's bonkers.

Face recognition, you know, shopping preferences in Google. It's all very narrow AI. Right? But there's this thing called, you know, this superintello banner over the top. Oh, here we go.

But, actually, even this week, OpenText has asked more funding from Microsoft to kind of look into this. Now, is it gonna happen? Who knows? But, you know, bringing this all together in maybe just talking to Alexa and saying, can you create me a presentation on the ten habits of highly, you know, effective DevOps engineer including, kind of pictures from this and that and other, oh, and do the marketing collateral in my voice, for snippets for TikTok. Stuff like this, and it just produces it all for me, maybe. I don't know.

And I can't see what next love it is.

Oh, yeah.

But then okay. What's this gotta do with Salesforce?

So again, is it? I don't know. Who knows? I don't know. Any ideas? Could be things like.

Well, actually, we understand how users are using Salesforce. We have all the log information. We have all the data the records changing in Salesforce. We have all the unit tests.

We have our automated tests. We have all this knowledge around how Salesforce is being use. So what if I give the AI a target to say, actually refactor we know that having Apex running on different APIs is less performant than having everything all on the latest, right, and greatest. So give AI that goal of refactoring all the code to align to one API based on all the processes and everything else, I don't want you to break, but refactor it so it all continues to work.

Right? Maybe things like that. I don't know.

But it's giving, you know, targeted goals to the AI to do things for us. And so has anybody seen this? So this is basically saying by giving the AI the the goal of buying a pizza from Domino's, yeah, a regular pizza. And then it goes off tries every permutation to try and figure out how it's going to buy a pizza.

From dominoes until it gets to the result and it buys the pizza, right, just by giving that prompt right at the very beginning. But also I think that the change is gonna happen with UIs, right, that actually everything has been built, thinking about human interaction, right? To Salesforce, human interaction to DevOps, you know, get branches and strategies and things like this. But actually, if we're kind of making in UI and are we asking the questions and it's coming up with the graphs based on all this data, is all UI is gonna change? Is the way we test systems gonna change in the future.

Who knows? Any ideas?

Anybody got ideas. At all, I don't know exactly. It's kind of like thinking far ahead and trying to prepare for the future without even knowing what's gonna happen. Right?

And so that's really the last one is what is yours. Right? What what do you think is gonna be the future? And what do you think of the values of a dev ops engineer that can really add value to an organization and excel in it.

And that is all. The only other thing is I do have this, scorecard, which one of the I've I've how do you measure against a success salesforce architect, and one of those things within what I think as a salesforce architect's role is working with dev ops to create that foundational architecture of making sure that the Salesforce these processes and everything are as streamlined as possible.

So yeah, if you wanna try that out, it kind of measures you against each of the kind of different areas and lets you know how you score and gives you some advice as well. So that's it.

Thank you very much.

Left.

Francis, you have a little bit of time left. Oh, go. Is it a question? We're gonna throw throw it out for out for some questions if we have them.

Do we? Don't be shy. Who's got the first question? It's not over are there any questions?

There's always questions. Who's got the first one? What do you think what do you think a talented dev ops engineer in your opinion is, what do you think the most that the best values are to a dev ops engineer? Any ideas?

I don't.

These are just my subjective idea.

Hang on. I get your mic. Hang on.

Check.

Higher. You all hear me now.

I just wondered what your thoughts are on softer skills, selling the vision, because we might be all deep in the the weeds of technology that we love, but sometimes we have to tell other people what we do. Any advice?

Yeah. I think it's that comes back to the audience you're communicating too. Right? And and how you you describe it. And I find like, I know this enter ow.

It's enterprise architect who is absolutely brilliant. At just creating one pages that describe everything. Right? And and I think it is very much the softest, you know, even just presenting, right, and and targeting at the right people, and knowing that actually this person is most interested in world or their world as a developer.

Yeah. Stuff comes in, stuff goes out, but what's gonna help them and target it at you being in their shoes, I suppose, and the softer skills of that, but also just like how do you communicate that on one slide, right? So everybody is aware and aligned to that vision and that can get behind it and actually, you know, focus on it, which I is just a really hard skill, to do. But, yeah, and it's just that continual.

When I do the, the it's also presenting, right? And for the, community groups, you get people actually one of these is, convince, like how do you convince stakeholders and different people in different ways? And a lot of it is, you know, standing up and talking to people. If it's a small group or a large group, and we have, the community groups, the five minute feature, right? So if you're not a bit nervous of tanning up and talking people. Well, actually let's just do it for five minutes in a group of community members that are very forgiving first so you can pitch your idea or some feature, like it's only five minutes. If it's a disaster, it doesn't matter if it's great, brilliant.

But then you can slowly build from there. So it's starting I think with the softer skills, and then slowly building up so you get more confident in doing it.

Any others?

Do we think that Salesforce? Gah, how are you? Oh, I'm gonna run run. I'm coming. Is the Salesforce UI gonna completely change and break We passed it? Use a automated user test. So who knows?

Hello. Thank you for that. I just want to ask. I'm surprised or wondering if you'd include a another c on that slide for coaching.

I've worked with a number of architects over the years. My background's an admin.

And one of the best that I've worked with is where he actually spent a lot of time coaching a team of devs to think like an architect and that kind of succession planning Yeah. Absolutely. And I I think it's that mindset, right, of getting things. And I think, you know, with architects, you get very lost in the tech.

Right? And it's about pulling out of that. And actually, yeah, my team, I remember there was a call that I was on and we kind of invite our you know, team members onto it, and one of them was a junior, and she came after and after it, she's like, oh, my word. It was a light bulb moment in that call because the customer is asking, we need a validation rule to do this, to do that, and we did these fields and stuff like that.

But actually, it's kind of don't allow them to see get to the root problem and identify what it is and then realize that none of that is needed, right, and actually could do it in a completely different way, which requires no work. Right?

So I think it is that definitely coaching if that training. Actually, I didn't mention it on the learning, right, the the the best learners and best people that really wanna learn more actually teach because they want to be in that mindset. The best way to learn about a subject is to teach it, right, because you're forced learn every little caveat of it. And if you've got an audience of a load of people asking you questions, then you need to know the subject, right? I remember at Dreamforce, we did Dreamforce live, which was basically a room of five hundred people asking us questions about the platform. It could be anything.

A little bit scary, but you need to know your stuff. Right?

But yeah, definitely a good question. Thank you.

Yeah.

You bought test classes, then they get covered in some stuff, but there's a gap where, you know, when it comes to testing the functionality, UI testing is very brittle. Yeah. Things like selenium. Okay.

They break as soon as Salesforce updates and, a tag name or ID or anything. Or if there's a time out, it just logs a fail rather than Yeah. And you can kinda, like, prove our kinda gets around some of those, but not everything. Right.

And I AI, how does AI, can AI help make that a lot smarter and, you know, kind of I think it's like how AI requires data, right? So I think it is maybe, right? It might be that if we're recording all the interactions of the of the users and understand how it's being used, that then actually, the AI can be more smart around, actually, we have got all those end to end processes all in the AI, right? And it's finding that actually these things are broken and these have not, or when the UI does change, that it's changed for everybody and what the impact of that could have, right, and dynamically update all the, you know, unit tests because that one element has changed.

Now we've changed it to something else, and it cascades through everything. But I always have had the, you know, I think everybody has this kind of love hate relationship with automated testing, right? Because it is like how deep do you go or how, you know, and and how, you know, you don't wanna be, you know, refactoring a u test or your your automated testing more than actually doing development. But you need to find the balance, right?

So yeah, hopefully.

There might be something in the future, and this is it. It's like maybe that whole unit testing kind of disappears. I don't know if you, you know, the this is how we expect it to work in other Sandboxes before push it in production or you're doing experimentations for a small set of group of users before it kind of goes global across in your Salesforce org and you can kind of structure it in that way so it can learn and know if something breaks or not. Who knows?

Oh, yeah.

Oh, online audience question. So what strategies have you got for addressing that silent Oh, the wick. Yeah. Yeah.

Yeah. So it all comes about what's what are the strategies around the silent killer, which whip. And actually, I always relate it to, you know, when you're doing the cam band view on opportunities, yeah, and you get all the cards appearing, Right? You can kinda sometimes just see it.

Right? Because in Jira or whatever it is, you can see this backlog of tasks appearing at different stages through the the pipeline. And so for that even in a salesperson. Wait a minute.

We're getting loads of, you know, opportunities stuck at this point. It's very visible to you. And I think for the big problems, it's gonna be evident from that, right? But then the smaller issues, when you start kind of going down, the constraints.

It gets harder to detect this, and then you've gotta start relying more on the data.

Like, for example, having a load of whip at the, you know, stuck at this workstation, that's if it's stuck at that workstation, but it might be that the sense, just pinging it back, like, any more info, any more info, leave me off in. So it's not evident that it is stuck at that workstation, right? Cause just pinging it back to the devs because they just want to try and push as much work off themselves because they're completely swamped. So I think this is where it comes down to kind of empath guys in talking to people and really understanding how they're doing work rather than them giving Oh, yes.

We do this. Oh, yeah. We do the testing. Oh, yeah. Absolutely. And then we push it.

They're always doing the normal process, the best case, the happy, happy path to the system, when in fact they're struggling, they're having problems, and that's not immediately evident.

Perfect. Francis, thank you so much for your time. France, of course, France, everybody.

Thanks a lot.

One moment. Hello. Hello. Hello.

How's everybody's day going so far?

Whoo. Oh, we got one more at the back. I think that was Rob manning, manning the online online staff. Hello to all the folks online.

I hope that you're enjoying, as just as much as we are in person here today as well. Very pleased right now to introduce you, to Matt Evans, senior developer at Payrock, and to my esteemed colleague, Piyacht, who is going to be talking the DevOps journey at Payrock. Gentleman take it away. Thank you so much.

Cool. Thanks, Jake. Yeah. So welcome to our tool dev ops zero to hero and how we, me or our team at a rock implemented dev ops.

Quick introduction between for myself then. Senior, technically a senior engineer, but it's a developer role. Been at Payrock just over two years now.

For, yeah, I've got a couple of certifications behind me.

Probably see me a lot at the London user group. So I'll go to the admin's devs, one of the co leaders of the data tribe, but I also try and get to as many as possible.

And an interesting fact that most people don't know is I'm a dog trainer. So I spend my Sundays on a field, taking a class, but also training my two Veegals that I've got. Piyot, Joanna? Thanks, Matt.

I'm Piot. I'm a a product manager at Giset. I've been at Giset for nearly two and a half years. And, yeah, we've just been working with hundreds of teams, to help them create and deliver Satorre's faster and provide more business value.

Quick disclaimer, we're going to do a sneak peek alternate coming, an upcoming feature. But please make any, purchasing decisions based on generally available software as you always, the the motor is a trained inflows. So what?

Could you say a few words about Payrock and your team? Yeah. So Payrock, probably most people have not heard of the company. We're a fintech company who, provide payment solutions, for businesses, we offer things like credit card processing, point of systems, e commerce solutions, and various payment technologies to, our merchants, which are sort of the end shops and different bits like that.

Agents who we go out and sell our services, and then partners who integrate with our systems, based or head offices based over in Chicago, in the USA, but we have a number of offices, across, I've got, the UK and all the various different places in America.

We this I took this picture from the website at the bottom. It says eighty one billion, but we're probably more around the ninety billion plus transactions at the moment this year.

And a couple of brands that you may have heard of as well net payments, big in the gateways and sort of next gen is one of the brands in the UK that put in the credit card terminals in different bits like that.

About my team, so we're a quite small team. I will refer to us as a small team, six of us, as you can see on the screen, mainly responsible for Salesforce and an assistant called Agreement Express, which is, like DocuSign, it's an agreement signing tool.

We work in sprint.

So two week sprints currently, but we don't we let wait till the end of the sprints release, we, so we're pretty agile in that we'll get things out as soon as as soon as they're ready and that's been signed off by the business.

So yeah. Thanks, Matt, for introducing Payrock and your team. Could you paint us a picture of what sells deployments look like before you implement it, that that website payroll? Yeah.

So I suppose we started about a year and a half ago, on this journey was that we, had a slightly different team, because what we have now, weren't just in the process of introducing sprints and formalizing our, cadences to get things out a little bit more quicker.

But we had shared sandboxes.

No source control or any tracking of changes, and any big release we had meant we pretty much span up a new sandbox.

And from there, we were sort of juggling, having to see what we hadn't released, changes that we had going through the pipeline, where there was dependencies, meant that we had to either include them in our deployments.

And, yeah, we, and or we would have to until whether a a sort of a situation where we could actually, get them released as part of a bigger piece of work work.

I suppose at the point, some points we were overwriting each other's because of the shared sandboxes, if we'd someone else to sign up a new sandbox, because they needed to be a little bit more in sync with production, they could deploy like a page layout or something like that, which would over right someone else's change, but we also have the problems where someone has included a new field and a page layout that, obviously, the dependency problems, and you then had to include that field, which you not have wanted in your releases.

So as you can imagine, we started stepping on each other's toes that came a bit of a nightmare. Oh, Stephanie.

So it's clear that your team, wasn't following a single process, and everyone was using different bits of tooling.

What sparked your search for a dev ops solution?

Yeah. So at Payrock, we have, initiatives, like, back then it was Hackophones.

So twice a year, we would get together when we had the opportunity to doing what we would do, normal user stories day to day and look at something that we could add value to the business.

And so, I suppose the very first hack form we went, okay, we're not we think we can improve our dev ops process or dad how we deploy. And so we started on setting some goals, as you can see on the screen, things like, one process for all.

We as a, when I sort of mentioned one process for all, we had in, we're getting a student placement who was out of university. We hadn't touched, Salesforce. So we wanted a process that could they'd be adopted by someone who didn't really know, Salesforce and things like, mezzo making it easy, from there.

And, version control, sort of the Jira integrations, different bits like that. And so once we've set these and everyone agreed to them, it was just probably as we're setting up the, what we were going to do as part of the hackathon, I had previously used geyser, or had some experience of it at my last company. And so I've recommended it to name.

So we went out and or I've got in con putting a little quest through on the website, going to the sales team, Benny. He's here today. He doesn't appear to be in the bright yellow shirts. I don't know how he met manage that, but he is around. Go bug him if you, what have any questions about Gisa, but, we got in touch with him, explained what our goals were and how we had three days, for the hackathon, to try and show a value from what a new Devox process could incorporate for us. And, so we agreed, so the first day of the demo.

I suppose, we got into it.

We had a little look through the various, features of gear set, because gear set has been around for a while. There's came with a lot of features.

And from there, we'd quickly implemented pipelines, which was in beta at the time, with some trial sound, some, not trial sandbox. We've had Sandboxes set up for this little hackathon, and the team started to use the tools to try and deploy the changes through the pipeline.

As you could imagine, a DevOps process, trying to go from zero, which pretty pretty much had to a fully blown ups process where we I pretty much had, your at that point, we decided for every bit of metadata we had in our logs in to Agate repo.

Had a few problems along the way. So, things like the comparisons and the CI jobs just ran slower because it was having to do more.

So if I I suppose the conclusion after the three days was, yes, we own some value of used, implementing this, but it wasn't as good as, I, I suppose I'd promised the team, or I was hoping to, get of the team, but also, it we thought there could be something better out there.

Sorry, I suppose we showed the initial value of having a more formal process, but we decided, okay, gear set is better than we had, but there could be better tools out there. For sure. So it sounds like your initial, introduction to Geesett as part of three day hackathon didn't go quite as planned, but you persisted and you changed your approach.

Could you take through what you did next? Yeah.

So as, as we, like to do at Payrock, we have bake offs. So when we have a new product that we're also a new something new we want to introduce. We don't just go out and go that's the that's the tool we're gonna get. We compare what tools are out there. So, as part of, the, obviously, the little bit of knowledge we got from the three days working with Geer.

We decided to look what else was out there, so blue canvas and Capado, Salesforce were just releasing DevOps Center at the time, and that obviously many more out there, but we decided to focus on some of the bigger ones that, had gone out there.

Also looked at what metadata we thought we it in version control, tools like this, you don't always have to put sync in version control. You can't just deploy them, using, like, auto log deployments. So we sort of decided, okay, things like custom objects is a must. We want to track what changes we're going through on there. Apex classes flows, method custom metadata, email templates and things like that, were all things were sort of the big things for us at that time because we were in the process of onboarding more teams into Salesforce on the service cloud.

So we wanted to make sure we did that. But we also to make it fair on when we were looking at the other tools, we decided we'll have some set tests.

So, we wanted sure we had simple tests, things like we wanted, to make sure that we could change a field, and things like the label of the field, the size of the field, the pick list values, things like that, pretty standard stuff. But as part of our DevOps process, the permissions was quite a a thing we wanted to incorporate. We didn't wanna have to deploy and then have a load of manual steps of having to say this field need to give this permission to all these different users. So we wanted to make sure the tool we selected could easily deploy things like permission set.

List fused, flows, the standard sort of stuff, but the more, I suppose, other bits that don't often think about is maybe destructive changes being able to remove the tech debt stuff. You don't want to leave it in there in your source control. So things like that. And we wanted to be able to keep this process in sync.

So where I sort of mentioned we had shared term boxes. We wanted to give ability to, our developers to have their own sandbox, so they didn't have to tread on each other's toes. And so having that process where we could sure everything is in sync, and we can see where a change was was quite important as well. And then we also wanted to really, give the solutions a good test by looking for things like dependency, test. So if we deploy this flow, which references the field, a new field, that the developers forgot to adding the, the metadata, we wanted to see if the tools would pick that up.

Things like, and also conflicts. So if two people, two of our developers were working on the same class or something like that. We didn't want them one just to overwrite each other. We wanted the conflict resolution to come in as well.

And because we're working trying to be more agile and work more efficiently, we wanted then be able to group smaller user stories into a bigger release.

So as part of that dev ops process, we Slide off with Blue Canvas.

And if you're new to DevOps, this tool is probably the simplest one to implement. Out of off the shelf anyway.

So, blue canvas is, you basically sign into it. You connect your orgs, and as part of you connecting that org, Blue Canvas will go out and sync every bit of metadata to it. It's own branch within their source control. So you don't need to worry about your own repo or anything like that. New canvas sort of did I think about, for it yourself, things like, org branching strategy, so blue canvases had its own. So it was an org based, branching strategy, and because that's in their own repo, when you came to do changes, it was a branch, the branch comparison. So it was super quick to do be able to pick the metadata, you could then cherry pick the metadata because you could see exactly what had changed, but that also, had its sort of negative size because you had to wait for Blue Canvas to sync, with that org to then see, that metadata changes.

They have got that down to breed quickly now. But sometimes we've found that, the we had to clone deployments for it if you already started a deployment and realized there's a bug in that I need to re redeploy something, you'd then have to clone it for it to then do that branch comparison again from from the system.

And one, I suppose, one of the other problems we had was lighting email templates. We're big on bringing the new team in at that top point.

So we needed to, as part of that team, being onboarded to Service Cloud, we were trying to deploy, email templates to get so they could get up to speed quickly, and we just couldn't do that in Blue Canvas for whatever reason. I must say these teachers, this was a year and a half ago. So this might not be the same now. So if you want to go out and test, test it yourself, and see if it's still there.

Permissions and permission sets, could be deployed, but it was they had a separate tool which sort of try to incorporate into their product. So it's you could do it, but they weren't properly grouped with, with the change that you were deploying.

So from there, we went on to Flayson, so Flayson, is like, a little bit like Capardo because it lives within a Salesforce org.

I think the difference I think you can do it with Capardo, you could, by default, I think Fosum will spin up a separate org so it doesn't live inside your production. So that was a positive because we didn't worry want our dev ops process to live inside our production org.

But, I suppose it was some a simple setup because it was just connecting the orgs again, and it would sync the changes. They seemed quite quick as well to pick up the changes.

So the with, flow some, their branching strategy, that we were testing was, you a story. So that user story that you build as part of the deployment, you pick the metadata and that user story would then just be deployed to multiple walks. They'll obviously see what conflict resolution, you sort of enclosed something that sort of had a load of buttons at the top that you would work your way along to deploy, and there was just a lot of buttons and, different bits like that.

So rollback was super simple, and there pipeline process at the time was more of a I'm gonna configure these number of steps, and if it the successful deploying at one point of in that step, it would just then go on and deploy it to Nextorg and then Nextorg. So you can quite quickly take a change and deploy it quickly, through the various systems.

But it wasn't something you could, have, I suppose that control of I want to deploy this in this org. You'd literally have to have a different pipeline process for different points of that.

But it did allow automatic deployments as part of that. So feedback from our team and And myself, obviously, we found the use of interface a little bit clunky because it was inside a Salesforce org, so they're limited to the Salesforce UI, and we know sometimes that's not the greatest.

Integration, integrations, so integrations to it third, pie systems like Jira.

Actually, you know, igrations like PMD, I suppose it's the one I was referencing with that comment, is was required manually setting up. They weren't, and if in when we were doing it, we had to spin up a Heroku instance to actually, there'd be a get it to be able to and the code that we were deploying.

So it was a little bit more clunky, required more manual steps in the setup process. The Jira integration was there.

It was about the formatting that went back into Jira that added which I did teams, would you look at, see where we were within our delivery cycle just wasn't formatted as very as nice. It didn't really give a nice feel. So that was, like, we weren't, peed on too much, but, the Microsoft team and we're a big Microsoft Teams user, and we're all, work remotely.

So teams notifications when something's being deployed is sync we wanted, and there was no team's integration out of the box. So it would these have to sync. We've had to custom build.

So yeah, so on the back of that, so we saw that's two other systems we looked at.

We also did look at Capado very quickly, but obviously it's, quite an expensive solution. So, and it also to keep the cost down, you would deploy it into your production.

Or so it wasn't saying we really looked into much further after that.

Dev ops center, I said, was quite new at the time, did install it, but we found that once you got past the initial stage, of, like, once it got into after UAT, any changes that are being deployed into UAT, then got bundled into their package.

So you couldn't then say, I just want to deploy this change into production that might have changed since, but we, it was, yeah, something we, came, it wasn't as some we wanted, we wanted that control of what what we deployed into production at what point.

So during this process, Benny, the sales guy, was still, in contact with us at Geerset.

So on the for our conversations, we decided, let's give gears at another go.

Taking on what we've learned before and, what? So, as you can see, things we liked about Clearset, well, obviously, it was a separate web app, and the user interface probably is the most intuitive, for us anyway, we found to how do you deploy it. It was, yeah, nice and simple, bought in feature branch is, which would obviously we had, we've seen before, which obviously a feature branch is normally linked to a user story. So you could easily see where that user story was within the pipeline.

You have this is pipeline view, probably a little bit small on the slide, but, that pipeline view, you can see these little numbers by the orgs in that, and that shows what user stories are waiting to be released, or what feature brought features of Paul requests are waiting to be merged into them, orgs. So it's very clear to see what your, orgs, if they're missing anything, what they had still waiting to deploy, and it's easy to, obviously, deploy that stuff in.

Obviously, other things, that were good, you could still do auto walk deployments. Anything we decided that weren't part of our source control, and our continuous improvement and pipeline, we could then also just use gear set to deploy and have the ability to roll back that change it wasn't in our source control.

Integrations, so out of the box with Geerset, Jira, is, integration there, Microsoft Team, Slack, chatter, all was very simple to set up. And the other things to note is what the team noticed was that you have, release notes that pop up in in the corner of gear set. And so in the, gear set are very quick to release new features. And you could literally get notified when something else has come about. And if we did have problems, we could quite quite a very quickly jump onto live chat with a gear set support team, and they would talk you through, the problem help you jump on a Zoom call if needed to a screen share. And when we were comparing some of the support with the other packages, Set was the only one that had the live chat feature. All the rest was email and then wait for the support to come back.

So but we did still note, even with what we'd learned about comparisons, and we're only picking the metadata that we knew that needed to select comparisons were still slower.

So off the back of that the where we now, where GISET did come our winner. This is a little table we put together in Conference.

We're big advocates of pipelines, and we've done since we've just gone over our year, with gearset, we've done over nine thousand deployments over, thirty one year, probably about nine thousand five hundred deployments now since I pulled these numbers.

The eye jobs keeping all the orgs in sync were over probably thirty two thousand now.

And you can see a number of comparisons we've run is quite a lot. So yeah. Thanks so much for sharing your your experience, those, what a kind of on, and shall I say a delicious idea to do a Davos Beakoff?

It's also amazing to see how well your team has adopted the gear sets and the dev ops and how many deployments in CIGO brands you've done. Could you, talk a bit about kind of where you are with your dev opportunity at the moment and what's the next steps are for you and your team? Yeah.

So I would say I am our our big I'm gonna say, our focus, we're already with dev ops process. We always try and improve on. But one big thing that we're gonna be looking at next is, testing. We do a lot of peer review at the moment. So as, I'm the senior dev who comes up with a design for a lot of our user stories, whoever there's a couple of other design as well, but whoever does the design, at the moment, we're doing the peer review of what the developers are built.

We that takes us away from doing what need to do. So we want to try and, look at automating the testing, putting, the regressions test inside of it, build a test suite, with some automation and we're in talks with, some companies at the moment getting demos in. So quite possibly have another bake off, but it will be of the testing tools, but one of our things will be that we want it to integrate with gear cert, because that's deployment tool. So we want to make sure that once it reaches a certain environment that the tests are automatically kicked off and it can't progress further until then tests have all been completed and don't introduce any bugs that we know of.

Super exciting. Any any tips for team, that wants to implement DevOps, embark on that journey? Yeah. So, Obviously, one of the big tips I would have is start small.

We're a bit like deer in headlights with the hackathon.

Decide what metadata you want in there, look at what solutions available, and I will say, look at free versus paid because a free solution, isn't always the quickest to market.

And rather at the back is gonna be a French touch dreaming. I think he's got a talk on exactly, free versus paid tools. So you can always speak to him at the end, and you never know if you might get him of the user groups to do the same.

Time and effort is, is a big thing with free versus paid.

I've had experience where we to implement as our open source at my old company and ended up scrapping it and then go down a paid version.

Definitely trial them.

There is no, I would say there isn't one dev op solution that suits everybody. They they can even out of the box, some of them you'll have to adapt maybe some of your processes to, but don't settle on just the first system you come across and make sure the system has, room for growth things like Capado, if we didn't know Capado, Blue Canvas was a very quick tool up and running with, but we felt we would have hit a point where we couldn't improve our DevOS process further Adoption is key as well, to bring it's not just your team adoption. It's bringing your other teams on within the business, and making sure they know because, nor sometimes when you implement a new DevOps process, your cadence of deployment may go down, but, your as you're as you get used to new system, and you'll find you speed up again on them. So letting your delivery team know that product teams and the business that you're implementing a new way working is quite it's crucial to along for a successful adoption.

Training is also good.

The more you know, the more you can cater for things like, I think Jack mentioned it in his as well. Dev up's launchpad Trail headed as I named a few. Jack had a way more, Stephanie, keep that in on as well.

So yeah, based on that PR, you mentioned some of new features that are coming? Yep. Yeah.

So, before I mentioned, before we talk really quickly about specific, specific features, just a few words kind of how we approach product development at Gayset. So we're heavily heavily influenced by our customers and then what they need and expect from a modern DevOps plot com. We regularly talk to hundreds of teams to find out if the most impactful products and features that we can build for and we've got one, one thing we wanted to show you today.

So, Matt and I first connected at the end of year. Matt mentioned that they were experiencing a slower performance.

Also, I think Maty really wanted make sure that, we can use source tracking, that Salesforce provides for monitoring changes.

Some of you are aware of that feature that you can switch on in production.

And the so the timing of that conversation was perfect because were just doing research, with our customers to figure out how we can speed up the performance of comparisons.

So that people can build their packages much faster.

So we jumped on a couple of calls. We showed you some early prototypes. And, really excited to show you. It's a sneak peek into a feature that's going into a pilot soon.

Hopefully, the demo will auto play. Cool. So this is actually Matt running it now. He's he's got a feature flag on his account.

He selected an org as a source, and that F Branch as the Target, and we now have this slightly, new workflow here. And, Marty's picking source tracking filter option that's, that's actually connecting to source tracking API, pulling only just the changes, so this is much, much faster and those changes have been compared in place against the target. And you can see on the right different types, method to types, kind of appearing in black, that means they compared. So, yeah, this is a new workflow we are working on.

It's going to an open pilot, in the next few weeks.

So, watch out for any announcements, and you'll be able to take parts. And hopefully, your your comparisons will be much, much faster, this way. So I think you select in custom field at this time, and as usual, just go into the problem analysis and some checks before deploying it. So Yeah. Super excited to show you that. It's, first public appearance.

And, just to mention, to find out about the products in features we're building. We've got a public roadmap. It's published on our website. We try we updated quarterly, trying to show you that kind of the quarters and the things we are working on. So we've got a bunch of new cool stuff coming out. It's at Guesets dot com road map.

Yeah, that's it. And thank you for coming to the talk. Yeah.

I'm not sure think we've gone over a little bit. So, if you have any questions, just come grab us, we'll be happy to answer them. And also, we answering online questions after the talk So if you had money.

Thank you, Pierre, Matt.

I think that, all that talk of Bake Off has made us all suitably hungry enough. It is now lunchtime. You'll be pleased to hear. So thanks for priming our stomachs for such a feast.

That is upstairs in the river room in the exhibitor area. The same place that you would have got refreshments before, and we'll all be back at twelve forty five for the final keynote of the day. We will see shortly. Thank you.

Yeah. I can project a bit.

That'll be alright.

Way we work to be done.

Let the music play.

Everybody in the street.

In your heart.

Let the music take control.

You may You made me return I know what to do.

Oh, I'm not so warm and tender.

Oh, no. I know. How not Brown cow. Woo hoo.

Alright.

How's everybody's lunch? Good.

Thumbs up. We got thumbs up. We got some small chairs.

Looks like we have people just filtering in, so we'll just let that start to happen a little bit more. Are people coming? People coming? Cool.

I hope you're all having a marvelous day. So far. It's been an absolute pleasure to have everybody here with us today, both joining us virtually, for the hybrid event as well as being here in person.

Really excited to bring you the next talk, from the fabulous Mary Williams who is going to be talking to us about how to make cultural change real and stick in our businesses. So, without any further ado, Mary, I'll let you take away. Thanks very much. Is this working? Just about there we go. Cool.

So hi, I'm Mary. I'm, originally South African and I grew up as a hardware hacker.

But, these days, I'm more on the software side of things. CTO Plio also the chair of the lead dev conference, which is a technical leadership conference disguised as a tech conference.

But today I've got five lessons for you about making cultural change real. The first is that dry doesn't work for human communication.

Don't repeat yourself as a great programming principle, and I'm from a Python background So it's, one of my favorites.

But it's a terrible human communication principle. Research shows we have to repeat things up to seven times before people really hear them.

And so they also don't know what they don't know, right? And so it's about helping people realize what they don't know, helping them hear the message over and over again, because the only thing that developers produced more of than code as conspiracy theories in the absence of information.

To be clear, be consistent And remember that you need to be bored with what you're saying before people will have even vaguely heard it for the first time.

And remember that the standard we walk past is the standard we accept. So if you see things going wrong and you don't call it out, it's gonna make things worse time and time again.

And remember not just to communicate in the present. I'm a big fan of architectural decision records because they're communicating with the future about why we what we did at a given time. If you've not come across ADRs before, there's some great stuff written online, about how to use them really well. But essentially what you want is for when your system is legacy because it will become legacy one day, maybe sooner than you hope.

You need people to be able to understand why you made the decisions you made and what you were thinking at the time so that they can figure out whether they can change that decision not. I've worked on systems older than me. I've worked on systems so legacy they were vintage, and I wished so much that somebody had told me what the hell were thinking when they made that decision thirty years ago, in order to be able to to decide to change it.

The second thing I've learned about cultural change is that high performing teams need you to create conditions for success.

I remember becoming a manager was definitely somebody who was better suited for saying an IC an individual contributor.

But I remember becoming a manager and knowing that I hated bad bosses, you know, the pointy head boss in dilbert's funny because it's so relatable. Right?

We think of bad bosses as clueless empty suits point They practice the seagull style of management, fly in, shout at everybody's shit on everything, fly away again.

And so my my base response was, oh, that's pretty sad. This is the best cat gift on the Internet, but sadly it doesn't seem to be working today.

But essentially decided that if I had be a manager. I refused to be bad at it. And so I went looking for what, good management looked like. I like this from Katarina Fake that at minimum, try to be the bullshit umbrella. Don't be the bullshit funnel who chooses who they like least and concentrates it all on them. And don't be the bullshit fan, just it all around indiscriminately.

And so because I'm a nerd, I like research, and so I went looking for research about what made high performing teams. And this is my favorite management book, which I appreciate makes me a real nerd.

But it's my favorite because it's immensely database. Interviewed eighty thousand different managers. They looked at four hundred different companies, and they went looking for what made teams high performing what made them happy.

And they found that there were these twelve questions that predicted high performance. Now I know my reaction to a slide that terrible is great. Now I'm drowning in information I can't use. So let's zoom out for a second. Has anybody read Drive?

Pink's book about motivation.

In that, he basically says that we need three things to be motivated. We need purpose, autonomy, and mastery.

We need believe in why have a say in what and be proud of how. And then you take away any negative factors that detract. If you have the worst, commute in the world, maybe it won't be made up for by these, these three things.

But those questions that we, looked at briefly a second ago fit very well into that. You know, are you proud of the mission or purpose of the organization that you're a part of? Do you feel like your opinion counts? Like, you can shape the work that you're doing. But then a huge number of these questions are about mastery, about feeling like you've got what you need to do your job well, feeling like you get to do what you do best every single day, that somebody cares about you at that there's these, opportunities for you to to learn and grow that you've like your colleagues care about doing quality work, even. Right?

But there's a few questions missing. In the last seven days, have I received feedback or recognition for good work.

Does some does my supervisor, it's very nineties, right? You're not my supervisor. Does my supervisor or somebody at work seem to care about me as a person? And do I have a best friend at work? I like this last question because it's say masterclass in cultural differences.

In America, apparently, that's a perfectly okay question. In Northern Europe, the responses like fuck you, the company doesn't get choose who my best friend can be.

So I will translate the last question for all of us who are more Northern European.

It's, is there somebody at work even if the company isn't paying, I will willingly spend time with. Okay? That's how you gotta gotta hear it. And this is really about being expected and rewarded.

So Camille Forneier refers to this as community. I I call it inclusion.

And so, the predictors of high performance essentially add up to these four categories. Purpose, believing in why autonomy having a say in what, mastery being proud of how and then inclusion, feeling like you belong.

And my based premises that our job as leaders and certainly everybody who's managers, their job is to create a space in which that work can happen really well.

Because every person and every role is capable of virtuality, I genuinely don't believe wake up in the morning thinking, today I'm aiming for just south of mediocre.

And if I can fuck up everybody else's day along the way, my day will be perfect. Like assholes exist, but I don't think they're very common.

The third lesson I've got is that inflection points really later. Semperon and Excusem said Altois, Verouand is Latin for always in the shit, just the depth varies.

Which, you know, one day I'll get tattooed on myself.

And different things come for free at different inflection points. I do a huge amount of work with startups and scale ups, and they find a lot of the time, they're trying to look at Google or Amazon or Salesforce or, you know, these huge companies and copy them. And like, you're like fifty people in a room together. There's no way that their problems are the same as your problems.

And so be aware of the actual problems that you're facing and try to find companies and people and groups that are twelve to eighteen months ahead of you. Try to find people who are just that little step ahead of you in the cultural change that they're making in the ways of working changes that they're making and learn from them. Rather than looking too far ahead and trying to optimize for something that isn't even your problem yet.

How yourself realize when you need to make the next tiny step rather than trying to to go too far too fast.

And focus on the right problems at the time. If you're just starting to get CICD working in your organization, then you're your real problem is getting people to let go of their very closely held change approval board, I imagine.

Approval boards. They are, they're the equivalent of scar tissue for organizations.

The change approval board list tells you every major in that has happened in the history of that company or in the experience of the people who wrote the lists, past, past world.

My fourth, lesson or in Obsurability matters a lot more than testing. It's really difficult to test people changes ahead of time. Sometimes you can achieve it by doing a small pilot or trying to, figure out if you can, you know, change one team at a time or whether you can you can make some, some some change in just a a limited way. But however well you plan, however hard try, sometimes the impact you have might not match your intent.

And so regularly check whether what you were trying to do matches up to what actually happens.

Retros are a really good way of doing this. I'm, I'm sure that you've all been exposed to different types of retro. If you've only ever been exposed one type of retro. Please for the love of god watch this talk. It's from Jesse Link. She's a senior director at Google now. She was a BPO engine Twitter before, and it's a really nice look at different retro formats that you can use to help manage whether you're help help keep track of whether you're team is changing in the way that you want it to, whether the process changes and people changes you're making are having the impact that you want them to.

There's also things like Spotify's squad checklist that you can use to keep track of whether the the changes that you're making are are happening in the way that that you want along the way.

The list down left hand side is obviously just the the things that Spotify cared about at the time. If you ask them today, it's a very different list, although they still use something quite similar to the squad health model.

And then you don't have to take any of these tools. You can sit with your team and articulate what matters to you one on one. This is from a talk called People are weird and I'm weird, by a guy called Sam Sam Barnes. And it's all about every single retro every one to two weeks, checking in with the team about whether the things that mattered to them were really happening or not.

Probably the most important thing that I want you to take away today is that culture ad matters a lot more than culture fit. We talk a lot about culture fit.

And when you're hiring, when you're bringing people into your team, when you're trying to figure out whether you who you promote and who you don't, it can be really tempting to look for the people who are just the same as what you've got. But we know from huge amounts of research from a lot of real life examples too, that homogenous teams don't win.

Not as innovative, they're not as profitable, they're not as high performing. And so we need difference, we need to get the most out of difference.

And we forget I think a lot, that the unit of delivery is the team. It's the team that achieves something together, not not very often just solo individuals.

I think a lot about that question in the twelve questions earlier, do I have the opportunity to do I do what I do best every day?

You imagine a world where everybody in your team could say yes to this question. You were using everybody for what they were really brilliant at. And maybe that's possible. Maybe the spikes that we have individually can be really well leveraged. And by our powers combined, we can a brilliant team with all of the skills that are needed.

We need to stop leveling people out to be just consistently mediocre. It takes a lot of effort to go from bad at something, to okay at something.

That time and effort is possibly better spent going from okay to brilliant or good to amazing.

If you can spend your time going from good to world class, that's probably better than going from shit to okay.

And instead of trying to wear away differences, trying to smooth everybody out to be exactly the same profile, maybe we can view different as a feature rather than a bug.

We need this sort of shifting perspective.

I really like this one if you haven't seen it for.

We're not interchangeable resource units.

And I tell engineers that if they're called resources by their managers, they should refer to them as overhead until they stop it.

We're colors or flavors were better in compliment or in concert with each other. I would watch the hell out of a seven hulks move but the avengers are good, are are cool as superheroes because they're different from each other, because they have different skills. You cannot send the hulk on widow's mission.

I mean, it would be fucking hilarious, but you cannot send the Hulk on Black Widow's mission. Right? And so What if we think of this rather than trying to get individual perfect employees or try to be individually perfect employees? What do we think of it as like roles and casting, who's best suited for the particular strength that you need, and how do those strengths combine add up to amazing performance at the team level.

How do we assemble a great team with complementary abilities?

I'm a massive fan of this, this movie. I don't know if you've all seen it. I got very upset at, like, man babies on the internet being being, like, shitty about women being in ghostbusters back in twenty sixteen. I this in Cinema eleven times, and I took a hundred people with me. There are somehow, there is an Odian data scientist somewhere in the who still doesn't quite know why Lesa Square ran ghostbusters for fifteen weeks in a row, but turns out if you fill the cinema once a week, keeps going.

But again, another team that is genuinely better for being different from each other.

In terms of how actually craft environments in which people can be themselves and be successful in which you can have this sense of belonging and inclusion. I probably talk for another day about how to do that. But I'll try to keep it relatively short.

I think people are asking themselves these three questions, whether consciously or subconsciously, when they're deciding whether to join, whether to stay, whether to say yes to a promotion, people do say no to promotions sometimes.

They're asking, am I expected here? Is someone like me even expect to be in this place? What does your company website say about the kinds of people who are and aren't expected?

I've got a physical disability. I'm I'm able to walk today, some days I'm on crutches, some days I'm in a wheelchair. I've never interviewed anywhere where I knew ahead of the interview whether I'd be able to get into the room if I was on crutches or in a wheelchair that day.

People would abilities are not expected in most workplaces.

We're not accommodated for, we're not planned for. And if you're team picture is all white or all dudes or, anything that is just one set of people. You're sending a message whether you want to or that other people aren't expected.

And my respect to here is about this thing I've said a couple of times, whether my differences seen as a feature or a bug.

And, like, I'm hyper aware of this. I'm the one the Daily Mail warns you about. I'm a I'm a foreigner with a job, which I think is worse than living off the state. But I've gotta kinda check the headlines regularly to be sure.

A woman working in tech. I'm queer and autistic and physically disabled, and my wife is British. I'm over here stealing your women and your jobs.

That joke is growing on her. After twenty years.

I don't often find people who are, like, a direct role model for me. There's not many people who are different in all exactly the same ways that I am.

But there are places that I've worked where my difference were a feature, and there were places that I worked that my differences were definitely a bug.

And that shows, and it's very felt by people who are who are different in any way, what the attitude is by, by folks around them.

And then this final question, can be myself and be successful here. Stonewall did a piece of research about twenty five years ago now that showed that people could be forty percent more productive if they could be themselves at work because it takes so much energy to pretend to be something that you're not. To pretend and act different and code switch or mask or, you know, whichever of the the terms applies to you.

And so when you're thinking about whether your your environment is inclusive enough, think about these three questions. What messages do you send about who is expected?

The number of startups I talk with in London who are like, we just don't understand why we don't have any girl developers. I'm like, you're calling them girl developers probably gonna answer number one. But the only benefits you have on your website is like beer Wednesday and and foosball Tuesday, that's not very surprising, guys.

Am I respected here? Or my difference is gonna be seen as features or as bugs? Is it going to be valuable or is it going to be something to ignore?

And then can I be myself and be successful? Is there evidence that people who are successful in company in this team, in this organization are different from each other in any way shape or form. And so sometimes you can't have a full rainbow compliment of ideal leaders that that you would like to have, but something you can do is make them seem more human and share a bit more about they are and how they've succeeded. And hopefully they've succeeded in ways that are different to each other.

That said, I've worked places where the leadership looked like they were wearing matching underwear to go with their matching ties and haircuts. So this isn't always possible. Right?

The funniest was a a group of guys, and they were all guys on the stage with matching ties and haircuts and everything else. And the company at the time had a big marketing campaign about doing things for first time.

It's going to be unfortunately easy to figure out who I'm talking about if you look at my LinkedIn, so don't do that.

And, they made the mistake of asking this set of leaders what they were gonna do for the very first time in their lives.

And the first guy said, cook a meal for my family.

And that was sort of the reaction.

And then the second guy said, the laundry.

And there was more of a, like, grumble reaction.

And then they stopped asking because they realized this was going pretty badly.

And I I happen to be sat next to the head of diversity and inclusion. I leaned returner was like, so Tina, what I'm what I'm getting from this is it's a really good thing that I have a wife at home, but she needs to stop with this designing a hospital's bullshit, my wife's an architect, and stay home and, like, cook my meals and do my laundry, right? And she was just sat with a head in her hands, like, cannot believe that they have said this.

But so even if you and and the other leaders around you are maybe quite similar to each other, try to find the ways in which you're different. Try to show those ways. Don't hide them. Be really explicit about them.

So in summary, making cultural change real is helped by these five things.

Don't repeat yourself sucks for human communication. You need to repeat eat yourself. You need to say the same thing consistently, clearly, and over and over and over again. If you're not bored yet, probably there are people in the team who still haven't heard your message.

High performing teams need four things to be high performing.

They need purpose, believing in why, they need autonomy, having a say in what, they need mastery, being proud of how, and they need inclusion. Feeling that they belong.

And if you can make those four things happen, if you can find those four conditions for success, then you can make teams really successful.

Inflexion points exist, so don't look for advice from companies that are way ahead of you on the journey look for the people who are twelve to eighteen months ahead of you and find out what they did when they were in your situation. They are the best sources of advice for you, not the people who are decades away.

With people, observability matters a lot more than testing, it's really hard to test people related changes. And so think about how you're going to measure success, how you're going to measure whether the process is effective or the people appier or whatever the outcome is that you want.

And then remember that culture add matters a lot more than culture fit.

If you if you do one thing after this talk, if you say, every time you're adding someone to your team, how will they add to our culture as part of your interview process? Then I think you y'all have gotten something out of this.

Thank you very much. I think we do questions now. Right?

Wow, Mary. Thank you so much. Cool. Thank you so much. We do have, a short window for questions if there are any from the audience.

I'm sure there I'm I'm sure there are many. Can can we all get time on your calendar or You can get through yes. If you can get through my AA, you can get time of my calendar.

Anybody.

Stung silence.

Nailed it. I think that's such a great presentation Cool, Mary, thank you so much for your for your generosity and your time. Thank you.

Okay. Regular programming will resume momentarily, as we wait for the next presenter. So, check your little leaf it, make sure you are where you want to be for your next session. And we will be back in a few short moments. Thank you.

Yeah. One, two, two, two, one, two, two, two.

Yeah.

Cool.

Can we hear?

Yeah.

Let's go pick up?

Wait. Mhmm. He could be here. Okay.

Okay. Probably not.

Okay.

Hello.

Following that, that whirlwind talk talk from Mary.

Hopefully Matt and Matt isn't Matt isn't too scared about it. I've known Matt for a long time. Matt is, as you might be able to tell judging by the t shirt, one of our fabulous, gear set employees.

Matt great experience working with teams, of all shapes and sizes, but has made it as focused recently to focus on the larger teams and solving problems for those large teams when it comes to our dev ops processes. So if you are a part of a larger team, or interested in scaling your team, then Matt is the perfect to be taking you through this next talk succeeding at scale.

Matt, take it away. Cool. Thank you. Yeah. Really hard to follow that last talk. One of my favorite favorite ones of the day to be fair.

But cool. Yeah, we can get kicked off.

So we're gonna talk about succeeding at scale today.

So a little bit of an intro to me.

Yeah, you can see him work for a gear set, of course. Been a gear set for about four years. Originally spent a lot of time on customer implementation patience. So, really diving into a DevOps transformation with the team and then spending time with them after, they become a customer. And, yeah, privileged to work with hundreds of teams over that time. Recently moved to work on the product side, work with them in a different way, still focusing on those larger teams. So, this is particularly on workflows around CST pipelines or, larger teams and how that that changes their workflow as you go.

So, intros, aside here's what I'll be talking out today. So first, I'm gonna explore the reasons why adopting DevOS prices on Salesforce can be challenged. We'll we'll come with some top level reasons. I'm sure there's there's hundreds more as well. Then we'll have a look at the difference team size makes as well, and why this can be more of a challenge as that team size creases.

Then we're gonna have a look, some of the tips that we've used to help these teams succeed when they adopt processes, along with some of the examples of some of the functionality we developed, which is helping a bunch of teams today. We're gonna have a look at some next steps well. So what do teams do when they they get into a good state as well. So cool.

We get started. So to kick off why Salesforce DevOps is challenging. At a high level, there's these three key factors always at play. So DevOps process is primarily about organizing the folks in your team, and this can be tricky to do on Salesforce because, you know, there's there's such a spectrum of technical backgrounds across the team, but there are no code admin.

You you still off with absolutely no development experience. You're a pro code developer, maybe full stack before and come on to Salesforce, or you're somewhere in the middle, you're an admin developer.

And you had to do both. And there's there's all these other, roles as well that come into play, especially with larger teams, where you get the technical release managers, business users at play, when you get into UAT, architects, etcetera. Everyone has slightly different requirements and needs, and this technical diversity poses a a bit of a challenge when you when you get into that that team size.

Secondly, we all know Salesforce as a platform, traditionally focused around clicks not codes. So the developer centric features have grown, a little bit more slowly around the platform than you would in more traditional software platforms. So it it comes with a number of and quirks, which means you need a bespoke set of tools for the job.

And lastly, the the cultural shift. So whilst DevOps has been on a decade and even longer in terms of the underlying practices, it's still fairly new in the Salesforce ecosystem. Over the last few years, it's really started to gain action.

So the cultural aspects to DevOps and the working practice involved, you know, in the last talk change approval boards and things like that. Sort of these practices are are still ones that, are around in teams, and and some of the devil's practices are are still willing to unfamiliar across Salesforce teams as well.

So we can start with the technical diversity challenge On a big picture level, your DevOps process, which should be a clear process for developing, deploying, and shipping changes, it's gotta inclusive.

It has to work for your whole team. You don't want to end up in silos, and creating bottlenecks around the least part of the row, the least robust part of your process.

If you have some siloed team members who are still making changes directly in prod, deploying org to org or manually back syncing between orgs, then you're going to suffer slow manual releases, and you're gonna tread on each other's toes as well, which is the worst part.

So we know this inspection of, technical backgrounds, and I'm sure some of you can see where you picture, where, like, picture yourselves where you, you sit on as well. So it leads to a bit of a split experience on the Salesforce platform where different folks have different approaches to creating changes.

So some folks on your team may have different levels of familiarity with source control and DevOps in general. And the biggest challenge we have with team when, you know, you have a bunch of developers who are really used in practices using git, and bringing those admins on board, and trying to bring them up to that tape technical capability is one of the biggest challenges.

The different groups across the team will end up working silos, whether it's by role, what part of the platform you're building, project you're working on, maybe the sprint team you're in. And this gets harder the larger the team gets because these silos tend to to get bigger as the more work you're doing. So with small teams, it's easy to maintain this consistent level of knowledge and technical capability, keep everyone on the same page, share between each other, but the the team gets larger, the number of folks at both ends of the scale starts to increase.

So as a result, you tend to lack a common and clear release process between each other.

So the second issue is around the technological barriers on the Salesforce platform. There's there's quite a few of these to run and get through every thing, but Salesforce is a a really good user driven platform, but it's traditionally hasn't really been built for collaboration, especially on the dev It's really difficult to see who's working on which items and features. It's common to step on other people's toes and overwrite people's change almost by design sometimes.

And for example, when changing or deploying really large monolithic XML files like layouts profiles, or just because you have a bunch of different dev orgs that's really hard to keep up to date with each other as well. Often this is going to be merge conflicts, arising, and they exacerbate over time as as as this drift happens.

And finally, there's also complex dependencies in metadata and API quirks or limitations. If anyone's ever used to change that, or or ever use the metadata API, you will have come across some some some sort of limitation over time as well.

At the cultural side, so I guess DevOps has been around for over a decade because it works. Teams using these processes work better together and move faster.

And one reason teams adopt DevOps process is to really improve communication and break down some of the silos that you start to see forming. So if you have development ops teams and release managers who don't communicate with each other, it's going to introduce some delays in your process.

If you have this proverbial fence that still exists where you kind of throw changes over the top of it for someone else to release They weren't totally involved with building.

You know, when when this has improved, teams release faster and more reliably.

This works best with, I'm more lightweight in team approvals, and a shared responsibility. And we heard some, if some folks were in the breakfast earlier, the Zurich team talking about how they bought kind of change approval boards into their into their team, rather than having sort of this external team who you always have to go through as eight, and we're having a shared responsibility of those changes. So if you can move as much of these processes into your team and as early as possible and if these issues left, you're not going to get surprises on release day, and you're going to keep the knowledge within the team as well.

So we're looking for a workflow which moves from separate silos. We're working in different sandboxes like this, an independent work by each role in the team.

To something much more inclusive where all team members are involved in the process. Everyone knows where stories have progressed to, how they interact with other people stories. And on top of that, having much better and closer communication across the team.

So These challenges are far from being unique to large teams.

They exist in teams of all sizes, when you're implementing a Devox pro s, but as this team size increases, they bite a lot more and they compound over time. So for a team of thirty, ensuring everyone communicate actively so that folks know what their colleagues are working on is a lot harder than it is for a team of three.

For a start, that team size will usually be organized into multiple logical teams in the business, and a single sprint team isn't isn't probably going to contain more than thirty people. So this immediately introduces these silos of information.

As a result, there's gonna be changes being made by folks on their user stories which others on the team aren't aware of or others within other pods in that team as well. And on Salesforce, there's gonna be more of a challenge as well because you've got so many cross cutting objects So profiles, record types, layouts, which can impact otherwise unrelated work, being worked on by others the team.

Sounds a result, you're gonna get conflicts that you'd see in git involving these objects. They'll come up a lot more frequently as team size grows. And that's even before you're considering kind of genuine conflicts between objects being made, in the metadata and Apex as well. So as this team structure increases, there's gonna be a division of roles too that we mentioned earlier, and this becomes a lot more pronounced. So work with lot of teams are three or four people where everyone has responsibility for their changes all the way to to prod, but I've seen very, very few twenty person teams for whom the same. Let's go. You've usually got a dedicated release manager, an architect, DevOps engineer, whatever the the the moniker might be, who manages the process of promoting changes UAT and production.

Which developers usually pushing their own changes up until that point. So for those larger teams, the volume of changes being pushed, so you can lead to changes in the release schedule as well. So most teams are work more than team members are releasing on a set cadence rather than just pushing features on demand.

And this can be due to a lot of factors, you know, end users, probably want to know what's being released on a predictable schedule as well. There may be an a change approval board example who, you know, there's a there's a set cadence you need to do that on, and maybe there's just some plane inertia in the team. You know, it's always the way we've done So that's that's how we do it now. So I guess how can teamed with this side often spread across multiple sprint teams in the company be successful in implementing a CICD process.

So the strategy we put out here for helping teams of all sizes set for success applies the board, but it's gonna be more important as the team size grows. So number one is assess the starting point.

Know who you want to bring in the price what their roles are, where they're happiest working as well. So this is really going back to some users are going to be living in VES code or version control system and be very, very comfortable with that. Others are gonna have only experience of, a clicks based guru to understand and push changes, others are gonna require a top down view of the whole process, you know, the release manager, the architect, etcetera.

Two, I think this is a common theme. We've heard from a few folks today don't move too far too fast.

You don't need to do a big bang of everything just to start getting some improvements. So if you don't have anything in version control and you're using change sets going org to org, moving straight to a fully fledged release pipeline in one shot, it's gonna be pretty hard to to do success fully. So start to define some of the steps you want to take in in the long term.

Number three, start adopting some tenants of DevOps culture, so increasing transparency across the team, breaking down some of the silos and and and having good communication.

And creating shared ownership of the core processes as well. So the onus is more on the the individuals who are building things together, to take responsibility together for, for moving them on and doing it at a high quality.

Shifting some of these processes left as well to be caught early in the process, so you don't get to UAT or prod, and start seeing issues there as well.

And for four and five, I guess one you've adopted these steps is vital that you don't stop. Elite teams are always iterating on their process and measuring some of these improvements. So you can understand how they're improving over time and a lot of this measurement around DevOps performance and team productivity, especially the last year started to come up as a topic. So understanding things like the lead time for changes, six rate for deployments, how much what's our failure rate, for example, and and what's our return on some of the investments we were making and projects is gonna be really to success as well.

So, to make the best best decisions, you need to know where you're starting from. Usually do this through, like, a DevOps maturity spectrum. I've seen Salesforce have one of these. I've seen many of our partners have their own maturity them. So, all of them kind of apply.

It's kind of, as as teens move along this spectrum from that to right, their their process is gonna enable some faster deployments. They have some shorter lead times, lower failure rates as well. And if things do go wrong, they can start to cover as well. But just looking at this, you're not really gonna know where you sit. You don't know whether you're a bike, you're you're a rocket, or a car. So, it's better to actually quantify a couple of things as well.

So a really good way to do this is through a door and mech rigs, developed by Google to monitor success of their dev ops processes, and as teams move from change sets to org to org deployments, start adopting version control, and then start relying on it as their source of truth, the cycle of releases shortens, or should do.

So, deployments which may have previously taken weeks of planning, are possible on demand or several times a day.

Time taken for a story to go from a developer's initial pull request into production could be measured in hours and recovery time from system issues in in minutes as well. And the success rate of deployment should skyrocket as well.

If your teams stood at those in stages there of adopting Devil's processes, again, trying to move everything to the the right hand side in one shot is unlikely to be a smooth journey. So picking out those met in your team that you could think you can move the needle on and what the next step would be, makes more sense doing an iterative approach.

Cool. So best thing to do is figure out where you're starting from, who you need to be involved in the process and how they want to work as well.

So this is something where, something where something like a pipeline UI would come in. This is making sure everyone's comfortable working in particular place.

Admins or users less familiar with Gitworkflows or terminology, they're gonna prefer a guru, which effectively translates functionality steps they need to take to progress an item, whilst telephone developers are probably gonna prefer to still work in via codes, get check-in, CLI, whatever they like as well. So they should be able to do that in tandem as well.

So yeah, pipelines becomes kind of translation this, helping users on the team have a common view of what's happening at different stages of the process all the way from those first commits and check ins through production.

So second step is starting small and scaling up, and the of sales was DevOps report, that we've spoken about earlier today as well. There's only nine percent of elite teams do, DevOps with a big bang approach. So it's it's important to realize that a big bang approach or doing everything in one step comes with a pretty big risk of failure. So DevOps involves a ton of different variables, whether that's team based, technological based, and it's better to use an iterative approach to implement DevOps.

So your organization you can focus on sort of continual improvements rather than trying to do everything at once.

So As we're moving through that dev ops maturity scale, we had version control as your source of truth as a pinnacle and the ultimate goal.

And it's a great point to aim for. And everyone, you know, in that case, you should just put everything into version control and start pushing changes when it's not, exactly what would happen on Salesforce.

That metadata structure means some metadata just unsuitable for keeping under version control. The source of truth will always be production. For example, some unretrievable via the API. Others like dashboards and reports, they can be environment specific.

You you you don't want your testing dashboards to be pushed straight into action. So starting to actually choose the metadata you want to version carefully and starting off with a core set can be a good way to go. So what we typically see teams that start out with version control is maybe twenty five to fifty metadata types of very core config, and code as well. And this covers the vast majority of changes that they want to push through and you can start to build on this over time.

There's a couple of different ways you can actually deploy changes between environments automatically. We recommend for some teams for performance based over APIs, looking at something like a a Delta or commit by commit deployment.

This way you're confident that only the changes that you've you've committed or updated, go out to the org. But again, there's different approaches. Some people like to do a complete. This is the branch, and that's going into the org, so it's up to you.

Cool.

The next piece as well is don't feel like you need to have all the possible environments in the process from day one or have a really complex branching environment structure, adding new environments and branches and sandboxes into your process should be easy later on to then complicate the process where you don't need to. Later down the line, you can just create branches from master. You can link environments to them, add them into the process if you need to.

So starting small also applies to you as an individual contributor as well.

So when you're, creating feature branches, committing changes into them, you wanna keep feature as small as possible. You want to minimize the chance of hitting merge conflicts. You don't want these huge sort of, huge combined units of moving up together to reduce risk, ship small and often.

For many metadata types, including layouts and record types, where with something like earset, you can deploy just the parts of the objects that you'd want to, which which solves some of the issues for those huge files that you would see. So it's easier to avoid the conflicts in first place, but Apex code is another case where it's good practice reduce the size of classes being used. The smaller the classes, the less likely it is that multiple users are gonna be hitting the same objects.

So arguably the most important stage, adopting principles of a DevOps culture and shifting left. And this is summed up nicely in this quote. I think we always use this quote. But if you're able to test early, get code in the first environments, get it under source control and understand conflicts and issues at the very first stage. The chance of having items failed later in the development cycle is going to be dramatically reduced So it keeps the onus on those folks who built the thing again. You're not sort of throwing these things over the fence for someone else to fix and make sure that they they have responsibility to to solve the issues in moving forward as well.

So, there are many aspects next to how Salesforce teams can achieve this from improving visibility of changes across the team, dealing with merge conflicts and keeping environments in sync through integration with project management tools like, like Jira, and defining a release schedule that works for your team. And these are some of the primary areas where the functionality, that we built comes into health teams, adopt some of these practices.

And I'll share a couple of the tooling and workflows we've enabled for these teams as well as some of the pit fours. I've seen them encounter over the last couple of years as well.

So the first piece is visibility the team. It's important for everyone in the team to have a common view of the state of the world. So across your team, your release manager, who's gonna need a high level visualization of all changes in flight, include reading the merge status, conflict resolution, validation status checks, work item tracking, all those good things.

And every member of the team needs to see where their stories are and kind of in the format that makes sense to them as well, and how they interact with the work being done by their teammates as well.

So it's where something like, yeah, pipeline's UI comes in. Give me that view of well. Stories are all parts of the process accessible to all team members as well.

Next, we should probably talk about merge conflicts.

They're not an inherently bad thing, but they do stop you from overwriting someone else's work without asking them. And making sure you're working constructively together as well.

It's gonna be really important to flag up these genuine merge conflicts that can be resolved in the process and that way users can talk with each other early and resolve them before they become a much bigger problem later on close to production.

So having having some sort of, UI that people can understand to resolve these conflicts together makes sense. But again, they're still inherent problems when folks, from an admin background who are coming into version control for the first time and looking at conflicts in an XML file is even, you know, it's it's something to bring the team along for. So finding a way to easily do this together makes sense.

A bunch of conflicts as well that you normally get in git down to git not down the structure of XML so well said they might see a conflict between two elements which actually were unrelated to each other. So, we built a semantic merge algorithm to deal with that to sort of take away or not even highlight many of these conflicts that you would actually in your Git provider.

So looking for something that has Salesforce specific knowledge can really help reduce a lot of the load on the team as well.

This one's a perennial issue.

Really key cause of problems in the release processes drift.

It's not totally hard to stop, but if there are a load of changes in your main branch or production environment, which aren't in your lower environments, maybe hot fix that haven't been back ported successfully.

You're gonna start to get problems when things are going through integration UAT.

New new features are often gonna conflicts and validation errors when you try and most of them. And to deal with this, we recommend merging, merging back from master or main into your lower environment's frequent to make the whole process cleaner, and ensure these are well aligned.

Some of the key cases where we've seen people get into trouble is if they let those environments drift further and further out of alignment and don't sort of get get ahead of it and solve it, and it's gonna cause more friction as they go through subsequent releases, and this drift happens more The next one's on the same thread. This becomes an issue if there are loads of changes that have been abandoned over a long period of time. So you've got, sort of, picky UAT testing or something that requested some extra changes and they weren't fixed forward or or reverted out. And so you've got a lot of changes that kind of stuck in UAT or integration.

They become landmines, really, their their new source of between environments that has the potential issued to cause conflicts further down the road. And these conflicts as well, it's more likely to resolve them in like a environment specific way when you get more further drift as well. So identify these features, revert them out, back to a state where you're aligned with production as well.

Integration with project management was like Jira is your DevOps. So allowing information to be surfaced about these changes to the wider business.

The two areas that we focus on with this. So just making sure the tickets are actually updated with all the information. There are some good links even if you're not using gear set between GitHub and Jira. So anything you can do to link those systems that you're using, either manage work or, you know, commit work as well.

The other one is just making sure that we update the status of that story as you move through environments, and this can be keyed so that have to test and manually check with you that something's actually in UAT. They know that when a ticket is in its place, it's been automatically updated with where it's been deployed as well. Gets really key as you have, you know, tens of poor requests going through a day in these teams.

Cool.

And finally it becomes around releasing to production as well. So you want to know what you want to achieve here. So different teams have different requirements with this step that we mentioned earlier. So we said feature by feature release further along the Devox maturity scale and, you know, releasing when ready is the holy grail, but it's just not viable for most large teams. This can be for a load of different reasons. It's that users want to know when changes are hitting prod as we said, or the requirements of those business processes or you want to release out of hours, for example.

And at the same time, you could be working on a longer term project that's completely adjacent to your business as usual work that has to be done on a different release cadence in general. So our recommendation here is to find the process that works best for your team. Make sure that you can promote feature by feature for hotfixes and other things, or build up a release over time, validate it continuously to production, and make sure it's integrated with those other hot fixes that are going out.

You should still be able to allow these individual features be deployed, and I have to wait to release it as well.

So how does this impact teams when team members have a clear understanding of this process to get changes approved for implementation?

It typically drives high performance across the board.

Ninety eight percent of teams from the reports show ROI from adopting Salesforce DevOps practices. It's not not surprising.

So when you've got all these processes in place, shorten your release cycle features are moving into production quicker than ever before with a higher success rate. What's next?

So teams of any size, but particularly large teams can't rest on their laurels. They're gonna have to be reassessing. You wanna be learning iterating on your process to ensure efficiency. I think there's loads of people who have spoken about where they've implemented DevOps today, but there's always this next step that they still have. So to make sure you're still identifying those and finding the new places you can win as well.

And with this, there's several areas you can focus on. You can take tasks that are manual today and continue to automate them to to reduce operational risk.

You can make sure you're testing what you need to test on every org at each stage. We heard UI testing come up a couple of times today on people wanting to implement that. Maybe backing up strategically important orgs and actually testing your recovery strategy, monitoring changes just to find out whether people are even jumping around the process as well.

So finally, keep measuring as you go because you can't really tell the impact of anything you've changed unless you're during it. So the benchmark for this is going to be door metrics, covering release frequency, lead time, success, and recovery rates, And then within those, you can start to extract more data that could be interesting for your team to improve performance as well. And using something like our reporting API is a good way to go through it. So extracting some of this data, maybe putting it into Tableau that you could see, make it visible to the whole team so that can start to work on this as well.

So I'm gonna leave with a really cliche message. It's a it's a math and not a sprint.

Know what you want to achieve. Do it step by step. Don't don't go too far too fast. And you'll see some of these improvements in your process as well. But whilst you're doing this, just make sure you're keeping the team happy with these changes.

It's gonna be really critical.

That's pretty much it. If you wanna go and find out a little bit more, we have a bit of an interactive workshop around CICD pipeline, so some of the functionality from the talk today.

Vasaiho at the back will be running this workshop and I'll be around there so you can jump on some of the laptops, but yeah, hopefully you see somebody there, a nice some, some funny faces. Yeah. Thanks.

Thank you, Matt.

Wonderful, as always. Oh, feedback. Be back. You good? Cool.

They're pretty good. Been good. Thank you.

We will be joined by Andrew Cook in just a moment. Who I do see standing up.

Lots of bumps still in seats.

The nerves rippling through Andrew as he his way down to the front, and I'm sure.

Press green.

Okay. Cool.

Without any further ado, I I'm going to get that lovely Andrew do his thing. One of the well esteemed Salesforce Ben instructors and expert on all things permission sets and profiles.

Thank you, Jack, for that lovely introduction.

No pressure. Pressure.

How's it run doing? Is it run tired? Okay. There's no coffee for a a while, not for a while. We've got an and a bit. Yeah. I just checked.

Anyway, yeah, thanks for thanks for coming to my session on this.

There's me.

For anyone that doesn't know, Salesforce bench had a rebrand.

There's some quite good new, photos of me in this, which I'm quite proud of.

But you can see the new logo there. We've got the purple in now, which is which is nice.

So before I start, I'm gonna just talk a little bit about me. So I started with the platform as an end user, actually. I worked in o two that I'm sure most people in the room will know, was an in store technical person, back in the day where you had blackberries, where you had mobile broadband where you needed someone like that. So they brought it in for us to literally for customers to be able to book an appointment with us to come and see us and fix their problem.

It was looking back, it was probably like a really customized I think it was Visualforce, to be honest. It was the customized, yeah, so that was how I got started with Salesforce.

I then moved to same industry, so still mobile, but it was b to b, and that was where we used it more traditionally, I guess you'd So it seems like my, accounts, contacts, leads, opportunities, all of those things.

So that was the point that I probably would say fell in love with the platform, because I literally was in two different companies similar industry, using it completely different ways. So that was the point where I thought, okay, this can be used for anything.

That was twelve years ago. So here I am now working for Salsel's Bend as a Salesforce technical instructor. So I work mainly on the courses platform, and do a lot of writing and the videos as well lately, which is quite cool.

I'm also now fourteen times certified, which I'm quite proud and this year I've done a lot of speaking as well, check dream in London's call in GPT dreaming. I was on the panel and done some user groups as well.

I'm also a super mom's mentor now.

I was previously a trailblazer one. They've obviously disbanded that.

And lastly, I'm also part of the Salesforce credential team, which is really cool, especially the last thing that I worked on for them was the AI associate.

So if you've got any questions afterwards come and come and grab me, and I'll answer what I can.

If you want to connect with you can scan that.

And here's one of the photos that I'm proud of.

Did you get did you get it, Todd? Yeah. Cool.

Cool. So here is the agenda for this session. I'm gonna start by talking about my experience in this area, because there's probably a lot of people thinking how can you talk about this? Is fair.

Next, I'm gonna talk through profiles, permission sets, permission set groups, the sort of planning you'll need to do for a project like this, before going on to the actual two pronged approach from the title of the user access and permissions assistant and user access policies.

Before I start, actually, I just want to put a caveat out there Cheryl Feldman, who leads up both of these, has literally just appeared on the admins' podcasts she might everything I might be about to say could be wrong and show them why I've changed everything.

I hope not, but I had to put it out there just in case.

Anyway, let's get started. So my experience in this area, you're probably wondering It's quite a lot actually. So start with, I'm a certified sharing and visibility architect, which anyone that's taken it will know. You need to know the whole ins and outs of profiles permissions, anything like that to pass it.

In my previous role, there's a typo on here for the record.

That should be socks, not sock.

Anyway, so in my previous role, I worked for a mobile com, a mobile security company based in London. We was then bought out by a big US firm who are publicly traded and any US firm like that, they need to, do certain seems to be sox compliant.

So part of that whole process, I needed to literally go through every user, every pro every role and say why each person needs access to everything.

Absolutely. Everything.

It took. It took about two months. It was a long, long process.

So after doing that, this this whole pick Sained relevance.

As I said before as well, I've been in the ecosystem for twelve years, mostly as an admin. So I've managed thousands of users doing a lot of things around permissions.

So first things first, what is a profile?

An easy way to think of it is as an office pass to your work building.

So your profile is like your basic office pass. It gets you in the door. It gets you up to the floor that you work on. It gets you into certain areas.

So that's I want you to keep that in mind because this theme kind of transcends throughout the the process of this talk.

And as well, obviously, with so you'll have a profile, someone else will have a different profile that gives them different access to different parts of the building.

So what is the future of profiles?

So Salesforce announced in spring that that in spring twenty six, permissions on profiles are gonna gonna retire then gonna be on there anymore.

However, certain things will remain on a profile. So there's things like one to one relationship. So you're logging hours, your IP ranges, your defaults, like your record types and apps, they will stay on the profile, and also your page layout assignments, they're they're all still gonna remain on the profile. So you're still gonna need profiles.

It's just things they manage will be changing drastically.

Right. So now what is a permission set? So if we go back to the is personal analogy.

Say you are or there's say your marketing team needs specific access to the fifth law and an executive suite.

So they will have their actual pass to get in the door, but then they'll be grant they'll they can be given an additional pass that allows them access to these areas as well. So that is a similar way to how a pin permission set is in in Salesforce.

So what is moving to permission sets?

Quite a lot. This is gonna be a long list, so strap in. So you've got your user permissions, your check permissions, your field permissions, tabs, record types that are not defaults, your apps that not defaults, your connected app access, Apex classes, Visualforce pages, and custom permissions. These are all things that are moving from profiles to permission sets as of spring twenty six.

Right. Now lastly, what a permission set group. So again, going back to the office analogy, say we've got two groups of users, you've got your marketing team, you've your IT team who both need specific access to certain areas of the office.

For those, the office management, I guess, who would be your admin can give a bundle of passes that they have act that they can use to access all of these areas. They're all bundled together, so everyone with that bundle knows that they can go where they need to.

So planning. So what you need to do with your plan in. So first, you need to know your profiles.

So if you've got a sales user and a sales manager profile, you to understand the differences between the two.

Likewise, if you've got a super user profile, what permissions have they got compared to a standard user, Next, you need to plan how you're going to group your permissions together. So if you've got a sales manager and a service manager, can these group be grouped together into just management kind of profile that gives things like reports and dashboards access.

And most important you need to communicate with your users. You need to remember that this is your users are who will be impacted most. This what the change is all about. They need to come along on the journey with you. They you need to make sure that they're part of every step of the way. They need to be testing need to be involved because if they're not involved and they don't feel like they're involved, they're not gonna appreciate the work that you're doing.

So first step one is the user access and permission assistant.

Before I do this, was supposed to be an actual demo.

I said to Jack a little while ago, how can I do demo, there's no laptop on the stage?

Jack pretty much said to me, you don't have the facilities for that man go do some screenshots.

So there's a lot of screenshots about to to come up, but hopefully because they're screenshots, I won't get sidetracked where in a demo I might have wandered off.

So demo is not a demo at Showtime because I'm not actually doing anything.

So here is the user and permissions analyzer.

So you can see We've got the permissions analyzer tab.

And if I move on slightly, you can select to analyze by your user, your permission, your permission set groups.

So an example of that would be here's my example of me as a user on the account object. You can see all of the of the access that I've got.

Granted on a user by user basis, this tool probably isn't the best way to do it. However, how many admins have gone into somewhere and needed to see who's got modify and has been scared by how many people has actually got modify.

These are the sort of permissions that this this tool's really useful for. So you can go in go into in the wall straight where you can say, okay, who's got who's got these main permissions that people shouldn't Next, we've got the converter.

So the converter literally has a list of all of your profiles.

And as you can see from the tab, got the option to convert the whole thing to a permission set if you want to. So, for example, here, I've got the sales pro well. In my demo, what I would have done, I would have converted the sales profile to a sales user permission set, and that's that's all handled through here.

So next you've got the report tab. So if I think back to my experience with my compliance project. This would have been a lifesaver for me, just being able to report on everyone's permissions in one place.

Run a report export it and manipulate the data that I need to from there.

And lastly, you've got the the manage tab. So from here, you can assign your permission sets to users or unass sign as well. And you can see that you can manage it by assignments and permission set groups.

And for anyone that wants to make use of this, it's completely free, download from the AppEx change.

I think there was something about the ratings on this because it was previously a different app. So the rate on it do not they don't they're not accurately representative of how good the tool is because it was a different app that wasn't as good.

So moving on, the user access policies.

So this is currently in beta, after the demo I've got, I show how to enable the beta. It's really simple now. It's it's all done through setup.

It's so this tool is really easy in that if you if you think back to the days of workflow rules, it's a kind of similar interface, really, in that you create a rule based around your users and their profiles and how you want to move them to permission sets.

So this is really useful in the fact that you can set up a rule and then just leave it and it will run. So we know this change is coming, but you might not be for the change or your organization might not be ready for the change yet. You can set these rules up now so that your users any users are being assigned the correct permission sets.

And then when the time is right in spring twenty six or later if they push it back, they're all they're all ready and you can just switch to profiles.

And again, an example of earlier from the my sales user permission set.

So show time number two.

So this is how it looks, so it's completely accessed through setup. It's built directly into the platform rather than, the other tool, which is a an installed package.

So this is how this is the romper of how you you would set up a rule. So you give it a label, as usual, it will automatically TV API name, you can set a trigger type, which is really important in that it can be when you create a user, when you update a user or either.

So you can have one rule for new users could have another rule for existing users if you wanted to. You've also got different statuses so you can retire rules as well based on the status so you can kind of keep track of things that way as well.

And this is how it looks in the end. So you can see you've got the label in at the top. I've got my if my profile is the custom sales profile.

I've added in another rule of they're active, because what's the point if they're inactive?

And then for that, it will assign them to the sales user permission set that that there went through a little while ago. So how's enable it. So it's really simple. All you need to do in setup, go to user management settings, and then just enable user access policies. It's really simple, unless Cheryl's changed it in in the podcast, and that's how it looks.

So in summary, you need to understand your current profiles. That's quite one of the main points of this is that you need to know what's going on in your org. You need to know the ins and outs of your profiles, or this isn't gonna work.

You need to plan how you group them together.

Planning is really important with this whole process.

Then you've got your user access and permissions assistant app, again, completely free.

You should definitely make use of it if if it fits in what you need to do and then enable the user access policies, which is in beta, but it's been in beta for a little while, so it's gonna come out of beta pretty soon.

And as with everything, do it in a sandbox, test it with your users, make sure everything works you push because this is one of the very, very real areas where if you get it wrong, you learn about it very quickly.

And that is pretty much it.

There's there's the last yeah. I know. I know. This is the one proud of.

Yeah, Jack, I don't know what we are for time. Do you have time for questions? Yeah. We're good for time. And we do actually have a question from Oh, that's not good. Is it?

We do have a question from the online audience. Would you recommend using the user access and permissions assistant to convert pro files to permission sets, or should profiles be broken down?

I think it depends on the exity of what you what you need to do.

I think the main is you need to plan it first because there'll be instances where you have a profile, like like a sales profile, for example, that may just be able to be directly to a permission set, or you might have a lot more complex profiles that you need to think about more and how you can break them down.

CA. It really depends on on your current setup, I guess.

Do you have recommendations for, segmenting permission sets around roles versus access to functionality across the platform.

Does it make sense for a master? Yeah. Yeah. It makes sense.

Again, I think that I can't remember the question.

The question that you were just about to it.

Yeah.

You're funny.

I was asking if there is, Hang on. Hang on. Do you have any recommendations?

There we go.

So I'll repeat. Do you have any recommendation around segmentation of the permission sets if it's around object or areas within the platform or more in terms of roles?

I think the beauty of this whole process is that you can the decision yourself. I think we can all we we can all within our organizations.

We know, like, we know we know organizations better than anyone. So I think we have the power to make that choice. I don't think we're gonna be pushed in one way or another in how we do it. So really, yeah, I really think it depends on, again, on on the org setup that you've got and kind of the permission going around, because there'll obviously be some people that have got very, very limited access, which a lot easier to manage than places that have got five different levels of super user to manage certain different things.

Yeah. So I think that I don't know if that answers the question or not.

We can chat after this one.

Oh.

That's a good question.

I don't know, actually.

I will check that. I would I would imagine yes because Cheryl built it and just I can't imagine Cheryl not doing that, actually. But, yeah, I'll I will check. I'll find out. Yeah.

We regards to the user access policies, can you remove permission sets as part of that? So you've got service user, they've got the service user permission set. Yeah. You can both add and remove permission sets and permission set groups from users.

Yes, actually a good way of doing doing both. So you could actually use it just for permission sets in general in that, like, if one needs access for a limited time, you could have a broad that after whatever time you can remove it. Yeah.

I'm all. Good. Andrew, thank you so much. Profiles of permission says Thank you.

Hello.

Alright.

Next, in the lineup. So, we got one more talk for you before a short afternoon break.

It's a pleasure to introduce somebody that I've known in the ecosystem for a long time.

Mr. Richard Clark. So he's gonna be talking to us about quality being a journey, and hopefully you can see the evidence, the spectacularness, this shirt and, yeah, exactly. Exactly.

Give us a tour. We need a gears, pro of our collaboration there, I think. I think that would be quite good. To take it away.

Thank you so much. Thank you, Jack. Thank you for coming along. So quality is a journey, not a destination.

What do I mean by at. Like all things in life, quality isn't something you finish doing. It's something you do continuously.

So we go on multiple journeys in our life. We have certain stage we reach, we go places, we do things, we have certain goals, but you're never finished. It's not the destination for what you're trying to do.

Could help.

So, I'm Richard Clark. I'm Chief Strategy Officer at Provar Limited.

Firstly, don't let that worry you. Okay? I'm taking as well. Okay? I was doing DevOps back in twenty twelve, quite early on.

I've been in your shoes. I've done those two AM deployments and rollbacks. I've lived it all from as a system integrator, end customer, and partner of Salesforce.

So at ProvAR, we produce integrated quality life cycle management solutions, and the most robust test automation solution designed for Salesforce and other applications to test that.

So today, I want to give you an idea of of why testing matters and why matters for DevOps, how you can integrate it into your CICD pipeline how you can measure quality of your DevOps solutions, not just about testing, but just one measure. So we're gonna look at measures, we're gonna look at some of the common techniques and metrics people use, how you can collate that data together into one quality hub. And when I talk quality. I'm not talking testing quality assurance.

That's one minor thing. If you're testing something, that's great. You're observing the results. You should improve quality at the start.

So we're gonna talk about that So hands up if you know what Dora metrics are.

Okay. Keep your hands up if you actively use them.

Not one. One at the back.

Too far to shout, Rob. Okay.

So door metrics are important, but they are not the goal. For that everyone else and everyone online, and I've had this ready today upstairs, This is not Dora. And yes, it's Dora. Okay? Dora the Explorer. That's not what I'm talking about, okay, but kind of she goes on adventures goes on journeys, so yes, it is.

I'm in Dora DevOps Research Assessment. Okay?

Acquired by Google in twenty eighteen, used by Google and sort of looks independent still. They have sponsors as they publish an annual report, and that annual report's made up a survey of over eighty six thousand customers or end users, I should say, companies.

So they survey them. They find out what's really making a difference. Is AI really transfer the way we do dev ops, like Jack said this morning, actually it's not. If anything, it's holding back dev ops in some cases. So the Dora report is much more.

However, so most people would be aware if they know Dora, they think the Dora metrics.

So starting at the top there of laser. Yes. We've got the mean lead time for change.

So from a commit of a change, long does it take for that to reach production? We can measure that time in minutes, hours, days, unfortunately weeks in some cases. How often do you deploy to production?

Okay?

You could deploy to production quite quickly if you do all your changes in production. We do it several hundreds of times a day if you wanted.

How what is your change failure rate? So how often does a change in production mean you have to roll it back? Not how many bugs do you get, but how often does it cause remedial action to occur?

And then the mean time to store, which has been reclassified as failed deployment recovery time. So basically, when there is a failure, how long does it take you to get back to the working data you're in.

So each of those metrics, you can improve individually if you wanted to.

But if I decrease my change lead time by making those changes in production, it's gonna improve my deployment frequency. Yes, but it's gonna be at the expense of the change failure rate. Okay? I can put test automation on my AppK integrated into my debit box process, and it's gonna reduce my change failure rates. But if I use the wrong product or do it badly, gonna increase my time to make changes, how long to commit to production. I'm gonna reduce my deployment frequency.

So we need to think about the metrics and what we mean by improving We also need to think about the human cost. Okay?

If I am making changes to time to data my production system, what's the impact on our users? How do they know how to use the application when every time they enter a transaction, it's changed on them. So more is not always better. Okay.

So because of issues like this, Dora started to talk about a fifth element. It's not metric, but it's an element, something at the middle.

Don't hand up you know what the fifth element I'm going to talk about is other than Rob, it probably does. No. Good.

The fifth element is reliability. We can bring the four metrics together by measuring the reliability of making that change.

So by measuring reliability, we can tell if those changes to the door metrics made a positive or a negative impact on our overall systems.

So let's take a closer look at Dora. And when I talk about Dora being a good thing, not talking metrics. I'm talking about Dora as a methodology.

So Dora thought of this, and if you look the top, capabilities predict performance, predicts outcomes.

Dora isn't about the software delivery performance we just saw, it's about commercial and non commercial outcomes. It's about you as teams, your well-being, less deployment pain, less rework, less burnout.

This is what we should be measuring. These are the things the outcomes we wanna see. And in order to get that, by all means, we have to deliver all the capabilities, but I've highlighted the ones that apply to me for test automation, code main ability, I can measure the quality of that.

The monitoring and observability of our systems, including production, to automation. It's important you can't do DevOps about test automation.

Test data management, reusing your test cases, having test data drive iterations. You don't maintain lots of test cases. You maintain lots of scenarios for your test data. And even trunk deployment. So lot of us did a lot of work in the last ten years. Oh, git flow. Git flow.

Actually, we wanna be CI. You should be looking at trunk based deployment.

And all the other things shift left on security, streamlined change approval. These are all important.

So I did some research, and I found GitLab, please don't boo, gear set. GitLab published their Dora metrics, okay, quite nice and I can look point in time if you had really good eyesight, but the metrics, the numbers don't matter.

They're their metrics. You can't really compare a Salcrest project to a gitlab project. But what we can look at is their trends. So we can look across the history over time, and we can see if getting better or worse. Again, those numbers tell us a trend, and we can correlate across them. So we can see how we change one metric, moves enough so in visualizing that is very powerful.

But that's all quantitative analysis. It's all numb is based. What about some context? Have we got a change freeze for December? That's gonna hit my deployment frequency?

Have we just hired a bunch of new junior developers that might hit the number of failures in production. Did we just lay off half our QA team? These are gonna change metrics. So the numbers alone give you a an item to look at, but you need the qualitative data as well to understand what events would have cause that to change. Your team may be performing just as well as before, but you've now got an issue with the, other things that are affecting them. Outside changes.

So in the twenty twenty three Dora report, it's worth reading. I've put a link at the end, and it's also worth reading the gear set state of dead ops report as well, some context about what's normal for Salesforce.

We see top teams are balanced teams. They're high performing, they have low burnout, they have high job satisfaction. These aren't Dora metrics. These are personal human cost. Human metrics we want to understand. And as a result of that, the top performers deploy on demand. There's not numbers say how many times per day, when they need to deploy, they can deploy, like we heard earlier from Jack.

Lead time to change is less than one day. We've got an idea. We need to do this. I prepared it. Let's ship it into production. Okay?

The change failure rate is less than five percent. I think that's quite high. There we go. And their failed deployment recovery time is less than one hour. Pretty good, pretty good.

So teams that focus on the user, rather than the metrics, forty percent higher organ organization performance, twenty percent higher job satisfaction.

These are things I'm interested in.

So apologies to be from sales in the room. I'm going to do a bit Salesforce bashing. Okay.

Two weeks ago, Salesforce did a patch on production and sandboxes on a Thursday. Anyone's experienced this, the, when you hit the new button on a related list, and you tried to save, and there was a mandatory relationship, master detail, the save was failing on the related record because it hadn't automatically it across the primary key or say the account or the opportunity, whatever it was, was the primary object.

I don't know how that would reach production. But the impact was up to four hours for Salesforce to roll back those changes. It shouldn't have happened. Okay?

It just shouldn't happen. The the coverage should have been there to protect you against that. You would have thought you don't need to test that. Unfortunately, you do.

Unfortunately, on the same day, there were multiple other unrelated outages.

A, data center power went down with the storm over Europe. In Asia Pac, some servers went down and people were doing site switching. So it looks like these things are related, but they weren't. You would never thought to for all these things.

Now if you were using Dora metrics, you would need this context because this would affect your availability or system. This would affect your ability to deploy change or roll them back if you needed to do that as well. So it's important to understand these other events happen that could influence your Dora.

Just a time check.

So this led me to look at something called site reliability engineering.

And this is really cool. And I've seen a few ex colleagues from Provar have gone on to do site reliability engineering instead of a QA person.

So SRE has been a doctor with a lot of big tech companies, and what they're investing in is prevent if maintenance for software.

So rather than fix things that are broken, design them from the start to be reliable, think about that in the early stages.

So the definitions vary, but the things I call out automation. Again, automation of processes deployments of script and your deployments of testing is important.

Only engineer don't over engineer solution folks on the necessary level of reliability.

Observe what's happening production through continuous testing. Don't just think if you deployed you're finished. Use log monitoring as well, not just UI testing, And then another thing I found really interesting was chaos engineering. Has anyone heard of chaos engineering before?

Two, three, I to a lot of people, that's good.

So, I was really interested by this. So back in nineteen eighty three, Apple, we're doing the Macatosh cuter, you know, the one with the old a four screen. Don't know why they got rid of that. It was perfect for looking at the page, and they wanted to test it.

Couldn't use their automated testing software. The reason they couldn't do it, there wasn't enough memory on the machine to run it. So someone built a machine to basically hammer the keyboard randomly to test and it worked. They were doing chaos in June.

Things you would not predict random events happening the keyboard to see if the application still worked.

Twenty years later, we see Amazon creates a total game day. So and I think were still mainly a bookshop at that time, they went to improve their website reliability, and they did that by deliberately creating major failures in their induction environment to see how they could respond to it. And they were motivated by seeing five fighters at work. So five fighter teams practice on burning planes, burning buildings, I don't think practice cats up trees, but maybe that as well. So they saw how they were getting better at recovering from incidents by practicing So they thought we need to practice this as well. We'll deliberately introduce problems so we can practice.

Two thousand and six, Google asked her recovery testing, is it testing? So again, they looked at catastrophes, natural disasters, data center going down.

Network connections, undersea cables being cut by anchors of ships dragging across them before we had satellites. They looked at all these things. In two thousand eleven, Netflix states that could chaos monkey, clearly influenced by Apple's the Apple monkey. So they created software that would take their production instances and randomly shut one down without their engineering team knowing which server would be taken down when how many of them.

And that developed a thing called Seemun Army. They've got a whole suite of tools around making sure they evaluated their platform. The form's not available. It's not available to their users.

They lose subscribers. It's their business. But more recently, we've seen something called failure as a service. There's quite interesting.

So tools such as proof doc and Gremlin, where actually you can test the reliability, not only of your applications, but of your people in Bob doesn't turn up to work, what happens? I'll be still able to start the business or, you know, to unlock the office. There's other things to test than just civil software. And processes.

You've got your happy day process. What happens to that process deviates? What happens if that step doesn't happen? We can look at those things.

So we looked at reliability earlier, but reliability is only one measure of quality.

I usually list these are the five dimensions of quality. Other people choose some slight different variations.

So we think about accuracy.

So our application can work without any bugs. Okay?

But if the data we're capturing is duplicate, if the data we capture is incorrect, then we're gonna be making bad decisions on that data.

We're potentially also liable for things like GDPR fines if you've got bad data.

So we know duplicate data is bad. We know we can measure duplication of data. We know we can measure, therefore, the data accuracy of all the different things where data could be bad.

Completeness.

So my marketing often say things like, oh, we got so many leads from this event. I did an event recently when I said, oh, you got you got hundred leads from that event. And I said, oh, I have the, company names, email addresses? Oh, no.

I can't give you that. Sorry. Response ring. Yeah. I can't give you that. Why is that?

GDPR can't give it to you. No. That's not right.

Completeness of data, if I don't have an email address, a company name, or a phone number, that data is useless to me. Instead of meeting GDPI by excluding the data, they should have it securely and got the, the attendees to opt in to give permission for their data to be used. So again, the solution we choose can impact the data can weakness if we choose the wrong solution.

So we want a day to be reliable. That doesn't just mean about bugs. We want to make sure there's no website outages. We wanna make sure if an integrations failing or fail silently, we know about it.

There may not be a bug. There may not be a Jira ticket for it. If the save button not work. We want to know about that.

It may look like it works, but there's no data in the table. These are common scenarios.

One I often badges, people often ask for a new field to be added to lead object, but they never tell our admins where they want their data to go on conversion. For me, a reliability issue. I've captured some data, and I just throw it away when I convert the lead. It's not good.

Relevancy, so unless a data scientist doing AI, you can store all the data in the world, but we only want what's relevant to us.

So at Provar, I want to know what DevOps solution you're using because makes a difference in terms of my recommendations and what tools to integrate.

At Pratt, they sell coffee and sandwiches.

I don't need to what food allergies you have. They don't need to know what DevOps tool you're using. So data needs to be relevant to the business and the process that you're using.

And then timeliness.

So some people say data currency. We don't mean pound shillings and pence or dried fruit. What we need to the data we're storing needs to be timely. It needs to be relevant.

If we're acting on stale data that's changing fast, again, it's inaccurate data. So the, timeliness you can get that data, the timeliness you can respond to it. On that point, one of the things I often come across is people during UAT on a project will often say things like, oh, this is a bug. It's a change in requirements.

And I always say to them, when did you capture the requirement? And if they say three months ago, well, you're building what they wanted three months ago, you should be building what they need today. So it's your job as a consultant to check with them as you go through process, when you start building that, is this still the right requirement? It's not their fault if the requirement or the business has moved on.

But also people don't tell you everything, so you get both.

So we looked at Dora. We talked about capabilities briefly.

We can see how we can influence capabilities things like test automation, we talk about quality measures.

So how can we integrate that into our dev ops pipeline?

So Salesforce now talk about testing.

So John's here. Thank you, John. DevOps has a suite of tools, and these tools are helping you with the quality. They're helping the quality of your applications. They're helping you things about code analyzers, static code analysis, and we recognize there's multiple stages to deploy something to production. This is good.

At Provar, we think of this is two split infinity strips. So you've got your normal DevOps process, where you've got your functional testing in the same place. But actually, we say you should be testing throughout that process, but the types of tests you do is different.

Here, I'm testing the functionality what I'm delivering hasn't broken anything thing, the things I'm delivering work. Over here, I'm doing static code analysis over here and deploying to production and maybe look at logs or maybe looking at performance, what's the performance of the system after I deploy it.

Even in production, you're still looking at what bugs, how many issues are being created, but seeing other ways that we can measure quality, other ways we can test quality throughout our life cycle.

So on our stand upstairs, we've got this banner. I'm gonna talk you through it. How much time have I got? Quickly.

So the left the right hand side is indicative. Okay? You can use gear set in here. Can use other tools.

You can use Azure DevOps. Yes. You can use agile accelerator. It doesn't matter what you're using, but we have a system where we're capturing our user stories.

Those user stories been built either declaratively or coded by developers.

In parallel to that, our QA team are looking at that story as well and thinking about is it they need to test when they're planning their testing?

Unfortunately, unless you're using Kanban, and if you're using scrum, you're probably thinking that a sprint plus one, you're typically execute the tests after the developers committed to work, because in my experience, you only get those commits three days before the end of the sprint, and that's not enough time to do your testing.

But if you're fortunate and you're more mature than that by all means in sprint testing, we build tests using pro automation.

We can test those on development environments, we can give developers and admins tools through the Salesforce CLI to run the tests where we already have the regression pack.

And then when we're in our partner release pipeline, we can do a more, deep level of testing. We can do things like code coverage. We can do things like test coverage, as well as code coverage, we can integrate the gear sets. We can do AI test creation. We can create tests for you automatically based on the metadata that's being changed.

We can do a static code analysis. We can do AI orchestration. So we can look at tests, we can say, which tests do you have that are new? Because they're probably gonna break first.

They may not be good tests. What always go wrong, run those first. So if we optimize our execution of tests, again, instead of waiting six hours for your results, we condone fifteen minutes that this is bad release, or this is a bad set of tests in some cases. Now as we move down the pipeline, we see each stage we do more regression testing, we capture manual test results during your AT.

They can see the results of what you've already tested against which user stories and why and what the results were and the performance of those tests, but you can also log what was it they tested, what were they trying to do, what did they break when they were testing. And ultimately, when you then deploy to production, you'd also do some production monitoring, some non destructive testing in your production environment.

Okay. Quick break for drink. So in the testing world, we talk about a software test life cycle. So unit testing, integration, system, and acceptance testing.

Now when we measure this, we put metrics on this, this isn't just about the number of provar tests that worked. How many commits did it take to make that change? You might wanna measure that. It might tell you something quite interesting thing. When you start looking at that by developer, you get some very interesting results. You might need to do some retraining.

How many unit test failures were there as part of that? How many actions come at their retrospective meeting at the end of the sprint. That's quite interesting. Is that going up? We have more retrospective mechanisms or we have less? Are they different?

Integrator test failures, how often are you changing metadata? Are we changing the same bit of metadata over and over and over? If so, why are we not thinking more in statistically about those changes.

Merge conflicts, everyone's favorite thing, how many times you get merge conflict, are we using the right branching strategy should we move gitflow to use trunk based development to avoid that. Even on the system, it's our business process failing, okay, how many times does it fail?

What is the relative performance of the application? So when I run my tests, I get a load of timings, about how long the save button on opportunity took. If it's taken ten seconds on opportunity save, your user's gonna be unhappy. Okay? And that's internal users. So you can measure that. You can look back over time, like we saw with Dora, and you can measure relative performance.

We can automatically run tests when those messaging changes occur, acceptance, how many UAT defects do they find, what are our adoram metrics for getting to production?

What's our customer satisfaction as well? So how what impacts us that had on our users?

So we can bring this together, and we bring it together through test analytics.

So we can take all that data we can put it in the Salesforce org, or we can put it in Tableau CRM just through a drug with the name off, okay, or you can put it in a completely different application. We can take that and can report across Salesforce as a quite good reporting tool. We can put quite a lot of data in it. We can actually start looking for relations between data.

So this is the ProvAR managed application available in the AppExchange, free trial thirty days yada yada yada. But in it, you can then and dice your information, you can look at things like what the changes buy in terms of which environment, which systems, how often, how frequently things break in, how frequently the things work. And what's the relative performance over time is our code coverage and our quality coverage getting better. So we can look at all these things in Salesforce. And this helps us understand that quantitative data, but I can also, because it's Salesforce, I can add notes. I can add chat records. I can add qualitative in information to this too.

So the reason I would do that is because I had a previous career, whereas the go around companies doing CMMI, so capability maturity models. So we've been pushing something called the quality maturity model, and SimMI and maturity models in general have five levels, but I always add level zero because I keep coming across level zero. We've got nothing.

Five levels are initial. And in our case, I've defined it as it worked. I've got no evidence it worked. I can't tell you what we did, but I can tell you that it worked in a little below that.

Number two, defined. So we've scripted what is it we're gonna test, in this case, or what is it we're gonna observe. We've got the evidence, and I can beat it. That's good.

A lot of people still working to this, still trying to get to defined.

Integrated.

I can automatic execute test as part of my CICD pipeline.

I can schedule regression as well as part of that. Understand that when I'm doing regression, I'm testing different things to when I'm testing a, individual change.

I'm starting to look at Dora metrics. I'm starting to collect the data. May not be doing anything with it, but I'll be collecting it. And I've got a single solution for my looking at my dev ops The results of that, my manual test, my automated test in one place.

Quantitively managed or just managed. We started to think about the automatic defect creation. So we observe something's gone wrong. We automatically create defect.

It automatically gets routed to the right engineer based on the type of defects.

We've had automatic test plans based on those changes I talked about, and we can historically look back at the quantitative data and understand where we may have a problem or repeat meeting issue occurring. So I can do something in a very managed way. And then the optimized level, never seen the optimized, so don't worry. Maybe it's aspirational.

Can start to see evidence of a continuous improvement because that's what it's about. This is a journey we're on continuously improving. I'm using site reliability engineering. I've shifted left in my processing to avoid finding bugs and focus on not having the bugs in the first place. I'm looking at the whole Dora thedology, I've got those outcomes we saw on the right. I'm thinking about my staff and employee welfare, thinking about commercial and non-commercial outcomes.

So this is a thing you can measure. And when you do a CMMI or a QMI in this case, you'll measure multiple factors. So the factors I would choose for my industry, process infrastructure planning scope. So how much sure where the process is.

So I've asked the questions, how mature are your processes for finding bugs and executing tests? Is it ad hoc? Who does it? How often it you got scripts showing me the scripts?

These are the questions I would ask. And I would rate them between naught and five on that score. Then I would look at like environments and tooling? Do they have enough sandboxes?

Are they trying to do everything with a dev sandbox? Okay? Do they have the right tools? Do they have a proper product, or they're still doing things using the metadata API or chain sets, how mature is their planning thinking ahead?

Are they proactive or reactive in their test efforts?

How quickly can they adapt to someone saying we need this tomorrow?

What was the scope of the testing they're doing? So I look at things like, you know, are they just checking happy day scenarios? They looking at performance? Are they looking at data quality? Are they looking at code quality? Are they thinking about user experience?

Okay.

Were the QA team recognized as team members, and I hear this a lot. So a lot of companies, people that doing QA, may be in team doing other jobs as well, they're being overloaded with work potentially.

So if people are doing testing, have they had the right training then? Do they have a career path? Are they recognized, because we get to see a lot of devs, admins, and BA's have to do testing because having QAs is still seen as a luxury in many companies. It's not easy to justify budget.

So hopefully from today, you've learned quality is a journey. Hope you agree.

Dora metrics are only imperative measures, and that Dora is a methodology. It's more than just the numbers. It's more than just metrics. Please go and have a look at Dora and learn about it.

Test automation is also integral for DevOps, platform engineering, which I forgot to speak about, and site reliability engineering.

Quick one on nope, I haven't got time.

So quality of the journey, and it's you to you.

Some links for you to take, hey, Quitra, the last, do a report. You can go and have a look at that. You download it, don't have to pay anything. They don't spam you too much.

We've also got our own survey. So if you'd like to a survey with Provar, bitly slash Qualcomm or take a picture with QR code. It takes just a Google form survey where you can find out more and submit your quality and we'll come back to you with what we think about where you are in that quality maturity model. And then lastly, the gear set that let me talk for this one, their state of dev ops report as well.

So specific to the Salesforce industries, what's considered good, what's considered to be elite performers.

If you'd like to know more about Provar, please come see us upstairs, Tact us on our website, free training LMS, like launchpad pro vie dot me. You can just sign up and start using that access and all our content, or connect me on LinkedIn or Twitter, I refuse to call it X.

Any questions in time for questions.

Must be one. We've got to plant a question. No. Thank you very much.

Alright.

Richard, thank you very much. I think one more twirl, I is re required for for for those of them.

Okay.

I think it's coffee time, everybody.

One last break left of the day before we finish the final session. So, thank you for your attention. Post lunch.

Grab some coffee, tea, etcetera. That should all be available up in the over a room once again. We will reconvene here. Somebody's gonna tell me I'm wrong.

It's after this one. Have I got that wrong? I've got that wrong.

Yeah.

I've got that. I've got got myself a one one job.

One job, one hosting job. Now, I see you giggling noise over there. That's not fair.

Cool. Alright.

Andy is getting mic'd up, and we'll be here shortly.

Still am I still on? Yeah. I'm still on.

After I after I saw nearly rudely, cut my esteemed colleague off here and, had the had you all running off for coffee coffee instead.

Pleased to bring you, Andy Barrick, one of gear sets DevOps architects. I'm sure he's gonna tell about himself anyway. So Andy, I'll leave all the fun stuff to you. Thank you so much. Lovely. Thank you very much, Jack. Thank you.

Good stuff.

Alrighty. We are. That'd be a minute or so early, but I'll, we'll get get cracking and then you might have a minute extra at the end for for the, promised coffee break.

So, we're gonna have a look today at, at merge conflicts. You mentioned in the last session, you may, maybe, encountered them described in other sessions so far today. We're gonna have a look, obviously, what they are. We're gonna look as well at ways to avoid them happening in the first place, shifting left, the mantra of DevOps, are ways that you can, we will maybe see them as more of a, a team exercise in how you can avoid them in the first place. They're not necessarily just the the developer concern. So who am I and why am I here?

Well, I've just said why I'm here to present that.

I have worked on the Salesforce platform for about ten years I was in, ISVs mainly beforehand, lead developer or the technical architect in professional services, packaging financial force, CTinia, cloud sense, service max, and then I worked a lot on projects where, you know, we got tried to get stuff into production and, you know, the the the deployment side of it all didn't work quite so well. And of course, we end up on the hook for, you know, the production aug not being quite right. And so I wanted to do something about that. And so I joined gear set to do that, but merge conflicts, you know, the developer side of things very much, a daily, a daily activity for me.

So as mentioned, we're gonna have a look at, emerge conflicts, a fact of life, for for teams using version control.

That is very true, but they don't necessarily have to be. They're a way of which you can design your processes the way that you're gonna work to hopefully avoid these happening in the first place as much as possible. It's never gonna be completely.

It's never gonna be completely clear of conflicts, and that's potentially we'll dig into the causes of why that will be, and look at look the strategies of avoidance.

So, to start with then, just to make sure that everyone's on the same page, you might, you know, you might be looking to adopt a version control system, and therefore not have experienced this, potentially already worked with one and do get them regularly. You may be at any level of maturity. But so just to make sure that everyone at the same level of thinking. If you have ever used the Salesforce UI, you've opened up a record to did it. Left it around for a while. Click save and got the message that actually you can't save because someone else has got and made changes.

You've got a data sort of conflict there. A merge conflict is very similar to that sort of situation.

If you could imagine that in that thinking about the UI there, if I opened up a record and edited field a, let's say, on the record.

And the some other user, somewhere else around the world, edited the same record, but field Now if if both people save at the same time, if you can imagine that Salesforce might say, okay. Well, I know you haven't changed field b.

So I'll take your version of field a, and I'll take the other person's version of field b. They haven't they, and I'll manage to sort of combine them together into a amalgamated state where I can accept both changes. That's effectively what Git is doing very smart at being able to detect what different bits have changed.

But if both users tried to change field A at the same time, it's not gonna be able to do that, and neither can get.

Ultimately, it's two different branches have the same bit, the same lines of a file, but in different ways.

And ultimately, you don't want for all, we talk about auto and such in dev ops. You definitely don't want to automate merge conflict resolution. You don't want some automated process deciding for you what some potentially critical bit of your business logic actually is gonna look like git saying, Hey, I need some help here. You know, I need some human interaction to tell me exactly what this final state should be.

Our dev ops is a a concept is always very much around trade offs.

We we heard it in the last session as well. You can't necessarily one thing without affecting another.

In a world where there was no version control, it's saying, you're just deploying org to org. You don't you don't get merge conflicts, obviously, because you can only change one thing at a time.

The existence of the ability to have future branches, which effectively mean you can have your application in multiple different states at the same time is the root cause of how you can get merge conflicts, obviously. You know, if if there if there wasn't the abilities to have these parallel states, there wouldn't be a need to merge and match together again. But the benefits of being able to do that for developments of different features in parallel is obviously considered a far greater benefit than the cost of to resolve merge conflicts.

So we've generally accepted that that's a reasonable trade off to make, but we can hopefully reduce even further the number of instances in which we get merge conflicts.

So, for Salesforce teams, there's two as we can see here, two typical main root causes of merge conflicts.

Long feature branches as we just defined.

The two branches, different changes to the same bits of file.

The longer a branch live on for, it makes sense that the chances of some other branch changing the same bit of the file in potentially a different way are going to increase.

And also Salesforce's representation and better data.

XML, quite, obviously, the vast majority of it is in XML.

And git, for all I spoke about how it's very good at being able to detect where changes have happened in files, When it comes to repeating blocks of metadata, it rather falls over.

If you think about, consider like a book where you've got every paragraph that begins with the same thirty left words and ends with the same thirty words. And you've got to work out if someone's put a new paragraph or change an old paragraph, you're gonna have to dig into the bits in the middle that are different each time to work out what each one actually is.

And ultimately, that's what gets gets tripped up by with XML, but it sees the same bits. It can't work out which one's which. It would need to dig into the XML schema and understand which are the identifying properties, master label, API name, those those critical ones to know which each block actually refers to.

And the metadata API can return data, especially around profiles in nondeterministic ways.

So you can find that the retrieval of the same item can actually come back in a different order, and that obviously can trip git up as well due to the XML parsing issues.

So with that context set, we'll have a look at these five packages about how we can reduce the instances of merge conflicts occurring.

We'll dig into each one in detail I won't read through them specifically here. So the first one is avoiding having teammates working on the same part of an org.

Like we said at the start, you know, two people working on the same thing in different ways is going to result in an increased risk of conflicts.

The example I like to think about here is where you've got maybe, some couriers a dispatcher.

And at the start of the day, the dispatcher gets the, you know, the job orders, the tasks to printing out five minutes before they start, you know, looks at the first one, courier one at the first of the queue. Right? You're going up to floor twenty of that building.

Second job You're getting up to floor twenty one of the same building.

That's clearly inefficient, right? That's obviously wouldn't. You would expect that not to happen in real life. If you use things like field service, you know, the whole dispatching logic. There's lots of lots of solutions for problems like that.

But you would expect that dispatcher to have done some sort of duration of the the job list and come up with idea of sending the first courier with both parcels, basically to the same building, to be the correct solution.

And that translates to your feature backlog.

If you've got two developers who are about to work, on the same same bit of metadata in two different features.

As we've discussed, this is where your conflicts are going to arise.

So looking at the backlog and either working out whether these can to be combined or separated, staggered. The second can't start till the first is finished potentially.

We'll help you avoid the conflict happening in the first place.

It's a wider it widens this out a bit because The question then that would follow on, I guess, would be, well, how do we know what we're gonna be working on?

And having a solid application architecture that's well known, that's easy to pick up and tend of course, can help with developers becoming familiar with the projects that they're working on.

But the team working on the backlog together to join stories to split them apart to understand exactly what the solution would be.

What changes are going to be needed to be made to achieve the outcome.

In that sense, you can pre prevent conflict occurring in the first place because you're preempting it by knowing exactly what's going to be worked on in parallel.

Joining stories is obviously one of the solutions.

The staggering was the other. You might then think about, well, if we join stories up together, what if the business only want one of the twos to go? You know?

This comes back to understanding the the actual requirements. If you're working on something and the business don't want it to again move on into the production org, you've then spent a lot of time working on something that's ultimately not adding value.

So shifting left, identifying the value, identifying the solutions, and keeping.

Though that work on the same bit of the application separate avoids the conflict from ever occurring.

Merging early, incredibly important.

What we what we mean about early here is within the life cycle of the story itself.

The one thing that's bound to cause trouble, as we mentioned at the start, long live feature branches.

The soon you're going to merge these branches, the much less chance there is for anything to conflict with it. As you can see here in the diagram, it it's clear enough, the strategy where we're merging early, we can potentially conflict we've got three potential conflicts.

Merging late, there's six.

So simply by merging early, every branch has started at the same point essentially, but because of how they've been merged in, we've cut in half the number of potential conflicts that there might be.

Branches can can certainly stay around longer where you've got where they descend into debates about acceptance interior. We're back to those again, or long running code reviews. If there's no clarity, if there's no definition of done, for a particular feature.

This can lead to branches being left open for longer as people try and work out exactly whether it's completed or not. So again, shifting it left being absolutely clear on on what you're gonna work on, how you're gonna provide it, and how you're gonna test it to know that it's good enough to then be merged.

The third option, the third strategy is to merge often, which on the face, it might seem like the same thing as the last.

It's it's a different lens of the same problem. That's for sure. You know, if the longer a branch exists, the more changes it can accumulate, and the more the more chance there is of those changes conflicting with something else.

If you've got completed and validated work stuck on feature branches, it isn't being merged.

It's not unlike having them having stuck in a warehouse that you could sell, but it's just stuck in the warehouse. It's not providing any value to your end users. It's getting in the way of other stuff in the warehouse. When you actually need to get to it, it's problematic. Right? It's hidden.

It's hidden of stuff, and it's just causing you cost to maintain.

And, ultimately, when does come to merge, you've then got a raft of conflicts potentially that someone needs to wind back three months.

To pick out a hopefully rather extreme figure. But going back to someone who said, you worked on this three months ago, I'm trying to merge it. It's now conflicted.

Help me solve it. They're unlikely to be able to provide you with any, rapidity, the the the state of their mind when they were making those changes.

And the chance are, of course, in that scenario that what it's conflicting with is work done by somebody else who's maybe not even on the project or with the company anymore, and how do you get it do you get their thoughts? It's very difficult.

So merging often is a significant strategy for avoiding merge conflicts.

Abandon work as well. That's another another potential issue.

Work that gets into something like your UAT environment and hangs around for ages waiting for someone to test it, waiting to be approved. Again, that whole sort of debate about, is it finished? Is it ready? Is it is it acceptable?

You want to avoid those sorts of scenarios.

So this this one strikes at the heart of, of good setups.

Having when we say teammates here, that would be effective to the developers. Right?

Encourage the team the team people who are creating the changes to take ownership of their merges.

This isn't overriding the idea of peer review or anything like that should still have critical parts of the process.

But DevOps came about because of the silo between development and operation of course, development do the work, specifically each feature, and then throw it over the wall is the old phrase to operations who've got to try and create some sort of release out of it. It's the equivalent of flat pack furniture, if you will. You know, you go all these components, you've got to put them together.

If they've not been created in a way that's been proven that they fit together, you as the constructor are gonna have a heck of a job trying to create whatever it's meant to be at the end of it.

So by having the developers take on responsibility of merges, if conflicts exist, then they're going to be much better placed to be able to solve this. They're gonna be closest to the work. If you're merging earlier, merging often, they're getting them. They're encountering these issues to solve it's all fresh in their mind.

And you don't have that problem of a release manager having to sort out hundreds of potential pull request merges that are all potentially conflicting each other.

It's not also to eliminate the concept of a release manager, as we mentioned. It's know, there's lots of use cases where that that's still a very relevant role. You know, I've worked on plenty of projects where I didn't get a license for the environment.

Because it cost a bit. I didn't need access. It was a customer's data who I I shouldn't we see in any of.

So there were internal release teams, you know, that's not we're not saying that the developer should go all the way to production but creating as far as that first integration point, where they can prove that this is becoming a a solid unit of release to take forward down the pipeline, they're definitely the best placed to start that process. And it as we said, it's a true spirit of DevOps. Collaboration across roles, not becoming one set of people doing everything but having the overlap between responsibilities to make that handover between the stages much much more agreeable, more seamless.

Good practice of decomposition for Apex classes.

So we've spoken about, we've spoken about the team.

We've spoken about at owners curating the backlog.

Architecture is the is the phone focus here, having a a defined and clear architecture One thing that surprised me when I moved into the Salesforce world for sure was the, the difference in adoption of things like the object oriented standards, the the gang of four, the those those patterns, use of interfaces, and all this sort of stuff.

The single responsibility principle, if you've ever looked at an org and found a a trigger handler class for an account or contact that's three and a half thousand lines long.

You'll probably realize that that isn't often it's not quite as common in Salesforce as maybe it is in other in other environments.

Thinking back to how we defined the merge conflict, two different branches changing the same bit of metadata in ways.

A class like that that's three thousand lines long is a prime candidate for attracting merge conflicts.

Salesforce when they brought out SFDX attacks like the object file, these huge monolithic object files that that were just, again, thousands of along and split it apart so that each field became its own file. That's essentially what the single response this is what we're looking at for Apex classes here.

Smaller classes, more classes, smaller classes, classes that do one thing, that you haven't got these huge trigger handler classes that do absolute everything related to it, you know, inserting other objects, deleting things that aren't even related to the object that their trigger handler for.

If you've got patterns or, strategies, you know, that there's some sort of alphabetical order or all private methods go together or something. It's very easy for two developers working on a busy class like that to try and put something new in at the same point. On different branches.

And again, that's exactly how a conflict come about.

It's not just a crashes though. Of course, now flows. You can create sub flows. You can you can also create some pretty hefty old main flows that that could become like the the monolithic Apex classes. So you can split flows apart as well.

I'm not sure quite how, things like profiles and permission sets really escape the SFDX, model.

There's still these huge monolithic XML files, which are obviously you know, tick any number of boxes for being susceptible to merge conflicts, but there's we'll have a look at some I some alternative approaches that can help with those sorts of files. But we seen across these five examples how various roles, not just developers. We might frame merge complexes. There a developer thing. Right? There are things that developers get that developers have to solve, and they do, you know, developers do end up with the consequences of it, or maybe release managers we discuss, although that's not ideal.

But the avoidance of them in the first place can be more of a team exercise.

You can anticipate scenarios in which they're going to emerge, and you can work as a team to address that.

So one other I'll just do a quick time check. That started a very odd number. How are we doing? About ten minutes. Good.

Alright. So, the strategies that we've looked so far, have covered one of the two common use cases. We said there were two main causes. These were long in feature branches, and Salesforce's representation of XML. What we've looked at so far largely fits in that first, well, exclusively fits in that this bucket. Smaller stories, more agility, more collaboration, lots of DevOps things.

Now pipeline earset pipelines will will cover both.

Pipelines is our functionality to give you this high level overview of everything that's going through your workflow, you can you can see you've you've probably seen this in other sessions today as well. So you may be familiar if you're not, a gear set customer of the representation of features going into orgs, where you can see the components that in there. You can see if there are any conflicts, you can resolve conflicts within gear set.

But it gives you this high level over view of your whole workflow pipeline. One also has though is a proprietary semantic merge algorithm.

And this if you think back to when we were describing, the XML and the the the concept the the paragraphs in a book all starting and ending with the same thing, and how you have to dig into the middle bit to know which one, any particular paragraph was.

The is what gearset does with the Salesforce XML. It knows what Salesforce XML means. It knows what the relevant, you know, the significant properties are in any gear and file. So if you give it a profile that's all come back jumbled up on a feature branch, when the developers pulled it from the org, when compared to what's in environment branch, then gear set can reorder that because it knows what blocks make sense, and it can find when your version control system has thrown up its hands and said, this looks horrifically conflicted.

If you ever seen a a conflicted profile XML file with fifteen hundred reds and greens all over the place.

You can see that in gear set and say actually, there's no change or there's one new field. That's the net change here. So gear gear set understands that and makes those sorts of conflicts disappear. This isn't about avoidance. This is about actually realizing that there is no merge conflict in the first place.

We've got a merge conflict UI. You can resolve the conflicts directly in gear set. You used to just be to choose a theirs or hours scenario, but you can even now take certain chunks from one side or the if the if the resolution needs to be a, combination of the two. We that like we said at the start, there's no automation. We will show genuine merge conflicts.

It's just the semantic ones that Gearset will solve. If two people have changed a label to two different things.

That's a real merge conflict. And gearset will show you that.

You actually get to a scenario where people have changed the label in two different ways is another matter. Maybe that's some something for the five steps that we looked at before. So We've spoken a number of times about culture and teams working together in collaboration.

And, ultimately, that is the bedrock of DevOps. And so it's just focused on a specific something like complex might seem to developers.

Actually, teams working and embracing dev ops as a way of working is a mental part of improving your process such that you not just avoid merge conflicts, right? But increase that performance as we were just seeing in the last session, they're getting those metrics, whatever they are, whatever's important to you, climbing in the direction that you want them to go.

By combining those five strategies, use of gear sets pipelines as well for the bits that the strategies can't handle, they're now get you definitely climbing your dev ops maturity and getting those numbers going in the the right direction. So we'd recommend anyone here who a custom of gear set.

To take out the fully featured thirty day trial, you can You can use pipelines. You can use every every bit of the gearset platform, and benefit from all our instant human support and all the good stuff that I'm sure you've learned about gear set across the course of today. So far, So, well, I should mention as well actually that straight after this, or after straight after this is coffee.

After coffee, there's a, a meet the product owner's session in the library room, which is upstairs on the right.

What be representative of the pipelines feature, as well as other other areas of the gearset platform. He'll be delighted to take your questions and, your comments about about anything gear set. But with that in mind, if anyone's got any product specific questions, that forum upstairs would be a perfect place for those. But if there's anything more conceptual about what we've just heard, then I've been liked it to take any questions now?

Nothing. Nothing. Nothing, that case. Really? Nothing?

Really?

Nothing. Nothing. Nothing. Cool. Well Merge conflicts. Don't don't don't get him anymore now. No. No excuses we've got merge conflicts.

All gone. Well, lovely. Thanks very much, Jeffrey. Thank you. Alright.

Let me consult this quickly.

Coffee.

It's a break. We've got half an hour. Those of you that are on the live stream. Hello. Hope you're enjoying the afternoon. As well.

We will reconvene in thirty minutes time, so at three fifty pm. Coffee's up in the river room. Same place that you got same place where the exhibitors are. We'll see you all again soon.

So yes, ma'am.

Day.

No matter where I go, I never find a bed Sometimes I feel I've got Run away. I've got to get away from the pain you drive.

Where, and I light my light, but I touch and turn again sleep at night.

One I run from you.

Now I know I've got to run away. I've got things, right? You need someone to hold your time, and you think But I'm sorry. I don't pray that way.

Could give you, take my tears and that I love you though you admit so.

Now Things in love.

When do you wanna come?

Would be it? I gotta care, baby, by the way.

That's what I should probably warn you. I'll be just that's what you wanna do.

Let's go girls.

I'm going out tonight.

I don't have Man, I feel lack of woman.

I'm gonna take the chance to get we don't Now, now, now, now. There we go.

Hello, everybody.

We are into the homestretch of the day. I hope you've all had a fantastic time up until this point. We have two more sessions left for you this afternoon.

Today without further ado and to kick off the first of those two sessions, we're gonna have Ben and we're gonna have Adam in conversation with Mark Arnold from Gearset. So it's all yours. Thank you so much.

Hi. Good afternoon, everybody.

As you can tell from the the big picture up there, my name is Mark. I'm one of the customer success managers here at Geerset.

And yeah, it's my pleasure to be on stage with Adam and Ben, from former and and DVD today for this fireside chat. And it looks pretty like we're all we do actually just miss the fire side because we've actually got, like, some really comfy chairs. I kind of feel like a leader, pint of getting in front of me and I'll be be well away.

So guys, you wanna sales. Sure. Yeah. So my name is Ben Coleman. I'm CEO of Performance.

So we're a Salesforce Consulting SI within the UK, and, we worked with DPD for almost seven years, I think now. Yeah. Hello. My Adam Hooper.

I have the grand title of the head of central platforms at DPD. Basically, we look after Salesforce, telephony, and all the platforms that nobody really loves, but we'll say, I'll go. We'll have a go. Me too happens.

Again, we've worked with these guys for a very long time, sort of know each other inside out and just really cool stuff, with Salesforce. So, yeah, she had to chat about that, I think. Yeah. Cool. We'll explore some of that in a here. So really the aim of this buy side chat is to, is to try and bring to life a little bit around, like how enterprise organizations such as DPD, work with outsourced organizations, like, like pro form a.

You know, the idea of kind of bringing in bringing an outsourcing company can be a bit, a bit scary sometimes. So we want to sort of debunk some of those we want to kind of be quite honest about some of the good and the bad that happens, and kind of just tell you the kind of journey in the story that these guys been on together over the last seven, eight plus years, and continue to do so as well. It's a it's a great story.

There's been challenges, which we'll dive into a bit as well. So, yeah, so I think it'll start off if it's alright, Adam with yourself. Just kind of, kind of, why did you, why did you choose to go with an outsourcing partner rather than them, than build out buildings. We have, we have a team, in Birmingham, and all of us out of here is part of that team.

There's ten of us in the office, but not developers, we're not coders, right? We'll do everything up to code. So we'll do all the BA work, the requirements, the design, all the clicking, clicking and stuff, but we're not coders, right? We can probably and have a bit of a stab at it, but we're not we're not great.

So we need we need help to do that stuff. The challenge that I have is I don't have the same amount of work every day or every work, every week developers. So I can't it's tricky to employ four of them full time because I may not have work for every day of the week, four of them. So that doesn't work for us.

It gets very messy. And also then suddenly a project will arrive. I need to quickly ramp up people, but that takes a couple of months to go through the recruitment cycle. And then, you know, we we've unfortunately employed developers just hasn't worked for us.

We have to let them go. The quality just isn't there. So then then we look to somebody like perform IT to say, look, we we've got a need. Can you help and you are a big enough organization that you can scale it very quickly, you know, we'll let you know with a week's notice for two weeks.

They've got this big project. Oh, yeah. We'll find somebody for you. No problem. And and sort of, it's how it sounds awful, I just I just pay you and you make it all happen, right?

Which which works really well for me. You sent me a bill and the quality is there, you look after the people, you deal with the HR stuff, I just know there's the right number of people in the right place at the right time delivering the quality I need, which makes my life really easy, which works really well for me. As a fairly lazy person, that's great.

So we have that. I think the other challenge I have as well is the UK, the UK market for developers is is quite challenging or it has been in the past for for people could go out and contract at seven hundred eight hundred pounds a day. Why would you wanna come and work for me as an end user for a lot less money? Why would you not go out and earn as much money as you can, take six months off of the year.

In fact, we know what we both notice already does that. Take six months off the year, goes traveling around the world, and then goes back and takes another six month contract. Can't offer you anything exciting. I have an office on the edge of birmingham that looks over a train line.

Like, it's it's not it's not the same as doing you know, and the freedom that comes with that is is is different.

I think what works well in terms of our financing is that because they're kind of the way we work with with formalities, we have a couple of people dedicated to us each day that do hotfixes and bugs and little projects, and then we come along and go right now. Here's a massive project. Let's work out the cost and we'll do it that way. But we race out through purchase orders.

So it's it's a CapEx rather than OpEx, which means it comes out different budgets. And that makes our final activity really happy. It's not an ongoing cost. It's kind of, it spikes and peaks and troughs.

We plan for it. We kind of roughly know spend each year, but it just makes our finest team a lot happier, which is a really boring answer I'm afraid around money. But, so there's like a scalability and, yeah, and you also you just have a variety of people. You've got three people, you know, this guy looks after UX, this guy looks after design this does this, like, I can't, I can't employ all those people because I just don't have the money to do it.

I guess, like, kind of where we've got technical architects, solutions architects, those are people that you want, you do want to involve in a project.

But again, to Adam's point, you might not need them every single day, you know, for six months flat, where, you know, we have those resources that we can kind of deploy as and when needed. And across our customer base that, you know, we have sufficient work to keep them occupied. But again, to Adam's point, maybe you don't, you know, if you don't have sufficient work. Yeah.

I mean, the fact is that we have well as where you do work on some of your projects, you have a breadth of experience that we don't have. You know, we we we live in our little logistics DVD bubble and with it, you know, thing. But actually, you guys would come on go helmet. With a previous customer or client, we did x y and zed, you know, that's a much better idea.

Like, we, we, you know, we, we're good at what we do, but you have a level of experience to us could just spread all these things. And I think what what also works really well is maybe that's just the way we work together, but it's gonna sensory of people. We've worked with partners in the past where we'll start a new project in incomes of different TA, incomes of different BA. Incomes of different solutions guy.

I suppose first two weeks getting them up to speed, whereas with you, we've worked the same people for five or six years, and they know it's inside out, you know, we'll just pick up a project off we go. Or I might have a question about something. Six years ago, which I don't know how it works. And we'll go and grab one of the team and I'll go, Oh, yeah.

I remember. It's it's it's the way your work is great. So that's that's great to kind of here, like reasoning, but you've you've you've brought in a formal idea or an outsourcing partner and things as well. So, let's get into kind of like the more gc part of the conversation where like what some of the challenges of of working with a partner with an outsourcing partner, it doesn't have to be just formal, but as in what are those challenges look like for?

So so DPD are a nightmare to work with. Okay? We're we're we're we're not we're not an easy one to people's work. We we Okay.

So it's quite a closed room. The the DPD in my world stands for different it is daily. Okay? Sorry to speak to you, which some people say it's delivering people's dreams, but it definitely isn't.

Right? It's it's different writings daily. And Oliver, again, you'll agree. Right? Everything we do on a Monday is not what we're gonna do on Monday.

It just it just changes constantly. And that that can be a frustration to a partner. You know, when we got into discussions with you, the first thing we said is this is not going to be an easy ride, right? Because we are we're at the forefront of what we do with our technology delivering, and we push and we push and we push and we push and we push Salesforce, we push our partners.

So when we come to breaking point, we've got people that have walked out on us as a business business, but we're really successful in what we do, but you've got to be able to keep up with us. And and, I mean, we don't use the word agile because we think we're further than agile. I don't want what the next step from agile is, but there's a big point, we're better than that. And and that's challenging to keep up with.

Right? I'm a nightmare to work with as well, and I'm aware of that. I I have a habit of going into circles and making things, because it's been that long now since I've been hands on with Salesforce. I still think developing the live system is fine, right?

Other other people have very strong opinions against that. I think it's fine, right? And I know not, by the way. Right.

But, usually if something was broken in the system, the first person you look at is me, because I've definitely probably broken it. But then you guys have to come up on a mop up after right. Yeah.

The biggest the way your biggest challenge lies is is mopping up afterwards.

To be to be serious, the biggest challenge we have is communication Yeah. We we sit in our office and and you guys are whatever you're dotting around doing, whatever you're doing. And if we sit next to each other in the office, we can at things, and we can go, let's do a quick diagram, and let's think about this. Well, that's fine.

It makes sense to us because we're there kind of making eye contact and things whereas, you know, we do meet up and we do things that you guys come into the office, but generally, it's an email or a quick Zoom court. And it's about we need to you enough information to understand the crazy thing that we've just invented in our head and the context as well. It's usually really important. So I think it's the communication.

It's taking us a long time to get you know, we're seven years in now. And and when we started, it took us a long time to find our group. Right? And we we would have frustrated conversations, and you and I would have frustrating conversations.

Because we just hadn't quite got there yet. But but now, you know, we understand that things need to be in a diagram and things need to have context and are you doing this? You know, because it's just important that you guys understand. That's the biggest thing.

So from Ben, from your perspective then, like, sounds like Adam's are matter work with. But, like, in terms of the challenges you're experiencing or have experienced and wait how you've worked through some of these, that look like from your, from your seat? Sure. Well, I think, the way that we engage with DPD, at the time when we, we engaged, is a little bit different because as Adam said, you know, he's got a sizable team.

He's got a lot of business analysts. He's got project manager he's got, you know, administrators, advanced administrators. So, you know, he's got a lot of skills in the house, and really, I think, to that point, back we were used to engaging and completely owning a project, so doing all the project management BA admin development testing, you know, own and deliver the whole thing. So I think that was a bit of a, you know, a change for us just kind of working out, you know, and understand and what that looks like for DVD and how in reality that will actually work and how we'll share work and to Adam's point, also, you know, communicate you know, what what what DVD might think is is a great requirements document we might okay, you know, that's missing a few things or or or not.

You know, so so there's those sorts of things to do. We we have a good information, but we can have quite a blunt and direct conversation. We do. Yeah.

You found me the week if you do that, you're gonna break sales or stop it. And, like, when our team have done something, like, our team are really worried if you deploy this, it's gonna blow up. We're like, okay, well, we'll stop now. Like, we'll go back and rethink this.

Like, you know, it's it's quite challenging to be able to turn out your customer and go, you're being stupid, and you use those words, but you could do. Yeah. Yeah. Absolutely.

Yeah. No. You've got to be, delicate and diplomatic, you know, in terms of how you communicate. And as Adam was saying, you know, communication is key, you know, we've got it, off- Pat now.

You know, we've got lots of systems and processes in place. We have a regular cadence of meetings. Be they daily stand ups, project meetings, you know, kind of meetings to discuss BA and then also strategic ones where we're talking about longer term plans. So, you know, that's definitely something that you've got to get in place.

I think one of the things that we touched on is, is speed. So, and that's obviously really relevant to gear set and DevOps, as Adam said, they've got a huge, you know, kind of backlog of innovative projects and they wanted of them at speed, continually and not stopping, but also on time on budget to quality. So I think that that's, you know, where Adam was saying, you know, can be challenging. It definitely was.

And I think sort of, for us, probably the it over COVID, you guys pushed us really, really hard. I mean, the, the, the volume of projects. I mean, we will be rebuild a whole course because I drink over, didn't we? Yeah.

And rolled it out. That that was hard. There were some long weekends, which to be fair to you guys, we didn't even know you were working long weekends. We just did it.

Yeah. And the which we're now. Great.

That's about me. Well, we we we we, you know, we wanna deliver, you know, we don't. We don't. Like I said, it leads to the next question as well, which is like, as you've got through those challenges and built yourself through those challenges, like how would you say the partnership has strengthened over that over period of time.

So I think, I think we're investing in each other's success.

So, you know, you were grown in a size phenomenally since we, since we work together, they were sure that the same level of quality, which is all great, But we're we're invested in your success. We want you to be successful because we want you to keep working with us and doing cool stuff, feeling employee and great stuff. But then you want us to be successful so we working with you ultimately, right? And it's a very symbiotic relationship.

We get we get you some cool stuff, let's be honest. Right? We we we do develop some really cool you know, we're very lucky that between us, we've designed and built what is currently Salesforce view as the best example of service cloud in Europe, right? We we did that during COVID, right?

There's three built now, and it's still used every month as a reference by Salesforce. And we designed that, right? You and I did that. We sat on, like, literally Ben and I did that over Christmas.

Twenty twenty, and then into January. And, like, part of the proudest thing I've ever done. And, but we've done cooler stuff since that, and we just keep pushing and pushing. And what's really great about your team is I'll speak to them on a Friday afternoon and go, I've got a crazy idea, and we'll go through it.

And then if they really like it, they'll give it their they'll give it their weekend in their free time and build it because as geeky of ourselves versus I am on our team, you know, which is which is cool, and we understand each other really well. But it has taken time to get there. Right? It's not it's not.

Doesn't just happen? No. Absolutely. And I think, you know, I think time, is important because, you know, yeah, we have to we have to get each other, we have to understand, how each of us works, our businesses, strengths, weaknesses, you know, implement processes adapt to them.

And I think ultimately what that's done is that's now built, you know, a really solid open relationship, you know, feel that, you know, we are. Well, you've helped us to be better than we do. So, you know, I've I've run this team for a very long And when I first started, it was a bit like the wild west, right? Because no one was that bothered about Salesforce or DPD.

I could sort of get away and do what I wanted and know real processes it was fine. But now it's kind of the biggest platform in the company. I could have some proper processes, which which is great for my team because I know what they're doing and great for you guys, but you you've helped develop those processes, you know, with dev ops, with using, you know, Jira and Monday properly and sprints, you know, sprints wasn't anything until two years ago. We kind of deploy stuff and hope for the best.

And, you know, it was frustrating. We didn't really know how to solve it. And you know, we had some very open conversations with you about, well, how do you work with other customers when Okay. We'll just sharpen up a little bit here.

And, no, it's beneficial for both of us, right? But we we learn from you guys all the time as well. We'll do a bunch of jobs. So you've always had a massive, like, in terms of like the development of our cycle, how you develop it on the platform, what you're doing.

There's been a massive impact for the DPD in terms of what the outsourcing company has been able to, we've always been able to IT you as well. Well, and the reason we have hearsay is because you guys said you should look at hearsay. Yeah. And we needed a tool, and actually, you know, all of our other people love it.

It's great. And we wouldn't have known about it unless you guys tested it and same with Yeah. So the products that we've got, you know, you you you you challenge us to be better, which is what we weren't a partner.

It's awesome to hear.

I didn't pluck the gas out there either, by the way. That's just come coming from That's a that's a check coming later. We we'd I mean, as Adam said, you know, just open, you know, happily plug gear set in terms of we, we adopted it ourselves as a business because we, you know, we wanna make sure that we're delivering on time to quality budget for all of our clients and gearset helps us do that. But, you know, as as we said, you know, not using that with Cbd was holding us back.

So it just made sense for us to adopt it. And it has made a huge difference, you know, shorten the, the, you know, the development time where we're all on, we're all much more aligned. We know what's happening. The management of environments is fantastic.

And we've still got our way to go, but you know, a massive game changer.

Awesome.

So what do you see as like the next steps in terms of their relationship?

If you get them on that one.

Well, as well as building more cool things, that's kind of, that's ambition in life. There's a really cool in Salesforce. We've already did a bit of a health check. So our platform, our portal, our platform is thirteen years old now.

We've already removed most of the legacy code, but there'll be some stuff floating around somewhere. We've got apps in there that need removing. We need a big tidy up basically, a big spring clean. And we we did attempt to do that this year, which put put six weeks aside in October and do it, and I've done none of the jobs that were given to me.

And I'm sure I've always done all of his, but, other people in the team haven't, like, just to be too busy is what it is. Right? So we need to put some time aside and just grasp all your guys and go, just tell me how to fix all this stuff. What have I gotta do?

We have challenges now this time of year, been a parcel company busy this time of year. The call center gets very busy.

We've got to make sure performance. So kind of we go into kind of maintenance mode now for the next sort of six weeks, and you guys are pretty much on call twenty four hours a day in case something breaks.

Not that it will do, because we've we've all our work. And then next year, we just we just keep pushing and pushing. We've got some cool projects lined up.

Yeah, we'll see what it takes us. I think it's what I've had tell you now what we're gonna do next year and it'll change next week. So it's not always on with me telling what we're gonna do. You gotta do, right? You gotta take EPD, right?

But yeah. What are you thinking? What what's from from your cyberity you, like, ways you'd like to see things progress to you with with the relationship and what you want to do with DPD? So one of the things that that is progressing, in the background is, so off of the relationship that we've had with DPD UK or CTPD is a large National Group.

We also support the team, at DVD Island. We've done their implementation, and we kind of work on various projects with them. But Adam's kindly introduced us to other parts of the group within Europe. So there's a couple of, European countries now that we're just starting to engage with. So I kind of see that. And very much, you know, the great thing for Adam is, you know, DVD UK is seen as a, you know, the kind of leading light, you know, the shining star of, you know, this is how to do Salesforce really well in the group. So all the other countries kind of look towards Adam and and the UK team to sort of follow their lead so we're, you know, I'm sure we can help some of the other European countries, catch up and and improve their Salesforce implementations.

I think another thing, just in terms of efficiencies and so on, you know, we haven't got into, gear set pipelines yet. That's something that we need to do. You know, we you know, CICD was a game changer we need to, we need to keep pushing.

And I think also one of the things that I've noticed recently is that where, as Adam was saying earlier, you know, We've typically, helped him with a lot of development resource and technical architect.

But we're also finding now that as Adam says, you know, where get spikes where the business is demanding projects, pretty quickly. You know, Adam's now called on some of our business analysts, some project managers to, you know, help deliver, you know, kind of iron out those, those spy weeks. Yeah. We've got a project where we need to be ages for eight weeks.

Now there's a waiting list of nine months. And certainly, I can't wait that long. I'd rather just go and grab Charles that works for you. And he'll come and do a great job.

You know, just we know him. Yeah. Makes sense. He's in rearchitecting at some point as well moving towards potentially.

Absolutely, yeah, no. As Adam said, you know, it's thirteen years old now the system. And there's definitely some, you know, I can think of a few is particularly within Service Cloud, where it's kind of creaking under the volume. And there are projects that we're looking out where we're, we're now thinking, hang on a minute, we need to step back.

We can't just rush into this because there's definitely some areas that probably need re architecting when might need to rethink how we're going to do some of the future projects. So, yeah, that's definitely on the cards for next year. Cool.

Concerts are I've got a few minutes left, but, we're going to leave, hopefully, of Adams and Ben's final thought, bit, but Jerry Springer style.

But if you were to give, like, a biased audience, here and the audience listening online about bringing in a consultant or working with a, an external provider. What would be like your up three, four ish things. So I think, communication we've talked about can't communicate more about communication.

Ben, Ben's company has won two awards this week for investors and people. Like you are the best small business on the five hundred people? Gold work for gold. Gold.

Right? Which is exactly right? But not many companies win that, and and that is one of the reasons that we work with form IT because actually you do really care about the people that for you. And we care about them as well, then we have that that really powerful relationship that works well.

Like, that's a massive achievement that you've won this week, and it shouldn't be underestimated. I think we've worked with we've worked with big partners in the past, and and it just hasn't worked for us. We've not that we want to be we don't want to feel important, right? We're not we're not that special, but we at least like consistency of people and people to listen to us.

And we had a project years ago where we there were lots of bugs. We got handed massive bill to the end of it, and we were pretty outraged that we'd be expected to pay for things that weren't our fault. So we fell out with those people. Whereas if we'd had proper communication and talked about it, we'd probably of that.

It is communication. It's it's about when something goes wrong, just being able to pick up the phone and have a conversation. I'd I'd I can't go back to communication, but I think that is actually the answer. Yeah.

If it wants is having the right people to work with, you either gel with some people or you don't. We gel quite well, and and your team get on really well with our team. And also just that shared vision you know, you wanna do cool stuff, we wanna do cool stuff and, you know, it's, you know, there might be your team, but really they sat next to us in the office virtually.

We're all one team. It's got no segregation. You are us and we are you. Yeah.

And I guess that's a slightly different question for for you, Ben, it would be around, what would sort of put you off working? I know this might be a bit of a challenge, like, unfair question, but What would put you off working with with a customer? I guess you want to work with all the customers, but they're sort of like red flags. You see that you think, oh, actually, this is going to be a bit of interesting project or something?

Yeah. Well, I think if I look back, you know, over the years and look at, you know, our customer base and look at those clients still working with us and some of those who are perhaps not. I think some of the things, that I would probably pick up on is, as we were saying, you know, that openness, that transparency, that honesty, that being able to, you know, we don't play the blame game, you know, problems happen we talk them through, we figure out what went wrong. We make sure that it's not gonna happen again.

But we're, we're completely honest, open and honest. And I think that, you know, if I look at you know, clients that we continue to work with, you know, years on years. You know, we've got that, and we've got that trusted relationship. So more, I see where it works really well is where it's a true partnership, rather than just a kind of transactional thing where it's like, do a project, but, yeah, kind of, I think it's just Yeah.

That's it. I think as well, we'll come to you and also work. And you will sometimes you don't need to do it like that. There's a much cheaper way of doing it, which actually we we really like, you know, it's easy for a partner to see you as a cash cow.

And, you know, we spend a lot of money, but because by more money, but your guys will come back and go, you don't, you don't do it like that. And we trust you to make sure that we're making the right choices, and I think there's there's that that trust is a big part of it as well. Yeah. Yeah.

I think actually another thing that we, you know, we, you know, we do see is, you know, over the years, we've seen a lot of people wear that the the communication is not great from the clients. So they're, or either that or they might be hiding things us. And we're we're kind of more like, you know, if, you know, if you were thinking this or thinking that, it's just just be easier just to just to tell us, so we can adapt to that.

And I think also, you know, sometimes where you just get that kind of, I think sometimes times clients can be a little bit over optimistic maybe on what they think they can achieve. So there's always a pressure on us to, you know, well, we need to start on this day and we need to deliver on that day.

But most of the time, I would say projects don't come in on time because actually we're waiting on the client, you know, have you done that testing? Have you signed off those requirements?

Have you you know, whatever procured these licenses, etcetera.

So I think, you know, that's that's something that, obviously can cause issues, I think. So it comes down to four things in which he's like honesty trusts.

Communication, communication and realism. Yeah. Essentially. It's just being realistic with each other. Yeah. That's it.

Yeah. Yeah. We would, yeah, we like to think like you say you know, that we can work with, with all organizations, you know, and one of the things is, you know, we so we do we are very flexible in that we have, you know, clients who want to engage with us in different ways, you know, we've got clients who who want us to manage everything from a sort of managed service perspective, or clients who say, actually, I've already got an in house admin team, but they are going to need support because there's kind of up to is they can do those things, but beyond there, they need, you know, someone that can bring in additional skill levels from them.

Exactly that, you know, they can kind of consult with us and the same with projects, you know, is it that actually, you know, they've got a team. We work with quite a few companies who've they've got an house development team, but actually they've just hit a spike of there's more development, there's more projects than they can handle. So they need to augment their team temporarily maybe, you know, for three months, six months, whatever it is, or take a project, off them. And I think the thing is, you know, so it's that we take it really seriously that, you know, we are owning that project and we will make sure it gets delivered.

You know, come you can become extension of the client. I would say it from that point of view. Brilliant. Oh, guys, very, very much.

Open it to the audience if there's any questions straight away.

I have two. That's fine. Number one, where this, the product ownership lies over the year, most honestly, like that. And then the second one, how did you, handle tech debt over the years, or was your intro earlier about your goals for next year?

Is Right. Should I start? Yeah. So I I own the product. I'm responsible for Salesforce across DPD.

We enjoy you to be the guardian of Salesforce, if that makes sense. You you you get in under the bonnet and do all the cool stuff and say, here's a problem. Here's a problem, but I'm responsible for making sure that If it doesn't happen, the Salesforce falls over, it's either against a phone call, and then my phone bell and cry, and and ask for help. Right?

In terms of tech debt, we'll always have tech debt because we move so fast. We'll take shortcuts if we have to. We shouldn't do what we do with humans.

The biggest issue that we have is is forgetting about the shortcuts we've made or the things that we say, oh, well, we must go back and fix that, and we don't. We've got email templates from two thousand and thirteen that we don't use anymore. They've just gotta go spin, but we just don't have the half an hour sit at work out. We really should do.

It's a really simple job, just delete, delete, delete, delete, but actually there's much more important stuff to do. It's not causing any problem, but at some point, it's gonna get in the way. We're gonna a limit or something. We've got we're about to hit the limit of, custom fields on the case page.

I need to sit down and work out which ones to delete, but that's a good couple of that actually just forget what what we struggle with, I think, and where you guys do help is all the five minute jobs or the, can you just kind of work this out for me? We'll always have ta ta ta ta ta just because it's been move. But if you know it today, you can do something about it. If you kind of align to it, then it's, then it's a problem.

Yeah. I think, so the with a lot of clients when we engage with them. We'll often start with a health check. So we'll basically take a really depth look at their org and understand and look at, you know, what's the tech, you know, the tech debt that's already there.

And that's really important because, you know, we definitely certainly have, hit in the past, the issue where, the clients our, you know, our orgs fantastic. There's nothing wrong with it at all. It's all hunky dory, and then we, you know, we develop, some new function until you go to deploy it and actually, oh, hang on a minute, you know, you haven't got enough test coverage and this, this was missing, and there's a problem there.

So, you know, so it's important for us to do that, that health check. And I think in terms of technical debt, I think it's one of those things where, you have to start somewhere. You know, it could be, you know, if you've got a thirteen year old org, you know, there could be quite a substantial amount of debt there. And, you know, we have had some clients in the past. You said, I just want to sit and completely, you know, all of that in one and then move on.

But generally it's more what we do as we tend to look at it and say, okay, well, we know the size of the entire issue. Actually based on your pipeline of projects, that are coming up, we really should address these areas because they might impact on that project. You know, and so we can basically come up with a plan over time and a prioritization of where to start with that technical debt.

Brilliant. Thank you. We haven't got any more time for questions. So these guys on machinery will be But we're around. Around for a beer after, so if you want to grab them and ask more questions, then please feel free to do so. Or if you've got other questions, then feel free to push them towards me over the next few days and I'll get the responses from these guys as well. But thank you, Ben and Adam for joining us today.

Thank you.

Okay.

Just do a quick switch over and then the one last final talk of the day for you, Johnny Harris from Zurich is gonna come and talk about his dev ops journey at Zurich. So We'll do a switch, and we'll be back in in just one second.

Ready, Greg. I think you. If you want to speak, and, we do Good. Sure.

Hi, everyone. Thanks for coming to the last session of the day.

My name is Johnny Harris, and I am the south force demo engineer at Zurich, a new recent job role, but we'll get to that shortly.

I'm sure you'll all be glad to hear that the this won't be a technical presentation this late in the day. It would just be a walk through my first five years with in the Salesforce ecosystem.

I'm hoping to kind of bring to life what I've achieved, some are learning, some of the challenges.

That I've experienced doesn't come through.

What you should be able to see come through it is some of the stuff that you've seen today around dev ops is actually how that can be used for your own learning and development rather than just always talking about technology.

I working within a dev ops team for the last five years, it's really pushed my career forward at quite a rate.

It's allowed me to kind of experience a lot of different things.

Okay. You should see some key takeaways up there.

I mentioned, so one of the key takeaways I hope you'll get from today is actually the continuous learning that I've gone through.

I'm sure you'll see and you'll know how important it is in our industry to continuously learn.

As we've again heard today and you'll see over the last year, how quickly something like AI has come upon us.

And if you're not continuously learning and developing your own skills, you can very quickly get left behind in our industry. So it's important to spend time and focus on yourself.

Not always just doing the work.

You'll see self development up there.

That one's more around being kind of like that clean Shay CEO of your own career. Noah's gonna sit and force you to do a trial heads. Noah's gonna sit and force you to do the next verification you want to get done, but actually you need to make sure you do that yourself so you can push yourself forward.

Hopefully you'll be a little bit empowered. Again, bit cliche and actually a bit ins inspired from this chat of seeing what I can do and what I've done in the last five years. Hopefully, you will take that away and go try and push on yourself as well.

And also life isn't a highlight reel.

We all get challenges as we go So it's it's good to understand that that can happen. You know, there are ups and downs and you'll see that throughout this presentation.

These takeaways are kind of what I found myself referencing back to.

As I was trying to bring together some sort of presentation for today, guess that asked me to present and it it kind of helped me look back and reflect and actually see where I've come from and actually is possible.

So Gonna roll back the years a bit and sorry to roll it back the other side of COVID. It's a tough one. So gonna roll back to January twenty nineteen.

This is my first year at Zurich.

I came in with limited knowledge around Salesforce.

My previous company, I was in marketing negative and I was using Salesforce as an end user, but I was building the reports dashboards really not using any of the kind of back end the admin work. However, when I was building the reports of dashboard, it kind of drew me into it a little bit more and wanted get to know a little bit more about how it was working.

So when I joined Zurich, in twenty nineteen, I suddenly realized how quick I'd actually have to learn and step into the deep end from the off.

So some of the things that were brand new to me, when I joined Zurich are now working with key stakeholders and product owners, trying to understand relationship that was required between myself, working in an operation side of DevOps and actually the wider business. So understanding what they expect from me, what I would need from them, how we have conversations around change, and what kind of rate, you know, incidents and fixes and bug fixes should be going in at.

I was trying to learn as much as I could around Zurich, you know, an insurance company.

It's a lot of new terms to take on trying to understand the new acronyms. It seems to be riddled with them.

And then also now working in DevOps, I never heard of it before. I joined Zurich, and now I was expected to try and work out how this how we were meant to work in this dev ops methodology. One meant what both sides of, you know, DevOps actually does.

I'd also now expected to trying to learn about agile, working in an agile way, and also trying to get to the basics of, you know, what a sprint is how does that work and using tools like Jira. So suddenly looking at a user story, understanding what a user story should how it has built what kind of information we need from the business on it.

I was also starting to learn how to use train sets. I know we gone there as Salesforce professionals using chain sets can be painful and being brand new to it, trying to move my changes through the different environments.

Really brought to light, you know, what you need to understand to get stuff through and actually how you make the changes.

And I was also stuck to a ten a change of forty boards as we've had today, you know, the the big meetings you rock up and some are suddenly looking at all your bit of work. Make sure if you're going there, waiting just to get it accepted to move into the production environment.

So some of the other key tasks that I was looking that during the first year. I was trying to build on my experience before building the reports and dashboards.

I was actually trying to achieve my ADM to one, it took me three attempts. So if you're ever doing it and it takes you more than once, don't worry about it because, you know, you'll get there in the end.

I was working in the operations team, trying to streamline some processes, and also using trailheads as much as I could to get as much learning from So you can start to see how already start to implement my learning into my day to day and actually try to iterate as I go through to improve myself.

So my second year of Zurich. It kind of gave me a chance to in bed my new skills.

Am I learning from from twenty nineteen it starts to bring through some new challenges.

So in twenty twenty, it was a year where I'd been introduced into the world of Release Management.

And I was now trusted and empowered to start to use some new deployment tools like Ant, bitbucket, bamboo, and the velocity build tool.

So during this year, I got a chance to be more involved with one of the major projects that the salesforce team at Zurich was working on at the time. And it kind of gave me then that working knowledge of working that agile way that I'd learned before in the previous year, but I was now working in that methodology.

I was going out and making the change request myself, going following the full journey through, not just turning up to the cab board to get the approval while actually starting the change, moving it all the way I've also now started to run the stakeholder calls with the business.

So I've sat in them, learnt what we've got. I've now started to actually run the myself.

And I was actually then also like I mentioned starting with the complete deployments using these new tools.

The deployments, however, did bring to life some of the challenges as you can read in the case study that Zurich has done with Geerset, and to quote the case study Some of the deployments were starting to now take three to four hours on a Friday night, and I have one colleague who took eight hours deploying profiles over a course of a Saturday.

And the the three to four hours deployment is actually me. So I was spending of my Friday nights, you know, kicking off the deployment at six o'clock using bamboo and sat there watching Salesforce spin round for the full four hours till it got deployed.

And with that, we're also starting to face full source code deployments.

It's because we didn't have a deployment way of we didn't have a regular cadence.

So it actually start to introduce more risk for adding a loss of time into our pre and post deployment steps.

So not only was I sat doing deployments, I was doing all the pre, all the posts, all the testing sign off. So it just the packages got bigger and bigger and bigger.

And also the challenge with the some of the tools I mentioned earlier, where they weren't easily accessed of all for admins and developers who are used to using change sets.

We actually had no consistent use of source control. We had no replica builds, so it meant it was really difficult to actually start to roll back any changes that did go wrong.

And actually some of those challenges is where we started the conversation with gear set and you'll see in the coming slides, it's actually developed, I think, and I'm sure the guys are back with agreeing to a really good partnership between from the gear thirteen.

So twenty twenty one, the year is three red for everyone, I think.

This year with a lot of workload pressure for myself, but it really developed my understanding and passion for DevOps.

My greatest achievement this year is actually I moved into a Salesforce developer role just two years after starting in the ecosystem.

And I need to give credit here to the training development. I've received that Zurich because without it, I wouldn't have got to where I got to.

And actually all support during the lockdown because I know we all kind of suffered in different ways, but I took quite a beating on my mental well-being during that time.

They really sported me well.

So this year is Zurich where we got gears up and running.

And it meant the major task for the year was understanding of the gear set functionalities, and then to be able to train them back out into the wider team.

This was a new tool, required to get everyone on board with, and especially with the new ways of doing deployments using the compare and deploy functionality.

Which allowed us to compare the different orgs, move metadata through a lot quicker and easier than we did using change sets.

And that actually, once we got it in place, made a massive difference to my own deployments because I went from doing a deployment on a Friday night be four to five hours. It now just took me twenty minutes. So there's a massive time saver straight away.

And actually once we got it rolled out, not only developers picked up the compare and deploy tool, but all the admins jumped on it straight away because it's easy to understand. It's a nice in UI.

And then midway through the year, Giza actually introduced the pipelines, and this is where my course kind of diverge merged, and my passion for the for DevOps actually really grew.

Starting to use this tool, it really made me start to understand how CICD works with Salesforce, what the best practices should be.

Allow me to develop a way of work with the new functionality.

And actually so much so I've got two and I think many more suggestions in actual product now that you see that when you're is offered by gear fit.

And you can see them where that partnership starts to come from.

Actually using that tool, seeing places where I feel there's a gap or something that we could be slightly better in passing that back and then seeing it come back around, you know, within quite a quick turnaround into the product is really great to see.

So actually one of them up there you can see on the screen to be able to turn back that back propagation.

When pipelines first went live, I think it was back propagating to your developer Sandbox and actually see suggesting to have a switch to turn it off and then seeing it with a really good way to be working.

And yeah, as I said, it'd start to show how that collaboration how the partnership started to develop.

And just to quote, again, gearset provided support to work out the right solution for and set up for Zurich, which allowed myself in partnership with gear set to refine the pipeline's process on the project which kind of formed the whole model to rolled out across all of the Salesforce, Zurich Salesforceaugs.

And just to add to this, I also challenged south this year to go on to a DevOps engineering diploma, which I'll jump on to now.

Let's check time.

So this was the DevOps diploma journey I started This course was funded by Zurich and supplied by Cornell to give a structured training and mentoring pathway to success.

This course ran over the next twenty four months, and it ended in a three month, presentation back in it as in two endpoint assessments, and there are two practical interviews.

One was discussing Devox best practices, and the other discussing my work that I'd done on the pipelines tool.

So the apprenticeship ran in four weekly cycles.

The first week would be reading week, the second a workshop, the third week with a kind of project work, and then the fourth with additional reading.

So that was all on top of my normal day today.

And some of the units we covered over the course, which really stretched my knowledge of DevOps so far and started to bring together the why we do DevOps. I knew how we do it and you know, in Zurich, but actually helped me understand why some of the history around it because I'll see again joining the company is brand new to me.

So some of you that really helped me was the general purpose of coding.

Actually, to be able to expose myself to other coding standards where I'd come from being a marketing executive. I've gone into Salesforce, only ever seen Apex. It's actually given me a chance to go and hyphen and understand that kind of different coding language.

We've start we also looked at automated testing using new tools and systems like Jenkins to run test scripts and start to get a bit more exposure to the other tools that are out there in the eco system.

One of the main ones for me is the actual DevOps culture, and how dev ops as teams should move forward and try and develop, in different ways, different toolings, and actually the continuous deployment and continuous integrations.

Again, we all see different tools working in different ways, but all achieving the same outcome.

And in the EPA, the endpoint assessment is actually assessed by the chartered Institute of IT and accredited by the British computer society.

So moving into twenty twenty two. This is kind of where my real passion and for DevOps came to life.

I've started to intertwine my apprenticeship with how what I was doing in my day to day job.

And actually start to like mention, bring the life to why we work in certain ways, and and really showing the benefits of why, and it helped me kind of have more in-depth conversations with the wider DevOps team as well and actually try and influence it in and ways that I've learned what actually are the best practices.

So in twenty twenty two, I actually managed to complete the twenty four month dev ops apprenticeship, and actually I achieved the distinction, and I was also nominated for the twenty twenty three dev ops apprentice of the year.

Made it through the final if didn't win it. Not faulty.

And then actually I got that far in got nominated as a finalist because I'll focus I'll focus my endpoint assessment on the gear set pipelines tool.

It'll allow me show what kind of automated CI jobs I'd set up, what monitoring jobs I'd set up.

Be able to track our code quality, work it in sprint actually working on Jira and following a user story all the way through end to end.

And actually, I spent a lot of time gear set launch pads.

It's a really good, I know we've talked about today, the good learning platform, and other try to achieve as many certs as I can on it, because it gives you a really good foundation.

I really recommend doing the Salesforce DevOps fundamentals there, and also Salesforce Devfleet ship certification.

They both were really fundamental in my kind of overall apprenticeship and be able to evidence and talk through and have those face to face conversations.

During twenty twenty two, Oils also, running a transformation project, and it ran for twelve months as there's an developer within that project.

And we, Zurich, for us, it was a cop one of the kind, we managed to Health, and actually we really drove forward the agile methodology with the wider business team. So all of our learn in DevOps, how we should work. We then brought the the business team on the journey with us.

It came with its own challenges, especially getting the wider business on board with agile and training them up. For them, they're always used to using work in a waterfall manner. Sadly now, we're taking them on a different journey and by the end of it, it took some time.

But we got there in the end and actually they they really saw the benefits of working in agile. Working in sprints.

So much so that a couple of the team are now implementing agile in their own data work. They're not in a technology way, but actually managing their day to day work.

Check time. Cool. So now come to this year.

As I mentioned, if you have just come off the end of a transformational project, which ran for month and it actually ended.

There's an extra sprint that came up after our hyper care.

And we managed to run it they're truly agile way.

So it's three weeks, and we actually managed to do a week of development deploy we could development deploy rather than the kind of waiting to a big package built up and then pushed it in.

And it really came to show what can be done with when you've got automated testing, we've got quick turnaround of business testing.

And all the other benefits that we showed during the project to the business, they gave us that trust to actually right let's go for it. Three weeks, let's try it, and it worked really well.

And as I mentioned right at the start, so you might notice I've I've now moved into a Salesforce Devil's engineer role. This is a quite a brand new role, the role for me and within Zurich, and it's giving me the chance to try and show what we can do over the next six months. So some of my focus is gonna be on our dev ops processes processes within the Salesforce I'm gonna be taking a holistic view and bringing together all of our best practices. So across what we do in projects and what we and ops and try and bring that all together into one good point.

I'll be working a lot on our on the gear set pipelines and trying to streamline the process we have at the moment in work around our deployments and getting a continuous view across the board.

I'll be focused on the gear set static analysis and implemented process around trying to optimize our code.

And then I'll also be building out a lot of documentation.

Around the processes as they change, and actually recently I read the, Door twenty twenty three report, and it it mentioned there that quality documentation is foundational.

It drives its successful implementation of technical capabilities and verify the impact of those capabilities have on an organizational performance.

Documentation also has a positive impact on outcomes such as team performance, productivity, and job satisfaction.

And actually, once I saw that, I've started to have a shift of set of documentation before are very much of, you know, we'll do that later. But I've now started to switch and think actually how do we help the wider team get to the place where I've got to? You need documentation. We need training. So I'm trying to now build out a bit of a backlog and portfolio to help the team come forward on the journey.

And with all this, I'm hoping that I actually alleviate some of the challenges and blockers the team are currently facing.

And I think a lot of that is kind of due to that lack of training, lack of documentation, and a requirement to all be aligned on one north star. I think, you know, they've kind of come round from over the last five years, the Salesforce DevOps team has grown from just five people to twenty six.

I think as we've grown, we've kept moving at a speed, but now we've recognized the team actually. We need to look back and cement that training in place. So every one comes who joins a team or anyone who's been here for a while, are all at the same place, not trying to all look at different ways and thinking, oh, that might be ripe. It might not be in trying to get that aligned process.

And just to the final for myself and from the case study of where we're trying to get to as a team now.

In partnership with Geifit, the team at the have ambitious goals for the future, and we're working to to establish a true CRC pipeline with automated testing across all of our orgs. So our vision is we wanna be able to push something into a feature branch, push it into the first environment, come in the next day. If in prod. Whether we ever get there or not, it's a different matter, but that is our goal.

There's just some useful links but I've kinda looked that briefly and talked about today. You're regularly now a lot of them. I think we've seen them in other slides today as well.

In fact, there's my LinkedIn issue. Anyone ever wants to ping me.

Johnny, thank you so much for sharing your story, story with us.

I think Johnny's story is a fantastic representation of everything that we have discussed here today. So it's testament to the leadership at Zurich for giving Johnny the opportunities to develop in the way that Johnny has been able to. It's a testament to Johnny for taking that learning and that drive to develop himself.

And he's also embodied all of those practices that we've been talking about today as well. So thank you Johnny again and for your time. Thank you.

Cool. Okay.

So one last thing. I am very, very, very conscious that I am the only thing now standing in the way of you in happy hour. So I will be nice and quick.

First of all, can I have a huge round of applause for all of the speakers that I spoke looking for us today at Deborah Freeman?

Hopefully, you've had an amazing opportunity to learn a lot from, this amazing bunch of people that have freed up their time for us today.

I found the sessions that I've attended really valuable, and I hope you have too. Can we also have a round of applause for the team at Glazier as hole and for all of the gear set staff that managed to put on today as well?

And we're gonna have a third round of applause for yourselves because by attending today, only if you learned something new hopefully and taking another step in your learning journey, but you've also raised six thousand pounds for the DC humanitarian appeal for Ukraine as well. So, so, yes, you have done some yourselves and you've done something for other people, and that's absolutely awesome. So thank you all for attending today. And again, I would reiterate, our thanks from the whole gear set team and all of our sponsors, that have supported us today as well. We really can't do these events without you either.

You will have noticed again, I'm plug this again. I spoke about it in my talk earlier, but if you haven't done so, please take the time at some point either on your journey home, providing you're not driving, and under that phone and and stuff.

To take part in the state of Salesforce DevOps twenty twenty four survey. You have a chance to win a thousand dollar Amazon gift card, which is either be super useful after Christmas or, or before. The QR coach there, you'll see the orange flyers around as well. Take one of those home with you.

Thank you. Happy hour. Go and enjoy yourself. Safe journey home, everybody. And thank you to, thank you for thing. Hope you all get home safe. Thank you.

Compare & Deploy

CI/CD Pipelines

Backup & restore

Lightning Talks

Compare & Deploy

CI/CD Pipelines

Backup & restore

DevOps done right

Ebooks & whitepapers

Webinars

Blog

Podcast

DevOps report 2025 New!

DevOps training

Help center

DevOps assessment

Why choose Gearset

Customer stories

Integrations

Security & trust

Events

DevOps Leaders

Feedback forum

New from the blog

Salesforce metadata analysis fundamentals for better deployment planning

New from the blog

AI and DevOps for Salesforce teams — benefits, risks, best practices

New from the blog

Built for scale: Gearset introduces Gitflow and automation for enterprise Salesforce DevOps

Lightning Talks

Description

Transcript

Contact us

Customer support