Six capabilities that only work together

The capability model usually arrives as six boxes: technical, business, product, delivery, organisational push, and temperament. As a checklist it is close to useless. The boxes are easy to tick, and they do not say which one week three will test.

Read as a system, the same six become an instrument, because they answer two different questions. Which capabilities are gates you cannot enter the work without, and which are walls that have to stand at the same time? The 2026 China FDE talent whitepaper gives the second answer directly: the closer a deployment gets to a production system, the more technical capability, delivery capability and organisational push must appear together, and if one of the three is missing the project stops at the demo layer.

That sentence is the spine of everything below. What follows is what "stops at the demo layer" looks like when the missing piece is different each time.

Two kinds of evidence, not six

The six differ in what counts as proof. Technical capability is evidenced by a system that runs; business capability by a requirement converted into a metric; product capability by a template, a component or an eval set; delivery capability by change handling and a signed acceptance; organisational push by the system actually being used; temperament by what happens in a bad week.

Only three of those can be produced alone in a room. A build can. A signed acceptance needs a counterparty. Actual use needs other people to change their Tuesday. So the model is not six equal weights but three capabilities that are demonstrable solo and three that exist only in relation to other people. Interviews tend to over-score the first group, because the first group is what a portfolio can show. The phases in which each one becomes the binding constraint are laid out in the five-stage delivery method.

What each gap looks like on site

The whitepaper's shortfall table maps a missing capability onto its on-site consequence, and the consequences are specific enough to test. A person who only knows tools produces solutions that never enter the process. A person who only writes code cannot hear the client's real problem. A person who only presents cannot handle a go-live exception. A person who never consolidates makes every project heavier than the last.

Bottleneck	Where the deployment stops	What month two looks like
Technical only	At the demo layer	A good prototype nobody opens
No delivery capability	At the first change request	An argument about what "done" meant
No organisational push	At adoption	A system with a login page and no users
No product capability	At the second client	The same work, priced again from zero
No temperament	At the first bad week	The FDE retreats to the parts that behave

The sequence matters. A project hits the technical wall first, the acceptance wall second and the adoption wall third, so a candidate who is excellent at the first wall looks excellent for exactly as long as the interview lasts. The gaps that kill deployments sit past the point the interview reaches.

The triad that has to be simultaneous

Once production is in play, technical, delivery and organisational push stop being sequential. A production system has to be built, accepted and used at once, and each of the three has a different counterparty: the person who approves the architecture, the person who signs acceptance, the person whose morning changes.

This is why "strong engineer, weak stakeholder work" survives an interview and fails in month two. The weakness is present from day one; it becomes visible only when the project reaches the phase where that capability is the binding constraint. Organisational push is the most frequently dismissed as a soft skill and the most frequently the actual cause of death. The evidence column the whitepaper gives it is not "communicates well" but "the system is actually used" — a fact about other people's behaviour, not a verdict on the FDE.

Business and product decide whether the work compounds

The other pair does a different job. Business capability converts an ask into a metric; product capability converts one deployment into something the next one can reuse. Missing the first means the system is optimised for a complaint rather than a cost. Missing the second means the customisation per client never declines — and a deployment practice where customisation per client never declines is not a deployment practice, it is day-rate outsourcing with a better story.

This pair is also the hardest to see in an interview, because both are invisible inside a single project. They only show across two.

Temperament is a gate

The whitepaper names temperament as the most underrated of the six and describes the specific failure: many technically strong people cannot tolerate on-site disorder, and the job is to build inside that disorder rather than wait for it to settle. Treat it as a gate, not a skill. A skill can be trained in a quarter; a gate that is shut does not open because the other five are strong.

What to ask for instead of a CV

Ask for one deployment and require four things the candidate cannot prepare in advance.

Give a messy requirement and watch whether roles, goals and constraints get organised before a tool is proposed. Give a data problem and watch whether a source-and-permission list appears or the client gets blamed. Give a failing system and watch whether the response is logs, evaluation and rollback, or a different model. Give a user who will not adopt, and watch whether the answer returns to process and incentives or asks management to push harder.

Then ask for three names: who signed acceptance, whose morning changed, and whose work lost value. A candidate who can produce all three has the triad. A candidate who can produce only the first has technical capability and a good demo. Questions one and three of the seven questions are the fastest way to find two of those names on a real site.