Melhores Práticas de Liderança Técnica

Hábitos sustentáveis de liderança para equipes de plataforma Go.

Estas regras destilam a orientação de liderança técnica desta seção em hábitos que você pode impor em calendários, fóruns de planejamento e cultura de revisão.

Como Usar Esta Lista

• Marque os itens à medida que sua organização os adota; lacunas se tornam ações para retrospectivas ou planejamento trimestral.
• Atribua um responsável por grupo (líder técnico, staff, plataforma).
• Revise após atualizações da toolchain Go ou grandes coortes de contratação.
• Emparelhe com as páginas da seção para justificativa, modelos e exemplos.

A - Escopo e presença

• Líderes técnicos ainda enviam PRs de produção regularmente. Credibilidade supera coordenação pura.
• Bloqueios de calendário protegem revisões de design e mentoria. Liderança não agendada se decompõe em combate a incêndios.
• Estatutos de staff nomeiam métricas de sucesso e não-metas. Influência sem escopo se torna ruído.
• Rotacione a propriedade do caminho crítico. Um único líder técnico herói é um fator de risco (bus factor).
• Participe do plantão (on-call) ou revisão de incidentes. Dor operacional informa o backlog e os ADRs.
• Delegue a calibração de revisão para engenheiros seniores. Líderes definem o padrão, não cada aprovação.

B - Decisões e documentação

• Divergências significativas obtêm ADRs antes de grandes implementações. Módulos, concorrência, formato de deploy se qualificam.
• Mantenha um índice de ADRs pesquisável. Novos contratados começam por lá após os padrões de código.
• Substitua ADRs em vez de excluir histórico. Auditorias e onboarding precisam de linhagem.
• Revisões de design precedem novos binários e APIs principais. Envie a documentação com 24 horas de antecedência.
• Modele ameaças de autorização e PII em revisões. APIs internas não são implicitamente confiáveis.
• Vincule PRs a ADRs ou documentos de design quando o escopo justificar. Impede arquitetura apenas retroativa.

C - Revisão e barra de qualidade

• Ensine em comentários de revisão com justificativa e links. "Não idiomático" sem o porquê erode a confiança.
• Bloqueie por race conditions, erros ignorados e exports quebrados. Bom gosto cede lugar a linters.
• Exija -race em alterações de pacotes concorrentes. Testes verdes que não detectam race conditions são insuficientes.
• Promova o terceiro "nit" repetido para linter ou ADR. Humanos param de repetir o mesmo comentário.
• Segundo revisor em PRs sensíveis à concorrência e segurança. Estado mutável compartilhado merece olhos extras.
• Autores anexem evidências de CI nas descrições de PR. A revisão começa a partir de fatos.

D - Mentoria e crescimento

• Sessões de mentoria usam agendas e artefatos semanais. PRs, testes ou notas de documentação - não horários de escritório vagos.
• Combine exercícios com as faixas do guia de níveis. Juniores em testes; intermediários em contexto; seniores em design.
• Rotacione duplas de mentoria mensalmente. Múltiplas vozes de revisão reduzem o viés de um único mentor.
• Faça pair programming em concorrência antes da propriedade primária do plantão. Desligamento e cancelamento são ensináveis.
• Engenheiros staff ensinam líderes técnicos, não apenas juniores. Habilidades de liderança escalam através dos líderes.
• Registre resultados trimestrais de mentoria para calibração. Evidências alimentam pacotes de promoção.

E - Dívida técnica, toolchain e plataforma

• Itens de backlog de dívida técnica incluem impacto e responsável. Dívida sem responsável nunca é agendada.
• Reserve capacidade de sprint para dívida (frequentemente 15-25%). Negocie com o produto usando linguagem de risco.
• Planeje upgrades menores do Go com notas de raio de explosão (blast radius). Mudanças de GC e vet precisam de validação de carga.
• Acompanhe pins de módulos e diretivas de substituição como dívida. Versões ocultas bloqueiam a resposta a CVEs.
• A política do golangci-lint é curada, não máxima. Bloqueie merge primeiro por linters de correção.
• Bibliotecas de plataforma são entregues com exemplos e guias de migração. Métricas de adoção superam contagens de LOC.

F - Desacordos e alinhamento

• Debates técnicos usam opções, critérios e um responsável pela decisão. Evite enquetes intermináveis no Slack.
• Registre resultados de "discordar e comprometer" em ADRs. Notas de dissidência são bem-vindas; desvios silenciosos não são.
• Limite o tempo de reuniões de decisão (frequentemente 45 minutos). Adie com data de revisão quando faltarem dados.
• Documente exceções de stdlib vs. framework. Consistência supera otimização local.
• Escalone decisões inter-equipes para sponsors staff ou arquiteto. Líderes de squad não definem silenciosamente a política da organização.
• Revise decisões em cronograma ou com novas evidências. Substitua ADRs em vez de reversão informal.

FAQs

Relacionados

• Liderança Técnica em Equipes Go - visão geral conceitual do escopo de liderança
• Noções Básicas de Liderança Técnica - exercícios práticos para novos líderes
• Escrevendo ADRs para Decisões de Arquitetura Go - modelos de ADR
• Revisões de Design para Serviços Go - manual de revisão
• Mentoria de Desenvolvedores Go em Diferentes Níveis de Experiência - planos de mentoria
• Backlogs de Dívida Técnica para Bases de Código Go - priorização de dívida

Versões de Stack: Esta página foi escrita para Go 1.26.x (GC padrão Green Tea, go fix modernizers - verifique o patch na compilação), chi (última versão - verifique na compilação), gin (última versão - verifique na compilação), echo (última versão - verifique na compilação), google.golang.org/grpc (última versão - verifique na compilação), sigs.k8s.io/controller-runtime (última versão - verifique na compilação), kubebuilder (última versão - verifique na compilação), tinygo (última versão - verifique os alvos de placa na compilação), wazero (última versão - verifique na compilação) e golangci-lint (última versão - verifique o conjunto de linters na compilação).