Transcript
Hurts when I think about the days I would tell myself.
It's okay for me to scream, to scream, to Alright.
We're gonna stretch things out a little bit and just wait one more minute before folks to drift in and then we'll get started.
I'm looking after the I'm looking after the sonic community.
Alrighty, folks. In the interest of time, we're gonna make a start just so that the the next sessions aren't running behind.
So thank you everyone for making the trip back into DevOps dreaming this morning. Hope you had a great day yesterday for those of you that managed to hit both days. Hopefully you're not too rough from any parties you might have been to last night. I know there's anecdotally a few sore heads this morning, but hopefully we're all fresh and bright and ready to get some more DevOps details going.
So this morning we're going to open up with a DevOps panel with a bit of a careers focus, looking at some of the journeys that folks have had, looking at how we can progress our DevOps careers and getting some tips from some of our experts up on the stage here. So without further ado, I shall start introducing our experts. So right next to me here, we have Melissa Hildees and then we have Kerry Proxon, and rounding out the panel at the end, we have Jeremy Foster.
So I'm going to briefly let the folks introduce themselves, tell a little about how they've come to the DevOps world and what brings them to DevOps streaming. So Melissa, let's start with you.
I have to turn this there it's on. It's on myself. Hi, I'm Melissa.
I'm relatively new to the DevOps world and really just getting started, as part of my career on that. I've gotten to the spot with a lot of help, actually, from Rob. Rob and I have been friends a long time. And finally, he has won me over because I'm working so much with Agent Force and being able to, easily deploy agents.
The DevOps is the the thing that makes it super simple and I've got to got to get more proficient at that.
Okay. Hi. I'm Carrie Proxel. I've been in the Salesforce space for the past like, I guess twenty years, even though I know I look incredibly young. So I know you're so surprised. It makes sense.
I've been in the DevOps space probably for the last five or six years. Kears had named me a DevOps leader which I think is very funny because my husband is actually in DevOps. He's a big AWS guy, this is what he does for a living and like, I'm on stage, buddy.
So, I think DevOps is very important. I think developer experience is very important. I think they're hand in hand and so that's why I am so glad to be here.
Hi, Jeremy Foster.
I've been at Pilot for the past five years, and that coincides with my experience in DevOps. I've been in the Salesforce ecosystem for a little over eight years now.
Twenty nineteen at Pilot, we picked up Gear Set and I helped roll it out for the team there from compare and deploy to disparate CI jobs all the way to a functioning pipeline now that we've been using for the last couple of years. So, I've really dove into that world and kind of helped lead it at our company. So and, I'm a DevOps alumni, so I've been very humbled to, be given that honor from Gear Set too. So, yeah, that's my background.
Fantastic. Great to hear from all of those different backgrounds. And it's great to sort of hear as well that, you know, like you two folks have sort of been about sort of five or six years each on the DevOps. Was Melissa, you're new? So I think we're going to get some some good perspectives on that.
So I I think probably we'll we'll start with, you know, some of the the the folks that have been kind of doing the Salesforce DevOps a little longer first.
How have you seen things change over those years? Because obviously we've moved from change sets to maybe ant packages to some of the tools including gear set and even Salesforce have entered that space a little bit now. So how have you kind of seen things evolve as you've taken that DevOps journey? We'll start with Kerry.
I feel like you missed the first one is doing it right in production, right? That was the first thing we did.
And then we're like, oh, I guess we choose a sandbox.
And then we did a change set, right? So it has changed a lot. I didn't know what a repo was fifteen years ago. I didn't know what a roll you could roll back. No, you got to fix it quick. I didn't know you could do that.
You release planning. What a concept. What a good idea. Why didn't I think of that when I was younger? But these are the things in DevOps that you can do now and these are how it's changed. You have the ability to have versions of the same application, right? You have the ability to roll back quickly and safely.
Yes, it's a different world.
Yeah, very similar experience to my background as a dev. It was weird to move into Salesforce and not have version control, not have merge conflicts, not have all those tried practices that are guardrails to your system and something you can rely on. And it's like, well, whoever got there last is the one that wins.
Having to rely on your orgs to be your source of truth and just hoping you can remember which ones contain the information that you need. So, it's been phenomenal for us to go from, you know, full day change set deployments because they take so long. And if you miss something, you got to go start at the beginning again to even compare and deploy was so much faster for us just moving to that. And then pipelines have just been the next evolution to get us to repo source of truth. Everything's more trusted. We've been able to deliver and deploy faster than we ever did would change that.
I'd also add the using pipelines to deploy plus a feature flag behind it. So only you and a couple of people can actually experience it to then fix it in production and then move forward. That's, you know, that's the A plus, right? That's the start.
And I loved what Jeremy was saying there about, you know, when he kind of first came to Salesforce, you know, it's like, what? You guys don't use Git? You don't work with source control on that? Because that's exactly how Gearset started.
Right? Our company was founded by engineers before Gearset was even founded that were working on Salesforce but used to other systems that had those things in place, that best practice around version control and rollbacks and backups and all the great things that, you know, we expect from DevOps. So seeing that it wasn't there was was the genesis of of kind of how we started building Gear Sets. So definitely relatable what you're saying there.
So, Melissa, obviously, you've you've come to the DevOps party a little later than these folks. Welcome aboard.
Thank you.
So as someone that's kind of new to the or newer to the DevOps principles, you know, how has that kind of shaped, like, how you approach projects now? You haven't had to go through the pain that perhaps some of us older hands have?
In fact, as I heard you all talking, I thought I actually realized the changes as well because I have been in the Salesforce ecosystem since twenty ten. And although I'm not a developer, I don't write code, I have worked with an ISP, I've worked with SIs, and done a lot of work myself. So that speed that you were talking about, right, I have seen the agony of change sets, you know, and watched it. I have seen the problems that other people have had. And so once I was able to pilot this program with Agent Force and see the speed and the accuracy with which we could deploy those agents, that's what really finally brought me on board was because, okay, I've got to learn this. This is so much faster, so much better than what we've done in the past. So, I'm sorry, what was your question?
Just coming back to sort of seeing, obviously, how have you changed how you approach projects now that you've kind of seen DevOps in practice and building on the lessons that we've all learned?
Right. And so, one of the practices that I've always espoused is the minimum lovable product. Getting eighty percent of the way and you never know what customers are going to need or want specifically when you get to production.
Being able to version, being able to go ahead and not be terrified if you install and deploy that eighty percent and fix, that to me is huge. That's something that's changed in the way that I approach things because you always want it to be perfect and sometimes done is better than perfect.
And so getting it in there and then being able to create a new version that upgrades or updates or specifically meets a need is so helpful.
That's fantastic. And I think it's important to learn that it's not a race. Right? As we go through DevOps, yes, it does enable us to go faster, to go smoother, but we do have to do that pause and check what it is that the customer actually wants. What is the job to be done?
Deliberate use of that phrase because there's there's other talks on how we uncover that job to be done later today.
So I want to change tack a little bit and kind of lean into the sort of career element of this morning's panel.
So, Kerry, I know that you are a certified system architect, certified application architect. So, you know, and and obviously at Gear Set, we have our certification tracks as well. So how have you found that that sort of continuous learning certification has has helped the career move along?
I mean helped.
I have eleven certifications. I've studied a lot.
I still think practical knowledge is trumps all. I think taking the test, you know, for me it was ends to a goal. I wanna be a certified technical architect. It turns out, oh my god, it's so hard.
It's so hard and everyone that I'm with. My buddies, they keep failing six zero two so it's very stressful for me and I need to get over it and just take the test. But again, if anyone could give me motivation after this, I appreciate it. But it helped me understand I guess more about Salesforce than my little world.
SDLC, IAM, integrations, it kind of opened up how you think about things and how there are standard for things and then to build upon it. So I think I was more helpful in meetings. I could understand a lot more. I could diagram them a lot more due to the certifications. But I will always say that experience and knowledge overall, it will always trump a certification. I would hire a person with no certifications that answered all the questions in the interview versus having a bunch of certifications but doesn't know the difference between a role and a profile.
And Melissa, I I I know that you have, some of the what I'd like to consider the more strategic, certifications. So like UX designer and strategy designer and what have you. Talk us through a little bit about what those certifications have meant for how you approach your your Salesforce live.
Yeah. Sure. So in fact, I would love to be a CTA too. I I think I'm going to save that for retirement, right, like my PhD or something.
But, Joanie Blizard, a great friend of mine that's not around anymore, told me one day, she said, Architect is not a certification, it's a mindset.
And really encouraged me to go ahead and be an architect, right, that solutions architect. That's why I think the DevOps side of things is so important. That's something I've neglected.
Strategy designer, UX designer, in fact, I have a presentation that I do about, okay, you architected all this, but did you architect the UX?
Because that's what always gets pushed off to the very end and that's what doesn't happen. That's a lot of what strategy designer is about. It's actually a lot of what the UX designer certification is about as well, in uncovering what it is that people really want, what customers really want, and asking why, why, why until you get to the root of what they're looking for.
And that entire process for my career, in fact, I've just had someone contract with me to come to their company and do a consequence scanning exercise with their company. And if you've never done consequence scanning, there's a great, Trailhead module on it. And once you've done consequence scanning, you'll never look at things the same way again. And that came out of the strategy designer certification.
So I think it's just vital, especially if you are going to have more of an architect and overall role than just, you know, if you want to be strictly a developer and all you want to do is sit with Apex and JavaScript day in and day out, that's one thing. Right? But it wouldn't even hurt you to learn how to uncover those instances.
Absolutely right. I think broadening the horizons and thinking about the impact of what we're delivering. Whether we're delivering it through DevOps or not remains to be seen. But I think just thinking about the impact that that has, and and how we present it in front of our users is super important. Now, Jeremy, I know as a as a DevOp leader and not alumni, a part of our wonderful growing family here at Gearset.
I I know you've done a lot of the the DevOps launchpad stuff, which is kind of our our Trailhead equivalent.
So I'm gonna I'm gonna kind of put us on the spot here a little bit. So what are some of these sort of DevOps practices that you think are vital to DevOps learning that maybe we've missed on DevOps Launchpad?
Well, to your credit, I think you guys do a wonderful job at providing insight, especially for some of our new team members. And from team members that don't have that background, like our admins are a mix of people that come from a dev world and decided they hated learning syntax and worrying about if they missed a semicolon somewhere. They wanted to build logic with Flows and I know they're deprecated now, but process builders and items like that when they existed. But we have QA members as well. And, you know, one of them is very interested in becoming an admin. And, in that he's been embracing Gear Set with us to help. And so I know for them, it's been a vital tool to go out and learn some of those items around how we do our release management.
I think one that we've had to source a little bit more beyond Launchpad is, particular to our company, we use GitHub. So getting team members familiar with all of the lingo involved with GitHub and the different processes with interacting with that layer of the tool set.
Fortunately, we are trying much more to keep them in gear set and help offset that because they can use that interface and not have to worry about so much of the minutia that comes with knowing Git or having to operate from the CLI. But going out and learning those gaps and figuring out where to replace it, I think is a huge skill. Launchpad is very helpful. Trailhead has some as well for Git basics and things like that.
But then seeing that gap and them reaching out on their own and learning from GitHub or finding Coursera or other online courses to learn that too. I think all of that's just in the same spirit of what DevOps is. It's a practice. It's not necessarily a doctrine and it's not an implementation tool.
It's how you do things.
It's a lifestyle choice, right?
So, yeah, I agree. I think that, you know, on on sort of two points there, I think, you know, as one of the people that writes the content for DevOps Launchpad, I selfishly now have some new material to go and to go and write. So that's that's great feedback. Thanks.
But I I also think, you know, it's important to kind of stress that DevOps Launchpad by design, obviously it's operated and run by gear set, but it teaches you the principles. It teaches you the fundamentals. It doesn't necessarily teach you just the gear set way of doing things, which is what I absolutely love about it. It will teach you gear set as well if you need that, of course.
But we, you know, we have whole teams that will will help guide you through that. But learning the principles and the best practice immaterial of how you approach it, I think is super important. And that ties in quite nicely to one of the other things that I often talk about where, you know, we firmly believe that DevOps is like eighty to ninety percent the culture of collaboration and communication with your team, and probably only ten to twenty percent of the actual tooling.
So in terms of that culture, I mean, I'm on stage here with three strong leaders in the DevOps and the Salesforce community. So obviously you have teams that you work with on a day to day basis. What kind of things have you done within the teams that you work with to kind of shape that cultural element? I'll go back to Keri for this one.
How I've shaped the team. So I listened to them. I did this crazy thing. I was like, hey, how could you make your day better?
What's the annoying thing that you had to do? And when I got to National Debt Relief, they had to the different protected branches that we would merge into, they weren't in sync. So you merge into the one and you don't merge the next one into it. You merge a new one into it.
So it was always different. So you never knew what was in each object, in each environment. You never knew what was in each branch. So it was never correct.
So once I understood the problems, then I worked with Gear Set and we released pipelines. And so with that, we were able to make one smooth way and everything merged into each other. So we understood the differences in the environment so much easier. And then a rollback was really a rollback.
A merge conflict was really a merge conflict. So that was a big thing that we did.
Melissa, do you want to go up next?
Well, I was just thinking about having those best practices, right? And the fact that even though DevOps means developer operations, you don't have to be a developer to use it. And I am not a developer. But it's important that that collaborative effort is there, right, between the architects, the developers, the admins, you know, everybody kind of has their own separate job, but the DevOps strategy and practice and using Gear Set in our case, pulls us all together. Right? I haven't learned to get Hub yet. That's one of the banes of my existence.
And, that's where a program we've got right now is currently living. So to be able I don't have to learn GitHub, you know, not right now, not today anyway.
And Jeremy, what what sort of cultural aspects have you had to kind of bring into your teams to get them thinking in DevOps?
Yeah.
So I'm currently a manager by title, but I use the terms leader and manager very specifically.
And I've had the great fortune of working for some great leaders in my time. And one of the things they taught me was leading from the front. So, when the question arose of like compare and deploy isn't scalable, how are we gonna move this forward? What can we do?
I embrace the fail fast mentality and just started. I dove in with a CI job and then I made a bunch of CI jobs and saw that they were failing and they weren't connected in the way I thought they would. And, I fortunately came to this conference three years ago and got some hands on training and and figured out that connection, but I was then able to take that back to my team and say, okay, here are all the lessons I've learned that you now don't have to deal with the mistakes, like learn from mine for free, but then here's what I can teach you about the correct way to implement this. And that way I was able to provide guidance where needed, but we as a team were then able to embrace that fail fast.
So as I had implemented the initial pipeline, once we brought more people onto it, more things were being committed, more work was being done, we could respond quickly to something was missing, something was broken and as a team we were able to triage and figure out what was needed next. So it's just that be willing to lead from the front when able and just bring everyone along for the journey.
That's fantastic advice. And you know for anyone that is a leader or even an aspiring leader, you know, that's one of the best takeaways I think that we can take from how to sort of drive that forward and get our teams on board and build that culture within our teams.
One of the other aspects of Salesforce culture, but I think sort of work culture generally as well is, you know, we're increasingly seeing that people are being expected to do more with less. And DevOps is definitely gonna help with that. Right? Instead of being up till three AM trying to get that release out the door the old fashioned way, DevOps is helping us kind of, you know, deliver more efficiently and stuff.
And it's one of the contributing factors to avoiding overload and burnout in the workplace. What are some other sort of things that you've noticed or good strategies that will help avoid some of that workplace burnout as we kind of build our sales force and our DevOps careers?
Melissa, do you want to run with that?
One of the features that I love is the rollback. Right? Because I am the least perfect person in the world and I don't know if you've ever rolled anything out that immediately you were like, oh, that was a major mistake.
And being able to roll back whatever you've released is, in my mind, a huge de stressor. Right? It's, you fail fast. I love that. And I fail all the time, really fast, and recuperate and learn something new. I don't make that mistake again, but I'll make a new one.
You. So being able to roll back for me is a huge de stressor.
And if we look at the sort of, you know, the the wider kind of implications of avoiding burnout in the workplace, you know, it doesn't feel free to answer in a DevOps sense, but don't feel obliged to. But, Jeremy, what other advice can you give folks here?
Yeah, it's an interesting topic. I know at least for myself and something I try to enforce for the team is to, feel comfortable to set your boundaries and and stick to them.
I am very willing to fight tooth and nail to make sure we don't work on weekends, we don't work after hours, with the one exception being if production's on fire, we'll put that out. But, just because your timeline is now an emergency to you doesn't constitute an emergency to me.
So, you know, setting those, being willing to speak up that, you know, you're uncomfortable about something or this is eating into my personal life for my personal time. We shouldn't sacrifice that because that will burn people out that will lose talent and just don't need to do that. You're not, There may actually be nurses and doctors in here. Our company, we're not saving babies. So, you know, it's not as important as everyone wants it to seem.
Carrie?
Yeah. I mean, to avoid burnout, don't be a working mom. That's probably a good first step. But to avoid burnout in like the workplaces, one, communication and listening, kind of what you said but define an emergency.
This is what an emergency is. We need to lose x amount of people. X amount of people cannot be using the system for it to be cleared an emergency. And then setting expectation.
We will get this done when time allows in the next three to four weeks. I use things like, Oh, best deal days is probably get it done. Flag day, some random day that they may not know and then I'll say that's the day we're gonna get it done.
To kind of set expectations to protect the developers as much as possible, I think is very helpful.
And don't do releases on Fridays. Yeah.
Even Tuesdays. It's a great day.
I would add in the bigger picture, right, of not having burnout, for me, I tell people I have what I call a work life integration.
Luckily now my husband's retired. You may have met him. He travels with me a lot these days. He's my assistant.
And for me attending these conferences, right, there are a lot of Salesforce conferences. I'm sure there are a lot of developer conferences. But getting to know the people in the ecosystem, making what my daughter calls my Salesforce friends, you know, is really encouraging to me because I've not seen every single challenge that you can face. Right?
I know people that are experts.
I can pick up the phone and call somebody or get on WhatsApp and say, hey, Rob. I need to know one line of JavaScript. And I do, don't I? You know, but having that extended team because I've always worked with very small teams, right?
Nothing on the scale of pilot or anything. So small teams and not everybody knows everything. Nobody can. So having that broader base of support, right, in the ecosystem is really encouraging to me.
It's almost like I've lined up the next question based on what you were about to say. I I had no idea what the folks were going to say in advance here.
But it's interesting that, you know, you reach out to that larger community pool for advice, whether it's technical advice or any other type of advice. So to wrap things up, we do actually have a last question here, which is what is the best career advice you've received along the way? Now, it doesn't have to be DevOps related, although use DevOps is pretty solid advice to be fair.
But yeah, so let's go Carrie again. What is what is the best career advice along the way that you've had on your journey?
It was from my mom, so but it still works. The only constant is change. So you need to embrace change. The only thing they're going to do is change the thing on you.
You release things production, they didn't want that, they wanted it in blue. You made it in purple. Of course, you should have known. So this is the thing that's always going to happen.
So embrace the change. No need to emotionally react, just roll with it.
And to be clear, that's embrace change, not embrace change sets. Yes. Good point. There we go. Yeah. Jeremy.
Well, Rob stole my continuous learning earlier, so I'll let him have that for the advice. So, I'll actually modify something I said at a previous session. And before I talked about always look for the kind people, look for the ones that are willing to elevate you. And, Jolene at the time had a really good point too of, like, you should also be your own champion.
So I've kind of blended those of you do need to be your own champion. You should speak up. You should show your talent. You should really fight for how you work and and how you are as a person.
From experience, I have also seen that even if you're yelling that from the rooftops, if people that are, you know, your leadership, if they're not the ones that are elevating you, it won't matter how much you champion yourself. So I think it's a blend of be your own champion, but also realize you need the people that are kind, that see the skill set and you see the, the way you bring the value. So have a mix. It's a balance in all things.
And to wrap us up, Melissa.
And so I go back to what I said before. It's the community.
I'm not the best or the brightest but I love people and I really am genuinely interested in who you are and what you're doing and what you're accomplishing in your life.
I made it, a rule a long time ago. If you are female and post something on LinkedIn, you've gotten a certification, you've done something, I see it, I will repost that and brag on you. Because as a woman, I'm not very good at bragging on myself, but I love to brag on other people. The community is how I've gotten every job in the ecosystem that I've had. Not because of the certifications that I had, not because of an app that I had produced, but because somebody knew somebody who needed somebody like me.
And so, if you're looking to advance your career, you know, I've never gotten hired because of a resume that I submitted. I've always gotten a phone call from somebody that says, Hey, I'd like to talk to you about this. So, I really make the investment to go to TDX, go to Midwest Dreaming is in Minneapolis coming up in July, July this year. There are close places, there are bar places, go to, Cairo Dreaming. If you've never been to Egypt, you should be there. It's fantastic.
Because it really is worth the investment in your career. And if you look at it that way, you can see the ROI there.
That's fantastic advice from all of you. And I just to kind of close things out for for today's session, I think, you know, we've we've heard career advice in in DevOps on the the technical side, the cultural side, the communication and collaboration side, and those personal relationships, which which kind of bring it all together. So hopefully, our esteemed experts here have have given you something to think about on that sort of DevOps journey that we're all taking, and it never ends. Right? We're all continuously learning, continuously growing, learning new tricks, making new connections. So I'd like to thank our panel, Melissa, Kerry and Jeremy, and enjoy the rest of the day. Enjoy the sessions.
