#179 | Why Organisations Treat Capabilities and People as the Same Thing and Why That Breaks Execution - Capability Unboxed Mini Series (powered by CIAB+) Part 3

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

Ever heard someone say, “We don’t have the capability,” when what they really meant was, “We don’t have the person”?

In this episode of Capability Unboxed, Fatimah Abbouchi tackles one of the most persistent structural mistakes in organisations: equating capability with headcount. It sounds harmless — but it quietly fractures delivery, inflates estimates, and creates governance bloat.

She resets the foundations by clearly separating capability from function, role, and capacity. Capability is the enduring what of the business. Functions are groupings. Roles carry accountability. Capacity is available effort. When those concepts blur, execution suffers.

From restructures and portfolio planning to regulatory programs and new product development, this episode explores what really happens when capability is reduced to a person or team label. Delivery fragments at handoffs. Estimates inflate inside silos. Steering committees default to “who owns it?” instead of “what system enables it?” Governance grows heavier, not clearer.

Fatimah shares a practical cross-functional model for anchoring capability properly — mapping it across outcomes, processes, tools, and data; assigning ownership for decisions; and planning capacity against capabilities rather than departments. The result is a more resilient system that holds steady even when leadership, teams, or priorities shift.

If you’re leading transformation, managing a portfolio, or trying to reduce rework and single points of failure, this episode gives you the language and structural clarity to re-anchor execution.

🎧 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). 

In this episode, I cover: 

0:40 The Core Problem: People Don’t Equal Capability

2:58 Layers: Capability, Functions, Roles, Capacity

4:55 Cross-Functional Nature Of Capabilities 

6:06 Why Organisations Conflate Capability With People

11:20 Governance Bloat And Inflated Estimates

13:17 Designing Cross-Functional Ownership

17:05 New Product Development Example

19:05 Avoiding Misdefinition And Misgovernance

And more

Transcript

Welcome And Series Recap

Fatimah Abbouchi 0:00

You're listening 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. Today we are continuing in the series of Capability Unboxed. We've already previously spoken on episode one and two about what capability really means and the difference between capability and capacity. And in today's episode, we're going to talk about why organizations treat capabilities and people as the same thing and typically use it interchangeably and why that actually can break execution. So let's get into episode three. So when we think about capabilities and the interchangeable way that they are used in organizations, think about some of the common messages you might hear, or some of the common phrases you might see seem to be around, where people are often referring to things as we don't have the capability to do something, or we don't have the capability in our team currently, or we need a capability owner, or who is the responsible owner for this capability, or this capability sits with Sarah, or things like that. As a simple example of some of the things we would commonly see in organizations, I found for a really long time, as I articulated in the first couple of episodes, that capability can be very misunderstood. In fact, as I said, for a really long time, I like probably many of you think of capabilities as people's skills and their abilities. But we covered that in a bit more detail in the previous episodes. So what I wanted to talk about here is the fact that capability can actually become shorthand to mean a person or a team or even a job title. But unfortunately, this is problematic in itself. As an example, I'm running a program at the moment, and when we talk about specific capability in relation to some of the work that needs to be done, the work was referenced as someone, you know, Johnny's job or Sarah's job. And that's because that individual has the capabilities in terms of the skill set, but also what they didn't consider is the outcomes, the processes, the tech, the data, all the other things that make up and underpin capabilities themselves. So, yes, the person had knowledge and skills, but didn't actually have all of the other components. And so assuming that capabilities themselves are a direct correlation to an individual is not a good idea because it impacts organizations from actually being able to produce the necessary outcomes when they have capabilities considered in a cohesive way. And so when we think about um the the times that I spend with organizations to help them um understand the the way to best introduce capabilities or more the way to consider them in their organizations, I think of it in multiple layers. So first of all, when I think about capabilities, the way that I articulate and introduce it is to help an organization think about the capability as your organization or your team or your functions ability to do something. So think of it as the what. And then when I think about the next layer down, it's then thinking about what functions you have in an organization. Those functions are the structured groups of people: finance, marketing, HR, etc. Then you think about the roles. So when we talk about roles, this is where accountability comes into play. And then it's capacity, which we spoke about in episode two. So this is around available effort. And basically, between those four kinds of criteria, they they are all very different but all interlinked. So as I said, capability is that enduring capability, the enduring what of a business, capacity being the available effort, roles introduce accountability, and then the functions is the grouping of people themselves. So it's really important to understand when we use any example, and I'll use one that I'm relatively um focused on at the moment as part of some regulatory work I'm doing. You could pick a particular capability that might span um risk areas, compliance areas, legal operations, reporting. And when you think about that, not there isn't an individual that is all those things because the capability itself crosses over multiple functions. And so naturally it will cross over multiple people. And so although there may be one individual who's accountable for a capability, that capability may span multiple functions and teams and areas, and so there's an interplay there. So an organization, for example, that has to have um the capabilities in place to be able to do what they need to do, they will often have to integrate across multiple functions, divisions, teams, etc. So this is where capabilities themselves are not functions. It's not a capabilities, there can be capabilities that sit in HR and in finance and marketing, but capability if you think about like the value stream um model, it it's effectively capabilities that sit across your organization and they touch multiple different um multiple different points. Um good examples of um some good examples of how organizations tend to confuse these layers is when they are um resetting their organizational structure, maybe they're acquiring a new business, maybe they're merging, demerging, any of those things, they'll often confuse structure and capability as the same thing. And that can tend to create problems uh longer term. Because if you are assuming your capabilities are mapped one-to-one to your functions, it actually doesn't make sense because functions and organizational structures change more frequently than your capabilities. And so it's important to understand the structural difference between capability, function, accountability, and role. So that begs the question: why do organizations collapse capability to begin with into um you know the people elements? Why, why, when we've got um visual visual and visible orc charts, do we struggle with aligning capabilities that are outside the realm of an org chart and outside the realm of the functions? We also think about um the ability to think about governance structures that exist in organizations that do reward single-point accountability. We also see leaders that currently think uh consistently think in reporting lines, not operating systems. And we also see steering committees that want to know who owns something, um, not where it sits or where it's uh accountable roll-up is. We find that there are a number of different instances where when thinking about capability uplift in general, people will assume then they need to integrate and involve HR and human resources teams or talent acquisition, people and culture. Yes, they deal with capabilities, of course, but so does every function in an organization. They just focus a lot of their efforts on the people side of capability. But capability itself, as I mentioned in the earlier episodes, is about people, process, and tools, tools including technology. And so it's um people are conditioned to think of capabilities in that way. It's far easier to just assume capabilities sit at the functional, just sit at the at the functional level and think about capabilities being people and their roles, than it is to actually unpack that and think about how there is actually cross-cutting capabilities that operate across an organization that is not as black and white um as people may seem, uh may seem to think. So when collapsing capabilities into people, there are a few considerations to keep in mind, and some of those um evidential consequences include things that really um resonate, particularly around the places that I spend a lot of time in, and that is delivery fragmentation. So delivery becomes very challenging when there isn't clear accountability not only on who is doing the work, but where it sits in organization and what it is that we're trying to do. Almost all delivery rolls up to um one or more capabilities. And unless those capabilities are clearly defined from the outset and effectively sort of help the organizations, think of it as like the governance spine in an organization, sort of underpins all of that. You can find that there is gaps at handover from delivery into BAU. You can find that there is rework a lot of the time. Um, often this gets picked up in audits. Uh, one big one that's something very familiar lately is the concept of program governance bloat. Um, when capabilities are not being factored in as part of estimating and planning delivery uh initiatives and projects and programs at a portfolio level, what that typically ends up happening, what typically ends up happening is you get this significant bloat because people are not thinking about what the organization's needs to do cohesively across the people, process, and tools. They're only thinking about it from their individual silo. And so what happens is then they are accounting for uplift and changes to their areas and not actually thinking about it more cohesively. So again, the the this ends up resulting in inflated estimates, it ends up resulting resulting in governance blow, it also ends up resulting in um structural difficulties around decisions, uh lines of accountability, and a number of other things as well. So ultimately, um by uh thinking about those sort of key challenge areas, it ends up being something that as an organization tends to scale, it duplicates and consistently um exacerbates the problem. Um, another thing is by not being clear on capabilities from the outset and just assuming it's a people problem, people will then assume that uh anything relating to a particular capability sits with that individual, and often it doesn't. As I said earlier, they're cross-cutting. And so it can actually really significantly impact execution. Um, and this is why thinking about it from capabilities, one of the other really important considerations is the fact that when you build your organization based on functions and people alone and not the capabilities, it ends up uh significantly changing every time you have uh you know an augury structure or a significant um change in leadership or something of the sort. So you want to avoid as much as you can conflating capabilities with people only, you want to think about capabilities uh more cohesively. The other thing to consider is that I mentioned briefly that capabilities are cross-functional and they absolutely should be. Why? Because capabilities themselves, as I said, is about what an organization does. And usually what an organization does can't be achieved without your strategic elements, your delivery teams, and then your um your enabling and supporting functions as well. So you need to make sure that you are not only assigning um, you may assign capability owners, but you need to make sure that the capability itself is structurally cross-functional. And doing so can make sure that you eliminate uh bottlenecks and also make sure that you have clear line of sight to where the accountability stops and starts. Um, what you want to also make sure is that you are factoring in ownership not just of the capability, but also the process, the tools, and the aspects of people that directly link back to line management and similar things like that. So there is this whole misconstrued view on capabilities just relates to people, but uh as I said, it is much more broader than that. So if you think about it more holistically, the challenge we find here is by just simply thinking about it from a people side, it really doesn't help your organization when those people change. And I've seen so much structural damage when someone key or a single point of failure leaves an organization or there's a big change at the top. So you need to think about capabilities more broadly and think about it properly and think about what it could actually look like. So the best way to start thinking about that is to re-anchor first of all, alignment on what capability means, and that's because people do have those mixed definitions. Think about capability overall as a system, it includes outcomes, processes, tools, data, technology, governance, roles, responsibilities, all of those sorts of things. And it's the individuals themselves, the people which operate the system, they're not the system themselves. So that means you can continuously evolve the system despite people changes, and the system shouldn't break. I'll give you a couple um of examples. So when we think about a particular capability in the organization, um, and what when I think about some of the recent clients we've dealt with, then they might have specific type of capability in the say new product development space. Now, new product development is something that cross-cuts many different functions in an organization, and so there'll be um aspects that link back to risk and quality, legal product, operations, sales, marketing, almost every function of an organization. So you want to make sure that the accountabilities are clear up front, but the delivery itself to support the capability is actually distributed more broadly. And so governance, remember, governance doesn't equal delivery. I know sometimes people like to grade their own homework and misconstrue the two, but also capability doesn't equal headcount. So again, another mistake organizations tend to make is when they are doing their org charts or restructuring or undertaking a transformation that involves restructuring, they will often think about just the individuals themselves, not the capabilities that those people support. Remember, capability is the system and people support the system. So it's really important to not ever forget that. The other thing um I'll just say as well is I know it can be quite challenging to move away from capabilities being people. So I'm okay if people um continuously reference capabilities in the context of people, but I think it's important to understand that the capabilities and the people element are just one cog in the system, so to speak. So I think it's really important to help organizations understand that, particularly when you're undertaking a significant or large-scale change. Um, I'm undertaking a number of programs at the moment, and we've had to think in capabilities because otherwise we get down into too low a level of detail that doesn't really help the organization that we're building to actually um, I guess, sustain itself long term, especially if it's built on existing functions or the individuals that are running those functions. So because we know that those sorts of things change. So I think if you um ultimately misdefine, misdefine capability, and I guess don't get everybody on the same page with what it means, or everybody assumes it's X and it's actually Y, or you make it simply about the people and you neglect the process and tools element, you will likely misgovern it, you will likely um misestimate, you will likely close some gaps prematurely and have others gap other gaps open that can't be um closed. And you'll also find that your underpinning operating rhythm and structures of your organization may feel chaotic at times, particularly when functions often operate in silos, whereas capabilities cross-cut across an organization. And so this is why it's really important and helpful to have that lens as well. In the next episode, we're going to talk about why strategy fails. Um, and really, I'm gonna emphasize I'm gonna emphasize rather why we see it all the time. Strategy uh is defined often you spend hundreds of thousands of dollars to have a big consulting firm put together a strategy, might be the best strategy in the universe, but the problem is that it's execution failure that impacts the strategy from actually being able to be achieved. So I hear a lot of statistics the strategy failed, but when you dig deep and you go under the surface and you complete your your uh quarterly reviews or your post-implementation reviews, or we're doing a bit of a diagnostic discovery for clients, I find that it's not the strategy that was failing, it was actually execution. And so sometimes there's some disconnect between the two. But we'll talk more about that in the next episode. 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 Idea?