Melhores Práticas de Liderança
Um resumo condensado das 25 práticas mais importantes de liderança técnica para especialistas em Rust - extraídas de todas as páginas desta seção.
-
Escreva opções antes de defender uma: Trade-offs classificados evitam fanatismo por framework - Tomada de Decisão Técnica.
-
ADR para escolhas custosas de reverter: Framework, fila, DB, atualização de edição, política de
unsafe. -
Substitua ADRs, nunca delete: Trilha de auditoria e aprendizado preservados - Registros de Decisão de Arquitetura (ADRs).
-
RFC antes de grandes PRs: Esquema entre equipes e migrações assíncronas precisam de revisão de design - Realizando Revisões de Design.
-
Atribua revisores céticos e operadores: Teste de estresse e impacto on-call obrigatórios.
-
Reuniões de design com tempo limite de 45 minutos: Decida aceitar, revisar ou fazer um spike.
-
Vincule spikes a perguntas abertas de RFC: Evidências antes de guerras de opinião.
-
Modelo de PR inclui intenção e rollback: Revisores focam no risco - Cultura de Revisão de Código.
-
Níveis de comentário: deve corrigir, deveria corrigir, nit: Nits não são bloqueadores.
-
Automatize estilo com rustfmt/clippy em CI: Humanos revisam design e correção.
-
Rotacione revisores de código: Espalhe contexto; evite um único gatekeeper.
-
Pequenos PRs abaixo de 400 LOC: Revisão profunda supera diffs gigantes rasos.
-
Acompanhe novos contratados por 90 dias: Faça shadow no on-call antes de páginas solo - Mentoria e Nivelamento.
-
Rubrica de nivelamento com exemplos em Rust: Evidência de promoção é comportamental.
-
Reúna refatorações complexas semanalmente: Migrações e auditorias de
unsafe. -
Delegue resultados, não tarefas: O briefing inclui autoridade e restrições - Delegação e Disseminação de Contexto.
-
Rotacione o capitão de lançamento e CODEOWNERS: Reduza o fator ônibus trimestralmente.
-
Propriedade de módulo no README: O on-call sabe quem contatar.
-
Log de discordâncias no apêndice da RFC: "O que mudaria sua opinião" falseável.
-
Nomeie o tomador de decisão antecipadamente: Encerre threads de PR circulares - Lidando com Discordâncias Técnicas.
-
Spikes de 2-3 dias resolvem disputas de evidências: Critérios de sucesso binários são necessários.
-
Discorde e comprometa publicamente: Sem sabotagem passiva pós-decisão.
-
Registre dissidência nas consequências da ADR: Gatilhos de revisitados documentados.
-
IC decide durante SEV1: Debate de processo espera pelo post-mortem.
-
Proteja 10-20% do tempo de mentoria: Liderança sustentável supera heroísmo.
FAQs
Quanto um líder técnico deve codificar?
30-50% no início da equipe; 20-30% em escala - mantenha a credibilidade nas revisões de Rust.
Líder técnico vs. engenheiro staff?
O líder é responsável pela entrega da squad; o staff é responsável pela arquitetura entre frotas - os papéis podem se sobrepor.
Quando pular a RFC?
Correção de bug em crate único e configuração reversível; não para esquema ou unsafe.
Líder aprova todo deploy?
Não - o capitão de lançamento é rotativo; o líder revisa exceções e tendências de CFR.
Conflito com EM?
O EM é responsável pelas pessoas e cronograma; o líder é responsável pelo padrão técnico - escale conjuntamente ao diretor se estiver travado.
Liderança remota?
RFCs escritas, resumos de design gravados, logs de decisão explícitos.
Medir o impacto da liderança?
CFR, latência de revisão, métrica de fator ônibus, saúde do pipeline de promoção.
Líder IC em todo incidente?
Rotacione; o líder treina o IC, não assume o modo herói por padrão.
Quando contratar um segundo líder?
Duas squads ou >10 engenheiros em uma área de produto.
Guilda de Rust?
Quinzenal opcional; compartilha incidentes, crates e aprendizados de ADR em toda a frota.
Relacionados
- Tomada de Decisão Técnica - decisões
- Melhores Práticas de Colaboração com Produto - lado do stakeholder
- Melhores Práticas de Governança - regras da frota
- Crescimento na Carreira - caminho
- Melhores Práticas de Entrega - envio
Versões de Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.