Leadership Best Practices
A condensed summary of the 25 most important technical leadership practices for Python 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, Python major version.
-
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 Ruff 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 Python examples: Promotion evidence is behavioral.
-
Mob complex refactors weekly: Migrations and typing overhauls.
-
Delegate outcomes, not tasks: Brief includes authority and constraints - Delegation & Spreading Context.
-
Rotate release captain and CODEOWNERS: Reduce bus factor quarterly.
-
Module ownership in docstring: 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% hands-on for working leads; rest on review, design, and unblocking.
When skip RFC?
Small vertical slices, no schema change, single squad, under two engineer-days.
How balance velocity and quality?
Error budget and DORA trends inform freeze; never silent quality drop.
Lead vs staff responsibilities?
Lead owns squad delivery; staff spans squads and standards - see governance career page.
Remote leadership differences?
Written RFC/ADR first; over-communicate decisions in public channels.
How handle underperforming delegate?
Manager partnership; adjust scope and pairing - not public blame.
Python-specific leadership focus?
Typing adoption, async safety, packaging standards, and ML governance literacy.
How often calibration?
Quarterly with engineering manager; align levels across squads.
When tech lead says no to product?
With data: risk, estimate, alternative - Product Collaboration.
How measure leadership impact?
Team CFR, review latency, bus-factor map, promotion readiness pipeline.
Related
- Technical Decision-Making - ranked decisions
- Architecture Decision Records (ADRs) - decision log
- Running Design Reviews - RFC process
- Mentoring & Leveling - grow the team
- Career Growth: Senior to Lead - long-term path
Stack versions: This page was written for Python 3.14.0 (stable 3.14, maintenance 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, and uv 0.6+.