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 gofmt and 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 test and 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).