.jpg)
The Agile Within
Providing agile insights into human values and behaviors through genuine connections.
The Agile Within
Unlocking the Future of Agility with Jessica Soroky
The Agile landscape has evolved dramatically in recent years, with demand for traditional roles decreasing while expectations for value delivery increase. How can Agile practitioners adapt and thrive in this changing environment?
Jessica Soroky, Senior Director of Program Management and Product Operations at Pendo, shares her fascinating journey transforming a team of Scrum Masters into Program Managers. This strategic shift expanded their focus from the software development lifecycle to the entire product development lifecycle – from initial ideation through customer validation to post-launch activities.
What makes this conversation particularly valuable is Jessica's candid assessment of the current state of Agile. While rejecting claims that "Agile is dead," she acknowledges significant market changes where once-plentiful positions have become scarce and increasingly specialized. Her insights on domain knowledge requirements reveal a troubling trend: companies demanding hyper-specific industry experience rather than valuing diverse perspectives that could drive innovation.
The most powerful takeaway comes from Jessica's practical experience leading organizational change. By redistributing responsibilities (engineering managers taking over standups, product managers owning sprint planning) while preserving the core facilitation expertise of Agile professionals, her team accomplished something remarkable – they shifted conversations from outputs to outcomes. Rather than celebrating completed sprints, they began focusing on delivering actual customer value.
For Agile practitioners wondering about their career trajectory, this episode provides a compelling roadmap. The skills that make great Scrum Masters – facilitation, process improvement, and human-centered problem-solving – create countless opportunities when applied more broadly. Former team members have progressed into product management, operations roles, and chief of staff positions they might never have discovered otherwise.
Ready to expand your perspective on what Agile can be? Listen now and discover how broadening your focus might reveal unexpected career opportunities and deliver greater value to your organization.
Connect with Jessica on LinkedIn:
https://www.linkedin.com/in/jessicasoroky/
Follow us on LinkedIn:
https://www.linkedin.com/company/the-agile-within
Welcome to the Agile Within. I am your host, mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now.
Speaker 1:Before we dive into today's episode, I'd like to take a moment to thank our sponsor, impact Agility. Impact Agility specializes in training and coaching through scrumorg and proconbonorg, empowering teams with cutting-edge tools and techniques. Their classes are designed to deliver actionable insights, whether you're a scrum master, agile coach, delivery manager or organizational leader. Whether you're a scrum master, agile coach, delivery manager or organizational leader, at the helm is president and founder Matt Domenici, who has guided over 50 organizations toward professional agility. With his hands-on experience, matt helps teams and organizations take ownership of their processes and outcomes, unlocking their full potential To explore free learning resources, check out their training schedule or book a free consultation. Visit impactagilityco Once again. That's impactagilityco. Well, hey, welcome back everybody. This is your host, mark Metz, at the Agile Weather Inn. I hope you're having an absolutely fantastic day out there today. Our guest for this episode is Jessica Soroki. Jessica, welcome to the show.
Speaker 2:Thanks for having me, mark, super excited.
Speaker 1:Well, jessica is from nearby Atlanta Georgia. I'm just about four hours east of her in Columbia, south Carolina. So, jessica, if I were coming to Atlanta Georgia for a day, been there many times, but if I hadn't been there before, what's one thing that you would say that I couldn't miss?
Speaker 2:doing. I would say you couldn't miss the aquarium. It's like the number one attraction, so I don't feel super unique in suggesting it, but it is super cool. And I did recently learn that you can actually go scuba diving with the whale sharks, so that is now newly on my to-do list at some point is to get in the water with them, and that's I'm super cool.
Speaker 1:And you did say whale sharks, not sharks, right?
Speaker 2:Yes, whale sharks, they are very gentle, from what I understand.
Speaker 1:We both have families and I understand that you can have like spend-the-night parties in the aquarium. Is that right?
Speaker 2:You can have sleepovers in the aquarium, like sometimes schools will do it or you can do it privately. And they actually also have a pretty extensive summer camp program now for like 5 to, I think, 12 years old, all about STEM and getting kids excited about the sciences and math and all that kind of fun stuff.
Speaker 1:That's awesome. Well, I'll have to say it really is impressive when you walk into the aquarium and you see those whale sharks for the first time, because you try to prepare yourself for how big they're going to be, but until you see them in person, they're tremendous. They are huge.
Speaker 2:We have three little boys five and twin three-year-olds and we can sit there for quite some time just looking at that huge aquarium and watching the whale sharks go by and all the other things. And anyone who has little kids knows that attention spans are very short, but that keeps their attention quite long actually.
Speaker 1:Well, I'm a big kid at heart. I love animals, so yeah, I could spend all day in the aquarium and be perfectly happy, all right. Well, I want to introduce Jessica. She is a Senior Director of Program Management and Product Operations. Jessica, why don't you tell us a little bit about your role?
Speaker 2:Yeah. So I figured it might be helpful to give like a little description of the role but also my background. I was in Agile roles for 12 years prior to my current role, so that would be everything from a scrum master to Agile consulting and coaching. I was a professional facilitator and professional speaker for a long time doing the big conference circuit. I was an executive coach all the things. My current role program management and product operations for Pendo is kind of my next evolution in that role, which I'm sure we're going to get into all things there. But product operations the best thing I can say about it simply to an agile audience is it is like a souped up scrrum Master for an entire product organization. So their whole job is to make product managers more effective, minimize wasteful activities, get them focused on all the creative ideation, building products things.
Speaker 1:So, leading into that, you and I had a conversation before this recording and we talked about the state of Agile, yeah, and so let's talk a little bit. What do you see as the current landscape for Agile and for agility, jessica?
Speaker 2:Yeah, I'm not going to jump on the bandwagon of it's dying or it's dead. I don't think it is dying or dead. I do think that it is less of a craze than it used to be and I do think that, unfortunately, there's just not a super consistent success story with agile and corporations. So when you go from company to company large or midsize markets you just hear really mixed experiences with it and I think that because there's not this like super strong, consistent, no, when you do agile, you get X, y and Z out of it. I think executives are still a mixed bag of weariness and buy-in level and because of that, I think that's why it is kind of in the same state, in the sense that I don't think it's dead. I think you have plenty of leaders out there and plenty of companies that still get some value out of it, but I don't think it's ever going to go back to the peak that it was.
Speaker 2:When you were you couldn't. You could throw a rock and hit a hundred job openings or maybe that's a little bit of an exaggeration but dozens of job openings. It wasn't difficult to find a job in the agile market, regardless of what level you were at. That's all changed. There's been some really big agile forward companies, like Capital One and a few others, that very publicly cut all, if not very close to all, of their agile roles, and the market right now is really difficult. My husband just went through a job hunt recently in agile roles and senior scrum, master, rte type of roles and it is really difficult. You're getting hundreds of people applying for every opening out there and it is a real fight because there's just not nearly the demand that there used to be demand that there used to be, so I think it is important to delineate.
Speaker 1:There is demand. It's just not what it used to be. Yeah, because that demand used to be high, we had a large number of people entering the workforce.
Speaker 2:Absolutely.
Speaker 1:So now we have a smaller market with more people, so it's simple supply and demand right.
Speaker 2:Yeah, absolutely, which is why I don't think it's dying or dead, because there is still a demand for it. There are still companies who see value and agility and want to embrace it. If that weren't the case, I would jump on the bandwagon of okay, it's dying or it's dead. Everyone, give up and find the new thing.
Speaker 1:So you and I discussed that companies like Capital One are doing away with anything that has Agile in the title. They just got rid of those positions right. And I think when we were looking at Agile positions, many of us as Agilists, we were leaning back. And when I say leaning back, we were leaning back from the business, from the product, and we were focused more on how the sausage is being built, what are our processes like, and not as much leaning in to the actual business. So what do you see as domain knowledge? How important do you feel that is for Agilis today? Jessica?
Speaker 2:Yeah, I think my opinion has changed over time. I used to be very anti-technical backgrounds when it came to Agilist, scrum Masters, coaches, and I still, frankly, if you're hiring or have Scrum Masters, I still very much believe that, while being technical in some way can have some value, in my experience brings too much danger to the conversation and that they were way too comfortable with what the engineers are talking about, and I think we all know there's not a single engineer out there who wants anybody in a scrum master, agile role telling them how or what to build. So my stance was always like know just enough to know what questions to ask, but don't know enough to have an opinion on the answer. And I don't know that. That's wildly different.
Speaker 2:I will say, like, if we get into like where I think Agilists should start looking when it comes to career, what's next for them, I do think domain knowledge becomes more important, but I would still argue that if you are really good at operations, process humans, team building, all those types of things, it really shouldn't matter what the context is of what they are working on. You should be able to do all of those things regardless. And I think people lean into too much domain knowledge when they aren't as comfortable on some of those other skills. That being said, I'm going to contradict myself a little bit here and say that, like I do think you have to have basic domain knowledge of how a business builds products and how an engineering team builds software. I think that is important, but I don't know that it has to go deeper than that.
Speaker 1:I'll just share a frustration of mine here recently. So I have been in the job hunt myself, like your husband, and was applying for jobs, and the recruiters would ask me if I had banking experience, and my answer was yes. And their next question was oh so which bank are you coming from? And my response was well, I'm not coming from a bank. I have from years past. I have banking experience, but I'm not coming from a bank. Oh well, this customer, they want someone coming from a banking background directly, and you know, you know, I think you sell yourself and so you know the customer is always right.
Speaker 1:But you're trying to sell yourself and it's like, well, sometimes you can be so close to the problem that you can't really think outside the box. And that was my angle and I was unsuccessful at painting that picture. But I was like, do you really want someone who is in the banking bubble that maybe you don't have? There are other domains out there. There are other verticals, other businesses that you could benefit from. Wouldn't it behoove you to have someone that has a wealth of experience and not just in your own little bubble?
Speaker 2:And you're not the only one that experienced that. My husband had the exact same experience. It wasn't, I don't know, banking, but it definitely was like insurance was a big one. Which insurance company are you coming from? Those types of things?
Speaker 2:I think my hot take here is going back to that supply and demand point we were making earlier. I think it has everything to do with that. Five years ago, when demand and supply weren't matching and there weren't enough people to fill all of the agile roles or opening, there was a lot more openness, I think, to diverse backgrounds and different points of views. And now, because there's so much supply and so little comparative demand, I think companies are getting into like really weird behaviors that you just described of like no, I need exactly this experience, exactly this background, and they're probably convincing themselves that that's the key to making agile work and that is, I know, means, the key to making it work.
Speaker 2:I will say my current company. We look at backgrounds, but mainly from like to understand what speed of organizations you come from. So, for instance, like we will look at resumes when it comes to like insurance or banking and no offense to anybody in those worlds, they're typically slightly slower moving companies than a SaaS startup right. So it's not to say that it's a deterrent, but it does change some of our questions and interviews to make sure that somebody coming from those backgrounds into a SaaS startup type of environment feels like they can still be successful because the speed of pace is wildly different and I think that's okay. But I think getting really stuck in know what specific bank did you come from feels unnecessary.
Speaker 1:I agree, I agree. So, like I said, I was unsuccessful, but I'll continue to fight the crusade along with your husband. There we go. So, jessica, we talked about one dead end road that I have experienced. What are some alternative paths, maybe, that we might take in order to serve companies better and not be stuck in the? You know, I'm just going to be a facilitator or I'm just going to schedule meetings, I'm giving air quotes. How do we pivot here for the agilist out there? How do we pivot here for the Agilist out there?
Speaker 2:Yeah, so Pendo, which is where I work. I've been there for almost seven years and we actually experienced this need for I hate to use the word transformation, but essentially this need for an internal transformation. We have always been an Agile company and I really do mean that Two of our four co-founders are very, very deeply embedded. They've always been bought in. It's never been a fight. But, all that being said, there came a point where, even in that environment, questions started to arise around, like do we really need this many scrum masters? What do they really add value? Like, how do they really add value? Why can't my engineering manager just do this meeting facilitation stuff and keep us organized and do the math on sprint velocity and capacity and all that kind of fun stuff? And so when I heard those questions, it was, I think, about a year into COVID and that kind of sent like my hairs raising right, like, oh, I've been down this path before. I don't want to see big layoffs in this team Like they. I know that they are highly skilled. So we did an objective assessment of kind of like how we were executing against our agile processes and how we built products, and what we came up with was, I think, a really significant career move for a lot of agilists out there. But what we figured out is that the product development lifecycle is actually a lot bigger than the software development lifecycle. The software development lifecycle is a piece of the product development lifecycle, and what the product development lifecycle has that the other one doesn't is it has the early ideation phases, it has customer validation, it has research, it's got data gathering, it's got experimentation and designs. It also has, at the other end of it, when the software is done, being built, how do you prepare a company to launch that software into customer hands? How do you make sure that your support organizations are ready, that your sales team knows how to sell it, that your documentation is where it needs to be all these different pieces right. And so we weren't really good at either one of those parts. We were good at the software development lifecycle. We'd gotten that.
Speaker 2:We figured that part out, and so we made a decision that was pretty bold and we moved all of our Scrum Masters from engineering as Scrum Masters to product as program managers and we partnered them up with the product this very small product operations team that we had at the time, and the whole point of that was because we wanted there to be a single point of accountability essentially for that entire product development lifecycle, and we needed a process expert to help us make that whole product development lifecycle much more effective, much more efficient. We needed a consistent process across. At the point At that time, I think we had don't totally hold me to this but roughly 30 scrum teams, give or take a few, and so we needed to figure out how to get them all marching in the same direction, just like we would. A software development lifecycle, but now for this whole beginning of idea through customer hands, and so we move them into program management. And I will say I didn't love it when I came to the team and said hey, I'm going to change your titles and I'm going to change your job. I need you, and I kind of positioned it from the point of view of I need you to maintain a lot of what makes a great scrum master a great scrum master. I just need you to do it in a different scope of work now with a slightly different set of stakeholders. So instead of your entire bread and butter being your engineering teams, your designer, maybe the product person that you're working with with those teams. I need you now to think about a wider range of stakeholders that include go-to-market functions. Go-to-market functions meaning sales enablement, doc writing, technical support, customer success all of these team members that are vital to a whole business's success that, frankly, engineering doesn't often hang out with. I'll just put it that way. So we changed their jobs to program management, and I know I'm going to hit pause for a second, because I know that there's a lot of different definitions of program management and, depending on what company you're at, you might even see technical program management, which is a slightly different slant than what I'm even describing. This is what worked for us.
Speaker 2:I still very much believe I probably could have kept their title scrum master, even though I changed their role.
Speaker 2:But I'm a big believer in psychology and I think had I not changed their title, they would have done.
Speaker 2:It would have been very hard for them to have broken their old habits and to apply new behavior.
Speaker 2:And it's been really, really successful.
Speaker 2:And I think one of the coolest things about it is that it has really created an endless opportunity, endless list of opportunities of what's next in their careers, because now they get exposure to so much of the business. I've had two of my old team members who have moved into product management because they've gotten a lot more exposure into how products are built and they found passion there. I've had folks start to explore other operational type of roles, like revenue has operations roles, sales marketing has operation roles, and those are career opportunities they probably would have never had the chance to explore had they stayed in that scrum master bubble. I've even had folks that are exploring chief of staff roles, helping to run major parts of our organization, and it makes complete sense when you step back and look at it, because it's running a bunch of special projects, getting organized, creating consistent operating practices. Like it's all the same skills. It's just I think sometimes Agilists get way too close to the trees and they forget that their skill set can be applied in a myriad of ways.
Speaker 1:So what did that look like when you started talking about the new set of accountabilities that they were going to have with this new title? What did that look like from the team? I'm sure they were. Were they taken off guard? Were they very?
Speaker 2:I had quite a few that weren't happy with me. I am proud to say, though, that we had a team of, I think, 17. I could be off again by a few there. Okay, in the transformation process, I only had one choose to leave, and they chose to leave, and they were very, very honest about what they wanted, and what they wanted was a very traditional scrum master. They loved that. Right, like I said, was entirely focused on engineers and maybe a designer, maybe a product manager. Now they were supporting whole programs. So the way we define our programs are essentially like think about it like a product area, typically a team of teams, right, so you could, if you're thinking about like a scaled agile point of view, like a release train. Now, granted, they were small, so, like, I don't want anyone freaking out and thinking that we went from you support one or two to 20. It was, they went from one or two to maybe three to five, but it's because they weren't in the weeds, and something controversial that we did was to help give them the capacity to do that.
Speaker 2:We had our engineering managers take over running daily stand-ups. We didn't say that my team wasn't allowed to go. They were encouraged to still go whenever they possibly could. But we needed to take the burden of you have to be there every single day off of their plate. And, ironically, if any of them are listening, I don't care, they still mostly go. If any of them are listening, I don't care, they still mostly go to all of them. But, for whatever reason, the mental burden of oh my gosh, I have these daily standups for a set of teams every single day. There's no way I can take on additional work. I'm like, no, you can't. So we moved the day-to-day responsibility to the engineering managers, which also upped their accountability and making sure that the engineering managers knew what was actually happening with their team. And then we moved the bulk of the responsibility of sprint planning to our product managers, so they were the ones that had to make sure backlogs were ready. We still have varying levels of experience in like setting sprint capacity and velocity and talking all the math. A lot of times our program managers will still kind of help with that conversation. In some cases our engineering managers have learned how to do that math too and they can lean in on that part, which I know is again probably controversial.
Speaker 2:The one space that we have protected is retros. I do very much, deeply believe that an engineering manager or product manager should not be the one leading a retro. I think it's a skill. So they still lead all of our retros. And then the other big difference is that their direct leadership team changed. So now we created leadership teams at that program level. So we had a product lead, a design lead, an engineering lead and then this program manager, and that became their first team if you're familiar with the concept of first team and so they spent a lot of their time there. But action-wise, day-to-day-wise, they now had to not just manage the day-to-day of these engineering teams, which was a little bit more on the engineering manager's plate now which ones are coming to engineering teams, which ones are in engineering teams' hands and which ones are coming out of engineering and needing to move to business readiness, and so they're managing a lot more, frankly, amounts of things on a day-to-day basis.
Speaker 2:But the cool thing is that to me, and what I think they really enjoy about it is, every day feels different.
Speaker 2:So it's not like, okay, I'm in a sprint, I'm going to go do sprints to daily standup.
Speaker 2:Okay, I'm going to talk to my team and help unblock them on this thing. Okay, well, tomorrow's kind of the same, oh, the day after that's a retro, and the day after that we have to plan, and then, oh wait, we just beat the whole thing again. This is like really a every day is very much different based on what they have, lifecycle and, like I mentioned earlier, it also is causing them to have to solve wildly different problems. How do we enable sales on the value of the thing your team just built, while they don't have to have every tiny granular detail of the answer to that problem? They have to now go hunt that problem down and they have to now go work with a different type of team to figure out how do we make sure that all this money we just invested building this thing isn't a complete waste to the business. So I think that they very quickly got on board when they recognized that they just get to solve different problems now.
Speaker 1:One of the things that stood out to me is the empowerment that you provided to them with this decision, and just it's a small thing, but I tend to just pick up on little small things and one of the things that you said was okay, now, instead of requiring you to go to the daily scrum every day, or the daily standup, now it's optional. And the team's reaction was oh well, okay, I can't attend every daily stand up, but then when you made it optional and left it up to them, they were like hmm, I probably do need to go, that probably is useful for me to do so. The empowerment of giving the choice to them, to let them make the decision, is it something that is valuable to you? Do you bring value and do you get value from it? I think just speaks volumes.
Speaker 2:Well, I think it changed how they viewed a lot of this and I think it reignited this idea of how you constantly evolve something to ensure that it is still valuable to everybody involved. I think when it was just kind of a part of a regular motion, even though somewhere in their minds I'm sure they knew that their job was to constantly make things better, it's really easy just to get stuck in that rut of, well, that's what we do and this is how it happens, and this is how my team is happy, and so that's, I think, drove a lot of that too is different kinds of conversations of is this still valuable, the way that we're doing it, and how can we make it better?
Speaker 1:Did retros change a lot?
Speaker 2:No, I will say that we are currently in an open debate with engineering leadership right now, because we allow our engineering managers to be in retros, which, I will admit, is something that I don't actually like. But I have chosen not to fight this fight. I think it's important to pick your battles, and that was just one that I didn't think the reward was worth the battle. But we're getting to a point where some of our teams are trying to get creative about how to continue to keep value in retros. So, on a good note, I would argue that it's coming from a place of. We've gotten our teams pretty open and honest with each other to where they're having regular conversations about what's working, what's not working.
Speaker 2:So, like we have teams that are currently experimenting with doing retros based on releases, not based on sprints. So instead of it being every two weeks, it's we release quite frequently. So it's not like we're saying, hey, you're going to wait three months or six months to have a retro, but, like when an epic gets completed, that might be once a month or once every couple of weeks. What changes the value in the retro if we were to focus from that point of view versus insisting again that it be every two weeks?
Speaker 1:And we're going to so I was curious about yeah, yeah, I was curious about that, about how this move to a program manager kind of broadened the horizon from a scrum master and they started asking different questions in the retro based on their based on what they were seeing, because they weren't just looking at just the team, they had a much broader view of the customer, of the problems and things like that.
Speaker 2:I think the number one thing that it did is it shifted. I think there's a lot of theory talk in the difference between outputs versus outcomes. I think there's lots of voices in the ad industry on this idea, but for me at least for years I was like, okay, I can understand the idea you're describing and I don't know how to actually do the cultural shift or the to get people to change behaviors, to to be about outputs and not outcomes, or be about outcomes not outputs. See, I can't even get it right. Um, until we did this, this, that was like a really unintentional result that we got was every conversation shifted to away from okay, great, you checked a box of getting this sprint done or you met your sprint commitment. It changed from that to but what value does this provide? How do we know customers will want this thing and will buy into it and will adopt it?
Speaker 2:It also helps that the company that I work for is a product analytics tool, so we are literally building a tool to try to get companies to better understand how their tool is being adopted. So like a lot of drink your own champagne kind of stuff happening there. But I don't think we were even having enough of those conversations until we made this shift and until we were able to see the impact company-wide and customer-wide, and the fact that, like, hey, we don't build just to build, we build because we're trying to solve a problem, so how do we know we're solving that problem? So I do think we've made that shift and I'm sure that that drives different conversations in those retros, but I see that driving different questions and conversations in pretty much every aspect of what we do in this PDLC, which is really cool to see.
Speaker 1:Coming from an engineering background myself, engineers like tough problems to solve right, and sometimes it's not about the value, it's about how fun is this challenge going to be to solve? And we forget that big picture that somebody is actually going to be using this and it is going to it's either going to make their life better or it's not right.
Speaker 2:Right.
Speaker 1:So that should be why we're doing what we're doing, not because it's a fun puzzle to solve, right? That's a byproduct.
Speaker 2:I mean I will say thanks to AI, because AI is making plenty of fun puzzles to solve.
Speaker 1:So, as we're wrapping up here today, jessica, I want to ask you the strategic move that you made to transition scrum masters into program managers. If you had to do it over again, is there anything that you would do differently?
Speaker 2:Oh, that's such a good question, I'm sure. Yes, yes, there's always things we can do differently. I think two things pop into my mind right away. The first one is because of all of the other responsibilities that we are asking them to take on that were different from their typical scrum master responsibilities, I do think we lost track for a while of these still critical skill set of facilitation, and so I personally believe that facilitation is one of the most powerful skills somebody could have, and I think it's something that you continue to hone over time and you can continue to build. And so I don't. I would.
Speaker 2:I would love to go back, and we probably took almost six months where we didn't, just it wasn't on the top of the priority list. It's not that we weren't doing, we weren't doing any of it, it's just we weren't actively continuing to try to build that skill and and looking at how we can make it better. So that's probably one thing, because we then had to kind of do some reworking after to come back to it and go hey guys, this is still a critical part of your job. I still need you to be really good at this, especially since the audiences you're facilitating are wildly different. And when you're facilitating a bunch of engineers who, frankly, have now been years and years and years used to a Scrum Master, that's an easier facilitation audience. Then now you're working with all these business partners who maybe aren't used to having a formal facilitator. I lost track of that so I would have probably done that better, and then we did. It took us a hot minute to figure out that we needed to do this. So have looking back, I would have done it much sooner.
Speaker 2:We ended up doing a I don't know like an education tour where, because I was exposing them to much more of the business, I just assumed, kind of what I mentioned at the very beginning of this podcast that, like, domain knowledge wasn't nearly as critical, and I still believe that. But they need to have some kind of base, that understanding of what each of these departments do. So we figured out probably too late and did eventually bring in, like representatives from each of these major departments to come to my team and do a quick overview of what the department even did, what they care about, what drove like, what motivates them. So, like we, I had a bunch of scrum masters who understood what motivates engineers but they weren't totally clear on like how do you motivate a customer success individual, how do you motivate a sales enablement team member, like those types of things.
Speaker 2:So once we got into that motion of continued education and we were constantly having people come in and talk to us, that like really unlocked the value that they were able to do. So looking back, I would have day one I probably might have even done it before we formally changed their jobs. Looking back on it versus after the fact and after a couple months of struggling. So probably those are my two things.
Speaker 1:Jessica, thank you so much for coming on the show. This has been wonderful. I've enjoyed talking with you Our audience. If they want to get in touch with you, how might they do that?
Speaker 2:LinkedIn is probably the easiest. Just my name, Jessica Soroki. Yeah, that's the easiest.
Speaker 1:We'll put a link in the show notes to make it easy for everybody. Jessica, again, thank you so much for being a guest here on the show. Really enjoyed having you.
Speaker 2:No problem, thanks for having me.
Speaker 1:All right, everybody. That brings an end to another episode of the Agile Within. We'll see everybody next time. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, mark Metz.