Competency & Portfolio Architecture

Why this matters#

Every consulting company already makes decisions about competence and capability.

They decide:

• what to hire for
• what to keep internal
• what to source from partners
• what not to sell

The problem is not that these decisions are missing. The problem is that they are usually:

• implicit
• fragmented across roles
• driven by short-term delivery pressure

Competency & Portfolio Architecture exists to make these decisions explicit, repeatable, and connected to business outcomes.

The cost of getting this wrong is concrete. A Nordic consultancy carrying 4 misclassified PM FTEs — contextual capability treated as core — is paying:

• ~340–400k€/year in fixed cost (4 PMs × 85–100k€ fully-loaded: ~70–80k€ base salary + ~22% Nordic employer on-costs covering pension, unemployment insurance, and statutory contributions)
• Opportunity cost: 2–3 senior technical FTEs at equivalent cost (senior consultant fully-loaded: 94–124k€/year)
• 3–5 gross margin points lost when technical capacity is the binding revenue constraint

Definitions#

Capability: A category of work the firm delivers to clients, described in client outcome language ("Customer portal delivery", not "Frontend engineers").

Competency: The measurable depth of a person's ability to deliver a capability — assessed on three axes: Technical (0–4), Business (0–4), and Agency (1–5).

Portfolio: The firm's full set of capabilities, classified by strategic importance and managed as a deliberate investment rather than an accident of past hiring.

Core capability: A capability that drives competitive advantage. Clients choose you because of it. Demand is chronic. Delivery risk is high if absent. Must be owned and buffered internally.

Contextual capability: A capability clients expect but do not choose you for. It does not command premium pricing. Should be sourced from partners — not built internally.

Sourcing policy: A standing rule for how to staff a capability: hire, partner, or decline. Set once per capability, applied consistently to all demand signals.

Who this is for#

This section is written for:

• CEOs, who need clarity on what the company should truly be good at
• COOs, who need to align delivery, staffing, and sales promises
• CFOs, who need to control risk, margin, and cost of capability

You do not need to be a technical expert to use this. You only need to care about how capability choices affect delivery risk and business performance.

What problems this helps solve#

This section helps answer questions such as:

• Which capabilities are genuinely core to our business?
• Where are we accidentally over-investing?
• Why do certain delivery problems keep repeating?
• Which gaps should be solved by hiring, partnering, or saying no?
• How does our capability portfolio constrain or enable sales?

These questions cannot be answered reliably by looking at:

• job titles
• years of experience
• headcount alone

They require a portfolio-level view of competence.

The Portfolio Decision Loop#

At the heart of this section is the Portfolio Decision Loop.

It describes the minimum set of decisions a consulting firm must make — consciously or unconsciously — to govern its capability portfolio.

Where:

• Competency Model = Technical × Business × Agency
• Capability Classification = Core / Strategic / Contextual
• Sourcing Strategy = Build / Buy / Partner

This loop is not a process to be followed mechanically. It is a mental model for understanding how capability decisions propagate through the business.

Translating your services into capabilities#

Most firms start with offerings ("we build web services"). The framework requires capabilities ("customer portal delivery"). The path between them:

The translation test: You have it right when you can answer "why do clients choose us for this?" without mentioning a technology or a job title.

1. Capability List#

What do we actually sell and deliver?

A capability list is not a list of job titles.

It is a shared vocabulary for:

• what kinds of problems the company solves
• at what level of abstraction
• for which customers

Example

For a mid-sized data & AI consultancy, a capability list might include:

• Data Engineering (pipeline design, lakehouse, ETL/ELT)
• AI & Machine Learning (model development, evaluation, deployment)
• Cloud Infrastructure (platform setup, DevSecOps, cost optimisation)
• Analytics & BI (semantic layer, dashboards, self-service enablement)
• MLOps & DataOps (model monitoring, data quality, deployment workflows)
• Backend & API integration (data product APIs, microservices)
• Data Architecture (data modelling, governance, platform strategy)

The purpose of this list is alignment, not precision. If people disagree on what these capabilities mean, all downstream decisions become inconsistent.

2. Competency Model#

How do we evaluate capability beyond "can they code"?

Competence in consulting is multi-dimensional.

Strong delivery requires:

• technical execution
• business understanding
• ownership under uncertainty

This site uses a three-axis model:

• Technical – can the work be executed correctly?
• Business – does the work support outcomes and margin?
• Agency – does this reduce or consume leadership attention?

This allows internal employees, contractors, and partners to be evaluated on a common decision-ready scale.

3. Complexity and Experience#

At what scale and ambiguity has this capability been delivered?

Two people can score similarly on competence but carry very different delivery risk.

Complexity captures:

• system scale and integration depth
• stakeholder complexity
• compliance and criticality
• ambiguity of the work

By modeling complexity explicitly, we avoid a common failure mode: treating strong performance in low-complexity contexts as readiness for high-stakes delivery.

4. Capability Classification#

Which capabilities should we own versus source?

Not all capabilities deserve the same treatment.

Using demand patterns, revenue impact, delivery risk, and agency requirements, capabilities are classified as:

• Core – must be owned and buffered
• Strategic – selectively built and monitored
• Contextual – sourced via partners or buying

This classification is a business decision, not a technical one. It prevents accidental strategy drift driven by short-term needs.

5. Sourcing Strategy#

How do we cover demand without overcommitting?

Once a capability is classified, sourcing becomes a constrained decision.

Choices depend on:

• time horizon (immediate vs chronic)
• risk tolerance
• availability of high-agency talent
• partner feasibility

The output is a default sourcing policy, not an exception-driven reaction.

6. Portfolio Actions#

What actually changes as a result?

The loop results in concrete actions such as:

• hiring
• upskilling
• building talent stash
• partnering
• limiting sales promises

These actions feed directly into:

• Demand → Talent Index
• Talent Economics
• Operating Model

This is where strategy becomes operational.

Action: Run the portfolio decision loop in 60 minutes#

Before the meeting (15 min):

• Pull the last 12 months of project data: what capabilities did you staff, and how often?
• List current headcount by capability (actual people, not org chart boxes)
• Note which capabilities have caused delivery problems or declined opportunities

Step 1: List capabilities (10 min)

Write every capability the firm delivers. Use client outcome language, not job titles. Aim for 6–10 capabilities. If you end up with 15+, you are listing tasks, not capabilities.

Step 2: Classify each capability (20 min)

For each capability, answer four yes/no questions:

1. Repeated demand — have we staffed this 3+ times in 12 months?
2. Revenue impact — do clients choose us because of this specifically?
3. High delivery risk — would gaps cause client escalation or contract loss?
4. Requires Agency 4–5 — does this work fail with supervised execution?

All four yes → Core. Two or three yes → Strategic. Zero or one → Contextual.

Step 3: Check investment vs. classification (15 min)

Map headcount to classification. If you have more than 30% of headcount in Contextual capabilities, you have a misallocation. If Core capabilities are running at 90%+ utilisation, you are under-buffered.

Step 4: Set one sourcing action per capability (15 min)

For each capability, agree on a standing rule: hire (Core + chronic demand), partner (Contextual), or evaluate (Strategic + uncertain demand). Write it down. It becomes policy.

Output: A classified capability list with a sourcing policy per row — ready to use in the next hiring or staffing decision.

What this section produces#

After applying this model, you should have:

• a shared definition of your capabilities
• a comparable competence model across talent sources
• clear classification of core vs non-core areas
• explicit sourcing rules instead of ad hoc hiring
• inputs that connect directly to sales risk and financial planning

How this connects to the rest of the system#

This section feeds:

• Demand → Talent Index → identifies where demand creates delivery risk

• Talent Economics → shows cost and margin implications of capability choices

• Operating Model → aligns sales, staffing, and delivery behavior

If you skip this step, downstream models still work — but they amplify hidden assumptions.

How to start using this#

A practical starting point:

1. Agree on the capability list
2. Classify 2–3 capabilities as Core or not
3. Apply those classifications in hiring and sales decisions

Consistency over time matters more than precision.

What decisions this enables#

• Which capabilities to invest in building versus sourcing from partners
• Whether a new hire request is for a Core, Strategic, or Contextual need
• Which sales commitments are safe to make given current capability depth
• Where to redirect headcount budget when rebalancing the portfolio
• How to explain capability trade-offs to clients and the board

Next#

• Competency Model — Three-axis model (Technical × Business × Agency) for evaluating capability holistically
• Technical Depth — How to assess and level technical competency from 0 to 4
• Business Context — How to assess how deeply someone connects their work to business outcomes
• Agency Excellence — How to assess ownership and autonomous execution on a 1–5 scale
• Complexity & Experience — How to match competency levels to work complexity so delivery risk is visible
• Core vs. Contextual — Classification framework: what to own, what to partner, what to exit
• Competency Matrix & Scoring — How to track and use competency data at portfolio scale
• Build, Buy or Partner — Sourcing decision framework based on capability classification and time horizon

FAQs#