The Shifting Competency Profile

Overview

Lists of future-proof skills are easy to write and hard to trust, because nothing disciplines them. This topic takes a different route: it states the shift, then tests it against the modules you have just completed, where the record of what actually produced value is available for inspection.

The test is not decorative. It changes one item on the list substantially.

Declining in relative value

Declining, not worthless — and relative to other skills rather than absolutely.

Raw coding fluency. Still necessary; no longer differentiating. The ability to produce correct code quickly was a large part of a senior engineer’s advantage, and it is the most directly substituted capability in the profession.

Memorised technology catalogues. Knowing the comparative properties of nine message queues was valuable when that knowledge was expensive to acquire. It is now free and, worse, the memorised version is often stale.

Being the person who knows how the system works. Uncomfortable, because this is how many architects built their position. Module 9’s whole practice exists to convert that knowledge into something durable — and the honest reading is that it also converts a personal advantage into an organisational asset. Doing it anyway is the right call, and noticing the trade is more honest than pretending it does not exist.

Rising in relative value

Systems thinking — reasoning about interactions, failure propagation and emergent behaviour. Resistant because it requires holding a whole context, which is exactly where context-limited generation is weakest.

Data literacy — understanding what a measurement supports. Module 6’s noise floor is the canonical instance: the arithmetic is trivial and the consequence was that a stated threshold was meaningless.

Cost reasoning — unit economics, and the multiplication of small per-unit figures by large volumes. Scarce because most engineers were never required to do it and it is where plausible plans fail.

Ethics and risk — blast radius, consequences of being wrong, and what the organisation is accountable for. Rising sharply because systems now take actions.

Communication — translating a technical position for someone who decides. Module 8 was entirely this, and nothing about it has gotten cheaper.

Verification discipline — checking whether a design, a document or a number is actually right. The guide’s own record puts this first, and the case below shows why.

graph TD
  A["<b>Declining</b><br/>coding fluency ·<br/>catalogue recall ·<br/>being the one who knows"] --> C["Relative<br/>value"]
  B["<b>Rising</b><br/>systems thinking · data literacy ·<br/>cost reasoning · risk ·<br/>communication · <b>verification</b>"] --> C

  classDef down fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  classDef up fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef hub fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  class A down
  class B up
  class C hub

Six rising competencies. The guide’s own findings concentrate in one of them far more than in the other five.

Why verification outranks the rest

Not because the others matter less in principle, but because of where the constraint sits. The previous topics established that candidate designs are abundant and evaluation is not, and the binding constraint on a system is where its value concentrates.

There is also a structural reason verification is durable: it is the only one of the six that produces a definite result. Systems thinking, risk judgement and communication are all exercised under uncertainty, and their quality is contested. Whether a number is wrong is not contested — it is settled by checking, and the person who checks is right regardless of seniority. That makes it the most portable form of authority available to someone without a mandate, which is the condition Module 8 established as normal.

What the list looks like applied

The practical form of this is unglamorous. Verification discipline in practice means: multiplying the per-unit figure by the volume before accepting the plan; asking what sample size the stated threshold implies; checking whether the constraints were in the input; and asking what happens if the dependency lasts four years instead of one.

None of that is sophisticated. All of it is the work that found every real problem in this guide.

Eight findings, sorted by what produced them

The substantive corrections across Modules 2 to 10, with the skill that produced each.

1. The deflection target was unreachable. Deflecting 38% of roughly 12,000 monthly tickets leaves a residual human cost of about $47,616 against a blended target near $36,000 — arithmetic.
2. Serial delegation undershot its floor. Three delegated stages at 90% each land at 73%, below the stated accuracy floor — arithmetic.
3. The regression trigger was inside the noise. A 3-point trigger on a 300-case set run once sits within a ±5.8-point band; four repetitions are needed to reach ±2.9 — arithmetic, specifically data literacy.
4. Five defects in the Modules 4–6 design — constraint checking against stated requirements.
5. The service boundary would erode. Conway’s Law predicts the two-service split merges within about a year under a single owner — constraint reading, organisational.
6. Review capacity would break without growth. About 54 hours a month becomes about 162 under a threefold generation multiplier, crossing one full-time reviewer while headcount stays flat — arithmetic.
7. The interim dependency was permanent. 35% of traffic moved in 24 months implies roughly 45 more months, not the assumed one year — arithmetic.
8. Credits were two processes under one name, which made the action tiering wrong — constraint reading, domain.

The tally: five arithmetic, three constraint-checking, zero from generating a better design. Every one of the eight began as a plausible number or a reasonable-sounding sentence inside an otherwise competent document, and every one was caught by multiplying, dividing, or asking whether a stated condition held.

What this does to the list. It promotes verification above the other five rising competencies, and it demotes something that sounds more impressive. Not one of these findings required deep knowledge of a technology, familiarity with a framework, or the ability to produce a novel design. The entire differentiated contribution across eight modules of work came from checking, and the checks were arithmetic a competent teenager could perform.

The honest caveat. Catching them required knowing which numbers to multiply — that a per-ticket cost must be checked against the blended target, that serial stages compound, that an eval threshold implies a sample size. That judgement is not arithmetic, and it is what the preceding modules were actually teaching. The skill is cheap to execute and expensive to acquire, which is an unusual and durable combination.

Feeds the workbook

Score your competency gap analysis against the six rising competencies rather than against a technology list. The rubric asks for real weaknesses rather than diplomatic ones — and verification discipline is the one most people over-rate in themselves, because the failures are invisible.

Check your understanding

1. Of the six rising competencies, which is your weakest? What is your evidence, rather than your impression?
2. Take a number you accepted in the last month. Multiply it out. Does it hold?
3. Why is verification a more portable form of authority than systems thinking?

---

→ Competencies determine what you can do. Tracks determine where it takes you. — Tracks, and the skill ceiling