On Episode 10 of the Agile Coaches’ Corner podcast, your host, Dan Neumann explores the DevOps culture movement with Sean Davis. Sean is one of Dan’s colleagues at AgileThought, a DevOps expert and a frequent conference speaker. He has been a Business Transformation Consultant at AgileThought for nearly two years and was previously a Technical Advisor at InterContinental Hotel Groups.
In this episode, Dan and Sean explore the background and history behind DevOps, where they believe it is headed in the future, the enablers that help teams be most effective with DevOps, important mindsets to bring to DevOps culture, as well as both the challenges and benefits of DevOps not having a defined manifesto or framework.
Like what you heard? Check out our podcast page for more episodes full of interesting discussions, agile insights, and helpful resources.
Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought, the podcasts for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann: [00:20] Welcome to the AgileThought podcast. I am Dan Neumann and glad to have you with us today. If you have some ideas that you want us to discuss, email them to us at firstname.lastname@example.org or tweet it with the #AgileThoughtPodcast and we’ll see about including those in a future episode. Today’s topic is going to be about DevOps and it’s hard to believe that DevOps is a movement is already a decade old and to explore some of the background on DevOps and what we’ve learned and maybe where we’re going in the future is one of my colleagues, Sean Davis, he’s a DevOps expert and a frequent conference speaker, so I’m excited to have him joining. Thanks John.
Sean Davis: [00:59] Thanks Dan.
Dan Neumann: [01:00] I know with the agile movement, there’s the agile manifesto that was kind of the marquee event that started a clock of sorts of people refer to when they talk about the age of the agile movement or how old it is. And I’m curious like what is that for DevOps? So is there a touchstone that people point to as that’s the start?
Sean Davis: [01:17] Oh, that’s a really good question. Um, you know, I think over the years, if you talked to Patrick Debois, known as the Godfather of DevOps, he’s very adamant about not having a manifesto so you don’t fall into any of the same traps that agile ended up, uh, having challenges with, I think not having a dedicated manifesto or framework is kind of a blessing and a curse, right? We have the freedom now that we can create different frameworks around what works best for a customer. So it’s much more adaptive. So take for example, a John Willis created a framework called CAMS and each of the letters, or an acronym, you know, culture, automation, measurement and sharing. And then others have kind of built on that over the years. But there’s nothing that’s really taking hold because DevOps is this a very ambiguous, almost philosophical conversation with a lot of organizations. So I think that’s really where it comes into the curse part, right? Is that because you don’t have formalized, it’s harder to get education around it. And I’ve been working with a lot of organizations such as DevOps Institute and ITS Academy to establish a lot of those training certification courses so that we’d have some standardization in the industry around what DevOps is and how it needs to be applied.
Dan Neumann: [02:32] Yeah. So you touched on something that was interesting, which is without that manifesto, it sounds like there are many possible interpretations of DevOps. It, you know, for Agile it’s easy when somebody says, well, is it an agile thing or not? You can kind of go back to the manifesto and the 12 principles behind and go, to what degree does the behavior you’re talking about or the mindset you’re talking about line up with these 12 principles and it’s a good, bad, or indifferent. It’s a little bit of a validation of is the thing agile not, and so what, what kind of challenges do you end up then with in the DevOps movement? Without the the manifesto, there’s not a creed that seems like that would create some challenges for defining what good DevOps looks like or what we’re even talking about when we use that term.
Sean Davis: [03:16] Oh absolutely. Yeah. It’s not quite as prescriptive as agile is unfortunately. And that can even cause friction within the communities from what I’ve seen. So what assembly as can be, you know, and I don’t want it to be very ephemeral, but DevOps is really just a culture of collaboration, right? We focus around making the organization continuously learning and growing. And we do that through at least how I do it. I think Gene Kim had the right of it with the three ways, you know, we want to amplify feedback loops, want to continuously learn through experimentation and we want to improve the flow of work through the organization. Right? And when you look at it at a high level like that, it may feel like there’s not a lot of, a lot of meat, but when you start actually focusing less on the words and more on the actions that support those words, you’ll see a more truer definition that really adapts itself for what organization and what they’re trying to achieve. And I think that’s really a, a bigger strength than a, um, a deficit for DevOps, right? Is that now we can adapt better to organizations and actually not breaking any rules or frameworks or any of that other stuff. So we don’t feel as bound. Because what I hear from the Agile coaching side of it is, you know, you look at frameworks like Scrum and the first thing that happens is you generally have two camps. Either the organization is, well, we want to do something like Scrum, but we want to modify it. And then they get very upset when they don’t see the results that Scrum promises because you’re using the framework much more as a guideline than the actual framework. And then on the other side of it, the people that do follow the rigor of it complained that they don’t want to have to be bound by all these laws and these rules, these practices by and by in order to get that desired result. So it’s almost like you’re not going to win either way. So to me it feels a lot better and a lot more fluid that DevOps doesn’t have any of those dedicated frameworks or manifestos. Right. So we can adapt and grow more easily through the years.
Dan Neumann: [05:19] Yeah, that’s interesting to touch. Um, the Scrum framework, yet there is, there are people who, um, they want all the benefits of Scrum, but they either don’t understand the framework or they’re following the rules that are very rudimentary way without understanding the principles, which there are similar ones, short feedback loops like you mentioned with DevOps, continuous learning, you know, through, through the retrospective, at a minimum within the Scrum framework, uh, and then flow, which is different with a Scrum, which is an iterative approach than maybe somebody gets pure flow. But definitely some of those principles line up very well. The loops, the learning and the flow coming out of the DevOps movement, like you said, characterized by Gene Kim.
Sean Davis: [06:01] Yeah, absolutely. And it’s interesting because I mean more DevOps being a hub to practices like Agile, Lean and a lot of these frameworks that are out there, we’re really helping connect those dots for the business, right? We want to focus on solving that business versus IT problem and less on being niched into just software development. Because if you look at the three ways, none of them are specific around software development. Now while they rose from the ground as intended practices to help deliver that software more effectively, we’re starting to find as time goes on, that there are much wider uses for it. Um, but that comes with the responsibility of understanding where this comes from, right? You can’t talk to organizations truly about DevOps without them understanding all of the underlying factors like lane, you know, when you say, hey, I’m pulling the end on court on production. If they don’t understand TQM and they don’t understand where endo court came from, it doesn’t make a lot of sense to them. And just because they heard the terminology and know what it is, if they don’t understand the importance behind it, it’s a very dangerous proposition for a lot of organizations.
Dan Neumann: [07:10] Yeah, you touched on something there to make sure it gets amplified. It’s not just about software development and you’re right, the agile manifesto says, you know, we’re uncovering better ways of developing software and they go through and that’s kind of been a, a pigeonhole I think where you had alluded to that the, the manifesto maybe doesn’t serve well going forward because yeah, now we’re looking at business problems and being agile at the enterprise as opposed to agile within individual software development teams.
Sean Davis: [07:40] Absolutely.
Dan Neumann: [07:41] Yeah. So DevOps a decade ago and DevOps now I imagine are quite different. You know, the, the tool suites continue to get better and better. Cloud is much more prevalent now than it would have been a decade ago. And I’m curious what enablers there are now that really help teams be effective with DevOps. And we’ll talk about the technology beats then. I think I want to get back to some of the team organization stuff as well, but we’ll start with the technology because that’s almost easier than the people stuff.
Sean Davis: [08:14] That’s funny that you say it that way because that seems to be the approach of most organizations and others when they want to learn about DevOps is we gloss over the people in the process and you jump right to the technology of things. Um, which is, it’s been a growing pet peeve of mine for almost the full 10 years is that automation isn’t DevOps. It’s a natural result of DevOps. Um, but in the vein of technology, you wouldn’t be able to accomplish true DevOps without these tools that enable. And when I look back over the last 10 years, some truly amazing things come out of the DevOps movement. One of my absolute favorites is this concept of something as cut. We started with code and then we moved on to network is code and security as code, which was, is now kind of in full swing is what they call it Dev Sec Ops. But it’s very interesting that as we’ve gone through this movement, when we talk about the cultural component of it, you see how it’s influencing the market and some of these tools that are being created where as look at Azure for example, one of the amazing things about Azure, is they’re the only call confider that gives you the ability to do infrastructure as code natively and their entire platform is built on it. It shows you how important that piece of the technology is to kind of that lifestyle and that mentality around where we’re going with DevOps. Um, but it’s also given rise to a lot of open source solutions and a lot of closed source solutions that can provide that uniform experience across any cloud or any architecture on premise or you know, up in the cloud, for example, Terraform is really, really great. Um, I recently saw something from XebiaLabs is actually taking it another iteration further and they’re defining everything from the beginning of planning to the delivery of the code at the end as code. Being able to quantify, you know, every single thing as a line of something in a file to say here’s what the entire process looks like and then you just plug the pieces that need to be different in. Which is an amazing concept because you know, even back in the day of doing automation, you still had to go through the process of researching everything. Everything was a snowflake and everyone did it different,
Dan Neumann: [10:27] That’s the problem with so much in house infrastructure and in people setting up servers on their own and going in and tweaking a configuration. Then you have fragile deployments and you know, you have 9 people, 12 people, 20 people getting on the phone once a week to deploy. If you’re deploying frequently and just it’s, it’s, there’s a goat Rodeo of trying to manage environments, right? So now those things can be coded and you can deploy your infrastructure repeatedly and consistently and you don’t have the snowflakes anymore.
Sean Davis: [10:58] Absolutely. Yeah, and it’s been, it’s, it’s been an interesting journey. We had a client this week that had mentioned to me that one of their challenges around why they didn’t want to use vsts versus a executive reporting tool was because there’s this activity or this event that happens in the organization every single time that they need to do something. So the, the C-SUITE says, Hey, we want to know what’s going on with our project and everyone rushes to write down their list of three things that they’ve done and advocate for their team. Right? And we as agileists and working with DevOps, we know there are a lot of tools at our level that can provide some of that visibility. But when you look, you kind of extract another layer up and you look at the business. There’s all these events that are going on that we actually started applying DevOps to, to be able to say, hey, if we understand the data that you need and we understand where you can get the data from, not only can we maybe automate that process, but we can actually at least drive what the process should look like and create a value stream map that we can start working on you know, simplifying, collapsing and automating some of the process.
Dan Neumann: [12:07] And that simplification, the automation, knowing what people are looking for that can help get out of some of the gaming too. So as a project manager, I think more than once we’ve spent time in the past trying to word smith a status report so that, you know, so some of that it sounded green or the yellow wasn’t really that yellow. It was mostly kind of greenish yellow. And it sure as hell wasn’t red, you know? And so, but if we can talk about what those metrics are, what we want for complexity, health of the servers, responsiveness, uh, whatever really key indicators we have. How many users are coming to the platform or are they being served well? Those are valuable things and then you can go to the actual source of data versus having it filtered through potentially multiple layers of people trying to put their little nuance into what the communication is. I really like that approach.
Sean Davis: [13:01] Yeah, it’s much better than the many to one framework where you’re gathering everyone’s thoughts and then one person is compiling those in. if we make those metrics transparent across the entire group, not only did we get a uniform standard of how we’re doing things, but it also opens the door that other people can contribute to diversity and say, Hey, while you’re looking at this, and this is a an important indicator of success, I’ve noticed this correlates to my data over here and now I have more insight on how I can draw conclusions and you get that multiplicative mindset where now the entire business benefits from a growth area, not just focused on one project or one program.
Dan Neumann: [13:53] And we talked about Scrum a little bit earlier. One of the easy things to look at is a team’s velocity and without a lot of, yeah, I know you, you’re smiling because it’s a piece of information that’s useful for a very few things, but some people will make it all about the velocity. Is it stable, is it increasing? Have we delivered within the sprint what we said we were going to and and lots of gaming. But if you can then bring in, yes, velocity is one piece. The measures of technical debt, the measures of the ability to release and are those features we’re releasing, getting used by somebody and delivering the value we expect, you get a much richer conversation. I see the DevOps folks enabling the frequent releasing and knowing that when we released something, it actually works the way we thought it was supposed to.
Sean Davis: [14:45] Absolutely. And I think that dovetails back to when you asked about the technology giving people an opportunity to not weaponize metrics, right? You know, I always tell my clients we only make data driven decisions. If you believe something to be true, it’s only an opinion until we run an experiment to validate that hypothesis, right? And I, I, I truly believe in that scientific method because more times than none, what you find are your hippos of the organization or your highest paid people’s opinions are always the things that are guiding how your products are being produced, how they’re being advertised and propagated through the organization. And what we want to do is identify the areas that can actually drive the most value for the business. We’re focused on how we align. Kind of at the top level. If you look at, if I had to summate what DevOps can do for an organization and a couple of sentences, our focus is taking IT capabilities and helping the business understand them and then helping align IT to what the business finds value so that it’s more of a partnership and you’re helping them accomplish each other’s goals versus business dictating something to IT or IT constantly feeling like some type of gate or walled garden from the, the rest of the business. Right. I think once you give people that understanding and they have the opportunity to contribute and they’re actually showing via real data, not gaining the system, but actually showing here’s the impact that we’re making with the decisions that we’re making. It changes the game entirely.
Dan Neumann: [16:25] It does and that brings me back to your, your statement of automation is not the same as DevOps. So let’s talk about that mindset a little bit. Because automation is not DevOps any more than having a two week iteration makes you agile. They may go together when things are working well, but they’re not synonymous with each other. So what are some of those mindset, um, important mindsets that you see people having to bring in to enable DevOps or this, this delivery between business and IT?
Sean Davis: [16:56] So probably one of the greatest things that I’ve learned over, I wouldn’t say more than 10 years on a name, but that’s all it is, is it’s really a name. If you’ve read the Phoenix Project or you pay attention when you work with these clients, you’ll notice that more than Dev and Ops is sitting at the table, right? And it’s having a mindset that while we can stay in our lane, what we’re really focused on is connecting the dots, right? Do developers understand what is preventing us from being able to give them what they need to empower them to deliver software, do operations understand the hurdles and the challenges and the, you know, the very convoluted processes and all of the parts moving around that developers have to jump through in order to deliver that software. And then how do we as a team of both and operations, they’re still, you know, as it as a whole, right? That’s all we did was we split one group away from an entire set of groups of the IT organization. But how do we articulate that to the business? All right. So we, we do things like we don’t, not only bed operations people on the team, but we get every stakeholder in the business involved, right? We don’t do things in a vacuum. One of my favorite books by Frederic Laloux talks about the Laloux advice process. Where basically, what we do is we focus on the people who have a stake within the decisions that need to be made are the ones that are called up and they’re the ones that make the decision because they have skin in the game, so to speak, right? So we don’t have a room of 40 people with an opinion about something. We have a room of 12 people that will be impacted by the decision that’s being made. And then once we start to make that decision, we start involving our subject matter experts to either support or disprove what our decision is going to be. And by doing that, we make more effective decisions with the organization. Um, being a continuous anything, right? Being a continuous learning organization is huge. Right? If you know, I honestly, I try to learn more from everyone that I try to teach people. And my only focus when I’m teaching people is that they should learn from every experience, good or bad. And that seems to make a healthier balance because now we’re focused on what did we learn from what happened, whether we made a mistake and we need to figure out how to prevent that from happening again, or whether we had a success and not only celebrate the success but let’s socialize it to the rest of the business so that others can gain benefit from the wisdom and the knowledge that we’ve acquired. I guess. And then finally, you know, going back to what we talked about earlier, just look at, look at Agile DevOps, lane, ITIL. These are all tools to accomplish a goal, right? But if we start focusing so much on, this is my fiftem this is where lean starts and where agile ends and where ITIL begins. I think what we’re doing is we’re kind of an anti power to DevOps, right? We want to break those silos down and knock those walls down. We want to be transparent. We want people to be able to talk and communicate and we want to have a rational system to be able to validate our thoughts.
Dan Neumann: [20:07] It’s so much more valuable to talk about are we getting the results we want or we’re trying to achieve or we need to get than to have a contest over, well, we’re not doing agile or we’re not doing lean, or is it an Itil or safe or dad or less or scaled scrum or whatever it is. Like really having a better conversation about are we getting the results now? It still makes sense to look at the, the framework or the platform that you’re trying to implement that maybe can help you get those results. But yeah, having the, uh, well, it’s not in the, you know, the Bible of my favorite methodology is not particularly useful.
Sean Davis: [20:43] Yeah. I want to hear organizations say the because of the, that we chose to take, we found success. Not because we did an agile transformation or a DevOps transformation. I think it’s really, if we’re going to preach teams to our clients and to our industry, we need to treat it as such. Right. And that call or single each other out. We’re all dedicating to that success.
Dan Neumann: [21:06] Yeah. You touched on continuous learning and really learning from every experience and that brings to mind, I had a chance to work with a man named Derek Wade for awhile and one of his passions was about effectively debriefing, um, in this case, simulations within a training. So if you do a training and you do the ballpoint game or you do some other game, it’s fun. But if you don’t effectively debrief it, there’s no learning. Yeah, if you’re doing Scrum and you’re not doing effective retrospectives, you’re not learning and so, you can replace whatever that learning mechanism is, but you have to have that mechanism so that you are continuously improving, regardless of the framework of choice.
Sean Davis: [21:47] Absolutely. We always make the joke if you want to see how culturally advanced or degraded an the organization is, I tell them to go take a look at their bathrooms. I said, when you go into your bathroom, is there pee on the floor? Is there water all over the seats? Is there paper towels overflowing in the bin? If you see that it tells you that you already have an unhealthy culture, the people don’t care about the place that they work, why would they care about what we’re trying to teach them to bring them into kind of that next phase of their transformation. So if we’re not addressing those problems, we’re not really, you know, we’re just covering up the systemic issues and trying to put a gold glaze over it. I think Einstein said it best, you can’t solve problems with the minds that create, right? You have to have an additional perspective. And that’s really where our value comes in is to say, Hey, we’ve seen what works and what doesn’t and we can help guide you down the road to success. But that road’s going to be different for everyone.
Dan Neumann: [22:43] That culture permeating everything you know, down to the bathroom is really an interesting insight. And it’s one that stood out to me a little bit as a fresh out of college I was at a CPA and consulting firm and the partner in charge of our office was walking down the hall, he picked up some nit of paper that was on the floor near the restroom and I don’t even know what it was, but here’s the guy who was running the whole office and paused to stoop down and pick up a little bit of paper as opposed to ignoring it and making it somebody else’s job. And that, for me it was, it was a pretty powerful example of the culture of that place and what they cared about and what the expectation of everybody was there. And, and that’s true. So even in the technology and the business then, what is our expectation? Is it okay to write a bunch of garbage and go have a hardening sprint later? Is that okay? Right. If it’s okay or it’s not okay, um, you know, is it okay to write code that we don’t deploy for months and months because we’re not really sure It’s okay. Um, or you deploy and we never measure the impact that we anticipated to get. So lets shift, we’ve talked a lot about some of the things that are happening now and some of the tooling and the mindset. Where do you see maybe things going or where do you feel like it’s imperative that the industry, the DevOps movement, the delivering results movement, well, however we want to characterize that. Where do you see things going?
Sean Davis: [24:08] I’m very passionate about that topic. I see a few things that are real big challenges and I’ve talked to a lot of colleagues really starting to branch out a lot in the areas that didn’t talk about DevOps and associated with DevOps so that I can understand where other people come from and their views and their perspectives. One of the biggest challenges, I think DevOps has before it is the name. I think at some point we finally need, you know, it’s how I felt about agile too. I mean agile is getting a little long in the tooth it’s been around for awhile, but the name limits you because while it suited you 10 years ago, I see people abuse things about it. I’m not so much in the agile community as I do with the DevOps. You know, you have, I literally bought a website, that says stopxops.com because every day it felt like I’m turning around and reading another article about AIOps, DataOps, SecOps, or you know, someone’s just pasting something on the front of it and marketing is just running rampant with it. I think we need to look at what is DevOps 2.0 for us, right as we’re meeting through these DevOps days in a lot of places, we need to start having that conversation, you know, and putting some guardrails around what that’s gonna look like and if it needs another name. I mean, this is the whole vein of Patrick Debois existence and creating DevOps, and he said, I never wanted the name to take hold. It just happened to because it made sense. But in the same way as we talked about the agile manifesto, it’s extremely limiting to DevOps because then people only hear, well, we’re going to think about the developers and we’re going to think about operations, but we’re not going to talk about how we’re solving business problems. Um, I think another big challenge is we need to start looking at DevOps as not something so narrow and focus on how we can radiate it through the entire organization and stop just saying, well, let’s build the CICD pipelines. Let’s automate testing. You know, let’s build these great teams and bend them down with security. But how can we apply those three ways to a much larger part of the organization? Because if you can show value beyond the development team, to the entire organization, to every other business unit, hands down, we’re going to make a lot more movement, we’re going to grow a lot bigger and we’re going to be a lot more successful in our endeavors. And then finally, I think we’ve gotta be really, really careful about building silos and our own communities. So many times I get into these conversations about agile and DevOps, right? ITIL and DevOps or lean and DevOps or whatever. And I think we’re all trying to do the same thing. We all have different approaches and we all deal with different parts of the business. So when I take a step back and I look and I think about that DevOps 2.0 um, I had actually done some research for the last few months and I came across a guy named Tom Gilmore and he created this open source model called Adapt and it actually ties together transformation, agile DevOps and product all into one executable transformation. And he breaks it down by every piece supporting every challenge that organizations have had and how they want to move forward. And it was so compelling to me that, you know, I’ve been a huge proponent of trying to spread the word about this because it’s just insane how well thought out it is. How rooted in its history that it is. When you talk about it, you can see where he goes all the way back with lean tactics. You can see how deep he goes with agile and not just with team building, but all of the components that make organizations agile. Um, and I think that’s where we need to move as a, as a community, right? Is it not just the DevOps, not just agile, not just lean, but they were all moving together. Um, and from a, I guess a less philosophical standpoint, I see a huge movement around the DevSecOps movement. I’m a premier teacher for DevOps Institute for DevSecOps are actually doing another class in February. It’s probably my favorite class to teach because a lot of people want to understand what this whole DevSecOps stuff is about. And it’s great to see how they embrace it, right? Most people think of it as, well, testing is just a phase within DevOps or security is just a phase within DevOps. But we actually show you, hey, we’re trying to embed these new thoughts and these new ideas and these new processes in these operational units within the business and to every step of our product, right? So that everyone is coming together and contributing, you know, that whole culture of collaboration thing that we talked so much about and I’m seeing a huge steep rise in Kubernetes containers. I mean it’s explosive how much containerization has grown and how people are starting to move more towards serverless architectures as well. And the security challenges that come with that because those are effemoral versus you know, the static infrastructure that you generally have. So some really exciting things coming, some challenges, some amazing, but I think, uh, we’re, we’re moving in the right direction and we’re growing in the right ways.
Dan Neumann: [29:25] Cool. You’ve definitely given us some things to think about, both with the current state and some of the, the movement going forward. Thank you for doing that. And then one of the things we do at the end of the podcasts is ask the people who are participating, what have you been reading lately and ask you to share. It could be anything. Book, article, blog.
Sean Davis: [29:47] Ah, I’m in love with, this book called Reinventing Organizations and it was written by Frederic Laloux and it’s very insightful. It tells a story from the business perspective about how these transformations are happening. Some of the pitfalls they’ve had, some of the lessons that the executive suites have learned along the way. One of my favorite, there’s a CTO that talks about, he was used to always being that guy that has to rush in and save everything, right? He’s the superman of the organization, if you will. And everyone looks to him to, you know, guide them technology wise. And it was one of the hardest lessons for him to learn to have to step back and let his people do that because he didn’t realize how much he was disenfranchising his own employees by having to be that guy that steps out there because then everyone looks at him like, well, he’s going to get the credit for the work that we do. You know, he’s always the only one that anyone recognizes the work that’s being done and the collected is lost in that. So being able to step back from it and allow his team, his staff to shine and to take those challenges even when it may feel painful. Right. You know, you might know that you can fix a problem in five minutes, but the value of another employee doing it in 15 minutes may have hurt your bottom line slightly. But what they learn in the empowerment from that, will grow that revenue line far beyond the money that you lost in the long run. And we have to start playing that long game. I think there’s just an immense wealth of information and wisdom in there for a lot of people’s experiences. Highly recommend it.
Dan Neumann: [31:20] Yeah. I’ll have to check that one out. And it brings to mind the resilient organizations as opposed to the fragile ones where you’re afraid somebody will leave or take vacation or you know, I, I, you know, you can have those people effectively hold the organization hostage if they know that they’re the single point and that does not serve organizations well. So yeah, how can people step out and focus on the environment and improving the resiliency. So look forward to checking out Reinventing Organizations and we’ll put a link to that in the show notes and those are available, uh, at AgileThought.com/podcast.
Sean Davis: [31:53] Now you brought up a really interesting point I want to touch on before we start closing things out. That whole misconception of I’m so important that I can’t, you know, the organization, you can’t leave me holds so many people’s careers behind. And I’m very passionate about that because I think, you know, I was told by my mentor a long time ago, one of the most valuable things I think anyone’s ever given me advice-wise was if you can walk away from a company and the company doesn’t miss a beat and they can pick up where you left off without any trouble or problem, you’re more valuable than somebody that can stop operations, right? Because that’s what they want is that you can come in and be so effective at what you do, that you teach others to be able to do it, and there is a greater value in that than being the person that has to quote unquote hold the keys to the kingdom or be that gatekeeper for something. Because our culture and our society and our business has changed and we’re no longer specialists in the things that we do and we don’t need to be limited by the fact that we fill our value with only the things that we know, but it should be around things that we can do and how we work as a collective. Same way as moving up from an engineer to a boss. You know, you realize, hey, now my effectiveness can only go so far. But when I have control of more people, if I can teach them to be as effective and empower them, I going to be able to show way better results than just me having to do everything myself. So I think that’s huge and it’s a great insight, Dan.
Dan Neumann: [33:24] Yeah, very important on that mindset there. For sure. Yeah, so thank you for that and we’ll look forward to having you back in a future episode. Thank you, Shawn.
Sean Davis: [33:34] Excellent. Thank you, Dan.
Outro: [33:38] This has been the Agile Coaches’ Corner Podcast brought to you by AgileThought, get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.