← Technical Lead: decisions, quality, and team
10 / 10 · 60 MIN

Technical debt, mentoring, and cross-team decisions

Distinguish effort from duration, expose assumptions, and develop autonomy through observable evidence.

Separate capacity, effort, and benefit

A fictional intervention costs 24 repair hours and twelve migration hours. If it removes five weekly hours of rework, it recovers 36 hours after 7.2 weeks of savings in the model. This break-even point is not the delivery date. With only six weekly hours reserved for execution, implementation requires six weeks, excluding queues and dependencies. Savings begin only when the change produces its expected effect. If benefit varies between three and six weekly hours, effort return varies between twelve and six weeks. Present these assumptions separately to the sponsor. Do not convert saved hours into guaranteed money or overlook migration work. After the change, compare observed rework with the estimate using a consistent window and definition. A technically completed task may not have removed the cause of manual effort. The calculation supports discussion; it is not a financial forecast.

Make decisions with visible assumptions

A storage prototype respects the memory limit under sequential access. Integration will require random queries that have not been tested. Writing “option validated” extends the conclusion to an unobserved use. In the proposed record, identify the assumption, limited confidence, owner, and experiment that may change the choice. A reproducible negative result is also useful when it answers the spike question. It should not be hidden because it produced no feature. If architecture has temporary and final phases, record each phase’s decisions with links and transition conditions. A planned date does not establish that the adapter was removed. When the platform cannot support required log retention, present options to platform and requirement owners; do not turn the technical limitation into a unilateral commitment change. Retain enough context for a later reader to understand what the team actually knew.

Develop reviewers through bounded tasks

A matrix declares that Ana and Rui know the module. Ana is unavailable, and Rui has never assessed the new access control. A populated cell does not demonstrate competence in that specialty. Start with a concrete task: ask Rui to assess inputs in an importer prepared for learning, identify two known defects, and justify a question requiring specialist support. Define available support and observe reasoning instead of counting only approvals or session attendance. If the colleague does not understand the problem, repeating “bring a proposal” can preserve the blockage. Work through an example and ask for an explanation of the next step. Positive feedback should also teach: identify the failure caught by the new test and when that criterion applies. Extend delegation from observed results while retaining boundaries for risks not yet practiced. This exercise provides bounded development evidence rather than an external certification.

Facilitated session and observation criteria

Prepare a 30-minute session with three roles: author, reviewer, and observer. During the first five minutes, the author presents the per-row rule and mixed diff from the earlier case. For ten minutes, the reviewer organizes assessment and requests evidence; the observer records whether the reviewer separates a demonstrated defect, preference, and missing specialty. Introduce a post-review modification and allow five minutes for an English handover. Reserve the final ten minutes to explain debt, capacity, and return to the fictional sponsor. Each participant should produce an annotated sequence, a handover note, and a decision with an open assumption. The rubric observes scope clarity, links between requirements and evidence, consistent units, and appropriate escalation. Use the previous lesson’s script to check only arithmetic and declared fields. This session has been designed but has not been performed with human participants; local results do not replace professional observation.

36 / 6 = 6 weeks of reserved execution capacity
36 / 5 = 7.2 weeks of savings after the effect begins
36 / 6 to 36 / 3 = 6 to 12 weeks of savings under the stated range
IN PRACTICE

36 effort hours, six available weekly hours, and three to six weekly benefit hours represent different measures with different sponsor implications.

Common pitfalls

Confusing delivery duration with return; treating a declared matrix as competence; hiding a negative prototype; extending approval beyond evidence.

Related topics: Decision records · Skill development

Take this idea with you

Expose assumptions and observe performance on bounded tasks before extending commitments or delegation.

Create account

Reference: Collaborate with workload and platform teams · Google Engineering Practices, SRE and DORA; Microsoft architecture decision and collaboration guidance; OWASP threat modeling; UK lead developer framework; inspected 2026-10-01