Introducing LiminalArc (Formerly LeadingAgile)

A message from our CEO on why we changed our name and what you can expect in the future!

What is LiminalArc?

LiminalArc is the execution engine trusted by Fortune 100 boards, cloud hyperscalers, and top-tier private-equity firms when the plan must translate into performance. Our team of 100+ experts sit shoulder-to-shoulder with the C-suite to cut through organizational drag, and work with your teams to accelerate stalled initiatives to deliver provable ROI. No shelf-bound strategies, no hand-offs; just measurable outcomes from boardroom to front line.

Video Transcript

Hey everybody, this is Mike Cottmeyer, the CEO and founder of LeadingAgile.

I’ve got some really big, exciting news that I want to share with you guys today. As of Monday, July 21st, 2025, leading Agile is officially changing our name and becoming Liminal Arc.

I want to take a few minutes to explain how we got here, what this name change means to me, and where LeadingAgile/LiminalArc is going next. As a company, it’s really hard to believe, but LeadingAgile turns 15 years old this month. The July 21st date is actually 15 years to the day that we incorporated the company. It’s just a little bit ahead of when we launched the brand on August 1st, 2010. But when I started LeadingAgile, I used to joke that I had somehow convinced my wife that it would be a good idea to quit my job and to go out, solo, as an agile coach.

I had never really set out to build a company, at least not at this level of scale, but it became pretty clear early on that I couldn’t make the kinds of impact and changes that I wanted to and the size companies that I wanted to make if it was just me doing this all by myself. So in those early days, it was me, Dennis Stevens, Rick Austin, Denise Taylor, Dean Stevens, and a handful of others. Really fundamentally trying to change how companies built software. And here’s kind of the ironic thing, I wasn’t really a software engineer by trade. I’d had a degree in computer science, have a degree in computer science. I’d run large software delivery initiatives. But at my core, where I was at my career, I was fundamentally a project manager. I cared about delivery time, costs, budget, execution. Those were the things that kind of got me going.

When I encountered agile back in the early 2000s, it just clicked. It was a better way of building software and dealing with uncertainty and still being able to deliver to the goals of the project that we were trying to deliver. LeadingAgile, in the early days, and really even up until now, was really built on three foundational principles. We wanted to be able to build complete cross-functional teams. We wanted those teams to be able to operate off of well-formed backlogs, and we wanted the ability to produce a working tested increment of software at the end of every sprint. The idea was if we knew the size of the backlog, we could establish the velocity of the team. We could get to a definition of done. I would have all the advantages of agility and still have the ability to deliver on time, predictability, manage scope, manage risk, all those kinds of things.

But as we got deeper into this game, we hit the same wall. And something that I talk about all the time is the idea of dependencies. And so dependencies led us to explore the idea of teaming structures at scale. What do lean-agile governance models look like? How do we do value-based, flow-based metrics that allow us to measure progress across multiple teams delivering integrated deliverables? And that really led to the idea, when we started to scale some of these things, is how could we do and create repeatable methods to manage organizational change and organizational transformation? In those days, we believed, and we still do believe, that true enterprise agility requires fundamental operating model changes in most of the organizations that we go into. And by operating model, I don’t mean just process change, but installing the systems, the teaming strategies, the governance models, the metrics and the practices that fundamentally transform how the business operates.

And over the last 15 years, we’ve had a lot of success, some really, really big successes. We have a few that we’d like to have back, but overall, the approach was working and we were learning a lot about how to do this at scale. Given all that success, the one thing that was really fundamentally in our way, it was really the dependency of all dependencies, was the idea that the code bases that most of our clients were working with fundamentally lacked the ability to deliver in an agile way. The developers struggled to deliver in agile way. The code bases were not architected to be able to deliver in agile way. And so when we brought the idea of teaming strategies and governance and metrics into organizations that had poorly architected software systems, it forced trade-offs that were really hard to recover from sometimes. And so, we’ve kind of known this for about 10 years, but probably about five years ago, I had partnered with Matt Van Vleet. He came into LeadingAgile. We had worked together 10 years earlier in a company called Pillar Technology, and we started incubating our studio.

The foundational idea with the studio was that if we could tackle the tech and platform issues that made agile difficult in the first place, that we could actually really solve this problem in a deep meaningful way. So what does that mean, right? We wanted to be able to extract critical apps. We wanted to be able to modernize them, get the architecture and the data, and then ultimately form teams around them that could move fast, aligned to business outcomes, and could actually operate with the level of agility that we were seeking to do for our clients. So today, as we are on this precipice of changing the name and rebranding to LiminalArc, I’d like to describe us as this. We’re not just an agile consultancy anymore.

We are a business focused technology forward organizational change management company. Agile is still fundamentally in our DNA, that doesn’t go away. So is software craftsmanship. That doesn’t go away. Those things are absolutely foundational, but those have always been a means to an end. And what’s that end, right? So resilient change ready systems that solve real business problems. So this is kind of how we’re approaching the market as LiminalArc. We start with a business problem, define how we’re going to measure success. We want to extract and modernize the key systems that are going to be necessary to deliver that value. We want to get the architecture fundamentally right? We want to get the data and we can begin to start thinking about how to form teams delivering in short cycles and tying all that up through our governance models to make sure that we’re cascading intent down in the system. And then as features and epics and user stories are delivered that we’re able to measure the progress in real business terms.

So, what we’ve done is we’ve packaged this into six go-to-market motions that we call facades. We call them facades because at the core, this idea of technology forward, business focused organizational change is really, it’s really the same thing no matter how you talk about it or what organization you’re throwing it at. So, the facades that we are centering around is the idea of private equity, helping portfolio companies modernize tech for mergers and acquisitions value. Cloud migration, not so much in moving applications to the cloud, but solving the cost and capability problems post lift-and-shift. Application security, embedding security into modular agile friendly solutions architectures. ERP integration, unwinding fragile integrations with strategic refactoring. AI readiness, making sure the foundation is in place before we attempt to do AI at scale. And of course, agile transformation/ enterprise transformation, still something we do, but almost never is it just the process and teaming strategies. There’s almost always a technical component to it as well.

So why the name change? Why LiminalArc? If you guys recall, LeadingAgile started as a blog. It was my blog back in the day when I was still in corporate America. And then it became a personal brand and then it became a company brand and it became a company. And so for me personally, letting go of that name has not been easy. We’re still struggling internally to call ourselves by the right name, but it was important to us because we needed something that honored our past while creating space for these new facades, these new offers that we’re currently doing more than we’re doing core agile transformation. So, the name LiminalArc, what does it mean?

So, liminality implies thresholds, it implies doorways, it implies in between states. Arc implies motion trajectory, a smooth curve through that change. So the name together, LiminalArc means just simply a smooth path through change, right? Navigating kind of that messy, risky, uncertain work of change with clarity, with confidence, and with impact. So, you put those two words together, and what LiminalArc means to us is creating a smooth, predictable, knowable path through change that’s often difficult. We help companies navigate the messy, risky, uncertain work of change with clarity and confidence, making sure that we’re focused on the impact that we’re having to the business at every step of the way. And one thing that was kind of neat about it is that many of you guys out in the marketplace, our clients our employees have called us LA for years, right? That’s often how we refer to ourselves internally.

And so, when we came up with the name LiminalArc, we really kind of liked the idea that it tied and connected to that LA that people often refer to us by. So, as we move into this new name and this new brand and this new market and this new positioning for the things that we do, the core of LeadingAgile is still in our DNA. We are still fundamentally a transformation company. And LeadingAgile is the foundation that LiminalArc is built on. But now as we move into the future, we’re ready to grow into something more. We want to open up more possibility and not have a name that focuses us so tightly on the agile part of what we do. I tell our people over the last years we’ve been contemplating this, that agile will always remain a part of this. It’s just that the agile and the agile transformation parts are moving more into the background, focusing on the business problem first, the technology that has to be cleaned up, modernized, extracted, rationalized in order to be able to solve those problems, create resilience systems, and then bring the organization and the governance and the metrics and all the things that we focused on for the last 15 years along with us.

And so as we do this brand, and as you guys listen to this message, I just want to say thank you for being part of this journey. Thanks to everybody who pays attention to our content. We’re going to keep creating content. You’re going to see us do new and different kinds of content. If you’ve been paying attention for the last six months, we’ve been kind of dropping some ideas out there and practicing a little bit.

And we just really appreciate your attention. We appreciate you being along for the ride with us. Appreciate everybody that’s worked here or works here now. We appreciate our clients and just really thank you for being part of this journey with us. And we’re really excited for the future, where we’re going, and there’s just this profound sense that we’re just kind of getting started. We really do feel like we’ve kind of cracked the code on something, and that as we get into this and do this with more clients, that we can really make a big impact. And so, appreciate it and we will keep you posted and let you know how our journey continues.