{
  "id": 19030713,
  "title": "Competence Without Comprehension: Systems Engineering Onboarding Framework",
  "url": "https://urgent.news/2026/11/08/competence-without-comprehension-systems-engineering-onboarding",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-08T22:12:03.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/dmitrii_efremov_7c5af18c7/competence-without-comprehension-systems-engineering-onboarding-framework-4nhb"
  },
  "original_language": "en",
  "account": "The concept of \"competence without comprehension\" is relevant when considering technical teams and their onboarding process. A complex system can produce reliable results even when no single component fully grasps the entire system. For example, a language model can generate useful code without possessing a developer's deep understanding of the product. Similarly, an operational chain can continue functioning even if no individual holds the complete map of the system. This realization does not render understanding irrelevant; instead, it shifts the focus to where understanding should be sought. In a well-structured engineering organization, competence should not rely on a single person having the entire system's knowledge in their head. Instead, it should arise from interfaces, feedback, tests, reviews, ownership, and the ability to identify and rectify mistakes. This is also the true benchmark for onboarding processes.\n\nTypical onboarding questions, such as \"How quickly does the new engineer understand the system?\" can be misleading, as the system might be too intricate for any individual to comprehend entirely. This question also promotes two undesirable outcomes: theatrical comprehension, where a new hire learns the vocabulary and architecture diagram, appearing fluent while lacking the capability to make safe changes, and dependence on a guide. The new employee may be reliant on a senior engineer to explain every local decision, but the actual operating capability still belongs to the senior person. A more effective approach is to ask, \"What can this engineer now accomplish safely, and what evidence demonstrates this?\" The initial stage of onboarding should not involve a comprehensive tour of the entire architecture. Instead, it should focus on assigning the new engineer a limited responsibility: one real path through the system, such as addressing a specific user or operational need, changing a particular component, adhering to imposed interfaces, fulfilling necessary checks, obtaining approval for exceptions, and monitoring signals to determine if the change was successful post-release. This approach emphasizes the importance of documentation in onboarding. Rather than merely describing existing structures, documentation should guide the new engineer on what actions they can take next, how to test their decisions, and when to cease their involvement.\n\nDaniel Dennett identified three levels of explanation for complex systems: the physical level, which examines the actual machinery, processes, networks, storage, runtime behavior, and failure conditions; the design level, which explores what components are for, the contracts they implement, and the architecture's expectations from them; and the intentional level, which utilizes a higher-level model to understand the system's purpose, the likely changes by other teams, and how customers will respond. New engineers require all three levels of explanation; however, they should not receive an equal depth of understanding in each level. Teaching only the design diagram might overlook crucial physical failure modes, while focusing solely on commands and files could prevent the new hire from understanding the component's purpose. Similarly, concentrating solely on business intent may lead to the creation of persuasive changes that violate the system's constraints. Consequently, a practical onboarding task should connect these three levels: purpose, design boundary, and observable runtime results. The team must retain responsibility for the system, even when employing AI assistance. AI can be granted substantial freedom in analyzing or implementing tasks while ensuring that a human retains ultimate control and accountability. The boundary is crossed when the objective changes, the action becomes difficult to reverse, or the consequences become too complex for the responsible person to check and rectify adequately. This principle should be incorporated into onboarding as an operating rule rather than a general warning about AI use. For instance, the engineer may utilize AI to explore alternatives and draft a patch, with the system documenting the proposed change, the performed tests, and the named person owning the release decision. Irreversible or externally consequential actions must require a fresh decision, and the result should be observed after execution rather than inferred from a successful command. This approach applies regardless of whether the work was suggested by an AI model, copied from an old runbook, or created from memory.\n\nTo facilitate this process, a concise onboarding evidence pack should be maintained for each first responsibility. This pack should include: Obligation, outlining what outcome the specific part of the system must protect; Boundary, specifying what the engineer may change without requiring a new decision; Evidence, which includes the tests, reviews, and runtime signals supporting the change; Owner, identifying the person responsible for the action and its consequences; and Recovery, detailing how the team detects failure and restores a safe state. This evidence pack is more valuable than merely inquiring whether the newcomer has \"understood the architecture.\" By transforming onboarding into a sequence of verified capabilities, the engineer does not need to fully comprehend the entire organization to contribute. Instead, the organization must ensure safe contributions are possible without assuming local confidence equates to global understanding. Dennett's idea offers practical value for technical teams, highlighting that reliable competence can be distributed across the team, but responsibility must remain firmly within the team's control.",
  "summary": "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…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}