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
-raceon 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
How many best practices should a new tech lead adopt first?
Start with ADR index, design review cadence, mentoring blocks, and debt backlog visibility - four foundations.
Can small teams skip staff practices?
Yes - fold charter and cross-team items into tech lead scope until second squad appears.
How often revisit this list?
Quarterly retro or after Go upgrade / hiring spike.
Who owns platform library best practices?
Staff or platform tech lead with consumer team representatives in review.
What if product rejects debt capacity?
Translate to incident risk and CVE exposure days; escalate with staff sponsor data.
Should best practices be enforced by CI only?
CI handles lint and tests; leadership habits still need calendars and facilitation.
How measure leadership best practice adoption?
ADR usage in onboarding, review latency, debt burn-down, mentoring artifact completion, middleware adoption.
Do these apply to contractor tech leads?
Yes for decisions and review; adjust mentoring continuity if engagement is short.
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).