#181 | Capability Ownership: The Hard Conversation Leaders Avoid - Capability Unboxed Mini Series (powered by CIAB+) Part 5

Capability Unboxed Mini Series (powered by CIAB+) #5

Capabilities don’t sit neatly inside org charts. But accountability still needs to.

In this episode of Capability Unboxed, Fatimah Abbouchi tackles one of the most avoided leadership questions: who actually owns a capability?

Because capabilities cut across teams, functions, and governance layers, ownership rarely sits in one place. And when it isn’t clearly defined, coordination becomes informal, accountability blurs, and delivery starts relying on individuals instead of systems.

She breaks down why this conversation is often delayed, and what happens when it is. From outages and regulatory programs to transformation initiatives that lose momentum post-delivery, the pattern is consistent—everyone owns a piece, but no one owns the outcome.

This episode reframes capability ownership as orchestration, not control. It’s not about one team doing the work. It’s about ensuring the organisation can deliver the outcome reliably, end-to-end.

You’ll learn:

- Why unowned capabilities rely on “hero” individuals to function

- How unclear ownership creates coordination gaps and delivery risk

- What changes when capability ownership becomes explicit

Whether you're leading transformation, managing cross-functional delivery, or strengthening governance, this episode provides a practical lens on turning capability from assumption into something actively managed.

In this episode, I cover: 

00:52 The Ownership Question

03:23 Customer Onboarding Shows the Problem

05:06 Agile Structures Add Confusion 

09:01 The Coordination Gap in Practice

13:15 What a Capability Owner Actually Does

17:16 Why Leaders Avoid the Role

19:49 What Improves with Clear Ownership

And more...

🎧 Tune in, take notes, and join us in May for our live webinar event where we take a deeper dive into all things capability (powered by the AMO Way). If you can’t make it live, register anyway and we’ll send you the recording.

Transcript

Welcome And Series Setup

Fatimah Abbouchi 0:00

You're welcome to Agile Ideas the Podcast, hosted by Fatimah Abbouchi. For anyone listening out there not having a good day, please know there is help out there. Hi everyone and welcome back to another episode of Agile Ideas. I'm Fatimah, CEO at AMO, Mental Health Ambassador, and your host. Welcome back to the Capability Unboxed miniseries. It's the mini-series where we break down what organisational capability really means and why so many strategy governance and delivery problems stem from misunderstanding it. So far in the series, we've explored what capability is, how it differs from capacity, and why projects don't automatically build capability in BAU, and how organizations distinguish between core and supporting capabilities. In this episode, we're tackling one of the most difficult questions that leaders face when it comes to capability visibility. And the question is who actually owns capability? Because capabilities cut across streams and teams and functions and governance structures, which means ownership rarely sits neatly inside an organizational chart. It's also why many times people misunderstand capabilities and misunderstand functions and assume that they are one in the same and they are not, as we outlined in earlier episodes. So because capabilities across so many different teams and functions and governance structures, it's often a common occurrence where the conversation of where the capability actually sits and who owns it breaks down and becomes a problem. So let's dive into this episode. Across this series, when we've talked about capability, we've defined capability as the organization's ability to achieve a reliable outcome, and that is what an organization does, not necessarily how or who does it. We've also talked about the capabilities themselves and how they are cross-functional, how they involve multiple different teams, how they may also cross over different governance and accountability lines, reported differently, and also depending on what type of program you're running, i.e., in a regulatory compliance program, you also have regulatory obligations and other things to contend with, also. So this creates that unavoidable question, unfortunately, but it's something that needs to be answered. And that is if the capability sits across an organization, then who owns it? So let's talk about that in a little bit more detail. This is something that often, when I'm speaking with leaders, they often delay allocating a capability owner. And when thinking about capability owners, they often misconstrue capability ownership with functional ownership. And it's very challenging because capabilities itself don't sit in a single department, they are like all value that an organization delivers, cross-functional. And that's what helps an organization to meet its overall objectives. I'm going to use a very simple example. Think of customer onboarding. In our business, we are regular regularly onboarding customers. And when we do that, the the processes that underpin that include sales and operational teams, maybe compliance, potentially HR for onboarding, um, onboarding new staff to support the customer, technology, because we'll be onboarding them into different systems, risk potentially, depending on the size of the company, legal from a contractual perspective. So you can see that every single function performs a part of the work that makes customer onboarding actually work. But when we think about who is accountable for the organization's ability to onboard customers reliably, well, that's a little bit unclear because you really think about it, and because it cuts across so many different functions, you actually can't pinpoint any one specific one. So capabilities themselves will exist whether they're owned by anyone or not, because otherwise there wouldn't be any point in being in business. Our business, as an example, has a number of capabilities that we provide, and they are the things that we do as a business. If our consulting business was to, for example, acquire a um a supermarket as an example, then our capabilities would evolve to then take into consideration what it takes and what we do in terms of retail. So why does why, when we think about it and we talk about this ownership piece, why is it such a challenge? I will also just point out that thinking about the recent sort of four or five years, more pre-COVID times, there was a lot of emphasis when organizations were changing their enterprise operating model and moving to agile ways of working. Something that continued to sort of come out of that. Well, a lot of conversations were there was confusion when organizations would establish things the vertical tribes, um, and effectively just doing functions but putting fancy names on it. But the challenge that they had, a lot of these organizations that I had seen, they had very similar challenges, is when work was cross-vertical or cross-functional, how they managed and dealt with that. And so even back then, in those examples, they introduced different concepts like chapters and other things like that as well. Because if you think about that as an example, and then referencing what I'm talking about around functions and capabilities, the functions or tribes in this example was providing the direction on what needed to be done, and then the horizontal uh chapters and capabilities effectively help to drive the how. And so I guess the point here is that organizations typically are structured around functional ownership, even if they have fancy names for it, and the leaders themselves typically own the teams, the budgets, the systems. Um, in our team, for example, the the people responsible for delivery will own the lit the resourcing, the budgets, the processes, everything to make sure that delivery is done well. Whereas when they think about the work we're delivering, it involves a number of different capabilities. They cut across boundaries. So work we're doing for a client might might touch delivery and touch actually several other areas as well. Lots of teams are contributing, and when all of these things are happening at the same time, it's really important that the organization itself can also maintain operations. So, for example, I'm I've run a number of different programs where, for the most part, organizations want to leverage their business as usual or operational teams, and they typically want to do that and they want to minimize disruption to those teams. So when we're thinking about the bigger picture, if we don't take into consideration who's ultimately accountable for the capability that we're building, because programs and projects often are introducing or uplifting capability, then issues can begin to circulate. And so, as an example, we might find that technology will say that some issues that might arise sit with operations, but then operations might escalate it, escalate that risk and refer it back to the business. And so there's sort of this kind of circular loop that happens because we haven't thought about those capabilities themselves. We were so fixated on the functions. So, uh, as a good example, one of the um automotive companies we work with had a major um outage investigation, and through that, lots of people performed their role to support addressing that um breach and that cyber issue, but no one owned the overall capability. So think of it as functions and managing pieces of the puzzle, but the capability is actually the representation of the whole system working together. And so, again, when I hear capabilities and think about capabilities, often organizations do conflate that with functions, and this is where I think they get it wrong. Hence, introduction of the coordination gap that actually ends up emerging. So let's talk a little bit about the coordination gap that I'm seeing. And I want to outline that the gaps that are effectively coming up are not unique to a specific organization, they are fairly consistent and fairly recurrent, depending on the size of the organization. It's not really that different, it's just the size of the problem or the challenges that they're facing. So, what happens when capability ownership is unclear? The obvious thing is that the coordination associated with getting outcomes and delivering what we need to deliver to meet those outcomes becomes fairly informal. So you find that BAU teams or business as usual operational teams end up having to fill a lot of gaps. And that's because a lot of the time when we think about programs and projects, often they are introducing new capability or, as I said, uplifting capability. But until they've done that, someone needs to fill the gap. And this often becomes the program leader, the transformation team, maybe a senior manager that's informally coordinating across functions because they're seeing the pattern. Ultimately, the business continues to operate, but there's all this hidden dependency on individuals. One of the biggest things I see when it comes to execution and delivery of projects and programs in general is every organization is delivering numerous projects and programs at any one time. The challenge is many of them, if not all of them, are effectively engaging or trying to engage or plan to engage or are proactively putting into their schedules time of these BAU operational resource teams to help and support and be part of their program. What we don't do very well, and in most organizations I've work with, we absolutely workforce manage and capacity manage the project resources. When we're requesting our budgets, we think about that, but seldom do I see people thinking about the operational impact on those resources. Think about how many projects are reaching out to HR, sales, marketing, and trying to bring those people into their project. Now multiply that by the number of projects. It is no wonder there is gaps. It is no wonder there is challenges in actually getting delivery, and it's no wonder there's all these metrics that say that projects aren't succeeding. And part of this is because they're not able to hand over to BAU effectively, or because they didn't engage well, or the people they engaged in have the capacity. So it becomes a bit of a problem. Thinking about transformation programs, which I've been involved in many and have part of some at the moment, they run across multiple streams. And that's because the program director is often coordinating constantly. But when the program ends, that coordination element disappears. And this is where capability weakens again. So if you are not focused on uplifting and making sure you have the right guardrails around your capability, you'll find that you will start to have execution gaps at the end of your projects and programs. As an example, uh customer complaints processes, part of customer onboarding, improves during maybe a regulatory review, the dispute resolution elements, they all are conflicts management. All these things are focused on and looked at during the program lifecycle. But once the program finishes what they need to do, or the review of those elements finishes, that particular area can begin to degrade. And why does that happen? Because often there is capabilities associated with these things, like the one I mentioned earlier, that is relying on a program to exist or relying on specific people to drive it, or it's just unknown. And so it often leaves us with a lot of visible gaps. And this really comes down to the fact that there isn't a single capability owner or ownership over capability. But first, before we think about what capability ownership actually means, let me just be really clear that capability ownership does not mean that one team or one person performs all the activities. That is definitely not what I'm saying. Instead, what I'm saying is that a capability owner, whoever is being allocated as the owner of that capability, is accountable for whether the organization can deliver the outcome reliably. Remember, the capabilities are what a business does. And so you need a capability owner to make sure that that capability is introduced, uplifted, and continues to grow. A capability owner, for example, that might be sitting on one capability that touches lots of functions could actually be an executive from finance or from sales or marketing. It doesn't matter where they're coming from. The point is that the focus here is about making sure that the organization can deliver outcomes reliably. So the typical things that the capability owner would be doing is they would be contributing to the design of the capability. They would help to determine and define the outcomes that the capability must achieve. They will help to ensure alignment across multiple teams, particularly when there's decisions that need to be made. They would help clarify the rights and accountabilities of the decisions that need to be made and make sure the right people are informed along the way. They will help monitor the health of the capability. They will look at gaps that come up as a result of that capability. And they will ultimately be coordinating the system that supports the capability. And I don't mean a technology system, I just mean the cohesiveness of that capability from identifying it or uplifting it and then making sure that its health continues long after any project or program is gone. So in many organizations, a probably common example is product management. So product management often acts as the capability owner for the product lifecycle capability. Engineering team will build and the risk teams will review, and legal does the contracts and the operations support, but the product owner ensures the system works end-to-end, so across that value chain. Capability ownership is effectively the orchestration, it's not the control. Everything from customers coming in through the front door to them being serviced, onboarded, paying, and then eventually you know leaving or just maintaining the services they had. Now that touches every part of the business, everything from frontline all the way through to the back-end operation side. Now, it would be very difficult to manage work across the value chain by having the work broken up and no orchestration layer on top. So in a lot of organizations who introduced the value stream mapping model or introduced different ways of working that centered around value streams, what they found was, and what they did was they allocated product owners as the capability owner for that whole life cycle. And then the product owner would coordinate with multiple teams and multiple areas to get the job done. And that works really well and actually sees effectively SMEs that help to see those things through and then continue to allow the functions like engineering and operations and risk and legal continue to do what they do best. So capability ownership is orchestration and it's not about control. So let's just be really clear about that as well. So bringing us back to leaders and capability ownership. Why do leaders avoid assigning capability ownership? Well, the truth is it does raise uncomfortable questions. I've been through this recently with some clients where I did get a lot of pushback questioning why we have capability owners when we have functional owners. And I had to try to explain how they are different and why it's important. It's very important and it's really helpful to know that when we think about multiple functions disagreeing, or who resolves that conflict, or when the capability ownership has to interact with multiple reporting lines, or when the authority against the capability itself, who holds that authority, who makes the design decisions on that? When we think about governance and the power structures, so your three levels of governance, your projects and programs, your enterprise, and your external governance layer, who actually holds the say in that? And ultimately, they are uncomfortable questions. So, because of that, it means that organizations want to postpone the conversation around who owns capabilities. In fact, when organizations talk about capabilities, other than more recent years, it's always been about people and it's not about the people in this instance. So let's use another example. I was engaging with a mid-sized law firm and they were introducing data management capability. They had technology teams own the platforms that were being developed as part of their programs and ownership into BAU long-term. The business units inputted and provided all of the data. The risk team provided oversight and input on the governance. And ultimately, what they found was that they continued to have issues, one with embedding that data management capability, with ownership, because every area that I mentioned and others would not be taking complete ownership. And even with all the large investment and the millions of dollars they spent introducing that system of that capability, rather, there really wasn't a capability owner that could own the capability or was uh identified to own the capability. So what it happened, what ends up happening was they had all these accountability gaps, and ultimately capability ownership doesn't remove accountability, but it will bring to the forefront those gaps if you don't have the capability owner defined. So what changes when ownership becomes clearer? So when the capability ownership becomes clearer, several things stabilize. In the recent examples of clients I've worked with, as an example, we've been able to reduce the decision timelines. Why? Because when you've got a capability owner that is overseeing it, it makes it a lot easier to identify decisions and get them triaged and also have those decisions made. So the life cycle of a decision becomes shorter. The cross-functional coordination improves. Often the capability owner has touch points into multiple different functions, so it helps there as well. And governance forums then can focus on the outcomes rather than debating who's responsible and who's accountable. So that really helps as well. And I'm seeing that more and more prevalent, especially in organizations that are starting to look at why capability uplift is important and why having capability owners is actually very beneficial for their business. And then the organization itself overall can start to manage the capabilities as their organizational assets. In our business, we're building out all of our capabilities, and we've continued to do that over the last 10 years. And that is building up our IP, our organizational assets. They're the things that are going to ultimately help us to make sure that we can deliver consistently for clients and meet the outcomes that we aim to achieve. Customers, in customer experience example, I used earlier, capabilities around this will often dramatically improve when you've got a single executive focus on who owns the outcome across the functions. Thinking back to the agile ways of working example I've made, they had nominated chapter leads. That was a very common role title. But that didn't replace someone's day-to-day role. That was a second hat that they wore in terms of their accountabilities. Very similar with capabilities here as well. So ownership turns from being just a capability to uh turns the capability from being assumed to actually something that is actively managed. And that is super important. In fact, when we um facilitate, and I've just got an example here. We actually have a cap, it's a bit hard to see, but a capability workshop that we do. And in that we have a different range of different personas. And we use that, those personas in actually working through and understanding where the capabilities sit. It's part of a workshops that we do to help clients and facilitate and identify capability gaps. And we find them super useful because we help to tease our ownership in a way that they would not have really thought of and actually enables teams to put themselves in the shoes of those capabilities, sorry, of those functional owners. So it makes making decisions around capability ownership a lot more clearer. So that's effectively how CAP, that's effectively I guess what you need to know when it comes to capability ownership. Capability in a Box or CIAB, CIAB, the product and service that we've developed over the last 10 years, has really been created to help organizations identify their critical capabilities, regardless of whether it's delivery projects and programs and governance, or at an enterprise level, and you're bringing in strategic and enabling supporting capabilities. But it also helps to define ownership. As I said, we go through a protest and actually define a number of things from governance personas right through to what the needs and desires of the executives are, and actually go through and map that out as well. And we do that through a range of prompts so that we can actually land on defining capabilities like this one as an example and streamlining them getting to the outcome that they are needing. So it identifies critical capabilities, clarifies capability ownership, and it aligns governance and delivery around them as well. So the goal is not to create new bureaucracy with capabilities, it's not a replacement for functions, but it's to help the organization's core abilities to be intentionally managed and also support the integration of new capabilities in a more streamlined way. And remember, clarity reduces friction at all times. If you have enjoyed what you've been hearing in this episode and in the previous episodes, be sure to join us in May for our live webinar event where we'll deep dive into all things capability and capability in a box powered by the AMOA. Keep an eye on our socials and remember to register. And if you can't attend on the day, we'll also be sending the recording for everyone who registered. If you have any more questions or you want to know anything more, please don't hesitate to reach out. Thank you so much for listening to this podcast. Please share this with someone or rate it if you enjoyed it. Don't forget to follow us on social media and to stay up to date with all things Agile Ideas. Go to our website www.agilemanagementoffice.com. I hope you've been able to learn, feel, or be inspired today. Until next time, what's your Agile Ideas?