The Meridian Point Podcast
Episode: Agile Without the Jargon - Coaching Executives Beyond IT
Guest: Om Patel, Enterprise Business Agility Coach at ClearlyAgile
Host: Kumar Dattatreyan
Date: December 2, 2025
---
Kumar: Hi everyone. Kumar Dattatreyan here with the Meridian Point. Thank you for joining and welcome to another episode. Today, I'm really pleased to introduce you to, or maybe you already know him, Om Patel. He's an enterprise business agility coach at ClearlyAgile in Tampa, Florida, and co-host of the Arguing Agile podcast. Well, maybe we'll get into some arguments here in this podcast. We'll see. And he has over 220 episodes since 2017, so he's been doing this a little bit longer than I have.
Starting as a scientific programmer, Om discovered Agile in 2011 and has since evolved into coaching executives and mid-level leadership across IT, finance, law, HR, and other non-traditional domains. His approach? Never mention Agile by name. Instead, he meets leaders where they are, uses hypothesis-driven experiments, and helps them rediscover the collaborative agility they've lost as they've scaled.
So without further ado, let me welcome Om to the stage. Hi Om, it's great to see you again.
Om: Likewise. Thank you for having me.
Kumar: Of course. So you mentioned in our last conversation preparing for this podcast that senior leaders didn't grow up working in an agile way. At least many of them didn't. They became successful through command and control. What's been your most effective approach to helping Type A personalities embrace collaboration over being the solo hero, if you will?
Om: Great. Well, fantastic start with the question. I really like this question. So personally, I like to start by reframing collaboration more as a performance multiplier rather than a threat to their authority. That's often how they perceive somebody outside the organization coming in. So I think it's important to understand Type A leaders didn't grow up in an agile way, right? They grew up in the traditional command and control method, following that method. So that's true.
But however, they also therefore thrive on results, which means that you have to be evidence-based, right? So I show them data. You know, I don't just tell them that teams that collaborate outperform solo or talented individuals all day, every day. But instead of telling them that, I gather data and I lead with that. So I think that way they can have a little bit of faith in what you're telling them, right? That's the end, and that's worked well.
The other thing is, with Type A personalities, they don't want to hear about this language of agile. I don't use that. I just use the language that they understand and they can relate to. So for example, using terms like risk mitigation or strategic leverage, right? You know, opportunity cost discussions. You're following a path, but at what cost? What are you not following? They tend to kind of, I think, resonate with that line of reasoning more than just agile jargon and agile vernacular. So that's the second thing.
With Type A people, you cannot just simply wave a wand, as everyone knows, right? So I like to also conduct measured short experiments, right? So coming in saying, you know, "Thou shalt do this or that," it's more like, "How about we try something for a short period of time and see how it goes?" And these experiments often initially with Type A specifically revolve around letting go a little bit of their control. So delegate decisions to teams and measure the outcomes from that, right?
So once they see that it leads to, and it often does, faster delivery because there are fewer points of escalation, there are fewer points of approval, things like that, the teams become a little more autonomous. Not all the way there yet, but at least to start. Once they start to see that, then the shift happens naturally.
In summary, it's really, with Type A folks, it's not about stripping control, which they really hold on to with a tight grip. It's not about that. It's about expanding influence through cultivating trust.
Kumar: Yeah, it makes a lot of sense. And it resonates with the experience that I've had with me and my colleagues with the Disruptor Method. The things that we do there is we try not to bring in a whole lot of agile jargon, but we also look at meeting people where they are and sort of understanding what the challenges are and using language that's not threatening in some way, you know, that they may have heard about Agile or the things that people do in an Agile team. And they're like, "Oh, that stuff is not for us," but using language that they're more familiar with.
We like to call one of our activities "emptying the glass," you know, like maybe their glass is a little too full. They don't have the space to really even understand the context that you're coming from, or what the challenges that they face. They may have a particular sort of mindset around those challenges where it's hard for them to express what they are or the impact that they have.
Do you find that to be true in your work when you deal with executives and leaders? And what are the things that you do to help them empty their glass, if you will?
Om: Yeah, I really like the metaphor, emptying the glass and making space, right? Because the day-to-day fills their mind and that's front and center. So some of the things I try to do is really going on a lower scale instead of saying, "Well, these are all the things that we have to change," right? Just go in and say, "What keeps you up at night?" I'll start with that question, right? And if it's multiple things, then fine, you know, just pick one of them.
So for me, emptying the glass looks like making room for trying something small for a short period of time but not necessarily seeing that as "we're changing the ways in which we work." This is just a little small bet. Let's see how it plays out. And if it doesn't, we'll change. So no full, long commitment or anything like that.
But before that, it's really for them to understand and own the why. Why do we need to? So when you ask the question, as I just raised, "What keeps you up at night?" it kind of gets you in that conversation. We can then talk about what would it look like if you could get a good night's sleep? What would have to happen? What would have to stop happening? So around that, you could now frame an experiment and see how things go.
I find the whole thing rather contagious once it starts to roll because one executive will talk about that with another. So it does gravitate sideways, left and right. But making room away from their day-to-day is the key here, right? Making just enough room, maybe just for one little experiment. And once they start to see, "Oh yeah, this is actually working for us," then they will invite you in, right? So you'll have more space to conduct maybe two experiments or across different domains eventually, but maybe across the two stakeholders that are really entrenched with their interests here, right? So yeah, I like that metaphor a lot.
Kumar: I'm wondering also, one of the things that we do with the teams that we work with, the leadership teams we work with, is conduct an assessment similar to DISC. It's the Predictive Index. And what that does is it gives the leaders in the room sort of a perspective on how they approach the world, how they collaborate, how they approach problem-solving, how analytical they are, and so on.
So if you find that the leaders that you're working with are all Type A personalities, it's very clear to them, "Oh my God, we're all Type A personalities. Who's going to do the analytical work? Who's going to be the more detail-oriented person? Who's going to be the one that actually rolls up their sleeves and does the work?" You know, if they're all sort of commanding and controlling.
Have you seen that and do you use techniques like that to help them sort of see themselves in some way as maybe realizing that, "Hey, maybe I need to change the way I operate," not that they can suddenly become the analytical person or the detail-oriented person, but maybe they need to bring somebody else into the leadership team that fills that void, right, so they can function more effectively?
Om: Yeah, absolutely. I mean, one of the things that I try and do is to, for each individual involved here, you know, get them to understand the WIIFM, right? The "what's in it for me." And then relay that to one another. And that happens in a joint setting, in the same physical space. Everyone's in the room together.
So then there's two realizations that happen, right? One is it lets them self-reflect on what is it that they're asking for and why? And then it lets them relay that to other people who then understand why this person's being the way they are in what they're demanding of them.
So at the end of that, we can say, "Well, now that you understand what's in it for you as well as what's in it for each person here, how can we now collectively unite so that we can chart a path forward?" Right? Where not everyone is going to, you know, submissively say, "Well, yeah, let's just do this, hold hands and sing Kumbaya." However, however, we'll find a middle path, that's the path of least resistance, right? Although I don't use the word "resistance" all that much.
So, you know, that then leads to the assessment, if you can call it that, culminating in a one-pager. And the one-pager simply is the top two things that each individual in the room is going to do to ensure that while they're looking after their own WIIFM, what's in it for me, they're also not shutting out the others.
That kind of has this appreciation for why finance is always taking their time, for example, at approving these financial bid requests or whatever it might be. They then understand, the askers can then understand that it's not these people being difficult, but they're trying to mitigate some risk around that. They're trying to do perhaps some due diligence and look at alternatives and things like that. So that the askers in the future, hopefully, can be better prepared with the information that they're going in with, right?
And so if you kind of look at that through a macro lens, it will help facilitate those kinds of decisions and hopefully reduce friction. That's really what it's about, right?
So, you know, you mentioned the phrase "meeting them where they're at," so the first thing there for me is having them realize where they're at. Because not everybody in the room will agree where they're at. Some people are very gung-ho, some are rather reserved and kind of more measured.
So once they can land on "where are we today," then let's not just go into this grandiose "where do we want to be," right? It's "what's our next step?" That's it. That's all we're going to do. And then we'll revisit that in due course, whatever that looks like. Typically, it's a few weeks. And say, "We were there. Now where are we?" Right?
So I mean, that's been my approach. So I don't like to take on things that are on a big scale and say, "Well, we're here, but we want to go over here." Just make sure that we can get one step at a time.
Kumar: Yeah. You talk about starting with finance teams using spreadsheets rather than tools, then gradually introducing them to Kanban boards with maybe some finance-centric terminology. Can you walk us through how you know when to give in and when to push for change?
Om: Yeah. So I mentioned just a few seconds ago about observing friction versus flow, right? So initially, that's what it's about is just understanding what is their journey like. And if a team's current tools allow transparency and predictability, I let them stay there initially. But when spreadsheets start hiding dependencies or slowing decisions, that's my signal that something has to change.
So I start to introduce visual boards. Again, not admonishing anything that anyone's doing, just to say, "Let's just see where we are." That's the first step. So I never push for change because it's agile. I gently prod rather than push when the pain is real and the benefits are obvious to everyone.
So in terms of the example here, spreadsheets are unidimensional. They only benefit the user that's looking at them at a time. So when you have a visible radiator of information, more people can ask questions. And those questions then turn into, "Well, what if? What if we do this? What if we do that?"
So change really sticks when it solves their problems, not mine, right? Start where they're comfortable. Push when pain is real and the benefits are obvious.
Kumar: I love that. You know, you've worked across different domains, right? Bringing agility to teams that you don't typically hear of as using, you know, agile methods like Scrum or whatever it might be. What's the biggest misconception these teams have when they first hear you're coming to coach them, and how do you break through those misconceptions?
Om: I think one of the biggest things when you go into teams that are not IT teams is "agile is for software development." That's how they think about agile. So I think agility equals chaos, right? No plans, no structure. So I counter that by showing how agile is actually about more discipline, not less.
But for, like, for example, finance, I use terms that they understand, right? So, you know, for HR, same thing, right? So for finance, you'll be talking about forecast accuracy, right? Not precision, but we're just saying we're there within a delta, right? They decide what the delta is, if it's, you know, depending on what the measure is at the time. But for HR, it's about employee experience, for example.
So in a nutshell, I try to translate agile principles into their language and show examples from their own industry. So once they see agility as a way to increase control through adaptability, that fear starts to wane, right?
Kumar: Yeah, I love that. So you're sort of like inching your way in and showing them you're actually using agile to help them embrace the change, right? So you're doing it very iteratively and incrementally, demonstrating the benefits that they get from it. And they get to see it along the way, which is awesome.
Excuse me. I really loved your story about watching construction workers doing their daily huddles without knowing it was agile. I know you commented on the lead-up to this event about that. Maybe it wasn't this event, maybe it was a post that I made about my first experience with agile was completely unrelated to what we know of as agile in the software and IT world. And my experience was in restaurants, and for you was watching construction workers doing daily huddles without knowing it's agile.
What did that teach you about the difference between practicing agility versus performing, you know, agile theater?
Om: Yeah, so to your point, the agile techniques, et cetera, were playing out in front of me without the labels, right? So every morning I would watch this construction crew arrive on site and they would huddle. After huddle, they will go out and do things that they would do, individual teams, and they'll get back together again at lunchtime.
So what it taught me observing this is that agility is instinctive when the goal is clear and feedback is immediate. Those guys were not following a framework. They were solving problems together because the cost of misalignment was obvious to them, right?
So agile theater happens when rituals replace purpose. For example, if your stand-up feels like a status report, you've definitely lost the plot there, right? Because people will just tick boxes. So, you know, agility obviously is about the outcomes and not the ceremonies. The construction crews nailed it. Daily syncs without the jargon, right? That's what I learned.
Kumar: Yeah, I love that. Yeah, you see that a lot in a lot of different contexts, right? People are being very adaptable, very nimble. They're responding to changes as it happens. You see that a lot in service industries, right? Restaurants and retail and so on and so forth, that people are being very agile. And it's about capturing that energy and bringing it to companies where, you know, things are less so. There's silos in between departments and divisions and so on.
So, you know, let's get to some maybe harder questions. Agile has, you know, taken a beating over the last few years, I would say, right? I mean, the traditional, I guess you would call it traditional agile, you know, the frameworks, and you got the framework wars, you know, you got SAFe and Scrum and Kanban and all this stuff. Companies have, you know, famously or infamously laid off thousands of people that were in agile roles, you know, Scrum Masters and Product Owners and things like that, and gone to more traditional roles. But the people are still doing agile things, which is good.
Where do you see the state of agile today? And, you know, especially with AI sort of in everyone's mind, right? The mindset is, "Oh, how do we use this AI thing? And we don't want to be left behind." What are your thoughts there?
Om: Boy, yeah, what a great question. Today, we are at an inflection point, I believe. Yes, for the last three years or so, specifically, maybe five, we've been seeing agile get a bad rap, quite frankly, right? But today, organizations are looking to get into or even ride further the bandwagon called AI, especially with agentic AI.
So while they are doing that, I have to say only one thing, right? Yes, agile as a brand has faded, may fade further, I think. But its principles have and will continue to permeate everything, especially outside of IT. In IT, there's a lot more scope of automating some of the mundane things that software development teams do, testing teams do, et cetera. But outside of IT, where agility has not really been adapted as widely, I think the certification mill, for example, will continue to lose relevance as organizations demand evidence of impact, not badges.
So success for practitioners going forward will mean shifting from framework evangelists pushing agile rituals to real business problem solvers. They may carry different labels as roles, but that's really where I think the crux of the matter will be going forward. We failed at installing agile in organizations as teams have found out, right? But the future isn't about that. The future isn't about doing agile. It's innately sort of weaving into the ways of working day-to-day and building adaptive systems that thrive in times of uncertainty.
Kumar: No, I love that. Yeah, there's so much going on. You're right. It's really about... I see it more in areas outside of IT where Agile still has a role to play. The principles, the values do. Maybe not so much the frameworks, but certainly the principles and the values do.
About your podcast, Arguing Agile, give me a sense for what that's about and what is it you argue about? I'd love to debate you on something.
Om: Sure. And we'd love to have you as a podcast guest. So back in 2017, we started the podcast with the concept of taking a topic and really breaking it down into contrary points of view, the pros and cons, however many facets there may be, and arguing for and against, et cetera, right, on each of these.
But then shortly after that, as we were looking at topics, we started, like most podcasts do, I guess, with, you know, agile-related topics around Scrum, Kanban, the events and so on, yeah? But we quickly devolved away from that into topics that nobody else was looking at, topics that we all face day in, day out, but nobody talks about them, right? So we do. We talk about those and we argue about those.
I will say we're not aligned with any specific agile methodology or framework, or we don't evangelize about agile all that much. We're also not aligned to any specific ways of working or thinking. All bets are off when it comes to the topics. Take a topic that someone cares about and then really go to town arguing about it in different ways.
Sometimes the two of us would argue, myself and my podcast co-host, even though we don't necessarily believe what we're arguing about, we still argue. We find there's value in dissecting the topic in a critical manner. That's what we do. Again, our podcast, the intention when we started was not to monetize it. It was just to make sure that there's a platform for people to come and listen to people that are talking about things that other people are talking about. So that's what we're doing.
Kumar: I like that. There is value in debating something. And I think that debating has waned somewhat, you know. I think in today's work society, work culture, it's all about work, work, work, work, work, and less about collaboration. And part of collaboration is the ability to argue, even if you do agree with the person, to argue different points so you can see things and solutions from a different perspective. And I suspect that's what you get out of it and viewers may get out of the podcast that you host.
Om: Yeah, absolutely. And I think one thing that really helps us is with my background, I bring in a specific set of beliefs and experiences. My partner has a product management background. So between the two of us, we kind of cover a vast landscape, if you like, in the workspace.
Kumar: Yeah, I mean, like you, this podcast got started as just more of an agile sort of, you know, me and my partners and I, we would get on once every couple of weeks or once a month and talk about some topic in Agile. And it quickly grew out of that into this podcast where this is really about disruption, leading through disruption, about disruption and innovation and how the two are related.
And whether it's Agile or some other method that comes after it, you know, I think disruption is always with us. And how people adapt to and innovate through that disruption is what sets successful people apart from people that succumb to it, succumb to the disruption. And we certainly are facing disruptions all the time with the pandemic and then AI and different things that are coming our way that we cannot yet foresee. It pays to be adaptable, nimble, agile, whatever you might want to call it.
Maybe some fun questions before we wrap this episode up. And actually, before I do that, anything I didn't ask you that you'd like to share with the audience?
Om: I think you've asked me a range of questions. So I think I'm pretty good with the questions. I'm just thinking through now what is it that I can say you didn't ask, right, in the context of why we're here.
I guess if there was one thing I'd say, maybe the mechanism by which people do things at work and how they're measured and rewarded. So, you know, organizational models tend to be either process-centric or people-centric, right, on the whole. And those that are process-centric tend to reward behaviors and norms that obviously do well process-wise. Here I'm talking about the practices and looking at failure and how not to repeat those again, rather than learning from them.
The other side of it, organizations that are people-oriented, they tend to value and reward taking risks, learning from failures, and embracing innovation, right? I've seen both sides of that in my experience. Organizations' reward systems are also aligned according to how they are, you know, culturally and, I guess, philosophically oriented.
So most of the time I've seen reward systems and reward models that align to being process-centric, right, not being people-centric. I do have one example to share if we have time. I worked with a global bank that shifted from individual KPIs to team-based OKRs that were tied to customer success, customer outcomes, right? And bonuses were linked to shared goals. It wasn't perfect. High performers feared dilution. But over time, collaboration improved because the system rewarded collective success, right?
So the takeaway was from that, if you don't change incentives, you're asking people to behave against their own interests, which are often quite entrenched and political.
Kumar: Yeah, that's, I love that, the whole reward model thing, the discussion, and I totally agree with you. And I like the example you gave, shifting from individual KPIs to more sort of team-based OKRs and things like that could be a way to reward people for the behaviors that lead to agility.
So here's a question from the audience. I think you can see it on screen. Partially on topic, you mentioned the construction industry, a very tough agile customer in my experience. Have you seen agile construction at scale in any setting?
Om: Great question. I've not seen it at scale. I've only seen it in pockets, right? So when you say scale, that's one industry, by the way, where scaling is linear, right, in my opinion at least. So essentially you're just doing them at a bigger scale. You don't have the chance variation as much in that world as you do in other spheres like HR or legal, or even to a certain degree, software development. So I've not seen it, but I would imagine that that model will scale fairly nicely, right?
Kumar: Yeah. And I will say from my experience in the restaurant industry, I wasn't even aware there was a thing called Agile at the time. But we still had stand-ups twice a day, before lunch, before dinner. We had planning sessions every week. Excuse me. I feel a sneeze coming on. Where we'd plan the menu, the entertainment for the week. We conducted, you know, events and ceremonies that were very reminiscent, of course, later on, getting into IT and Agile, of the ceremonies and events that an Agile team would undergo.
Of course, we kept track of metrics and our sales and our sort of customer churn rates and our ad spend, all kinds of things that were very reminiscent again later on. But what we didn't do was use any Agile jargon at all because we had no choice. We didn't know any jargon.
Om: Yeah, so high-performance teams.
Kumar: Haas, hey, Haas is in the house. Welcome. So I worked with Haas some time ago. He's experienced it at scale with the New York School Construction Authority. That's wonderful. I'll have to have you on the show. We can talk about that at some point.
A few questions, fun questions. So one, first one. Fill in the blanks, this one. The biggest blocker to organizational agility isn't processes or tools, it's blank.
Om: Your own mindset.
Kumar: General mindset, you said?
Om: It's your own mindset.
Kumar: Oh, it's your own mindset. Okay, yes. I love that. What's one popular agile practice that you think is actually overrated or misused?
Om: The daily sync, or the day used to be called a stand-up. I believe is the one that's often misused. And just because it becomes a status meeting, it becomes a status meeting. It becomes, you know, a chore for people to show up at just to say, you know, what they did. Yeah. They have no blockers. If they did have blockers, why wait till the next morning sync, right? Raise it immediately so that it's no longer a blocker 24 hours hence, right?
So I think a lot of times that teams don't like to do that. And then teams that are hybrid, you have offshore components to your team, right, team members. It's the tail end of their day, right? They're looking to wrap up their day. It's late evening, they're trying to get to dinner, and now you have a stand-up. It's not effective, I don't think.
Kumar: Yeah, I agree. I totally agree. The comment here, the founder actually watched that movie. And actually, my first job was at McDonald's, and I was a manager there. And I went to Hamburger University. And it's just unbelievable how lean and agile their restaurants really operate, at least back when I was running their restaurants. I went from McDonald's to full service and I ran the gamut in my twenties and up to the late twenties. But you're right, it is very much so. They even laid out the kitchen to help the workers deliver the food in a fast, efficient manner while still preserving quality. Yeah, good stuff.
One last one. If you could eliminate one thing from corporate America tomorrow to accelerate agility, what would it be?
Om: Well, without thinking, I would say politics. If you can do it, right. So it's not just agility. We'd all be much better off all around. Of course, to get to that point is difficult, especially in today's political climate.
Kumar: Yeah. Yeah. That's a good one. I like that. All right. I lied. One more. If you could go back in time and give your 2011 self one piece of advice when you first discovered agile, what would it be?
Om: When I first discovered Agile, it was around that timeframe, in fact. And it would be that we're trying to ask the orchestra to conduct music, right? But every member of the orchestra doesn't really have the same sheet of music in front of them. So you've got the percussionists going crazy over there. You've got the wind section going crazy over here, the brass guys. So that's really, you've got to tame that chaos somehow.
And the way to do that isn't about bringing them every day at the daily sync, all of those rituals that we talked about. The way to do that is to have a common, shared sense of purpose, understand why they're there, and give them clear understanding of that. Hey, listen, first, these guys are going to start and then these other ones will blend in and so on and so forth.
So that's what I would say to my 2011 self is take the patience and the time to make sure people understand why they're there.
Kumar: Yeah, I love it. All right. We're running out of time, so we're going to call it a wrap here. Om, thanks so much for being on the show. I really appreciate your insights. And if you're watching on LinkedIn or YouTube or Facebook, please subscribe to the channel. We go live mostly every week. So we will see you next week for another episode. And if you're interested, check out the Arguing Agile podcast.
I'm going to make an attempt to travel down to Tampa and be a guest, or maybe we can do it remotely. I don't know if that's possible or not. We can figure it out.
Om: Yeah.
Kumar: Okay. Awesome. Well, thanks again for watching and have a safe holiday season coming up and I'll catch you all next week.
Om: Thank you. Pleasure was all mine. Thanks.
Kumar: All right.
---
END OF TRANSCRIPT
