Leadership Best Practices
A condensed summary of the 25 most important technical leadership practices for Rust specialists - drawn from every page in this section.
-
Write options before advocating one: Ranked trade-offs prevent framework religion - Technical Decision-Making.
-
ADR for costly-to-reverse choices: Framework, queue, DB, edition bump,
unsafepolicy. -
Supersede ADRs, never delete: Audit trail and learning preserved - Architecture Decision Records (ADRs).
-
RFC before large PRs: Cross-team schema and async migrations need design review - Running Design Reviews.
-
Assign skeptic and operator reviewers: Stress-test and on-call impact mandatory.
-
Time-box design meetings 45 minutes: Decide accept, revise, or spike.
-
Link spikes to RFC open questions: Evidence before opinion wars.
-
PR template includes intent and rollback: Reviewers focus on risk - Code Review Culture.
-
Comment tiers: must fix, should fix, nit: Nits are not blockers.
-
Automate style with rustfmt/clippy in CI: Humans review design and correctness.
-
Rotate code reviewers: Spread context; avoid single gatekeeper.
-
Small PRs under 400 LOC: Deep review beats shallow giant diffs.
-
Buddy new hires 90 days: Shadow on-call before solo pages - Mentoring & Leveling.
-
Leveling rubric with Rust examples: Promotion evidence is behavioral.
-
Mob complex refactors weekly: Migrations and
unsafeaudits. -
Delegate outcomes, not tasks: Brief includes authority and constraints - Delegation & Spreading Context.
-
Rotate release captain and CODEOWNERS: Reduce bus factor quarterly.
-
Module ownership in README: On-call knows who to ping.
-
Disagreement log in RFC appendix: Falsifiable "what would change your mind."
-
Name decision maker upfront: End circular PR threads - Handling Technical Disagreements.
-
2-3 day spikes settle evidence disputes: Binary success criteria required.
-
Disagree and commit publicly: No passive sabotage post-decision.
-
Record dissent in ADR consequences: Revisit triggers documented.
-
IC decides during SEV1: Process debate waits for post-mortem.
-
Protect 10-20% mentor time: Sustainable leadership beats heroics.
FAQs
How much should tech leads code?
30-50% early team; 20-30% at scale - stay credible in Rust reviews.
Tech lead vs staff engineer?
Lead owns squad delivery; staff owns cross-fleet architecture - roles can overlap.
When skip RFC?
Single-crate bugfix and reversible config; not for schema or unsafe.
Lead approves every deploy?
No - release captain rotates; lead reviews exceptions and CFR trends.
Conflict with EM?
EM owns people and timeline; lead owns technical bar - escalate jointly to director if stuck.
Remote leadership?
Written RFCs, recorded design summaries, explicit decision logs.
Measure leadership impact?
CFR, review latency, bus factor metric, promotion pipeline health.
Lead IC on every incident?
Rotate; lead coaches IC, does not default to hero mode.
When hire second lead?
Two squads or >10 engineers under one product area.
Rust guild?
Biweekly optional; shares incidents, crates, and ADR learnings fleet-wide.
Related
- Technical Decision-Making - decisions
- Product Collaboration Best Practices - stakeholder side
- Governance Best Practices - fleet rules
- Career Growth - path
- Delivery Best Practices - shipping
Stack versions: This page was written for Rust 1.97.0 (edition 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, and Polars 0.46+.