Competency & Portfolio Architecture

Why this exists#

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.

This is not an HR framework. This is an operating model input.

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.

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:

• AI
• Data
• Integrations
• Cloud Infrastructure
• Back-end
• Front-end
• UI / UX
• QA

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.

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.