Tech Leadership Basics
9 examples to get you started with Tech Leadership - 7 basic and 2 intermediate.
Prerequisites
- You are a senior engineer or new tech lead on a Go team with an existing module and CI pipeline.
- Ensure
docs/adr/or equivalent decision folder exists, or create it in your first leadership PR. - Read Technical Leadership in Go Teams for scope before running these exercises.
- Have access to schedule a 60-minute design review and a recurring mentoring block on the calendar.
Basic Examples
1. Draft a minimal ADR skeleton
Capture a decision before implementation spreads.
# ADR 0042: Use errgroup for fan-out in ingest worker
## Status
Proposed
## Context
Ingest fan-out today uses naked goroutines; shutdown drops tasks.
## Decision
Use golang.org/x/sync/errgroup with context cancellation in internal/ingest.
## Consequences
+ Unified error return; - adds dependency on x/sync.- ADRs need status, context, decision, and consequences - not implementation diffs.
- Number sequentially; link from README or
docs/adr/README.md. - Keep proposed until review meeting approves.
Related: Writing ADRs for Go Architecture Decisions - ranked Go ADR templates
2. Index ADRs for onboarding
Make decisions discoverable without archaeology.
# Architecture Decision Records
| ID | Title | Status |
|----|-------|--------|
| 0042 | errgroup in ingest worker | Accepted |
| 0041 | Single module monolith | Accepted |- The index is the first page new hires read after coding standards.
- Status values: Proposed, Accepted, Deprecated, Superseded.
- Supersede rather than delete old ADRs.
Related: Technical Leadership in Go Teams - why ADRs anchor leadership
3. Run a 30-minute design review agenda
Time-box review before coding a new service.
## Design Review - payments-api v2 (60m)
1. Goals / non-goals (5m)
2. API sketch + error model (15m)
3. Data model + migrations (10m)
4. Threat model: authz, PII (15m)
5. Operability: metrics, rollout (10m)
6. Action items + ADR need? (5m)- Send the doc 24 hours early; reviewers comment async when possible.
- Record action items in the ticket, not only meeting notes.
- If the decision forks architecture, open an ADR before merge.
Related: Design Reviews for Go Services - full review playbook
4. Add a review comment that teaches
Replace vague nits with rationale and links.
Consider wrapping with %w so callers can use errors.Is for ErrNotFound.
See internal/errors/policy.md and ADR 0012.- Teaching comments reference team docs, not personal taste.
- Block on correctness and operability; defer style to
gofmtand linters. - If the same comment appears three times, promote to linter or ADR.
Related: Mentoring Go Developers Across Experience Levels - teaching through review
5. Schedule a weekly mentoring block
Protect time for structured growth.
## Mentoring - Alex (mid) - Tuesdays 30m
Week 1: table-driven tests on internal/pricing
Week 2: context propagation in handlers
Week 3: co-review concurrency PR- Agenda beats open-ended "office hours" for skill transfer.
- Tie each block to a small artifact: test PR, doc note, or review.
- Rotate topics based on leveling guide gaps.
Related: Mentoring Go Developers Across Experience Levels - level-specific plans
6. Log a tech debt item with impact
Make debt legible to product partners.
## Debt: golangci-lint staticcheck backlog (42 issues)
Impact: CI noise hides real defects; new hires copy suppressed patterns.
Cost: 2 engineer-days
Proposal: burn down in sprint 12 at 20% capacity
Owner: @lead- Debt tickets need customer or velocity impact, not only "cleanup."
- Size in days so planning can trade against features.
- Assign an owner; unowned debt never ships.
Related: Tech Debt Backlogs for Go Codebases - prioritization framework
7. Facilitate a time-boxed disagreement
Close an idioms debate with a recorded outcome.
## Decision: HTTP router for notifications (45m)
Options: stdlib ServeMux vs chi
Criteria: middleware needs, stdlib-only policy, team familiarity
Decision: chi for notifications only; ADR 0043 documents exception
Review date: 2026-Q4- List options, criteria, decision, and review date in the ticket.
- One documented exception beats silent per-service forks.
- Escalate only when criteria conflict with company policy.
Related: Handling Technical Disagreements on Go Teams - facilitation patterns
Intermediate Examples
8. Plan a Go minor upgrade with blast-radius notes
Lead toolchain change across services.
go mod edit -go=1.26
go test ./...
go fix ./...
golangci-lint run ./...## Upgrade plan Go 1.25 -> 1.26
- CI images: update .github/workflows + Dockerfile
- Notable: Green Tea GC default; run load test on checkout
- Rollback: revert image tag; go.mod go directive unchanged until green- Run
go testand linters on every module affected. - Note behavior changes (GC, vet checks) in the rollout doc.
- Pair upgrade with a office-hours block for squad questions.
Related: Tech Debt Backlogs for Go Codebases - module and toolchain debt
9. Define staff-scope initiative charter
Widen influence without losing delivery accountability.
## Charter: shared HTTP middleware library
Problem: duplicated auth metrics across 4 services
Success: 3 services migrated; golden middleware tests in CI
Non-goals: framework replacement; org-wide DI container
Sponsor: platform TL; Timeline: Q3- Staff-style work needs problem, success metrics, and explicit non-goals.
- Ship a reference implementation consumers can copy.
- Measure adoption, not only lines of shared code.
Related: Staff Engineer Path in Go Organizations - scope and influence expectations
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).