Technical Leadership Best Practices

Sustainable leadership habits for Go platform teams.

These rules distill technical leadership guidance in this section into habits you can enforce in calendars, planning forums, and review culture.

How to Use This List

• Tick items as your org adopts them; gaps become retro or quarterly planning actions.
• Assign an owner per group (tech lead, staff, platform).
• Revisit after Go toolchain bumps or major hiring cohorts.
• Pair with section pages for rationale, templates, and examples.

A - Scope and presence

• Tech leads still ship production PRs regularly. Credibility beats pure coordination.
• Calendar blocks protect design reviews and mentoring. Unscheduled leadership decays into firefighting.
• Staff charters name success metrics and non-goals. Influence without scope becomes noise.
• Rotate critical-path ownership. One hero tech lead is a bus factor.
• Participate in on-call or incident review. Operational pain informs backlog and ADRs.
• Delegate review calibration to seniors. Leads set bar, not every approval.

B - Decisions and documentation

• Significant forks get ADRs before large implementation. Modules, concurrency, deploy shape qualify.
• Maintain a searchable ADR index. New hires start there after coding standards.
• Supersede ADRs instead of deleting history. Audits and onboarding need lineage.
• Design reviews precede new binaries and major APIs. Send docs 24 hours early.
• Threat model authz and PII in reviews. Internal APIs are not implicitly trusted.
• Link PRs to ADR or design doc when scope warrants. Stops retro-only architecture.

C - Review and quality bar

• Teach in review comments with rationale and links. "Not idiomatic" without why erodes trust.
• Block on races, ignored errors, and breaking exports. Taste yields to linters.
• Require -race on concurrent package changes. Green non-race tests are insufficient.
• Promote third repeated nit to linter or ADR. Humans stop repeating the same comment.
• Second reviewer on concurrency and security-sensitive PRs. Shared mutable state deserves extra eyes.
• Authors attach CI evidence in PR descriptions. Review starts from facts.

D - Mentoring and growth

• Mentoring sessions use agendas and weekly artifacts. PRs, tests, or doc notes - not vague office hours.
• Match exercises to leveling guide bands. Juniors on tests; mids on context; seniors on design.
• Rotate mentoring buddies monthly. Multiple review voices reduce single-mentor bias.
• Pair on concurrency before primary on-call ownership. Shutdown and cancellation are teachable.
• Staff engineers teach tech leads, not only juniors. Leadership skills scale through leads.
• Record quarterly mentoring outcomes for calibration. Evidence feeds promotion packets.

E - Debt, toolchain, and platform

• Tech debt backlog items include impact and owner. Unowned debt never schedules.
• Reserve sprint capacity for debt (often 15-25%). Negotiate with product using risk language.
• Plan Go minor upgrades with blast-radius notes. GC and vet changes need load validation.
• Track module pins and replace directives as debt. Hidden versions block CVE response.
• golangci-lint policy is curated, not maximal. Gate merge on correctness linters first.
• Platform libraries ship with examples and migration guides. Adoption metrics beat LOC counts.

F - Disagreements and alignment

• Technical debates use options, criteria, and a decision owner. Avoid endless Slack polls.
• Record disagree-and-commit outcomes in ADRs. Dissent notes welcome; silent forks are not.
• Time-box decision meetings (often 45 minutes). Defer with review date when data missing.
• Document stdlib-vs-framework exceptions. Consistency beats local optimization.
• Escalate cross-team decisions to staff or architect sponsors. Squad leads do not silently set org policy.
• Revisit decisions on schedule or new evidence. Supersede ADRs instead of informal reversal.

FAQs

Related

• Technical Leadership in Go Teams - conceptual overview of leadership scope
• Tech Leadership Basics - hands-on exercises for new leads
• Writing ADRs for Go Architecture Decisions - ADR templates
• Design Reviews for Go Services - review playbook
• Mentoring Go Developers Across Experience Levels - mentoring plans
• Tech Debt Backlogs for Go Codebases - debt prioritization

Stack versions: This page was written for Go 1.26.x (Green Tea GC default, go fix modernizers - verify patch at build), chi (latest - verify at build), gin (latest - verify at build), echo (latest - verify at build), google.golang.org/grpc (latest - verify at build), sigs.k8s.io/controller-runtime (latest - verify at build), kubebuilder (latest - verify at build), tinygo (latest - verify board targets at build), wazero (latest - verify at build), and golangci-lint (latest - verify linter set at build).