Capability development consulting is the work of moving an ability out of the individuals who happen to have it and into something the organization owns: knowledge that can be retrieved by whoever needs it next, practice built into real work rather than into events, and permission for those people to act. Vivaldi has been a strategy firm since 1999, and we build capability the way we run strategy work, inside the work that is already happening rather than alongside it in a classroom.
- Since 1999strategy, innovation and capability building
- 200+published case studies
- 10 officeson four continents
- 5xWirtschaftsWoche Best of Consulting, Strategy and Innovation
When companies bring us in
Capability development is usually bought by a CEO, chief strategy officer or chief people officer at a company that has already spent money on training and cannot point to anything the organization now does differently. The trigger is almost always a specific failure rather than a development calendar.
- The second instance costs what the first one did. The company has done the thing before, successfully, and is starting from zero anyway because nothing about how it was done survived.
- One team is a single point of failure. A capability exists, it sits with three people, and every plan that depends on it has to be queued behind their calendars.
- Training landed and behavior did not change. People completed the program, rated it well, and went back to working exactly as they had.
Two near neighbors are separate engagements. If the question is who leads, how they decide and how that scales, that is leadership development. If the capability in question is specifically what AI changes about roles, skills and accountability, that is workforce transformation and AI. This page is about what the organization can do, not about who leads it and not about what AI does to it.
Why training does not produce capability
An organization that has trained people and still cannot do the thing repeatedly is usually missing one of three components, and a course delivers only one of them.
- Retrievable knowledge. A team that solved something once should not solve it again from scratch. When the reasoning behind past decisions lives in message threads and in people’s heads, every new instance restarts. That is a dependency, not a capability.
- Practice inside real work. Skill exercised only in a workshop does not transfer. Capability develops through repetitions that carry consequences, which means the work itself has to be designed to produce them.
- Permission. People who have been trained and are not allowed to act do not build capability, they build frustration. A surprising share of stalled capability programs are permissions problems wearing a skills costume.
The practical test is blunt. The second time the organization does the thing, does it cost less than the first? If it costs the same, no capability was built, whatever the completion rates say.
What our capability development services include
Five bodies of work. Most engagements need three of them, and which three is the first thing we establish rather than the thing we assume.
- DoThe first instanceThe work gets done, usually well, by whoever in the building happened to be able to do itUsually strong
- CaptureThe reasoning, not the conclusionWhy the choice was made, what was rejected, and what would change the answer next timeUsually thin
- RetrieveThe next team finds it in timeReachable at the moment of the decision, not filed somewhere discoverable in principleUsually absent
- ActPermission to use itDecision rights held by the people with the skill, rather than queued above themUsually blocked
1. Naming the capability as work
Competency language makes capability unfalsifiable. We describe it as an outcome the organization has to produce repeatedly, which makes it possible to say whether it exists.
- The specific outcome, written as work rather than as a trait
- How often it will genuinely be needed, since something required twice a year rarely justifies building internally
- Where a version of it already exists somewhere in the business and simply does not travel
2. Diagnosing which of the three components is missing
This is the part most programs skip, and skipping it is how a permissions problem gets a training budget.
- A read on knowledge, practice and permission separately, because the remedy for each is different and the symptoms are identical
- The last two attempts examined in detail, which is faster and more honest than an assessment instrument
3. Making the reasoning retrievable, not just the conclusion
Documentation that records what was decided is close to worthless. What the next team needs is why, and what would change the answer.
- Decision records that carry the alternatives considered and the conditions that would reverse the call
- Knowledge placed where the decision happens rather than in a repository people visit when they are not busy
- A named owner for the material once the engagement ends, because unowned knowledge decays quietly
4. Designing repetitions into real work
Capability is built by doing the thing under consequence. We design the engagement so the practice is the work rather than a simulation of it.
- Live cases selected so that the organization gets several real repetitions inside the engagement window
- Coaching at the point of the decision, not in a review afterwards
- Progressive withdrawal, so our involvement in each repetition is smaller than in the one before
5. Moving decision rights, then proving it on the second instance
The handover is the deliverable. If it cannot be demonstrated, the capability is still ours rather than yours.
- Decision rights formally moved to the people who now hold the skill, with the escalation threshold written down
- A second instance run by people who were not involved in the first
- Cost and elapsed time compared between the two, which is the only capability measure that resists interpretation
Not sure which of the three is missing in your case?
Start with a working session. We will take the last two attempts at the thing you want to do repeatedly, establish whether the gap was knowledge, practice or permission, and tell you which of the five bodies of work above would actually change the next attempt.
How a capability development engagement works
- Diagnose. The outcome named as work, the last two attempts examined, and the gap attributed to knowledge, practice or permission. The output is a decision about what to spend on, including what not to.
- Design. The repetitions selected from real work, the decision records specified, and the decision rights that will have to move identified by name and role. The output is a plan with an owner against every part.
- Run. Several live repetitions with coaching at the point of decision, our involvement reducing each time. The output is work that shipped, plus the reasoning behind it in a form the next team can use.
- Hand over. A final instance run without us, measured against the first on cost and elapsed time, with the capability owned by a named person inside the organization.
Why companies choose Vivaldi for capability development
- We are a strategy firm, not a training provider. We do not run an academy, issue certifications or operate a learning platform. What we build is the ability to produce a specific business outcome repeatedly, and the work is done inside live client problems.
- The diagnosis comes before the program. A proposal that goes straight to content has assumed the gap is skill. Often it is not, and that assumption is expensive.
- We design for our own removal. Progressive withdrawal is built into the plan, and the final instance is run without us on purpose.
- Capability is judged on cost, not on sentiment. Satisfaction scores measure the program. The cost of the second instance measures the capability.
How to evaluate a capability development consultant
Five questions worth asking any provider, including us.
- What will the second instance cost? Capability makes it cheaper. If the projection is the same as the first, you are buying delivery with a development label on it.
- Where will the knowledge live when you leave? In our systems or in your materials. Only one of those survives the end of the engagement.
- What are you proposing before you have seen whether this is a permissions problem? A provider who cannot distinguish a skills gap from a decision rights gap will sell you a course either way.
- How much of the practice is real work? Simulated practice produces confidence. Consequential practice produces capability, and the two feel the same on the day.
- Who runs this without you, by name? If nobody inside the organization can be named at the proposal stage, the handover has not been designed.
Strategy firm, corporate training provider or learning platform?
| Criterion | Strategy firm building capability | Corporate training provider | Learning platform |
|---|---|---|---|
| What it builds | The ability to produce one business outcome repeatedly, without the people who produced it first | Individual skill against a competency framework | Access to content, at scale and on demand |
| Where the work happens | Inside live client problems, with coaching at the point of decision | In sessions, workshops and programs scheduled around the work | Wherever the learner is, asynchronously |
| What it does about permission | Treats decision rights as part of the capability and moves them explicitly | Out of scope, and usually the reason the program underdelivers | Out of scope |
| What you leave with | A second instance run without us, and the reasoning behind the first in retrievable form | Completion records and a skills matrix | Engagement analytics and a content library |
| Best when | A specific outcome has to become repeatable and currently depends on named individuals | Broad baseline skill really is the gap | The content exists and distribution is the constraint |
Related work
Capability is rarely the whole question. Which of these you need depends on what the diagnosis finds.
- Organizational enablement is the broader practice this sits inside, covering structure, leadership, decision rights and skill together. Start here if more than one of those is in play.
- Leadership development where the capability that has to improve is judgment at the leadership layer rather than execution below it.
- Organizational design where the diagnosis comes back as permission, because decision rights are a structural question before they are a development one.
- Sales enablement consulting where the capability in question is specifically what the commercial organization can sell repeatedly.
- Workforce transformation and AI where the capability question is being forced by AI, which changes what has to be built and what stops being worth building.
- Change management where the capability exists in pockets and the obstacle is adoption.
This work sits inside our People, Culture and Capabilities practice at Vivaldi, the strategy firm behind the Demand Landscape and the Interaction Field.
Capability development in the US and worldwide
We work from 10 offices on four continents, which matters here because capability does not transfer across markets as cleanly as a curriculum suggests. The same outcome can require different decision rights in a US business unit and in a German one, and a program that assumes otherwise builds skill in both and capability in neither.
Engagements run onsite and remote. Multinational clients typically build the capability once, in the market where the work is most frequent, then test the handover by running the second instance somewhere else.
Start with the second instance
A working session on what your organization needs to be able to do repeatedly, what the last two attempts cost, and whether the gap was knowledge, practice or permission. You leave knowing which of the three to spend on.