Beyond Admins and Devs: The new dynamics of DevOps teams

Share with

Description

It’s time to rethink the Admin-Dev divide. Join our panel as they discuss how teams can balance people and process, the rise of the “Admineloper”, and how to achieve team and career success by embracing diverse roles beyond this traditional divide.

Panelists

Transcript

Folks, thank you so much for taking time out of your days to chat with me and with the attendees and really get stuck into how Salesforce teams have changed over the years. I've worked in the Salesforce ecosystem for the last six years, and I've only focused on the DevOps side of the house and how teams interact and get their changes out to production and to their users. And to me, I feel a lot has changed in terms of responsibilities, who is going to really pioneer and lead certain initiatives with within a team. But I think one of those most interesting changes, particularly as it pertains to DevOps and what is typically seen as a very developer heavy style task is moving towards admin based responsibilities. And I wanna start with you, Kate. And in your role as lead admin evangelist at Salesforce.

For you, how has the role of admin changed over the last five years or so as as you've seen it and the folks in the ecosystem that you speak to?

First off, I love this question because at Dreamforce this year, we celebrated ten years of the awesome admin. So this is, like, very timely.

And it was a really great time to celebrate all the things that admins have accomplished and how the role has evolved.

Over the past five years in particular, I think that core responsibilities have changed, admins have more on their plates, and many of those things involve, more technical know how. So I see the role advancing, including some dev fundamentals as admins are, advancing their their admin careers. So you think about things like automation. Like, we started off with workflow rules, and then we went to process builder, and now we're using flow. And so just like the capabilities that are there within the system, as well as the different things that admins have at their fingertips to go ahead and troubleshoot events that are happening in their Salesforce instance is remarkable. So I would say that that admin role is continuing to evolve.

Admins now also have that core responsibility of product management, which is one we've recognized recently, understanding and, managing release updates in their orgs because they are designed to be that kind of Salesforce product expert understanding the users as well as the system and the declarative capabilities.

So I think that, the role has changed quite a bit. It's continuing to advance, and I am so happy to be part of this conversation because I think it's really timely with what we're seeing.

Yeah. For sure. Karen said something really interesting in the keynote, actually, and I think this is verbatim if I wrote it down correctly, but she said everyone's a developer.

Do you think that statement holds true? And do admins see themselves as developers?

I don't know if admins see themselves as developers, but I think that, it's getting to that point. Like, we still have I think that thinking back to when I started in the Salesforce ecosystem, which is going to date me a little bit, you would go to an event like TDX or Dreamforce, and they'd be like, oh, who is an admin? Who's the developer? And that was kind of it. There was, like, this split in the room, and now there's the evolution of all these different roles. There are the self proclaimed admin helpers. I think that really anyone that is developing on the Salesforce platform is a developer, whether that be pro code or low code.

Yeah. Yeah. Jessica, you manage a manage a team at American Fidelity. Tell me a little bit about how the roles in your team are sectioned and some of the responsibilities that might blend a bit of those gaps.

Yes. So one of the things historically is we've had our admins and our developers separated into their own different teams.

And just recently, with the start of this year, we've actually moved them into their into combined teams, and we divided them out by clouds. The the challenges that we the challenges that we were seeing is that there was a breakdown in communication, or there was such a big task for admins to do and developers to do, but there's crossover. Like we need a new field, we need permissions for the new field. And when a developer might go to the admin for their resource, they wouldn't have the capacity to do that because they just weren't communicating and working together sit sitting in their different silos. So putting them on the same team helps break down those communication issues where, oh, well, that's not on my team. Somebody else is going to talk to me about that and really opens up our communication between each admin and developer role.

Yeah. So that collaboration becomes super integral to the success Mhmm. The the success of your team. Crystal, as a consultant and, developer background and coming forward more from a more traditional software engineering background, role of collaboration, especially working on client projects and understanding the roles of everybody in client's team, customer's team. What does that look like for you, and how do you typically see it set up?

So a lot of my a lot of my experience with Salesforce development has been just like Jessica just described, it's the admins and the devs are one team. We're not two separate teams. And so we work very closely with, client admins or client developers, in that case, on delivery. And I and I found just coming from a Java background, it seemed normal to me, oddly enough, because I saw it, like, coming from a Java background, I was off often on the team where I might be the back end developer, and I'm working with some front end developers and maybe, you know, a database person or some other type of of skill set.

And it wasn't sort of this big divide. It was we brought different skill sets to the table, but all of them were needed together. And so I'm finding, that that works best for us. It is a challenge sometimes because the folks who are more admin centric, you know, they can make things and make changes, and they don't end up in version control.

And so trying to make sure that we are pulling those changes back into version control so that we're not overriding changes, right, in terms of just managing your environments can be a bit of a challenge. So it has meant educating our our admins a bit, and I and I think also partnering with them for for things as simple as like, hey. Okay. You're gonna write a flow, but we like to do test driven development.

So I'm gonna pair with you to write the test for your flow.

Yeah.

And and that's been a way that we sort of help drive that partnership, and and and sort of bridge the gap between the different skill sets.

Yeah. But for many, I see concepts like version control and test testing test forward. We talked about shifting left quite a bit in the in the summit already.

Those concepts, I still find it relatively new. I talk about them all the time all all the time. So I I feel I feel that everybody knows them, but that's just me because I talk about them all the time. Do you still think there's some, I guess, question to to you, Crystal, as well as maybe maybe the rest of the panel? Do you still think there's a lot more that needs to be done in terms of education, in terms of software development best practices, if we're gonna call it that?

I I think so. I I was it was a little bit of a challenge for me to adjust as a as a Java developer and and sort of the the just the general software development practices, compared to how you'll see, Salesforce development done a lot.

I think that I found that it's better. I found that we get better solutions, like, even just something as simple as doing a design session before you build a flow out, right, which is something that's very normal from a software development plat you know, practice, but not always done in Salesforce because you have people who are not necessarily coming from a software development background.

I I find when I introduce those practices and and people see how much cleaner the solution is, they're on board. But it it it takes a little bit to to teach how to do it.

Yeah.

To to go on Crystal's comment there, I think the admin side of the house typically the way that Salesforce is designed historically is that we can just develop in orgs.

So there's not a lot that can prevent you from developing directly in a UAT sandbox and move it to production or even in very bad situations in production.

And I think that is where as developers, it's not only is it a best practice, but for us, it's an industry compliance issue where we have to have version control. We have to have, like, this tracking for audit trails. And our devs or admins haven't necessarily been subjected to that, and they're starting to be. So because they are doing if you're working in a flow, you are doing UI development. Like, you are doing development in a UI space, but it's still development.

And those that type of tracking needs to happen across the board from the from the entire life cycle. We can't make changes in QA, and then we don't know what state QA is in now because it's different or things aren't being put back in. And one thing that I've seen is that we might build everything, get it pushed up to a QA environment, and then that project dies.

And when that project dies, now that environment is very different because there's no tracking. There's no pulling that out, and who knows what all changes happened during that project or during that time.

So version control really, it opens up visibility to everything that's moving through your org. And in the long term, it really helps get that visual.

Things aren't gonna die in your pipeline.

Things aren't going to work in QA, then suddenly we move it to production and it doesn't work, and we don't know why. So it kinda helps, put some guardrails in in the process.

Yeah.

On on those topics, as we start to delve into what we traditionally see as best practices, Kjeski, you mentioned when you started talking there, we're we're used to developing an orgs. Orbs is our source of truth, and that's that's what well, that's what we're used to in Salesforce. That's that's what we have.

Not always the case in traditional software dev. And when you start to talk about version control and those things, the practices and principles can start to become complex, which, Nadim, is that's that's why I wanted to come to you here. So you you have quite an interesting journey because you were an admin, and then you were a developer, and then you transitioned to release engineer at Click. Tell me a little bit about that journey. Tell us a little bit about that journey, and what were some of the biggest considerations and the learning curves that you had to overcome to adopt a DevOps mindset and a DevOps way of thinking?

First of all, thank you very much for the question, Jack. Definitely trans transitioning from a admin to developer to, again, you know, ultimately to a release engineer has been an definitely an exciting journey for me. And when it comes to adapting to a DevOps way of working, it definitely required both the skill development and and and just as as Jessica mentioned that there is a huge gap when it comes to know the core fundamental, concept, which is version control and, obviously, the mind mind mind shift.

Well, when it comes to skill development, it all start with having version control as Jessica mentioned. When when we say version control, it's basically having memory.

Right? So familiarity with Git something like Git is definitely very crucial whenever if someone is moving from admin to developer and all the way to DevOps focus rule. And I had to push myself not just beyond no committing changes or pushing changes. Rather, I had to push myself to learn beyond, like, branching strategy, how these branching strategies are built, pipeline, no creation, and dealing with merge conflicts, collaborative workflow, developing collaborative workflow, and definitely learning tools like automation tools like Giaset, Copado, understanding how the the automation flows from development to QA all the way to production.

And, again, it all comes to system thinking. Right? When we when we are working as an admin or as a developer, we are thinking about code base only, and we are some some kind of silos. Right? But when we talk about DevOps, we are talk about the system holistically.

What's happening from the development and all the way to production?

And it again come comes to the what we have been talking about in the summit as well, like, observability. Right? How we will be tracking what's happening in the pipeline, how many changes are flowing through through the through the pipeline, and what are the, you know, quality checks which we have, built. So as a developer, you don't worry about those things. You only worry about so what what has been assigned to you, just develop and you are good to go. Leave it to the Infra team or the ops team, whatever you want to call it, and they will ship it.

When it comes to mind shift mind mindset shift, that's definitely, very crucial for anybody who is looking to, like, change from admin, developer to DevOps.

In in in in in the world of developer or admin, we often work in silos. We we sometimes lack no communication, who is building what, and that that something which which will act as a as a beacon to break the things. Once you have a proper communication and communicative environment, that helps to understand who is building what, how the how the change is going to flow in the pipeline.

And when when I move to release management, I I I sometime have to involve have to be involved in dealing with ambiguity, sometimes, you know, working in a time tight timeline to fix the error so that the developer can flow their changes all the way to production.

And mostly, when we move to, a role focused in DevOps, we we talk about value delivery rather than just a technology delivery.

And in essence, like, adopting to do of DevOps mindset meant stepping away from no task oriented execution to see a broader life cycle in in my opinion.

Yeah. Yeah. It's it's interesting. To me, it usually takes somebody in a team to spearhead best practices and really drive those those things forward.

One of the great things about the Salesforce ecosystem in my view is we are all very much self starters. We we do the trailhead. We we go out and we learn new things continuously. But when it comes to a team environment, and we've we talked about touched on collaboration a little bit already.

But when it comes to that collaboration, how an open question to the panel. How do we avoid dropping into those silos and going, that's somebody else's responsibility? I don't that's not what I do. I'm just here to build the flow or what have you.

That's somebody else's responsibility. If it's deployable, it's deployable. If it's if it's not, somebody else can worry about it. How do we build on that and make a team collaborate so that their DevOps systems and DevOps processes are ultimately gonna have great results.

I'll start.

Oh, go ahead.

Yeah. You're right.

We're all so excited.

I know.

But I'll start and then kick it off to Jessica because I just wanna wanna say that, I think that the thing to keep mind here that's really important that I like to stress all the time is that admins and developers aren't just separate entities.

Like, we are on the same team. We're serving the same customers, whether that be external customers or our users. And so being able to come together in our different roles and collaborate and being able to speak the same language is really kind of that key thing that I think is going to be that next step to get us there. And it's it's happening as mentioned. Like, when I got into the ecosystem, there were these very separate silos of admins versus devs, and now we are. We're coming together. We're realizing we're on the same team, and I think that Jessica's probably gonna take it from there.

I think whenever we have a problem that comes out, it really comes down to ownership.

Yeah. You can have somebody who can who's going to sit back and wait for somebody else, but that's not going to bring us together. So if you go in and you see a problem, you take ownership of it. And you say, I'm going to dig into it. Nobody's asking me to do it, but I'm gonna dig into it, and I'm gonna reach out and say, hey. I noticed this is failing. And I think when we have a team that works together and takes the ownership to something's broken regardless if they worked on it or not, that's where your team really starts to become a higher performing team.

Yeah.

I'll get off my soapbox.

Crystal?

I so, I I spent a little bit of time, in my career as a DevOps, transformation lead. And and what you just hit on is how do we hold accountable. I think what I see when DevOps is when DevOps has done poorly, it's it's because dev teams are only held accountable for speed but not quality.

And your operations folks are only held accountable for quality and not speed. And I think from a leadership standpoint, like, I I've seen a lot of grass root things, and it's great if you can get people bought in. But until you have a leadership team that holds your everyone accountable for both speed and quality and improving speed and quality, you're you're gonna have a hard time getting anything in particular to stick on a on a large scale.

And I and I think that is ultimately, you know, at the heart of DevOps. Right? Is, I've been on a soapbox for the past year really around using, like, LWC test testing to to increase speed and quality. And and it took a little bit, but I think what what what I what I saw from it was, you know, the business partners saw that the the stability of our delivery first, there's a significant increase in in stability in the production environment because we invested some time in testing.

The other thing that they saw is we were starting to go faster.

And I think that was the thing that that was the tipping point for alright. Well, go go and invest more time and dollars in this because we're we're getting we're getting more and we're getting better quality, and and and that ultimately is the point of DevOps.

Yeah. What came first, the chicken or the egg? Like, speed or stability? It sounds like stability comes first.

I think stability, I'd I'll be honest. I think what came first was speed, and speed resulted in a a loss in quality. And it was it was an unacceptable loss in quality.

And so I think that was the thing that drove an investment in in better testing, because we were feeling pain. I, change all change tends to start from pain, and I find that in this very fast paced world and especially in the Salesforce ecosystem, what I notice is, there's not the same emphasis on quality, across the board. And so it's it's easy to put things in place that break other things, and then your end users start to lose trust. And, so the first thing that happens is the slowdown. And then I think that pressure to continue to deliver fast is enough to if you can find your big wins, from a a testing standpoint or a test automation standpoint, that's usually enough to get a little momentum behind it to get also. I would say, quality came first. Speed came second.

Yeah. Change starts with pain is such a heck of a soundbite as well, by the way. Yeah.

So so so good in the deep. Yeah.

Yeah. Definitely. My my take on on this particular topic is, I see that as a cultural establishment. Right?

Now it it all comes down from the hierarchy in your organization. If you have managed to build that culture where you appreciate the failure, right, then then it all it's all going to improve. Now the now the thing is, are your team is doing the same mistakes again? Are they are doing a different mistake.

Right? Mistake or, a failure means they they they did they did try to, experiment, but it failed. Right? Now when it comes to stability and, speed, I think it's it's counterintuitive.

Right?

In order to be stable, you have to be fast. And in order to be fast, you have to be stable. I'm referring to the to the to the podcast done with Nathan Harvey, if you remember. So I think it's it's it's not egg and a chicken. I think it goes both hand in hand.

Yeah. That's that's my take. And and and I think it also connects to the how team has been doing. Right? Lot of talk, you know, in this ecosystem has been what we are building. For example, if you talk to admin what they're building, they were building flow, they are building a layout, but people very less talk about how they are building. When we say how, and that's where the open this this opens the world of DevOps.

What process are they are following, how they are communicating with the team. So if we manage to establish this culture, then it's definitely going to minimize the the chances or likelihood to, you know, have any mistakes or any failure in the system.

Yeah. Yeah. Of course. I think one one of the things one of the things for for me when I look at admin developer architect, whichever role it is that we feel that we occupy whichever camp we put ourselves in, we we take qualities from each of those traditionally predefined roles in the ecosystem, but they have all blended.

And the the qualities of a Salesforce team are a conglomerate of all of those all of those styles of roles. And we've only got a few four minutes left on the panel. I I remember when I did the pre call with y'all, and we said we could probably talk about this for for an hour, but we haven't, we haven't got we haven't got that time. So I'd love, in the last few minutes here for for each of you, one piece of advice that you would tell anybody in their Salesforce role.

When it comes to being able to deliver the features and be the best version of ourselves in our roles as possible, what would you focus on, and where would you start? And And I'm gonna start with UK.

Oh, gosh.

I'd say it's a combination of education and collaboration.

The Salesforce platform is huge. It is not getting any smaller. I feel like you used to be able to say, I know everything about being a Salesforce admin, and that's just not the case, especially with all of the incredible changes and developments that we're seeing in AI these days. So really continuing to educate yourself to stay curious, stay involved, and learn from the people around you and collaborate with them and work together.

Perfect. Crystal?

I would say make make quality a priority and make quality easy.

Super succinct. I love it. I love it. Jessica?

I think making sure that we're take maintaining relationships and collaborations with our team and to take the initiative on things. Take take ownership of your projects. Don't sit and wait for somebody else to do something for you. Go ahead and step out there and take the risk.

Take the chance, and collaborate. And if it's not the right thing, it might not be. But if you don't tell anybody, nothing's gonna change. So just put your put yourself out there.

Hundred percent. Dean, take us home.

Hundred percent. I I I can't agree more with with the panels here. Definitely collaboration is one of the key factors in establishing a culture where people know, appreciate failure, and talk to each other. So it's definitely comes down to collaboration. And and my take on this one is, like, is building the knowledge base as well. Because when you build the knowledge consider knowledge within your team as an asset. The more knowledge base you will double up, you're you're you're going to flourish hundred percent.

Yeah. Fantastic. Thank you so thank you so much. There's there's so many takeaways, and, something interesting that you just said there, Nadeem, is making people okay with failure.

And failure is a failure is absolutely fine as long as you learn a lesson from it. I think that's what everybody's career teaches them at some point. Failure is gonna happen. It's how you deal with that failure and how you deal with adversity and move forward from it.

The that is super, super, super important.

For folks, I don't know if you have any advice in the last minute here, if any of the panel panelists have any suggestions of if folks here are looking to learn more DevOps best practices or collaboration.

Kate, I know you're gonna jump in and say Trailhead here, of course.

But where where where can folks go go and learn a little bit more about some of these concepts and the things that have made your lives easier in your careers as it comes to adopting a DevOps mindset?

Well, for me, I mean, Gearset and tools like Coparto has done a great job. It all brings down to, like, learning materials. You have Launchpad, great platform. Just go and you know, there are two ways to learn.

Right? Either you can follow the user manual or you just go to the driving seat and go ahead. So it's all up to the up to the person. I I would definitely recommend go to the Launchpad or Copado's community, bunch of learning materials, and start, like, take take the micro steps.

Don't don't take it in in don't try to take it in one go. Right? Think in agile mindset. Agile up also applies to your learning, journey as well.

So that that's my advice for the people who are trying to break into the selfless dev ops space.

Perfect. Thank you. Kate, here's your chance to say Trailhead, by the way.

Yes. I have also gone through Launchpad, by the way, and gotten my, two certifications on there. But, yes, absolutely Trailhead. I've, of course, I'm gonna say that that is where to learn Salesforce and where to get that mindset and actually get hands on with things.

Yeah. No. I'm a big fan of Trailhead Trailhead right here. So, so absolutely. Thank you, panelists, so much. We've reached it reached the end of our time, but some so many great sound bites have come out of this, and I hope the the audience has has enjoyed the conversation.

They've been really generous, with their time. So if, even if you're at home or in your office, round of applause, for for this wonderful panel and everybody that has, contributed to sessions today. Thank you all so much.