What teaching others revealed about what I actually know

One of my mentees once asked me a question I was not prepared for.

"Why do we spend so much time creating a capability model, if the stakeholders are never going to use it once we are gone?"

I did not have a good answer. And the fact that I didn't told me something important.

Since qualifying as a Certified Business Architect in 2019, I had been an enthusiastic advocate for the discipline. In every engagement, regardless of context, I would produce a capability model and a set of value streams. The Business Architecture Guild has long emphasised the capability model as central to business architecture practice, and I had absorbed that view completely. It was what a business architect did. So I did it.

The mentee's question cracked that assumption open.

If the answer were obvious, I would have given it without hesitation. Instead I found myself reaching for justifications that dissolved under examination. The Guild recommends it. The methodology requires it. It is best practice. None of those are answers. They are appeals to authority.

And then I remembered something a programme sponsor had said to me earlier in my career, with the patience of someone who had been through many consultancy engagements and retained a healthy scepticism about all of them.

"This business has been running without a capability model for more than fifty years. Why do we need one now?"

At the time, I had taken it as resistance to manage. With my mentee's question still in my head, I heard it differently. It was not resistance. It was a legitimate question I had never properly answered.

The rethink that followed was not comfortable, but it was necessary. And I want to be precise about what it did and did not change.

I did not stop building capability models. I still build them. I still map value streams, analyse operating models, and document the interdependencies that make an organisation legible to itself. That work has not diminished in rigour or importance.

What changed was the purpose I assigned to it.

I had been treating the artefact as the output. The capability model was what a business architect produced, therefore producing it was the point. But an organisation does not commission architecture work because it wants a capability model. It commissions architecture work because it has a problem it cannot solve with the tools it currently has.

The capability model, the value stream, the operating model canvas: these are my tools, not my deliverables. They help me understand the organisation well enough to offer options. Options grounded in how the business actually operates, what its constraints are, and what its appetite for change will realistically support. The model is how I arrive at the answer. It is not the answer.

There is also a legitimate case for the artefact itself. A well-constructed capability model is organisational memory. It gives the next person who walks in a shared language, a map of interdependencies, a foundation they do not have to rebuild from zero. That value is real. What I had been missing was the distinction between building a model because it serves the organisation, and building it because the methodology says to.

What changed in practice was my approach to the first weeks of an engagement.

I stopped leading with the artefact. I started leading with the organisation. More time spent reading: the language people used to describe their problems, the way decisions were made and by whom, the risk appetite for change and where the tolerance for disruption ran out. Not as a preliminary to the real work, but as the work itself.

The capability model emerged from that reading rather than preceding it. And when I sat down to build it, I understood what I was building it for.

That shift made my practice more relevant. It also made it more humane — by which I mean that the organisation stopped being a subject to be modelled and became a context to be understood. The people in it stopped being inputs to an artefact and became the point of the exercise.

If you are an aspiring architect still in the early years of practice, the question worth sitting with is not "can I build a capability model?" Almost certainly you can. The harder question is: "what problem does this organisation actually have, and what would help them most right now?"

The answer to that question might require a capability model. It might not. Knowing the difference, and having the confidence to let the problem determine the tool rather than the other way around, is what separates technical competence from genuine usefulness.

A mentee's question taught me that. It took me longer than it should have to be ready to hear it.