Why Weight a Competency Model at All

Every competency matrix I have been handed in my career had the same defect, and it was visible before I read a single cell. Skills down the side, levels across the top, and every row silently worth the same as every other row. Communication mattered exactly as much as unit testing, which mattered exactly as much as estimation, which mattered exactly as much as whatever the last reorganisation had made fashionable. The grid was complete, agreed by committee, pinned to the wiki — and useless for the only two questions a competency model exists to answer. What should I work on next, and what does this organisation actually value?

The failure is structural, not editorial. A model in which everything matters equally is a model that refuses to decide, and a model that refuses to decide cannot guide anyone. This series is about the alternative: a competency model that commits to numbers, defends them, and uses them to drive development planning. Two models, in fact — mirrored ones — because the years in which I built them are the years in which the job itself split in two.

The spreadsheet that could not say no

Unweighted competency models are not an accident. They are a peace treaty. Every stakeholder in the room gets their row, and because no row is ranked above any other, nobody has to lose an argument. The security champion gets a security row, the agile coach gets a ceremonies row, the platform team gets a cloud row, and the matrix grows sideways until it describes everything and prioritises nothing. It is easy to agree on precisely because it commits to nothing.

The cost lands later, quietly. An engineer sits down with the grid at review time, scores themselves against thirty rows, and produces a number that cannot tell them where a gap actually hurts. Being weak at production observability and being weak at giving conference talks read as the same size of hole. A manager trying to build a development plan from that has nothing to push against — every improvement is worth the same on paper, so the plan defaults to whatever the engineer already enjoys.

Weighting fixes this by making the model falsifiable. When I write down that software architecture matters roughly twice as much as observability for a working engineer, that is a claim you can argue with. You might think it is wrong for your team, and you might be right — the weights are defaults, and later in this series I will show where I would move them for regulated industries, product-led companies and consultancies. But an arguable number beats an unarguable blank. The disagreement is the value.

A register note before the numbers

Let me state plainly what this series is, because the register matters. The two frameworks it walks through — a seven-discipline model of traditional software engineering competency and an eight-discipline model of AI-era engineering competency — are my own design: the discipline names, the sub-disciplines, the weights, the level definitions and the assessment templates are all mine, built and refined for my own use and claimed in creator voice throughout. Where the series leans on third-party evidence — METR's randomised trial of AI-assisted developers, the Stack Overflow developer surveys, named cases such as Klarna and StrongDM, Kruger and Dunning's calibration research — that material is credited synthesis: their work, named and linked where it appears, never presented as mine. When I own a number, I will defend it. When I borrow one, I will say whose it is.

Two levels of weight, one line of arithmetic

The mechanism is small enough to hold in your head. Each framework distributes 100 points across its disciplines — that is the first level, and it answers “what does this model value most”. Within each discipline, the sub-disciplines distribute across their own 100 points — the second level, answering “what does this discipline consist of, in proportion”. A sub-discipline's absolute contribution to the whole model is the product of the two, divided by 100.

One worked example. In the software framework, Engineering Craft carries a discipline weight of 25, and within it Writing Code carries a sub-weight of 18. So writing code contributes 25 × 18 / 100 = 4.50 points out of the model's 100. That single number is the model's honest opinion of how much raw code-writing matters to overall competency — and the fact that it is under five points out of a hundred is itself an argument this series will spend several parts making.

Assessment sits on top of the same arithmetic. You rate yourself from 1 to 5 against each sub-discipline, multiply the rating by the absolute weight, and sum. A perfect scorecard — a 5 against all 100 points of absolute weight — totals 500, which makes the maximum weighted score a fixed ceiling you can compare against across people, across teams and across time. And because every gap has a weight attached, the development priority falls out mechanically: the biggest gap on the heaviest sub-discipline is the thing to work on next. Part 11 builds a full 90-day planning loop on exactly that formula.

Seven disciplines for the craft I grew up in

The traditional framework organises software engineering competency into seven disciplines. Here it is at a glance:

Two things are worth noticing before we go deeper. First, Engineering Craft carries the highest individual weight — without technical competence none of the rest matters — and yet it is only a quarter of the model. The six professional disciplines collectively carry 75 points, which is the model committing to a position the industry keeps relearning: from Brooks's The Mythical Man-Month in 1975 to the Agile Manifesto in 2001, the human side of software development determines outcomes at least as much as the technical side. Second, the ordering is not a corporate values poster. Each weight has a rationale — leverage, frequency, consequence — and parts 2 through 5 walk through them discipline by discipline.

Eight disciplines for the agent era

The second framework is the AI-era mirror: what competency looks like when agents write most of the code and the human's job is to direct the work. Same mechanics — 100 points across disciplines, 100 within each, a 500-point assessment ceiling — different disciplines, different order:

The headline is deliberate provocation: the discipline most people mean when they say “AI skills” — prompt craft — sits sixth of eight at weight 8, while specification engineering tops the model at 22. Part 9 is entirely about defending that pair of numbers.

One person, two scorecards

The mirroring between the frameworks is a design decision, not a coincidence. Both use the same two-level weighting, the same 1-to-5 ratings, the same 500-point ceiling and the same gap-times-weight prioritisation, which means the same person can be assessed on both and the two profiles compared directly. That comparison is where the most interesting material in this series lives: which traditional disciplines survived the transition intact, which transformed into something with a new name, and why seven disciplines became eight. The transformation gets its own part, because it deserves one.

Where the series goes

Twelve parts, weekly:

1. Why Weight a Competency Model at All — this post.
2. Engineering Craft and Its Nine Sub-Disciplines — the technical quarter of the model, and why writing code is only 18 points of it.
3. Delivery Is a Discipline, Not a Date — increments, breakdown, prioritisation and ambiguity as trainable skills.
4. The Human Disciplines — Feedback and Collaboration — why people skills carry a quarter of the model.
5. Leading Without the Title — leadership as a discipline of engineers, not managers.
6. Five Levels and Observable Evidence — Novice to Architect, and why every level demands proof you can point at.
7. Your Self-Assessment Is Lying to You — METR, Dunning-Kruger, and how to calibrate anyway.
8. Seven Disciplines Become Eight — the transformation map between the two frameworks.
9. Why Specification Weighs 22 and Prompt Craft 8 — the AI model's most argued numbers, argued for.
10. The Supporting Disciplines — agent architecture, evaluation, governance and domain translation.
11. Weighted Planning and the 90-Day Loop — turning a scorecard into a development plan.
12. What a Scorecard Cannot See — the honest retrospective, including the gaps my own model leaves.

If your organisation's competency matrix is a grid where every cell weighs the same — or if your last development conversation ended with “just keep doing what you're doing” because nobody could say which gap mattered most — the next eleven parts are for you.