2026-10-30 · ~22 min read · Decision records

The engineering technical strategy decision record: why the technical strategy model you chose determines your architecture coherence ceiling and your engineering investment justification surface

Engineering technical strategy decisions are not choices about which technology bets to make or which architecture patterns to adopt. They are a set of founding decisions about which categories of technical choice require coordination across the engineering organization versus which can be safely delegated, how the strategy is documented and maintained so that engineers who were not in the room when it was made can make consistent decisions against it, and how technical investment commitments are integrated into the roadmap and capacity allocation processes so that strategic priorities compete with feature work on equal terms rather than existing in a parallel document with no forcing function — decisions whose consequences are invisible when the CTO can hold the entire technical direction in their head and communicate it directly, and visible when the organization grows past the point where that direct communication is feasible at scale.

A 19-person developer tools startup had no formal technical strategy. The CTO trusted the engineering team, did not want to impose unnecessary process on a team that was shipping quickly, and believed that good engineers would naturally make good technical decisions without needing to be told what the direction was. For the first year and a half, this worked well. The engineering team was small enough that the CTO was in every architecture conversation, could course-correct in code review, and could communicate direction through daily interaction with engineers whose offices were within fifteen meters of each other. The implicit direction was consistent because the CTO was present in every significant decision.

By the time the company reached nineteen engineers, the CTO was in none of the architecture conversations and in a small fraction of the code reviews. In the previous year, the company had hired six engineers: two backend engineers who had worked primarily at companies using REST with resource-first naming conventions and action-based HTTP verbs; one who had come from a gRPC-first company and whose instinct was to design every external API as a typed service definition regardless of the underlying transport; one frontend engineer who had read a strong argument for GraphQL and applied it to the one API she owned; and two fullstack engineers whose prior experience was with RPC-style REST and who designed their services accordingly. None of these choices were wrong in isolation. The engineers who made them were experienced and had thought carefully about the decisions they were making. They were making those decisions without any documented guidance about what the company's API design direction was, because no such guidance existed. Each engineer was applying the best judgment they had from their prior experience, and their prior experiences were different.

Two years after the company's founding, the engineering team had four materially different API design conventions operating simultaneously in the codebase: the original resource-first REST services, the new gRPC-typed services, the GraphQL API for the analytics feature, and an RPC-style REST service for the background processing layer. A new engineer hired in month twenty-two asked the CTO which convention to follow for a new integration service she was building. The CTO, who had not been aware that the conventions had diverged this significantly, spent three hours reviewing the codebase to understand what had happened before she could answer the question. The answer was that the company had no convention — it had an accumulation of reasonable individual decisions made without coordination, and the cost of that accumulation was now visible in every cross-team integration: each integration had to negotiate between the conventions of the teams on either side; the API documentation was inconsistent; the client SDKs had different interaction models depending on which service they wrapped; and new engineers onboarded to a codebase where the right approach depended on which part of the system they were working in rather than on any documented standard. The CTO had been present in zero of the six decisions that produced the divergence. The divergence had accumulated not through negligence but through the absence of a classification model that specified which categories of technical decision required coordination versus which could be safely delegated to individual engineers.

A 48-person B2B SaaS had a written technical strategy. During the Series A fundraise, the CTO had spent three days writing a twelve-page technical strategy document that articulated the company's architectural direction for the next three years: the platform would be API-first, enabling a partner ecosystem; new product features would use microservices rather than extending the existing monolith; the data pipeline would adopt an event-driven architecture to enable real-time analytics; the observability investment would be a Q2 priority; and the developer tooling investment would reduce deployment time from 25 minutes to under five. The document was substantive, well-reasoned, and accurate at the time it was written. The CTO shared it with the engineering team at an all-hands; it was received positively; the seven engineers who were at the company when it was written were familiar with its contents.

Eighteen months later, the CTO conducted a strategy review in preparation for the Series B fundraise. The review produced three discoveries. First, seven of the nine engineers who had joined after the strategy was written had never read it. The document lived in a Notion folder that new engineers were not directed to during onboarding, because the onboarding checklist had been written before the strategy document existed and had never been updated to include it. Second, the microservices commitment had been quietly abandoned. The first two microservices built under the strategy had been operationally demanding enough that both had been rolled back into the monolith after six months; the engineering team had made this decision collectively and had not documented it anywhere, including not updating the strategy document. The strategy document continued to describe a microservices direction that had been reversed, and three engineers who had joined after the reversal believed, based on the strategy document, that the company was building microservices. One of them had started designing a new feature as a microservice. Third, the event-driven pipeline direction had been partially implemented — the pipeline ran in production — but had not been extended to new use cases because no engineer had a clear mandate to do so and the strategy document had not specified which features were expected to adopt the event-driven pattern. A senior engineer who joined eight months after the strategy was written had designed a batch processing approach for a new analytics feature. The CTO had reviewed it and rejected it as inconsistent with the event-driven architecture; the engineer had not known about the event-driven commitment because the strategy document was not part of his onboarding, and the code review was the first time anyone had told him that the event-driven pipeline was the expected pattern for new analytics features.

The three-year strategy document had become a twelve-page description of the technical direction at one moment in time. It had not been updated when the microservices bet was reversed, had not been shared with new engineers as a living document, and had not specified the implementation mandates that would have given the strategic direction influence over individual engineering decisions. The CTO had a clear technical direction in her head; the document that was supposed to make that direction accessible to the engineering team was eighteen months stale in one of its most important sections and unknown to the majority of its intended audience. Connect this to the software architecture documentation decision record: the maintenance currency failure mode described in that record — documentation that is accurate at creation and progressively diverges from reality as the system evolves without corresponding documentation updates — applies to the technical strategy document with the same structural dynamics and the same consequences: a document that is known to be unreliable is worse than no document, because the unreliable document directs engineers to make decisions based on a direction that may have been superseded, while the absence of a document at least makes the absence of direction visible.

A 72-person enterprise SaaS had an annual technical strategy process that the VP of Engineering had built over three years. The process ran in Q4: each engineering director submitted a technical strategy section covering their domain — the current state, the strategic priorities for the next year, and the engineering investments required; the VP synthesized the submissions into a company-level technical strategy document; the combined document was reviewed by the CTO and presented at the January all-hands. The process was well-structured, the output documents were substantive, and the VP was proud of having a strategy process more rigorous than most companies at this stage. The technical strategy documents consistently identified real priorities, and the engineering directors who submitted sections were genuinely thoughtful about their domains.

In the most recent cycle, the strategy process had identified three critical engineering investments for the year: an observability overhaul to address a mean time to detection problem that had produced three significant SLA breach incidents in Q2; a database read-latency migration to support the data-intensive features committed for H2; and a deployment pipeline modernization to reduce the deployment time that was creating friction for the product team's release cadence. Each investment was estimated at six to eight weeks of platform team capacity. Each was genuinely important; the engineering directors who proposed them had strong technical justifications for why the investments were necessary. The technical strategy document described all three as critical priorities for the year.

In the Q1 roadmap planning session, the product team presented the feature commitments for the year. The commitments had been developed in parallel with the technical strategy process — the product planning cycle and the engineering strategy cycle ran on separate tracks that had no formal integration point before the Q1 planning session. The product commitments fully claimed the platform team's capacity for the first two quarters, with expected spillover into Q3. The commitments were backed by customer expectations, sales dependencies, and a partner integration that had a contractual delivery date. When the VP raised the three technical investments in the planning session, the response was: these are important, let's find time for them in H2. By Q3, none of the three investments had been started. The deployment friction had accumulated; the data-intensive H2 features were delayed because the database latency problem had not been addressed; a fourth SLA breach incident in Q3 produced a post-mortem whose remediation included the observability overhaul that had been a strategic priority since January.

The VP raised the prioritization failure in the annual strategy retrospective. The product director's response was accurate and unhelpful: the feature work had external stakeholder commitments that the technical investments did not, and when faced with a capacity constraint, the investments with external accountability had to take priority. The technical investments had been identified as strategic priorities in a document that had no mechanism to compete with feature commitments in the capacity allocation process. The strategy document produced a list of priorities; the roadmap process produced the allocation decisions. The two processes had no integration point before the allocation decisions were made, which meant the strategy could identify the right investments and the allocation process could systematically de-fund them without either process being wrong within its own logic. The VP had built an excellent strategy process and a zero-influence integration between the strategy and the resource allocation that determined whether the strategy was funded. Connect this to the engineering planning horizon decision record: the technical strategy process and the roadmap planning process are working on different planning horizons with different stakeholders, and the failure to integrate them before capacity allocation produces exactly the outcome described here — technical debt accumulates as a predictable consequence of a structural gap between where technical investment commitments are made and where the allocation decisions happen.

Structural properties set by the engineering technical strategy decision

Two structural properties are determined by the founding decisions about scope classification, documentation accessibility, and integration with the capacity allocation process. Both are invisible when the CTO can communicate technical direction directly and personally to every engineer on the team, and visible when the organization grows past the point where that direct communication is feasible at scale.

Property 1: Architecture coherence ceiling. The architecture coherence ceiling is the maximum degree of architectural consistency achievable across the engineering organization, given the decisions made about which categories of technical choice are coordinated versus which are delegated. The ceiling is bounded by three factors. First, decision scope classification: whether the organization has an explicit model for which technical decisions require cross-team coordination before they are made versus which are team-local and can be made independently without coherence risk. The classification model is not a list of rules; it is a framework for distinguishing the categories of decision whose consequences are cross-cutting from the categories whose consequences are contained. Cross-cutting decisions — error handling conventions, logging and observability standards, API design patterns, state management approaches, testing infrastructure choices — have consequences that span multiple teams and that accumulate incoherence if made independently by different engineers with different prior experiences. Team-local decisions — the data model for a specific feature, the algorithm for a specific computation, the library choice for a specific technical problem — have consequences that are largely contained to the team making them and that produce minimal incoherence even when made independently. The absence of this classification produces implicit delegation of everything, which means every engineer's prior experience becomes the de facto standard in their area of the codebase. The presence of the classification produces a model that distinguishes the decisions the organization wants to coordinate from the decisions it wants to delegate, which allows the CTO to communicate direction on the former without constraining engineer autonomy on the latter — the right balance between coherence and flexibility rather than an implicit choice between all-or-nothing. Second, strategy accessibility: whether the technical strategy is documented in a form that is accessible to engineers who were not in the room when it was made and who need to use it to make consistent decisions daily. A strategy document that is accurate and unknown to the engineers it is intended to guide has no influence on their decisions; an accessible strategy is one that appears in new engineer onboarding, that is referenced in code review when a decision touches a strategic direction, and that is the first place an engineer looks when they are uncertain whether their technical approach is consistent with the company's direction. Accessibility is not a documentation quality problem; it is a distribution and maintenance discipline problem: the most accurate strategy document has zero influence if engineers do not know it exists. Third, strategy-implementation coupling: whether the technical strategy produces artifacts — classification models, architecture decision records, design standards documents — that engineers can use to make consistent decisions independently, rather than producing directional statements that require the CTO to be present to interpret. The difference between "adopt event-driven architecture for the data pipeline" as a strategic direction and "new analytics features should use the event-driven pipeline pattern; reference the ADR at /seo/architecture-decision-record-example for the implementation model" as an actionable strategy is the difference between a direction that requires the CTO to be in every relevant code review and a direction that an engineer who joined last week can apply independently.

Property 2: Engineering investment justification surface. The engineering investment justification surface is the degree to which the technical strategy produces a shared vocabulary and priority ordering for engineering investments that allows technical leaders to justify investment requests to non-technical stakeholders in terms those stakeholders can evaluate — the surface area of the strategy that is legible to people who are not engineers. The surface is determined by three factors. First, investment specification quality: whether the technical strategy specifies investments as explicit time-team-outcome commitments rather than as directional priorities. The gap between "we should invest in observability" and "we need eight weeks of platform team capacity in Q2 to reduce mean time to detection from 47 minutes to under five minutes, which will prevent the recurrence of the three incidents in Q2 that each produced four-plus hours of SLA breach and an estimated $23,000 in credits and remediation engineering time" is the gap between a directional statement that requires a non-technical stakeholder to trust the technical leader's judgment and an investment proposal that the non-technical stakeholder can evaluate against alternatives in the same terms they evaluate every other investment. The investment specification quality determines whether the technical strategy produces commitments that can compete in the allocation process or positions that can be overridden by anyone with a louder external stakeholder. Second, coupling to business outcomes: whether each strategic investment is explicitly coupled to the business outcome it enables or the risk it mitigates, in terms that a non-engineering stakeholder can evaluate independently. This coupling requires the technical leader to do the translation work that non-technical stakeholders cannot do for themselves: the connection between "deployment pipeline modernization" and "reduced time from feature-complete to customer-usable, which is currently the primary constraint on the product team's ability to ship the features committed for H2" is not obvious to a CFO who is deciding whether to approve platform team capacity for a technical investment or for a roadmap feature. The technical leader who has done that translation work in the strategy document has given the CFO the basis for an evaluation; the technical leader who has not done it is asking the CFO to take the investment on technical faith. Third, revision discipline: whether the technical strategy is reviewed and revised when major assumptions change. A strategy built on an assumption that was valid at Series A and invalid at Series B — a microservices bet that was technically feasible at eight engineers and operationally infeasible at eighteen — must be revised when the assumption changes, or the strategy document continues directing engineers toward a direction that has been superseded and continues giving non-technical stakeholders incorrect information about the engineering direction they are funding. The revision discipline is the maintenance component of the investment justification surface: an outdated strategy does not just fail to justify current investments accurately; it justifies investments in directions that have been abandoned, which erodes the technical leader's credibility with non-technical stakeholders over time as the divergence between the strategy document and the actual architecture becomes visible. Connect this to the engineering metrics decision record: the metrics that make the technical strategy's investment justification legible to non-technical stakeholders — mean time to detection, deployment frequency, change failure rate, system availability — are the same metrics the technical strategy's observability and reliability investments are designed to improve; the strategy and the metrics that demonstrate its progress should be designed as a coherent system, because a strategy without instrumented outcomes is a directional statement, and a metrics system without strategic context is a dashboard without interpretation.

The engineering technical strategy ADR: five sections

Section 1: Technical strategy scope and decision classification model. The decision classification model specifies which categories of technical decision require coordination across the engineering organization versus which can be safely delegated to individual engineers or teams. The most consequential decision in this section is where to draw the boundary between coordinated and delegated decisions — a boundary that is too restrictive produces a strategy that is a compliance exercise rather than a direction-setting tool, because every decision requires coordination approval; a boundary that is too permissive produces the API convention divergence described in the first story, where the absence of coordination on cross-cutting decisions accumulates incoherence faster than the engineering leader expects. The classification model should specify at minimum: the cross-cutting categories that require coordination (error handling and status code conventions, logging standards and observability requirements, API design patterns for external-facing interfaces, state management and data access approaches for shared data stores, testing infrastructure choices that affect CI/CD pipeline behavior); the team-local categories that are explicitly delegated (internal algorithm and data structure choices, library selection for non-infrastructure problems, internal API design for services that have no cross-team consumers, testing approach for unit-level behavior that has no cross-team observability implications); and the boundary cases that require judgment (library selection for categories where consistency has integration value — serialization, error handling utilities, HTTP clients — but where team preference has legitimate weight; architectural patterns for new features that will eventually require cross-team integration but do not have it yet). The classification model is not a comprehensive decision catalog; it is a framework that allows any engineer to determine which decision category they are in without having to ask the CTO. The most useful classification models describe the principle that distinguishes coordinated from delegated decisions rather than enumerating every specific decision, because the enumeration will be incomplete at any given time and the principle allows engineers to handle new cases consistently.

Section 2: Technical strategy content model and investment specification. The content model specifies how the technical strategy document is written to produce actionable guidance rather than directional positioning — the difference between a document that engineers and non-technical stakeholders can use to make decisions and a document that describes the CTO's aspirations in terms that require the CTO to be present to interpret. The most consequential decision in this section is the investment specification format: whether technical investments are written as directional priorities or as capacity commitments with specific outcomes. The investment specification format determines the strategy's influence on the allocation decisions that fund technical investments. A directional priority — "invest in observability" — communicates that observability matters; it does not produce a commitment that can be evaluated against alternative uses of the same capacity. A capacity commitment — "eight weeks of platform team in Q2 to reduce mean time to detection below five minutes, eliminating the Q2 SLA breach pattern" — produces a specific investment proposal that can be evaluated against alternatives in the same terms as a product feature commitment. The content model should also specify the revision protocol for the strategy document: the conditions that trigger a revision (major technical bet reversal, significant assumption change, annual review cadence), the revision review process (who reviews and approves revisions), and the change log format (how readers who have previously read the strategy understand what changed between versions and why). The revision protocol prevents the strategy document from becoming an artifact whose reliability is unknown because readers cannot determine whether it reflects current direction or an older version of it. Connect this to the software architecture documentation decision record: the documentation currency model described in that record — the decision about what triggers a documentation update, who is responsible for it, and how the currency of the documentation is communicated to readers — applies directly to the technical strategy document, which is a documentation artifact with the same currency dynamics as architectural documentation: accurate at creation, requiring maintenance discipline to remain accurate, and more dangerous when stale than when absent.

Section 3: Technical strategy accessibility and maintenance model. The accessibility model specifies how the technical strategy is distributed to engineers who were not present when it was made, how it is maintained when circumstances change, and how it is surfaced at the decision points where it is most relevant. The most consequential decision in this section is where in the engineer's workflow the strategy is accessible — whether it requires the engineer to go looking for it or whether it appears at the points where it is relevant. A strategy document in a Notion folder that new engineers are not directed to is a strategy document with no influence on new engineers' decisions. A strategy that appears in the new engineer onboarding checklist, that is referenced in the code review template when a decision touches a strategic direction, and that is linked from the ADR template as the context section's first recommended reading, is a strategy with influence at the specific moments when engineers are making the decisions the strategy is intended to guide. The maintenance model should specify: the owner of the strategy document (typically the CTO or VP of Engineering, with explicit accountability for keeping it current); the review cadence (minimum annual, with out-of-cycle review triggered by significant technical bet changes or major assumption changes); the notification model (how engineers who have previously read the strategy are informed when it changes, so that engineers who made decisions based on an older version of the strategy know to re-evaluate those decisions); and the onboarding integration (how new engineers are introduced to the strategy during onboarding, including a specific mechanism for the new engineer to identify and raise potential inconsistencies between their current work and the strategy direction, since new engineers are often the first to notice divergence that accumulated during their predecessor's tenure). Connect this to the engineering team charter decision record: the charter revision cadence model — the set of triggers that cause a team charter to be reviewed and updated — applies to the technical strategy with similar structure; both documents describe organizational commitments whose validity depends on the assumptions under which they were made, and both require explicit triggers for revision rather than passive accumulation of divergence.

Section 4: Technical strategy and roadmap integration model. The integration model specifies how technical investment commitments in the strategy are integrated into the roadmap and capacity planning processes so they compete with feature work on equal terms rather than existing in a parallel document. The most consequential decision in this section is the integration timing: whether the technical strategy and the product roadmap are integrated before capacity allocation decisions are made or after. If the strategy and roadmap are developed in parallel and brought together only in the roadmap planning session, the allocation decisions about capacity have already been made implicitly by the product roadmap, and the technical investments are competing for capacity that has already been committed. If the strategy and roadmap are integrated before capacity allocation — the technical investment commitments are presented as capacity reservations alongside feature requests in the planning process — the allocation decisions can be made with explicit visibility into the trade-offs between technical investments and feature work. The integration timing is the single design decision with the largest effect on whether the technical strategy has any influence on how the engineering organization's capacity is actually spent. The integration model should also specify the investment priority ordering: not all technical investments are equal, and the strategy should specify which investments are dependencies for other strategic commitments versus which are independent improvements, since an investment that is a dependency (the database migration required before the H2 data-intensive features can be built) has a different priority claim than an investment that improves an existing system (the deployment pipeline modernization that reduces friction but does not gate any roadmap commitment). The dependency investments should be visible to product planners when the roadmap is being built, so that the feature commitments dependent on them can be sequenced correctly rather than discovering the dependency during execution. Connect this to the engineering planning horizon decision record: the planning horizon model determines how far in advance the engineering organization is making technical investment decisions; a technical strategy that specifies annual investments but an engineering planning horizon that operates on a quarterly sprint cycle has an integration gap at every handoff between the annual strategy and the quarterly planning, and closing that gap requires either bringing the strategy's investment commitments into the quarterly planning process or maintaining a rolling technical investment backlog that translates annual strategy priorities into quarterly capacity reservations.

Section 5: Technical strategy accountability and revision cadence. The accountability model specifies who owns the technical strategy, how that owner's accountability for the strategy is measured, and what the process is for revising the strategy when circumstances change. The most consequential decision in this section is the accountability model for strategy-investment coupling: who is accountable for ensuring that technical investments identified in the strategy are funded in the capacity allocation process. Without an explicit accountability owner for strategy-investment coupling, the gap between the strategy document and the actual capacity allocation will be filled by whoever has the strongest external stakeholder relationships — which, in most engineering organizations, is the product team rather than the platform or infrastructure teams whose investments are most commonly de-funded in favor of feature work. The accountability model should specify: the strategy owner (typically the VP of Engineering or CTO, with explicit accountability for the strategy's accuracy and influence); the annual review process (timing, participants, output format, and the specific criterion for revision — what level of divergence between the strategy and the current architecture or business context triggers a revision rather than a note); the quarterly review process (a lighter-weight review that assesses whether the current quarter's capacity allocation is consistent with the strategy's investment commitments, and produces an explicit flag if it is not); and the escalation model (what happens when the strategy's investment commitments are not being funded — who is accountable for raising the gap, in what forum, and with what decision authority). The revision cadence should be treated as a commitment with the same standing as the strategy's investment commitments: a strategy that is not reviewed annually is a strategy whose accuracy is unknown, and an unknown-accuracy strategy has the same influence problem as no strategy, because engineers who have been burned by acting on a stale strategy will stop acting on the strategy at all. Connect this to the open-source extractor: the reasoning behind technical strategy decisions — why the decision classification model draws the boundary where it does between coordinated and delegated decisions, why specific technology bets were made and what assumptions they depend on, why the integration model specifies the specific timing it specifies for strategy-roadmap integration, what the investment priority ordering is and why — is reasoning conducted in AI chat sessions across multiple strategy cycles and leadership transitions and rarely preserved in a form the next CTO or VP of Engineering can inherit; the technical strategy decision record that captures that reasoning is the institutional memory that allows each iteration of the leadership team to understand not just what the strategy says but why — why the classification boundary was drawn here, what would need to change for a specific bet to require revision, and what the integration model is designed to prevent — without having to re-learn those design decisions at the cost of the failure modes that produced them.

FAQ

Why does the absence of a technical strategy produce architecture incoherence faster than most engineering leaders expect?

Architecture incoherence accumulates without a technical strategy because every engineer's prior experience becomes the de facto standard in their area of the codebase, and the prior experiences of different engineers are different in ways that produce inconsistency at every interface. An engineer who has worked primarily at companies using REST with resource-first naming will design their service's API one way; an engineer who has worked primarily at companies using RPC-style REST or GraphQL will design another service's API a different way; a third engineer who has read a recent blog post arguing for action-based URL naming will design a third service's API a third way. None of these choices is individually wrong; they are collectively incoherent, and the incoherence costs compound: new engineers onboard to a codebase where the right approach depends on which part of the system they are working in; cross-team features require reconciling incompatible conventions at every integration point; and the engineering leader who wants to improve consistency has to negotiate with each engineer's prior experience rather than pointing to a documented standard. The absence of a technical strategy is not the absence of a technical direction — every engineering organization has a direction, determined by whoever makes the most technical decisions. The absence of a technical strategy is the absence of a documented, accessible direction that new engineers can read and use to make consistent decisions without needing to ask the CTO. At fifteen engineers, the CTO can communicate direction directly to everyone; at fifty, they cannot, and the direction that was implicit becomes invisible.

What is the most common failure mode of a well-written technical strategy document?

The most common failure mode of a well-written technical strategy document is that it becomes an accurate description of the technical direction at the moment it was written and a progressively less accurate description of that direction in the months and years afterward — not because the strategy was wrong but because the document was never updated when the circumstances that validated the strategy changed. The failure has two components. First, the divergence problem: the strategy describes technical bets and architectural commitments made under specific assumptions; when those assumptions change, the document continues describing the original bet while the actual architecture and team working model drift away from it. Second, the onboarding problem: a strategy document that has diverged from current reality is more dangerous than no strategy document, because it instructs new engineers to make technical decisions based on a direction that has been superseded; the engineer who designs a feature against an event-driven architecture commitment the team quietly abandoned eighteen months ago has built something requiring rework, and the strategy document gave them permission to do so. The combination of divergence and onboarding failure is what makes 'we have a strategy document' sometimes worse than 'we don't have one' — the document exists, the expectation is therefore that it is current, but it is not.

Why do technical investment commitments in strategy documents get systematically de-prioritized against feature work?

Technical investment commitments in strategy documents get systematically de-prioritized against feature work because the two types of work compete for capacity through different mechanisms, and the feature work mechanism produces a forcing function that the technical investment mechanism does not. Feature work enters the prioritization process through customer commitments, sales dependencies, roadmap reviews with product stakeholders, and sprint planning cycles where product managers are present — each creating an external accountability structure. Technical investments enter through the technical strategy document, which has no equivalent external accountability structure. No external stakeholder is waiting for the observability overhaul the way a customer is waiting for the feature. When the platform team's capacity is fully claimed by feature work, the technical investment has no forcing function that gives it the same priority as the external commitment. The structural asymmetry means technical investments are deprioritized not because they are less important but because the prioritization process was not designed to give them equal standing with feature work. Closing the gap requires integrating technical investment commitments into the same capacity planning process as feature work before the roadmap is finalized, so that the investment is treated as a capacity reservation rather than a directional statement.

How do engineering technical strategy decisions connect to AI chat sessions and decision preservation?

Engineering technical strategy decisions are among the organizational design decisions most frequently conducted in AI chat sessions and least frequently preserved in a form that outlasts the person who made them — the CTO working through 'we have four incompatible API design conventions across the codebase and I need to decide which one to standardize on and how to communicate the decision to twelve engineers who each have a different prior experience' is working through a technical strategy question, and the reasoning they produce covers exactly the dimensions that distinguish a coherence-producing strategy from a directional statement: what the classification model is for which decision categories require coordination versus delegation, how to write the strategy so that an engineer who joins six months from now can use it to make consistent decisions, how to specify the architectural investment so that it competes on equal terms with feature work in the capacity planning process. That reasoning is conducted in the AI chat session and rarely preserved anywhere accessible to the next engineering leader who inherits the architecture. Running those sessions through the open-source extractor produces the technical strategy decision record that allows the organization to maintain the reasoning behind its technical direction — not just the strategy itself but why each classification decision was made, why specific architecture bets were placed, and what would need to be true for the strategy to require revision — in a form that survives leadership transitions and that new engineers can read to understand not just what the strategy is but why.

Structural properties set by the engineering technical strategy decision

The engineering technical strategy ADR: five sections

FAQ

Further reading