A catalog by role or a shared architecture — which model scales better

A shared architecture begins with a different decision. It defines a common foundation of skills and differentiates roles through expectations: depth, autonomy, complexity, scope, leadership, impact, and required evidence. It sacrifices some local freedom to preserve relationships that make assessment, development, and mobility easier.

No model scales because of its visual form. It scales if it retains its meaning as the number of roles, changes, and dependent decisions increases.

What the role-specific catalog optimizes

An independent catalog can describe work in language closely tailored to each position. A team can move forward without waiting for a central taxonomy and adapt its list to an immediate need.

This model works reasonably well when there are few stable roles, little mobility among them, and clearly separated owners. It can also be useful during discovery: local descriptions reveal vocabulary, tasks, and capabilities that have not yet been reconciled.

Its weakness emerges when duplication becomes difficult to see. Analytical thinking, problem-solving, or stakeholder management may exist in fifteen catalogs under different wording. The organization loses the ability to tell whether they are the same skill, contextual variants, or genuinely distinct concepts.

Every new version compounds the problem. Updating a definition in one role does not update the others. Comparing people across positions requires catalog translation. Mobility paths depend on textual matches, and assessments may apply different standards to the same capability.

What a shared architecture optimizes

A shared architecture makes reuse an explicit rule. Roles within a track share exactly the same set of skills; the expectations associated with their level and responsibility distinguish them. Across tracks, the architecture identifies shared capabilities, new skills, and needs for adaptation.

This principle does not require every role to be the same. It requires each difference to be represented in the right place.

If two positions use the same capability at different degrees of autonomy, creating two separate skills conceals the progression. If they require materially different objects or forms of performance, merging them for convenience produces an overly broad category.

The decision changes five costs

Maintenance. With independent catalogs, costs grow with every role and duplicate. In a shared architecture, changing a common skill requires more governance at the outset but reduces repeated updates.

Consistency. The role-specific model readily accommodates local variation. A shared architecture needs rules for deciding what should be reused and what deserves a separate entity.

Detail. A local catalog can incorporate specific context. The architecture must preserve that context in expectations, examples, and evidence without fragmenting the skill.

Mobility. With independent lists, comparing roles becomes a separate project. With a shared foundation, the relationship among reusable capabilities, adaptation, and new skills is more visible.

Legitimacy. Central standardization can drift away from the work if functional experts are not involved. Local autonomy can produce incoherence if no one governs shared concepts. Scaling requires distributed authorship and clear final decision authority.

A more demanding selection criterion

The question should not be how many roles the organization has today. It should be how many future decisions will need to cross their boundaries.

If the architecture will support mobility, succession, shared development, coverage analysis, or comparisons across teams, a common foundation offers a structural advantage. If the scope is small, temporary, and has no need to interoperate, a local catalog may be enough—as long as the organization recognizes the debt it will create as it grows.

There is a valid hybrid approach: discover locally and reconcile centrally. Teams describe the work in detail; an architecture function identifies equivalencies, separates concepts, and preserves contextual extensions. What does not work is calling a collection of duplicated lists with no common layer a hybrid model.

An architecture scales when it allows roles to be added without multiplying meanings unnecessarily.