2026-11-04 · ~20 min read · Decision records

The engineering team decision-making decision record: why the decision-making model you chose determines your decision throughput ceiling and your alignment surface

Engineering team decision-making decisions are not decisions about which meeting format to use or which collaboration tool to adopt. They are a set of founding decisions about how the organization determines who has the authority to close a technical question — when a decision is owned at the team level and when it requires escalation, what process governs decisions of different risk and reversibility profiles, how decision authority is documented clearly enough that engineers can act without informal polling, and how decisions are recorded and distributed so that the engineers who implement them understand not only what was decided but why, and so that future engineers can find the reasoning rather than re-litigating the same question in a new meeting two years after the original decision was made. The consequences are invisible when the team is small enough that everyone's mental models align without documentation — when there are eight engineers and the CTO has attended every important technical conversation, the implicit decision-making model works because everyone's calibration of "what requires CTO input" has been built from the same set of observed decisions. The consequences become visible when the team reaches a size where engineers have different histories of observed decisions and different calibrations of authority, when a CTO override in one specific context propagates as a template for all similar contexts, and when a decision that could have been closed in an afternoon takes four weeks to merge from two parallel implementations.

A 14-person developer tools startup had been building its SaaS product for two years without a documented decision-making model. Technical decisions were made informally: whoever had the strongest opinion and the most relevant expertise drove the conclusion, and the CTO closed the rare high-stakes questions when they spilled into more than one or two Slack threads. The model had worked well through the first fourteen months when the engineering team consisted of the CTO and four senior engineers who had all worked together previously and shared a common implicit understanding of which decisions warranted escalation. It had started showing strain at month fifteen when the team hired five additional engineers who had not participated in the history of past decisions that calibrated the implicit model, but the strain had not produced a visible failure — the new engineers learned the implicit model by observation, the same way the first team had.

The failure became visible when the company needed to decide which authentication service to adopt as it prepared to launch enterprise sales. The existing in-house authentication system, written hastily in the product's first quarter, was not suitable for enterprise security requirements: it lacked audit logging, SAML support, and the kind of multi-tenant session management that enterprise buyers expected. The engineering team needed to decide whether to build a proper in-house authentication service, adopt a managed service like Auth0, or use AWS Cognito, which one of the new engineers had used at a previous company. The decision had real costs: the in-house option would require three to four weeks of a senior engineer's time; the managed service options had different pricing structures, vendor lock-in profiles, and integration complexity tradeoffs. The CTO, who would normally have driven this decision, was in the middle of a Series A fundraise and had made clear in a team meeting that he needed the engineering team to operate autonomously for six to eight weeks.

The decision was introduced in a Slack channel on a Monday. Over the following eleven days, engineers posted analyses of the three options, asked questions about the fundraise timeline's implications for the build timeline, and debated the vendor lock-in question. The discussion was substantive and high-quality; engineers raised considerations the CTO would have found useful. But the discussion never closed. No one had the authority to close it — or rather, no one knew whether they had the authority to close it. The principal engineer who had the strongest opinion on the question (use Auth0; the team doesn't have time to build a production-grade auth service before enterprise launch) had not been given explicit authority to close technical decisions in the absence of the CTO. The team lead who had nominal responsibility for the sprint containing the auth work was newer to the company and was uncertain whether an authentication architecture decision was within his team-lead scope or required CTO sign-off.

On day seven of the discussion, before the principal engineer had formed a clear consensus, two engineers independently began implementation work: one started building the in-house auth service because they believed the principal engineer's Auth0 recommendation was not yet final and the sprint timeline required making progress; the other started the Auth0 integration because they read the Slack thread as having reached a sufficient consensus. Neither engineer told the other they had started. Each assumed the other had seen the same thread and was working on a different aspect of the same approach. On day eleven, the CTO briefly rejoined Slack between investor meetings and posted a three-line comment: "makes sense to use Auth0, let's not build our own." Neither engineer stopped their work. By day fourteen, there was a 60%-built in-house auth service and a 70%-complete Auth0 integration. The principal engineer, reviewing both when they became visible in pull requests, spent the next four weeks merging the two implementations into a coherent authentication layer — a week of technical work and three weeks of coordination work, reconstructing the design intent of each implementation from code comments and Slack threads whose context had already been partially swept away.

A 44-person B2B SaaS had implemented a formal Request for Comments process eighteen months earlier, in response to an incident caused by a team decision made without consultation. The incident had involved a team changing the data serialization format for messages on the internal event bus — a decision the team lead had made as a performance optimization, correctly identifying that the existing JSON serialization was adding 30ms of overhead to a hot path. The change had not been reviewed by the two other teams whose services consumed the same event bus, and the new format had broken those consumers silently: the consumers were still parsing the events without error but were now receiving zero-value defaults for fields whose JSON keys had changed. The incident had produced a production data inconsistency that took nine days to identify and three days to remediate. The VP of Engineering had responded by implementing an RFC process with a ten-day minimum comment window and a requirement that all significant technical decisions receive two principal engineer approvals before implementation.

The RFC process was well-designed for decisions at the scale of the incident that prompted it. Cross-team API contract changes, shared infrastructure choices, and new external dependency introductions were exactly the category of decisions for which a ten-day comment window and multiple senior reviewers produced better outcomes than informal team-level choices. The incident would not have occurred under the RFC process — the two consuming teams would have reviewed the serialization format change and caught the key-name discrepancy before it was deployed.

The failure mode emerged not from the process design but from its scope. The RFC mandate applied to "all significant technical decisions" — a phrase the VP of Engineering had intended to describe the incident's category of decision and that engineers interpreted as covering a significantly broader category. A team lead proposing to switch a single microservice from Protocol Buffers to a custom binary format for internal queue messages — a team-level decision with no cross-team dependencies, affecting one service's internal serialization logic — submitted an RFC because the word "serialization" in the decision description triggered his mental category of "significant technical decision." The RFC entered a queue with seven other pending RFCs. The team lead waited. At day twelve, two principal engineers had commented but neither had formally approved. At day nineteen, one principal engineer had approved and the second had requested significant changes to the proposal — specifically, a comparison against three alternative binary formats the principal engineer wanted evaluated. By day twenty-six, the team lead had produced the requested comparison. By day thirty-two, the RFC was approved.

During those thirty-two days, the team continued building features that depended on the message format of the internal queue. Each feature was built against the existing Protocol Buffers format because the RFC was pending and the team lead had not authorized anyone to begin implementation under the new format. Each feature also added technical debt: internal abstractions designed to isolate the queue format dependency so the team could switch formats once the RFC was approved. By day thirty-two, six features had been built with format-isolation abstractions that would have been unnecessary had the decision been made in the two hours the team lead believed it warranted. The principal engineer who had delayed the RFC by requesting the multi-format comparison later observed that the comparison was useful — it produced a better-informed decision — but that the same quality of comparison could have been produced in a forty-five-minute conversation between the team lead and one principal engineer, with a one-page written outcome, rather than through a process whose overhead was calibrated to the incident that prompted its creation.

A 72-person enterprise SaaS had built a detailed Decision Authority and Consultation Index — a DACI matrix — that defined the driver, approver, consulted, and informed roles for forty-three categories of technical decision. The DACI had been developed collaboratively over three months by the engineering leadership team, drawing on the company's incident history to identify which decision categories had produced coordination failures when the authority model was unclear. The result was a thorough and well-thought-out document: service-level design decisions for single-service scope were owned by the team lead; decisions affecting a shared data schema required the principal engineer's approval; decisions introducing new SaaS vendor dependencies required the VP of Engineering's approval; decisions affecting the core authentication or billing services required the CTO's review. The DACI was accessible to all engineers in the company wiki and was referenced in the engineering onboarding materials.

Seven months after the DACI was introduced, the VP of Engineering noticed that she was receiving approximately twenty to twenty-three approval requests per week — far more than the DACI assigned to her approval scope. Reviewing a sample of requests, she found that the majority were decisions the DACI assigned to team leads or principal engineers: team-level caching strategies, within-service API refactors, single-team queue architecture choices. The requests were framed as approvals but functionally served as status updates and confidence checks — engineers were not genuinely uncertain whether their approach was correct; they were uncertain whether they had the authority to proceed without VP sign-off.

The pattern had started four months earlier, following an incident in which the VP had reversed a team's caching strategy decision. The team had designed a cache invalidation approach that the VP, reviewing it in a post-incident review, identified as having a correctness issue under concurrent writes — a specific flaw, not a category error. The VP had made the reversal clearly, with specific technical justification. The team had implemented the corrected approach. The incident review had been conducted professionally, with no punitive framing and clear acknowledgment that the original decision had been a reasonable design that exposed an edge case under concurrent access. But the signal engineers received from the incident was not constrained to the specific technical concern the VP had identified. The signal they received was: "the VP has opinions about caching architecture; decisions that are architecturally significant should include the VP." The DACI assigned caching strategy decisions to the team-lead scope, but the implicit model updated by the incident assigned them to a category that warranted VP input.

The escalation surface expansion remained invisible in the DACI — the documented authority model still said team leads owned team-level decisions. It became visible in the VP's approval queue, which the VP identified when a request arrived for approval of a security patch. The patch addressed a CVE in an authentication middleware library; the fix was straightforward: update the library version and modify three lines of initialization code to use the new API. The team lead had identified the fix on day one of the CVE disclosure window. She had submitted an approval request to the VP because the fix involved changing the initialization pattern of an authentication component and she had observed, from the caching incident, that authentication decisions were the kind of architecturally significant decisions the VP had opinions about. The VP saw the request on day eleven, approved it immediately, and asked the team lead why she had waited for VP approval on a CVE patch. The team lead's answer was accurate: she was not certain what the boundary was between team-led and VP-approved decisions since the caching incident, and given that this was an authentication component and the CVE window had a narrow timeline, she had erred toward escalation. During the eleven days the company had been exposed to the vulnerability that the team lead had identified the fix for on day one.

Structural properties set by the engineering team decision-making decision

Two structural properties are determined by the founding decisions about decision authority scope, process tier calibration, escalation trigger documentation, decision record quality, and authority signal management. Both are invisible when the team is small enough that the implicit model is consistent; both become visible when the team grows past the size where everyone's implicit calibration can be built from the same set of observed decisions.

Property 1: Decision throughput ceiling. The decision throughput ceiling is the maximum rate at which the organization can close technical decisions and begin implementation without creating bottlenecks, parallel conflicting work, or approval queues that delay time-sensitive actions. Three factors determine this ceiling. First, authority model: whether the authority to close a decision at each scope level is documented explicitly enough that engineers can determine who owns the decision without informal polling. The first failure story illustrates the absent authority failure mode: when neither engineer knew whether the principal engineer's recommendation was authoritative or advisory, the decision remained open past the point where implementation work began in parallel. The authority model is not just about who is the final approver — it is about whether engineers know enough to act without asking, which requires a documented model specific enough to handle the boundary cases that arise in practice, not just the typical cases that the DACI covers cleanly. Connect this to the engineering architecture review process decision record: the architecture review process is the specific instantiation of the decision-making model for architectural decisions — the architecture review's scope, trigger criteria, and participant model are the decision authority model's concrete expression for the highest-stakes decision category, and an architecture review process without a documented authority model for lower-scope decisions leaves the full range of decision types uncovered. Second, decision process fit: whether the process model is calibrated to decision risk and reversibility. The second failure story illustrates the uniform process failure mode: a ten-day comment window and two principal engineer approvals is proportionate overhead for the incident's category of decision — cross-team API contract changes — and disproportionate overhead for a team-level implementation choice. The process fit failure mode produces friction that is highest precisely for the low-stakes decisions that could move fastest and have the highest throughput value from moving quickly. Connect this to the engineering technical debt triage decision record: a decision process calibrated uniformly to the highest-risk category of decision applies RFC-level overhead to technical debt triage decisions — decisions that need to be made frequently, iteratively, and with low ceremony — and in doing so trains teams to avoid the formal process for the category of decisions the technical debt triage model most depends on. Third, escalation surface: whether implicit authority signals expand the documented scope of what requires escalation. The third failure story illustrates the implicit expansion failure mode: the DACI correctly scopes VP approval to decisions introducing new SaaS vendor dependencies; the implicit model generated by one CTO override expands that scope to include all architecturally significant decisions regardless of cross-team impact. The escalation surface failure mode produces an approval queue that grows without updating the documented authority model — the DACI still shows the right number of VP-approval-required decisions while the actual queue contains decisions the DACI assigns to lower levels. Connect this to the engineering sprint planning decision record: an escalation surface expansion that routes team-level decisions through VP approval inflates the sprint planning model's cycle time for decisions that the sprint's scope requires — a team waiting eleven days for a VP approval on a decision the sprint plan assumed would take one day is a team whose sprint velocity is bounded not by engineering capacity but by the approval queue's throughput.

Property 2: Alignment surface. The alignment surface is the degree to which decisions are known to, understood by, and actionable by the engineers who implement them — the gap between "this was decided" and "the engineers who need to act on this can find the reasoning, understand the constraints it creates for adjacent choices, and apply it without re-litigating it in the next meeting where the topic arises." Three factors determine this surface. First, decision documentation quality: whether decisions are recorded with enough context — alternatives considered, primary selection reason, constraints on adjacent choices — that an engineer who was not present can understand the rationale and apply it correctly to a new but structurally similar question. Connect this to the engineering technical strategy decision record: a technical strategy document is only as useful as the decisions it captures with sufficient context — a strategy that lists "API-first architecture" as a direction without documenting why the alternative of an internal-first architecture was rejected and what the API-first direction implies for service design decisions cannot be used by an engineer who is making a service design decision to understand whether their approach is consistent with the technical strategy. Second, re-decision prevention: whether the decision record makes it clear when a decision is closed — no longer open for re-litigating in new meetings — and what the conditions for revisiting it are. The absence of a re-decision prevention model produces meetings where settled questions are re-opened by engineers who were not present for the original decision or who disagree with its conclusion but have no formal process for challenging it except bringing it up again. Connect this to the engineering code review velocity decision record: code reviews that relitigate architectural decisions the organization has already made — "should we be using this library at all?" asked about a library whose adoption was a closed decision three months ago — are code reviews where the review's attention is consumed by a question the reviewer cannot actually answer in the review context rather than by the correctness and quality of the change under review. Third, authority signal propagation: whether a decision made in a specific context is communicated in a way that correctly scopes its implications for other contexts. The third failure story illustrates the signal propagation failure mode: the VP's override of the caching strategy decision was correct and specific to that design's flaw, but the override signal propagated as a general scope expansion because no mechanism existed to bound its implications. Connect this to the engineering sprint planning decision record: a sprint planning model that absorbs an authority signal expansion without updating the sprint's decision timeline assumptions — treating a one-day team-level decision as a potential eleven-day VP-approval decision — is a sprint plan whose commitments are based on the documented decision-making model's cycle times while the actual cycle times are determined by the implicit model's expanded escalation scope.

The engineering team decision-making ADR: five sections

Section 1: Decision scope classification model. The scope classification model specifies which decision categories are owned at which scope level, with enough precision to handle the boundary cases that arise in practice. Three components. Category definitions with worked examples: each scope level in the authority model includes at least three worked examples of decisions that clearly fall within it and two worked examples of decisions at its boundary with the adjacent scope level. The worked examples are updated when retrospectives identify cases where the category definition produced inconsistent escalation behavior. Example tier definitions for a 40-80 person engineering organization: team-lead scope covers implementation choices within a single service with no cross-service dependencies — internal data structure choices, library selections for a service's private dependencies, performance optimization approaches for a service's internal paths. Principal engineer scope covers decisions that affect a service's externally-visible behavior or add a dependency shared across teams — API contract changes, shared infrastructure choices, new external service dependencies. VP of Engineering scope covers decisions that establish patterns all teams will follow, introduce vendor contracts above a named cost threshold, or affect the organization's core authentication, billing, or data model. The worked examples document the boundary cases: a caching strategy for a service's internal cache falls in the team-lead scope; a caching strategy that changes the freshness guarantees the service exposes to consumers falls in the principal engineer scope because it affects the service's externally-visible behavior. Connect this to the engineering technical strategy decision record: the technical strategy document should specify which architectural directions are settled at the organization level — not requiring re-decision each time a team makes a structurally related choice — so that the scope classification model's team-lead decisions can reference the technical strategy for settled directions and the principal engineer scope can be reserved for genuinely new questions. Named escalation triggers: the classification model includes a list of named triggers that move a decision to the adjacent scope level regardless of category — the decision affects a shared data schema; the decision changes the semantics of an API endpoint that more than one team depends on; the decision introduces a new external dependency with a contract or pricing model; the decision creates a constraint on a named future architectural direction. The named triggers address the boundary case failure mode: they give engineers a specific list of conditions to check rather than a category judgment to make. Default-to-lower-scope: the default interpretation for scope-ambiguous decisions is team-led, with a named consultation option for uncertainty. If the team lead is uncertain whether a decision falls in team-lead or principal engineer scope, the consultation option is a fifteen-minute conversation with the principal engineer before proceeding, producing a documented one-paragraph outcome rather than triggering the full RFC process.

Section 2: Decision process model. The process model defines the procedure for decisions at each scope level, calibrated to decision risk and reversibility. Three tiers. Tier 1 — team decision, lightweight documentation: decisions that are reversible within a single sprint, affect only one team's services, and have no cross-team dependencies. The process is a team discussion (synchronous or async over at most forty-eight hours) closing with a written outcome in the team's decision log — what was decided, two or three alternatives considered, the primary selection reason, any constraints on adjacent choices. No approval step, no comment window. The team lead closes the decision. If no conclusion is reached within forty-eight hours, the team lead makes the call. Tier 2 — principal engineer review, structured proposal: decisions that are costly to reverse, affect a shared component or cross-service API, or introduce a new external dependency. The process is a one to two page written proposal, a named review window of three to five business days, a named reviewer, and a documented outcome. The review window is firm: if the reviewer does not respond within the window, the decision proceeds as proposed. The named reviewer can request additional information once; the response window extends by one business day for each information request. Tier 3 — RFC process, extended review: decisions affecting the organization's foundational components or establishing patterns all teams will follow. Full RFC with a ten-day minimum comment window, multiple named reviewers, and a final decision meeting where the RFC author presents the proposal and reviewers close the decision. The comment window closes on the named date regardless of comment completeness. Connect this to the engineering architecture review process decision record: the architecture review process is the specific institutional form of the tier-3 RFC process for architectural decisions — the RFC process model and the architecture review process should be aligned so that decisions in scope for the architecture review go through the architecture review rather than a parallel RFC track. The process tier assignment is made by the engineer proposing the decision; the team lead can reclassify within two days if the assignment is clearly incorrect. Tier misclassification is not a punishable offense — it is a signal to update the worked examples in the classification model.

Section 3: Decision authority model and delegation protocol. The authority model names the individuals who hold closing authority at each scope level and the conditions under which authority can be delegated or backed up. Three components. Named authorities per scope level: each scope level in the classification model has a named closing authority — a specific person or role, not a committee. The closing authority for team-level decisions is the team lead; for principal engineer scope, the named principal engineer for the affected area; for VP scope, the VP of Engineering. Named authorities reduce the opening-unresolved failure mode in the first failure story: when no one knows who can close a decision, decisions accumulate options without conclusions. Backup and delegation: each named authority has a named backup who can close decisions when the primary is unavailable. The authority is delegated explicitly — the team lead notifies the principal engineer when they are out of scope for a decision; the principal engineer notifies the VP when they are on leave — rather than leaving decisions open during unavailability. The delegation protocol addresses the first failure story's specific failure mode: the CTO's unavailability during the fundraise should have triggered an explicit delegation to the principal engineer for the duration, with a written note to the team that the principal engineer had closing authority for decisions in the VP/CTO scope during the fundraise window. Authority signal management: when a senior authority exercises closing authority on a decision in a lower scope level — a CTO override of a team-level decision — the communication of that decision includes an explicit scope statement: whether the override establishes a general principle or is specific to this context. The scope statement prevents the implicit signal propagation failure mode in the third failure story. Connect this to the engineering code review velocity decision record: the code review's approval gate model is a micro-instance of the authority model — the CODEOWNERS model in the third failure story of that record and the DACI override in the third failure story of this record share the same structural failure mode: an authority model that is correct on paper produces incorrect escalation behavior in practice when implicit signals override the documented scope.

Section 4: Decision documentation and distribution model. The documentation model defines what a decision record must contain and how it is distributed to engineers who need to act on it. Three components. Minimum documentation requirements: every tier-1 or higher decision produces a written record containing the decision statement (what was decided), the alternatives considered (at least two, including the rejected options), the primary selection reason (the factor that made the chosen option better than the alternatives in this context), and any constraints on adjacent choices (what future decisions this decision forecloses or constrains). The minimum requirements are designed to make the record useful for the engineer who was not present for the decision — the selection reason is specifically required because a decision record without the selection reason is a record of what was chosen, not a record that allows the reader to understand whether the choice would hold in a new but structurally similar context. Distribution model: tier-1 decisions are recorded in the team's decision log and do not require active distribution. Tier-2 decisions are recorded in a shared architecture decision log visible to all engineers and are summarized in the weekly engineering digest. Tier-3 decisions are recorded in the shared log, summarized in the engineering digest, and presented in the next engineering all-hands. The distribution model ensures that engineers learn about decisions relevant to their work before they encounter them in a code review or a new feature design — the alignment surface failure mode in the first failure story was not just that the decision was undocumented but that the two engineers implementing in parallel were not in a distribution channel that would have surfaced the ongoing decision discussion. Re-decision protocol: a decision record is closed by default — not subject to re-litigating in new meetings — and specifies the conditions under which it will be revisited: a specific new technical constraint that changes the tradeoff, a change in the product requirements affecting the decision's scope, or a named review interval. An engineer who disagrees with a closed decision can submit a formal revision request that documents the new information or changed condition; the closing authority reviews the revision request and either opens the decision for revision or rejects the request with a documented reason. Connect this to the engineering technical strategy decision record: the technical strategy's effectiveness depends on its decisions being treated as closed in the same way team and principal engineer decisions are closed — a technical strategy direction that is re-litigated in team meetings by engineers who disagree with it is not an effective technical strategy, it is a discussion document. The re-decision protocol makes the technical strategy's decisions as closed as the DACI's scope assignments, with the same process for formal revision requests when new information changes the tradeoff.

Section 5: Decision health measurement and improvement cadence. The health measurement model defines how the organization monitors whether its decision-making model is producing the intended outcomes and what prompts updates to the model. Three components. Decision throughput measurement: the VP of Engineering tracks two metrics monthly: the median time from decision-initiation to decision-closed for each process tier, and the fraction of decisions in each tier that exceed the tier's target cycle time by more than 50%. Tier-1 decisions should close within two days; tier-2 within seven business days; tier-3 within fifteen business days. Decisions exceeding these targets by more than 50% are reviewed to identify whether the tier assignment was correct, whether the authority model produced the right closing behavior, or whether the process model created friction that slowed the decision. Escalation volume monitoring: the VP of Engineering tracks the volume of approval requests per week and the fraction that the DACI assigns to lower scope levels. A threshold of more than five DACI-below-VP requests per week triggers an investigation: an unclear DACI boundary, a recent override that generated a scope expansion signal, or a team lead who needs clarity on their authority scope. The investigation produces one of three outcomes: the DACI is updated to reflect the actual authority model, an exception note is added to the relevant decision record explaining its scope, or the VP communicates the authority model's scope explicitly to the affected team. Connect this to the engineering technical debt triage decision record: a decision process that creates escalation surface expansion functions as a form of technical debt in the decision-making infrastructure — decisions pile up in the approval queue the same way technical debt piles up in the codebase, and the resolution is the same: identify the root cause, make it visible, and address it at the structural level rather than processing the queue faster. Decision quality review cadence: quarterly, the engineering leadership team reviews a sample of ten to fifteen decision records across all tiers and assesses whether they meet the minimum documentation requirements, whether the tier assignment was appropriate in retrospect, and whether any decisions produced implementation inconsistencies because they were not distributed to engineers who needed them. The quarterly review produces updates to the worked examples in the scope classification model and updates to the minimum documentation requirements based on the gaps the sample exposes. Connect this to the engineering sprint planning decision record: a sprint planning model that is well-designed for the organization's current decision-making cycle times needs to be reviewed whenever the decision health measurement indicates that cycle times have changed — a sprint plan designed around a two-day team-level decision cycle time is a sprint plan that breaks when escalation surface expansion has pushed team-level decisions into an eleven-day VP-approval cycle.

FAQ

How do you define decision scope boundaries precisely enough that engineers can determine whether to escalate without asking?

The core challenge in defining decision scope boundaries is that any boundary drawn with categories — "service-level decisions are team-owned; cross-service API changes require principal engineer review" — produces boundary cases that the category description does not resolve. An engineer changing a service's internal caching strategy knows this is a service-level decision. An engineer changing a service's cache invalidation behavior in a way that affects the data freshness guarantees the service exposes to consumers is at the boundary between service-level and cross-service. If the boundary description does not handle this case explicitly, the engineer's escalation decision depends on their personal calibration of which category the decision falls into — and that calibration varies. Three components address this. First, decision category definitions with worked examples: each scope level in the authority model includes at least three worked examples of decisions that clearly fall within it and two worked examples of decisions at its boundary with the adjacent scope level. The worked examples are more useful than the category definition because they provide observable anchors the engineer can compare their actual decision against. "A change to this service's internal retry delay falls within team scope; a change to this service's retry behavior that affects how often consumers of this service's API need to implement their own retry logic falls at the team/principal boundary and requires a fifteen-minute consultation with the principal engineer before proceeding." Second, default-to-lower-scope with named escalation triggers: the default interpretation for any decision whose scope is ambiguous is team-owned, with a list of named triggers that move a decision to the adjacent scope level regardless of category. Named triggers include: the decision affects a shared data schema; the decision changes the semantics of an API endpoint that more than one team depends on; the decision introduces a new external dependency with a contract or pricing model; the decision creates a constraint that would prevent a named future architectural direction from being pursued. The named triggers are enumerated in advance and updated when new trigger types are discovered in retrospectives. Third, low-cost consultation model for boundary cases: the boundary between team-owned and escalated decisions is not a binary gate — it is a spectrum where the consultation overhead should be proportional to the decision's stakes. A team-lead decision that benefits from a five-minute check-in with the principal engineer is different from a team-lead decision that requires a formal RFC. The model explicitly includes a lightweight consultation option — a Slack message or brief meeting that produces a documented one-paragraph response — that engineers can use for boundary cases without triggering the full escalation process.

How do you calibrate a decision process model so that high-process decisions get appropriate review and low-process decisions don't create RFC backlogs?

The calibration failure mode in the second failure story is not the RFC process itself — the RFC process is well-designed for the decisions it was designed for. The failure mode is applying a process calibrated for high-risk architectural decisions to decisions that do not need it. The fix is a process model with multiple tiers calibrated to decision risk and reversibility, not a single process applied uniformly. Three tiers work for most engineering organizations at the 20-80 person scale. Tier 1 — team decision, lightweight documentation: decisions that are reversible within a single sprint, affect only one team's services, and have no cross-team dependencies. The process is a team discussion (synchronous or async over at most forty-eight hours) closing with a written outcome in the team's decision log. No approval step, no comment window. The team lead closes the decision. Tier 2 — principal engineer review, structured proposal: decisions that are costly to reverse, affect a shared component or cross-service API, or introduce a new external dependency. The process is a one to two page written proposal, a named review window of three to five business days, a named reviewer, and a documented outcome. The review window is firm: if the reviewer does not respond within the window, the decision proceeds as proposed. Tier 3 — RFC process, extended review: decisions affecting the organization's foundational components or establishing patterns all teams will follow. Full RFC with a ten-day minimum comment window, multiple named reviewers, and a final decision meeting. The comment window closes on the named date regardless of comment completeness. The tier assignment is made by the engineer proposing the decision; the team lead can reclassify within two days if the assignment is clearly incorrect. Tier misclassification is not a punishable offense — it is a signal to update the worked examples in the classification model. The RFC process's effectiveness depends on being reserved for decisions that genuinely warrant its overhead; an RFC process that is applied to tier-1 decisions trains engineers to bypass the formal process for the category of decisions the RFC process was most designed for.

How do you prevent an authority model from being overridden by implicit escalation signals without updating the documented model?

The implicit escalation signal failure mode is specifically difficult because it is transmitted by behavior rather than by documentation. When a CTO overrides a team's decision in a specific context — even with good reason, even with specific justification for why this particular decision warranted the override — engineers observe the override and update their implicit model of which decisions require CTO input. The updated implicit model is not constrained to the specific context of the override; it generalizes to "decisions that are architecturally significant," which is a much broader category than the documented authority model covers. Three practices address this. First, explicit scope statement at override time: when a senior leader overrides a team-level decision, the override communication explicitly states whether the override establishes a general principle or is specific to this context. "I'm reversing this caching strategy decision because this specific design has a data consistency issue under concurrent writes — this is specific to this design; team-level caching decisions remain team-owned." The explicit scope statement transmits the specific learning without transmitting the implicit signal that all structurally similar decisions now require escalation. Second, escalation volume monitoring: the VP of Engineering tracks the volume of approval requests they receive weekly and the fraction that the DACI assigns to lower scope levels. When DACI-below-VP requests exceed five per week, the VP investigates the cause: an unclear DACI boundary, a recent override that generated a scope expansion signal, or a team lead who is under-confident in their authority. The monitoring makes the implicit scope expansion visible before it inflates the approval queue significantly. Third, documented authority model review after high-profile overrides: when a senior leader makes a decision that falls outside the documented authority model, the override is followed by a fifteen-minute review of whether the DACI needs to be updated or whether the override was a one-time exception that should be documented as such. All three outcomes close the signal propagation loop — the engineers who observed the override receive explicit communication about its scope rather than inferring it.

How do engineering team decision-making decisions connect to AI chat sessions and decision preservation?

Engineering team decision-making decisions are made in AI chat sessions when engineering leaders work through the authority model — which decision categories are owned at which scope level, where the boundary cases fall, what triggers escalation from team to principal to CTO — the process model — which process tier applies to which decision risk profile, what the review window and reviewer assignment model is for each tier, how the process ensures decisions are closed rather than left open indefinitely — the decision documentation model — what information a decision record must contain for an engineer who was not present to understand not only what was decided but why, what constraints the decision imposes on adjacent choices, and what would trigger revisiting the decision — and the authority signal management model — how to communicate a high-level override in a way that transmits the specific learning without propagating an implicit scope expansion across the entire engineering organization. The reasoning in those sessions is the substance of the decision-making model — more so than the DACI spreadsheet, the RFC template, or the decision log folder in the company wiki — because the model's effectiveness in producing consistent escalation behavior and actionable decision records is a function of whether the tier boundaries, the trigger criteria, and the scope statement practices were designed with an accurate understanding of how decision-making models fail rather than how they appear when the team is small and the leader is in every important conversation. Running those AI chat sessions through the open-source extractor produces the team decision-making decision record that allows the next engineering leader to inherit the reasoning about why the RFC process is scoped to tier-3 decisions only, why the DACI includes a list of named escalation triggers rather than relying on engineers to infer the boundary from category definitions, and why the authority signal management practice includes an explicit scope statement at every override — rather than inheriting a DACI spreadsheet and an RFC template whose design rationale was worked out in a ChatGPT session by the VP of Engineering who responded to a high-visibility incident and whose departure removes the specific incident context that made the RFC mandate feel proportionate.

Structural properties set by the engineering team decision-making decision

The engineering team decision-making ADR: five sections

FAQ

Further reading