How should I prioritise and address this technical debt?

{
  "_meta": {
    "schema": "https://www.drawdecisiontree.com/decision-dag.schema.json",
    "source": "https://www.drawdecisiontree.com",
    "description": "DrawDecisionTree.com is a free tool for building, sharing, and embedding interactive decision trees. This file is the machine-readable export of a published decision tree. The `dsl` field contains the original source in the Decision DAG DSL; the `dag` schema is documented at the URL in `schema` above.",
    "links": {
      "interactive": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-tech-debt.html",
      "embed": "https://www.drawdecisiontree.com/embed/path/drawdecisiontree/engineering-tech-debt",
      "dsl_reference": "https://www.drawdecisiontree.com/decision-tree-dsl-reference.html",
      "guides": "https://www.drawdecisiontree.com/guides",
      "schema_docs": "https://www.drawdecisiontree.com/decision-dag.schema.json",
      "author_trees": "https://www.drawdecisiontree.com/trees/drawdecisiontree"
    },
    "generated_at": "2026-05-29T12:05:39.285Z"
  },
  "author": {
    "handle": "drawdecisiontree",
    "first_name": "Andrew",
    "last_name": null,
    "avatar_url": "1d32d828-b6ca-40ec-bdd7-771fe7b9c36a/avatar-1778531481027.svg",
    "display_name": "Andrew"
  },
  "file": {
    "id": "be273510-e545-4e07-ab9b-515c5f74f824",
    "name": "How should I prioritise and address this technical debt?",
    "public_slug": "engineering-tech-debt",
    "updated_at": "2026-05-12T16:53:43.587978+00:00",
    "url": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-tech-debt.html",
    "json_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-tech-debt/tree.json",
    "dsl_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-tech-debt/tree.dag"
  },
  "meta": {
    "description": "Not all technical debt deserves the same response—some debt is blocking and dangerous, some is a low-priority annoyance, and some is a deliberate trade-off worth keeping on the books. This tree helps engineers and tech leads make a consistent, defensible decision about whether to fix immediately, schedule the work, formally accept the debt, or escalate to a broader architectural conversation.",
    "mode": "decision",
    "entry": "Q1",
    "tags": [
      "engineering",
      "tech debt",
      "refactoring",
      "software quality"
    ],
    "image": "https://images.unsplash.com/photo-1605379399642-870262d3d051?w=1200&q=80"
  },
  "questions": [
    {
      "id": "Q1",
      "text": "Is this technical debt actively blocking current development work or causing recurring production incidents?"
    },
    {
      "id": "Q2",
      "text": "Can the fix be completed safely within the current sprint without scope risk to committed deliverables?"
    },
    {
      "id": "Q3",
      "text": "Does this debt have security or compliance implications?"
    },
    {
      "id": "Q4",
      "text": "What is the blast radius if this debt is left unaddressed for the next quarter?"
    },
    {
      "id": "Q5",
      "text": "How does the estimated effort to fix compare to the expected impact on developer productivity or system reliability?"
    }
  ],
  "outcomes": [
    {
      "id": "FIX_NOW",
      "label": "Fix Immediately"
    },
    {
      "id": "SCHEDULE_SPRINT",
      "label": "Schedule in Next Sprint"
    },
    {
      "id": "SCHEDULE_QUARTERLY",
      "label": "Schedule for Quarterly Clean-up"
    },
    {
      "id": "ACCEPT",
      "label": "Accept and Document"
    },
    {
      "id": "ESCALATE",
      "label": "Escalate to Architecture Review"
    }
  ],
  "dsl": "dag: How should I prioritise and address this technical debt?\nversion: 1.0.0\nimage: https://images.unsplash.com/photo-1605379399642-870262d3d051?w=1200&q=80\ndescription: Not all technical debt deserves the same response—some debt is blocking and dangerous, some is a low-priority annoyance, and some is a deliberate trade-off worth keeping on the books. This tree helps engineers and tech leads make a consistent, defensible decision about whether to fix immediately, schedule the work, formally accept the debt, or escalate to a broader architectural conversation.\ntags: engineering, tech debt, refactoring, software quality\nentry: Q1\n\nQ1: Is this technical debt actively blocking current development work or causing recurring production incidents?\n  hint: \"Blocking\" means engineers are working around it daily, it is causing test flakiness that slows CI, or it has triggered at least one production incident in the past 30 days. If the team has developed a stable (if ugly) workaround and velocity is not measurably impacted, it may not meet the bar for \"blocking.\" Be honest—engineers often over-escalate frustrating-but-manageable debt. Recurring workarounds that cost even 30 minutes per engineer per week compound to a significant annual cost and are worth quantifying.\n  yes -> Q2\n  no  -> Q3\n\nQ2: Can the fix be completed safely within the current sprint without scope risk to committed deliverables?\n  hint: Consider the full blast radius of the change: does it touch shared libraries, database schemas, or public API contracts? A fix that looks small but requires coordinated deploys across multiple services or extensive regression testing may not be \"safe\" within a sprint. If there is any doubt, a time-boxed spike to scope the work properly is often a better use of the sprint slot than rushing the fix and introducing a regression on top of the existing debt.\n  yes -> [FIX_NOW]\n  no  -> [ESCALATE]\n\nQ3: Does this debt have security or compliance implications?\n  hint: Examples include outdated cryptographic primitives, dependencies with known CVEs, personally identifiable data stored without adequate controls, missing audit logging, or code that would fail a SOC 2, ISO 27001, or PCI-DSS audit. Even if the risk has not yet been exploited, regulatory and contractual obligations may require a committed remediation timeline. When in doubt, loop in your security or compliance lead before deciding—they may already have a tracking requirement for this issue.\n  yes -> [SCHEDULE_SPRINT]\n  no  -> Q4\n\nQ4: What is the blast radius if this debt is left unaddressed for the next quarter?\n  hint: Think about compounding effects: does this debt make the surrounding code harder to change, increasing the cost of every future feature in that area? Does it sit on a growth path—a module or service likely to receive significant new development in the next two quarters? High-blast-radius debt that lives in frequently changed, foundational code should be treated more urgently than equivalent debt in a stable, rarely touched service at the edge of the system.\n  A: Low — isolated, rarely touched, no compounding effect -> Q5\n  B: Medium — some compounding, touched a few times per quarter -> Q5\n  C: High — blocks future work, sits on a critical path, or compounds quickly -> [SCHEDULE_SPRINT]\n\nQ5: How does the estimated effort to fix compare to the expected impact on developer productivity or system reliability?\n  hint: Use a simple 2x2 framework: low effort and high impact is a no-brainer to schedule; high effort and low impact is a strong accept-and-document candidate. Be rigorous about impact estimates—\"the code will be cleaner\" is not a measurable impact; \"we estimate 2 hours per sprint saved on debugging this module\" is. If you cannot quantify a concrete benefit, the case for scheduling the work over other priorities is weak and it belongs in the accept-and-document bucket.\n  A: Low effort, high impact (clear productivity or reliability win) -> [SCHEDULE_SPRINT]\n  B: High effort, high impact (significant investment needed for meaningful gain) -> [SCHEDULE_QUARTERLY]\n  C: Any effort, low impact (marginal or unquantifiable benefit) -> [ACCEPT]\n\n[FIX_NOW]: Fix Immediately\n  color: #dc2626\n  description: This debt meets the threshold for immediate action because it is actively harming velocity or system reliability right now. Assign the fix to the current sprint and treat it with the same rigour as any production bug: write a clear ticket, define acceptance criteria including test coverage requirements, and require a peer review before merging. Do not skip tests to save time—rushed fixes on already-fragile code are a common source of regressions that create more debt than they resolve. Once merged, add a brief post-fix note to the ticket documenting the root cause and any follow-on hardening work so the context is not lost when the incident fades from memory.\n  code: ENG_TDB_FIX\n\n[SCHEDULE_SPRINT]: Schedule in Next Sprint\n  color: #ea580c\n  description: This debt is significant enough to warrant near-term attention but does not justify disrupting the current sprint's commitments. Create a well-specified ticket this week—while context is fresh—including the problem statement, proposed solution, acceptance criteria, and a rough effort estimate. Add it to the next sprint planning agenda with a named owner so it is actively reviewed rather than passively carried in the backlog. Avoid letting it slip repeatedly: if it is not picked up within two consecutive sprints, escalate to your tech lead to reassess priority. For security-related debt, set a hard completion deadline and communicate it explicitly to your security or compliance stakeholder.\n  code: ENG_TDB_SPRINT\n\n[SCHEDULE_QUARTERLY]: Schedule for Quarterly Clean-up\n  color: #d97706\n  description: This debt is real but not urgent enough to displace near-term delivery priorities given its effort-to-impact ratio. Log it in your team's tech debt backlog with enough detail that a future engineer can understand the context without chasing the original author—include the affected code location, the nature of the problem, the preferred remediation approach, and the reason it was deferred. Nominate it for the next quarterly engineering health sprint or hack week, attached to a measurable outcome. Review the backlog each quarter: debt that remains unaddressed for more than two consecutive quarters should either be escalated or formally accepted; invisible backlogs grow without bound.\n  code: ENG_TDB_QUARTERLY\n\n[ACCEPT]: Accept and Document\n  color: #16a34a\n  description: Formally accepting technical debt is a legitimate and sometimes wise engineering decision, not a failure of discipline. Document the debt clearly in your ADR or inline in the code: what it is, why it was not fixed, what the known risks are, and what the trigger condition would be for revisiting the decision (for example, \"revisit if this module is scheduled for significant new development or if error rates in this area exceed X per day\"). Add an inline comment in the code referencing the decision record so future engineers understand the context and do not waste time re-evaluating the same trade-off. Review accepted debt items annually as part of your architecture health check to confirm the original rationale still holds.\n  code: ENG_TDB_ACCEPT\n\n[ESCALATE]: Escalate to Architecture Review\n  color: #7c3aed\n  description: This debt is both urgent and complex enough that a sprint-level fix carries unacceptable risk without broader design input from engineers who understand the full system. Raise it in your next architecture review or request an ad-hoc session if the urgency warrants it—do not let it sit in a backlog waiting for a scheduled meeting. Come prepared with a written problem statement, a description of the current workaround and its costs, and at least one proposed solution with a rough effort and risk estimate. The architecture review should produce a decision within one week and a concrete remediation plan within two. In the interim, document the workaround formally and notify any teams whose delivery timelines may be affected by the unresolved debt.\n  code: ENG_TDB_ESCALATE\n"
}