Competence Without Comprehension: Systems Engineering Onboarding Framework

Dmitrii Efremov — Sun, 08 Nov 2026 22:12:03 +0000

Competence Without Comprehension Is Not an Excuse for Weak Onboarding

Daniel Dennett’s phrase competence without comprehension is useful for thinking about technical teams.

A complex system can produce reliable results even when no single component understands the whole. A language model can generate useful code without possessing a developer’s lived understanding of the product. An operational chain can keep working even when no individual holds its complete map. A company can remain effective without its leader knowing every mechanism inside it.

This does not make understanding irrelevant. It changes where we should look for it.

In a strong engineering organisation, competence should not depend on one person carrying the entire system in their head. It should emerge from interfaces, feedback, tests, review, ownership and the ability to correct mistakes. That is also the real standard for onboarding.

The wrong onboarding question

Teams often ask: “How quickly does the new engineer understand the system?”

That sounds reasonable, but the system may be too large for anyone to understand completely. The question also encourages two bad outcomes.

The first is theatrical comprehension. A new person learns the vocabulary, repeats the architecture diagram and appears fluent without yet being able to make a safe change.

The second is dependence on a guide. The newcomer can work only while a senior engineer explains every local decision. Knowledge seems to have transferred, but the operating capability still belongs to the senior person.

A better question is: “What can this engineer now do safely, and what evidence tells us that?”

Onboarding should transfer controlled action

For a technical role, the first useful unit of onboarding is not a tour of the whole architecture. It is a bounded obligation.

Give the new engineer one real path through the system:

one user or operational need;
one component they may change;
the interfaces that constrain that change;
the checks that must pass;
the person who can approve an exception;
the signals that reveal whether the change worked after release.

The goal is not to make the person repeat the design. The goal is to let them complete a small action while the system makes its boundaries visible.

This is where documentation becomes useful. A document should not merely describe what exists. It should help a person decide what they may do next, how they can test the decision and when they must stop.

Three levels of explanation

Dennett distinguished different ways of explaining a complex system. The same distinction can improve onboarding.

At the physical level, we examine the actual machinery: processes, networks, storage, runtime behaviour and failure conditions.

At the design level, we examine what components are for, which contracts they implement and what the architecture expects from them.

At the intentional level, we use a higher-level model: what the service is trying to achieve, what another team is likely to change, or how a customer will respond.

New engineers need all three, but not all at once and not in equal depth.

If we teach only the design diagram, they may miss the physical failure mode. If we teach only commands and files, they may not understand the obligation the component fulfils. If we teach only business intent, they may produce a persuasive change that violates the system’s constraints.

A practical onboarding task should connect the levels: purpose, design boundary and observable runtime result.

The team must remain responsible

Competence without complete comprehension is normal. Competence without responsibility is not.

The team still needs a way to identify who authorised a change, what evidence supported it, what actually happened and who will respond if the result is wrong. This becomes more important when AI assists with analysis or implementation.

AI can be given substantial freedom while a human subject retains control and responsibility. The boundary is crossed when the goal changes, the action becomes difficult to reverse, or the consequences can no longer be adequately checked and repaired by the responsible person.

That principle should appear in onboarding as an operating rule, not as a general warning about AI.

For example:

the engineer may use AI to explore alternatives and prepare a patch;
the system records the proposed change and the tests performed;
a named person owns the release decision;
irreversible or externally consequential actions require a fresh decision;
the result is observed after execution, not inferred from a successful command.

The same rule applies whether the work was suggested by a model, copied from an old runbook or written from memory.

A simple onboarding evidence pack

For each first responsibility, keep a compact record:

Obligation — what outcome this part of the system must protect.
Boundary — what the engineer may change without a new decision.
Evidence — which tests, reviews and runtime signals support the change.
Owner — who accepts responsibility for the action and its consequences.
Recovery — how the team detects failure and restores a safe state.

This is more useful than asking whether the newcomer has “understood the architecture.” It turns onboarding into a sequence of verified capabilities.

The engineer does not need to comprehend the whole organisation before contributing. The organisation does need to make safe contribution possible without pretending that local confidence equals global understanding.

That is the practical value of Dennett’s idea for technical teams: reliable competence can be distributed, but responsibility cannot be allowed to disappear inside the distribution.

Source episode: Why Can a System Be Smarter Than Its Leader? | Daniel Dennett