What must remain common and what can vary across areas
Even when two areas work differently, they can still share an architecture. Adaptation stops being local when it changes meaning, comparability, or the rights attached to use.
One area operates in daily cycles. Another develops projects that take months. Both use the same skill, but their situations, language, and opportunities for observation differ within a shared architecture.
Forcing them to share identical examples makes the architecture feel foreign. Allowing local definitions without boundaries creates the opposite problem: two different entities retain the same name.
The common core protects three functions
The first is meaning. The skill must represent the same object, and its levels must distinguish equivalent contributions even when the visible work changes.
The second is comparison. It does not require every area to produce the same evidence, but a difference in level must carry a compatible interpretation.
The third is the set of rights attached to use. Insufficient evidence cannot become a gap in one area. Nor does a result that is valid for development automatically gain permission for use in selection because another team finds that convenient.
These functions define the common boundary. If an adaptation changes any one of them, it is no longer a minor operating decision.
Local context can change how a skill is demonstrated
Cases, everyday vocabulary, available sources, timing of observation, and calibration methods may all vary.
A problem-solving skill might be observed during a brief interruption or over a long design decision. Duration alone does not define the difference. What matters is complexity, autonomy, quality of interpretation, and the consequences assumed. It is also useful to distinguish which part of the configuration needs breadth, depth, or integration: changing demand does not require creating a new architecture.
Local examples help when they translate a common expectation. They become dangerous when they replace the expectation and end up turning frequency, visibility, or familiarity into a level.
The process sequence can also vary. One area may gather evidence during a project cycle and another through monthly reviews. What must remain common is not the calendar, but the ability to reconstruct what was observed, against which expectation, and under what conditions. Standardizing the ritual when work happens differently produces formal compliance and weak evidence.
Test equivalence across boundaries
Exchange cases across areas without revealing the assigned result. Ask evaluators to explain which manifestation they observe, which level they would support, and what information is missing.
Perfect agreement is not necessary. Useful disagreement shows where context changes interpretation. If only people from the area understand the example, the documentation may be incomplete. If they reach incompatible conclusions even with the context, the adaptation may have changed the object itself.
The test must also work in reverse. An area needs to explain why its example is equivalent to the common expectation. Claiming that its work is special is not enough.
Documenting adaptation prevents invisible drift
FRAME was developed to describe modifications to implementation interventions. It proposes recording what changed, when, who made the decision, and why. Applied cautiously here, it offers a useful discipline: separating deliberate adaptation from accumulated drift. Stirman et al., FRAME, 2019 (opens in a new tab).
In a skills architecture, that record can identify the common expectation, the local element, the operating rationale, the approving authority, and the evidence of equivalence.
Maintain a map of equivalences, not a collection of exceptions. For every adaptation, state which common element it preserves, which local difference it addresses, and which signal would show that it has stopped working. Reviews can compare disagreements, the distribution of results, and cases that do not fit an appropriate category. If an adaptation holds only because no one compares data across areas, the equivalence exists in name only.
Authority depends on the scope of the change
An area can update a case, choose a relevant source, or change the cadence of a session. Changing the scope of a skill, its levels, or the authorized consequences affects other areas and requires shared governance.
NIST maintains NICE Framework components through explicit versions and relationships among work roles, competency areas, tasks, knowledge, and skills. Although it belongs to the cybersecurity domain, it demonstrates the value of separating shared structure from updatable components. NIST, NICE Framework: Current Versions (opens in a new tab).
Define the boundary before urgency arises. State what the area may decide, what it must consult on, and what remains blocked until a cross-functional review.
The architecture also needs a path toward convergence. Two areas may separately discover a work pattern that deserves a place in the common core. Governance should allow them to propose it with evidence, test it outside its original context, and decide whether it should replace a local variant. Without that path, the common layer grows stale and successful adaptations remain isolated. Maintenance should turn those findings into proportionate changes with an owner.
A common architecture works when different areas can recognize themselves in it without becoming isolated. The control question is concrete: does the variant translate a shared expectation, or has it just created another architecture under the same name?
To extend this reading, see The org chart is not a map of the work, How to scale beyond the pilot without losing quality, and Sorting Things Out: every taxonomy describes and decides, which develop complementary dimensions of the problem.
Keep exploring
When to split, merge, or retire a skill
Splitting, merging, and retiring a skill correct different failures. Even if the catalog looks tidier after the change, the choice depends on which distinction in the work must be preserved and which decisions will change.
Designing the interfaces between teams is also designing capability
On the eve of a launch, an incomplete interface can immobilize capability that each team does possess.
The organization can have the right skills and the wrong operating model
An organization can have the right skills and still fail to produce the expected capability. Even when the inventory is accurate, the rules of work may prevent those skills from being used.
When to create a new role and when to redesign an existing one
Should the organization create a new role or redistribute the work? The answer depends on the stability, distinctiveness, and accountability of the missing contribution.
How to maintain an architecture without turning it into a permanent project
Maintaining an architecture starts with distinguishing a signal worth recording, a small change with a clear owner, and a structural decision that deserves deliberate review.
Generalists, specialists, and hybrid roles: what the architecture should decide
Does the organization need breadth, depth, or integration? Generalist, specialist, and hybrid are possible answers, not identities the architecture should fix permanently.