A shared leadership language only helps when each business unit can use it in the decisions its own work creates. The centre should define the meaning of the capability and the evidence that matters; the units should translate that meaning into their customers, constraints and trade-offs. That balance is the difference between an enterprise framework that travels and one that becomes another central programme. That is how leadership capability across business units becomes usable rather than merely named.
This matters when an organisation has grown through acquisition, geography, product lines or distinct customer groups. Each unit has learned how to win. Each also carries habits that may not travel well. A central programme can bring the units together, but it cannot erase the operational differences that make their leadership work real.
The tension between consistency and context | leadership capability across business units
A common leadership framework gives people a way to describe behaviour, decisions and capability without translating everything through local jargon. That shared language helps a group compare patterns. It also makes movement between units easier because a leader can explain how they create value beyond the title on their business card.
The risk is over-standardisation. A leader running a regulated service, a fast-moving digital product and a field operation will face different constraints. If the central team prescribes identical routines, managers learn to comply with the framework instead of using it to make better choices. The framework should define the outcome and the quality of judgement, not every step.
| Layer | What is shared | What stays local |
|---|---|---|
| Leadership language | The capabilities and behaviours the organisation expects | Examples that make the language credible in each unit |
| Decision principles | The boundaries for risk, customer impact and accountability | The pace, evidence and forums used to decide |
| Development pathway | The sequence of practice, feedback and review | The work assignments that create practice |
| Evidence | The kind of change leaders should demonstrate | The measures and operating records that show it |
| Governance | Who owns the standard and who challenges it | How the unit integrates it into its rhythm |
Start with a capability architecture
The first job is to name the capabilities that matter across the organisation. Avoid a long catalogue of admirable traits. Choose capabilities that change how leaders make decisions, grow other people and carry accountability. Then describe what those capabilities look like at different levels and in different settings.
The shared-to-local architecture
- North star: A small set of enterprise capabilities that describe how leadership creates value.
- Level signals: Observable differences between leading self, leading a team, leading a unit and leading across units.
- Local translation: Examples, dilemmas and practices that make each capability real in a business unit.
- Practice portfolio: Assignments and decisions where leaders can exercise the capability in live work.
- Evidence loop: A review rhythm that connects behaviour, operating outcomes and next development action.
Name fewer capabilities
A framework is useful when leaders remember it while making a difficult choice. If the list is too long, every conversation becomes a search for the right label. Use plain language. Judgement, system-building, talent multiplication, customer stewardship and collective contribution are easier to test than a page of abstract competencies.
The wording should also make room for difference. A leader does not demonstrate judgement by copying the centre. They demonstrate it by making a sound decision with the information, constraints and consequences of their unit visible.
Define levels through work
A leadership capability becomes useful when people can see how it changes with scope. At team level, system-building may mean creating a reliable weekly rhythm. At unit level, it may mean connecting capacity, customer demand and investment. Across units, it may mean designing a rule that lets several leaders act without returning to the centre for approval.
Use examples from actual work rather than idealised descriptions. Ask what a leader does when priorities conflict, when a peer needs help or when an important decision must be made with incomplete information. These situations reveal level differences more clearly than a rating scale alone.
Translate the framework without losing its meaning
Give each business unit a translation session. The unit leadership team should take one shared capability and answer three questions: what does this look like here, where does it currently break down and which real decision could provide practice? The centre should listen for meaning, not collect identical wording.
- Choose a capability: Start with one capability that matters to the unit's next operating challenge.
- Bring a live dilemma: Use a decision with real trade-offs rather than a hypothetical case.
- Describe the current pattern: Ask what leaders currently do, what the team experiences and what the outcome shows.
- Design the practice: Choose a decision, assignment or routine that gives leaders a chance to try a different behaviour.
- Agree the evidence: Define what observers should be able to see, hear or review after the practice.
Build practice into operating work
Leadership development becomes credible when it is attached to work leaders already have to carry. A market-entry decision can practise judgement and stakeholder alignment. A service redesign can practise customer stewardship and system-building. A succession conversation can practise talent multiplication. The development activity is the way the leader approaches the work, not a separate event that sits beside it.
This approach also reveals where the operating model is blocking development. If leaders cannot make decisions without five approvals, they have little chance to practise accountability. If every unit protects its own data, cross-unit leadership remains a slogan. Capability work can therefore expose design constraints that a training calendar would miss.
Create a cross-unit learning loop
Leaders across units need a way to compare practice without turning the programme into a competition. Use a small set of recurring questions. What decision did you make? What did you notice about your behaviour? What did the team experience? What evidence changed your view? What will you test next? The questions create continuity while the examples remain local.
Pair leaders from different units around a common capability. Ask them to bring one success and one unresolved pattern. The purpose is not to exchange tips. It is to expose assumptions. A practice that works in one unit may fail in another because the decision rights, customer promise or risk profile differ. That contrast is valuable learning.
- A live decision with a named capability in view
- A short reflection from the leader and the people affected
- A peer challenge from another business unit
- An operating record that shows what changed
- A next experiment with an owner and review point
Measure capability without pretending it is a single number
Use evidence at three levels. Behavioural evidence shows what leaders do in the moment. Relational evidence shows what their teams and peers experience. Operating evidence shows whether the capability changes the flow of work, decisions or customer outcomes. None of these is sufficient alone. Together they give a more honest view than course attendance or satisfaction scores.
CIPD's evidence review on leadership development is a useful reminder to connect development activity to transfer and context rather than treating participation as proof of change. Use that principle in governance. Ask what the leader applied, where the application was supported or blocked and what the organisation learned from the result.
A useful review conversation stays close to the work. Ask the leader to bring one decision, one interaction and one operating result. What did they notice before acting? Which people did they involve? What did they make easier for the next person? What would they repeat, and what would they change? These prompts help leaders move from describing an intention to examining a choice.
The evidence should also include voices that development programmes often miss. A direct report can describe whether the leader creates clarity or dependence. A peer can see whether the leader helps the wider system or only their own unit. A customer-facing colleague can show whether an internal change is felt outside the leadership team. Inclusion is part of the evidence design, not an optional theme at the end.
Do not compare business units as if they operate under identical conditions. Compare the quality of the reasoning, the transfer of practice and the willingness to learn. A unit facing a turnaround may show capability through stabilising decisions. A unit in innovation mode may show it through disciplined experimentation. The evidence must respect the work while still testing the same underlying expectation.
Govern the standard lightly
A central owner should protect the integrity of the framework, maintain the evidence model and make cross-unit learning visible. The owner should not become an approval office for every local programme. Business-unit leaders need enough authority to adapt practice, provided they can explain how the adaptation still serves the shared capability.
Review the framework on a fixed cadence. Retire capabilities that no longer help leaders decide. Add a capability only when the organisation can show a repeated demand that the current architecture does not cover. This keeps the system alive without turning every new leadership concern into another pillar.
Governance should include a route for challenge. A business-unit leader should be able to say that a shared expectation is creating the wrong behaviour, then show the evidence and propose a better translation. The central owner can test whether the issue is local, systemic or a sign that the framework itself needs revision. This protects the architecture from becoming a one-way broadcast.
Keep the language accessible to managers who are using it in a busy week. Replace abstract labels with a question they can ask before a decision. Replace a long competency description with an example of what a good hand-off sounds like. The simpler the language, the more likely it is to travel from the centre into the conversations where capability is built in practice.
A shared framework earns trust when leaders can use it without waiting for the centre to interpret every situation. That is the practical test of scale: common expectations, local judgement and evidence that travels between them.
Common failure patterns
- A central curriculum is launched before the organisation agrees what capability means
- Local leaders are asked to translate a framework without time or decision authority
- Evidence stops at attendance, confidence or completion
- The same high-potential group receives development while operating barriers remain
- Business units compete for talent instead of building a shared leadership pipeline
Each failure points to a design issue. The remedy is not more communication. It is a clearer link between the capability, the work, the evidence and the owner. When those links are visible, leaders can see why the programme exists and how their choices contribute to it.
A practical first ninety days
In the first month, select the enterprise capabilities and test the language with leaders from different units. In the second, choose one live practice per unit and agree how evidence will be gathered. In the third, bring the leaders together to compare what happened, identify design barriers and decide what to keep. The sequence creates proof before the organisation invests in scale.
The strongest signal is not that every unit reports the same story. It is that leaders can explain the shared expectation, show how they adapted it to their context and name the evidence that changed their next choice. That is what an enterprise capability looks like when it has become part of the operating system.
If you are building this architecture, begin with the Leadership Capability Architecture, use the Leadership Capability Diagnostic to identify the most important gaps, or explore Leadership Assessments for a deeper evidence base.
Related reading: leadership capability architecture. The Leadership Capability Diagnostic can be used to test the issue in context.
The most useful enterprise review is a translation review. Take one strategic priority and follow it through a business unit meeting, a manager's weekly choices and a customer-facing decision. Note where the meaning changes, where authority becomes unclear and where local knowledge improves the decision. Then adjust the framework or the operating routine, rather than asking the unit to repeat the central language more loudly. This creates a shared standard without pretending that every business unit faces the same work.
Cross-unit governance should be light enough to preserve ownership. A central group can maintain the capability definitions, the evidence questions and the cadence for reviewing what is being learned. It should not approve every local experiment. Business-unit leaders need room to adapt the practice, and they need a route for returning a genuine conflict to the centre. That arrangement makes difference visible without turning context into an excuse for avoiding the shared standard.
Let each business unit translate the standard
A shared language travels when local leaders can connect it to their own work. Use building leadership capability at scale, measuring leadership capability across an organisation and capacity versus capability to test the standard against measurement, operating context and the difference between capacity and capability.
Where this fits in the wider work
This topic sits beside three decisions that often get separated in practice. Read what leadership systems fast-scaling companies need; what causes leadership development programmes to fail; the team collaboration and effectiveness framework. The comparison is useful because it keeps the argument in this article specific: which decision is changing, who owns it and what evidence would show that the change has travelled into everyday work? Use the linked pieces as contrasts, not as a substitute for the judgement required here.