Team & Onboarding Best Practices
Shared portable guidance across SME tracks.
These rules distill onboarding, pairing, review, documentation, and leveling guidance in this section into habits you can enforce in tickets, 1:1s, and engineering calendars.
How to Use This List
- Tick items as your team adopts them; use gaps as retro action items.
- Tie each rule to an owner (manager, buddy, or platform).
- Revisit quarterly after toolchain bumps or hiring cohorts.
- Pair with section pages for rationale and examples.
A - Ramp and milestones
- Assign a named buddy before day one. Ramp fails when hires guess who to ping.
- Run the 30/60/90 checklist with dated evidence. Merged PR links beat vague "on track" updates.
- Match Go version locally to CI on day one. Prevents first-week toolchain churn.
- Require first merged PR in week one. Docs or tests are valid; process learning is the goal.
- Use Effective Go Reading Path blocks, not random blogs. Order reduces gaps in errors and concurrency.
- Compress ramp for Go-experienced hires, not culture-experienced. Team norms still need proof.
B - Pairing and teaching
- Schedule structured pairing sessions with agendas. 90 minutes with debrief notes, not ad-hoc screen share.
- Rotate driver and navigator every 20-30 minutes in mobs. Keeps engagement and spreads skill.
- Run
go test -racein concurrency pairing exits. Green non-race tests are insufficient. - End sessions with one follow-up PR or ticket. Verbal agreement without artifacts fades.
- Rotate buddies after month one. Hires absorb multiple review voices.
- Record decisions, not full sessions, unless policy allows. Written follow-up respects privacy and async teammates.
C - Code review culture
- Authors paste CI proof in PR descriptions. Reviewers start from facts, not assumptions.
- Block on races, ignored errors, and unapproved breaking exports. Taste nits yield to linters.
- Teach with rationale and doc links. Comments like "not idiomatic" without why erode trust.
- Promote repeated nits to golangci-lint or ADRs. Third repetition means automation or documented exception.
- Require second reviewer on concurrency changes. Shared mutable state deserves extra eyes.
- Target first review response within one business day. Latency silently stalls ramps.
D - Documentation and standards
- Comment every exported symbol starting with its name. godoc is the reference surface.
- Keep one package comment per package in doc.go or designated file. Avoid duplicate package blocks.
- Add Example functions for libraries consumed by other teams. Executable docs catch drift in CI.
- Separate godoc from runbooks. Operators need wikis with paging links; godoc holds API contracts.
- Update comments when behavior changes. Stale docs are defects, not debt to defer forever.
- Point hires to coding standards and ADR index in week one. Reduces repeated review themes.
E - Leveling and career clarity
- Share leveling guide during onboarding retro at day 60. Aligns hire and manager on expectations.
- Evaluate scope and teaching, not syntax trivia, at senior bands. Promotion signals are multi-package impact.
- Staff impact shows in multi-team idioms and durable teaching. One project heroics are insufficient alone.
- Calibration uses evidence over quarters. Single PRs do not make a level.
- Seniors own buddy assignments and exemplar PR curation. Review culture scales through modeling.
FAQs
How is this different from the 30/60/90 checklist?
The checklist is a hire-specific scorecard with dates. This page is team policy any engineer can apply or audit.
Can small teams skip formal buddies?
Even two-person teams should name a default reviewer-teacher. Bus factor and inconsistent idioms appear quickly.
What if hiring is paused?
Reuse pairing and review rules for internal transfers and contractors. Onboarding patterns help any new-to-team engineer.
Should managers track every checkbox?
Managers track A and E categories; tech leads own B-D in most orgs. Split ownership keeps lists actionable.
How do these practices interact with agent skills?
Agent skills operationalize review and audit steps. Human onboarding still needs pairing and judgment calibration from this section.
Minimum viable subset for startups?
Items: buddy, week-one PR, CI version match, review response SLA, and export godoc. Add 30/60/90 when headcount exceeds five Go engineers.
How often update best practices?
After each hiring cohort retro or Go minor release affecting toolchain defaults.
Do contractors follow the same list?
Yes for B-D during engagement. A and E may end at handoff milestones instead of day 90 promotion talk.
Where do HR processes fit?
HR owns compliance and benefits. This list covers engineering outcomes only.
Can we copy items to other SME sites?
Yes. Pairing, review, and documentation rules transfer; replace Go-specific tooling references as needed.
Related
- Onboarding Go Specialists - ramp mental model
- Go SME Onboarding Checklist (30/60/90) - hire scorecard
- Team Onboarding Basics - first-week runnable examples
- Code Review Culture for Go - review norms in depth
- Leveling Guide: Junior to Staff in Go - career signals
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).