Mejores Prácticas de Liderazgo Técnico

Hábitos sostenibles de liderazgo para equipos de plataforma Go.

Estas reglas destilan la guía de liderazgo técnico de esta sección en hábitos que puedes aplicar en calendarios, foros de planificación y cultura de revisión.

Cómo Usar Esta Lista

• Marca los elementos a medida que tu organización los adopte; las brechas se convierten en acciones para retrospectivas o planificación trimestral.
• Asigna un propietario por grupo (líder técnico, staff, plataforma).
• Revisa después de las actualizaciones de la cadena de herramientas de Go o de cohortes importantes de contratación.
• Combina con las páginas de sección para obtener justificación, plantillas y ejemplos.

A - Alcance y presencia

• Los líderes técnicos aún envían PRs de producción regularmente. La credibilidad supera la coordinación pura.
• Los bloques de calendario protegen las revisiones de diseño y la mentoría. El liderazgo no programado se convierte en extinción de incendios.
• Las cartas de staff nombran métricas de éxito y no objetivos. La influencia sin alcance se convierte en ruido.
• Rota la propiedad de la ruta crítica. Un solo líder técnico héroe es un factor de riesgo.
• Participa en la guardia o en la revisión de incidentes. El dolor operativo informa el backlog y las ADR.
• Delega la calibración de revisiones a los seniors. Los líderes establecen el listón, no cada aprobación.

B - Decisiones y documentación

• Las bifurcaciones significativas obtienen ADRs antes de una implementación grande. Los módulos, la concurrencia, la forma de despliegue califican.
• Mantén un índice de ADR buscable. Los nuevos empleados comienzan allí después de los estándares de codificación.
• Anula las ADR en lugar de eliminar el historial. Las auditorías y la incorporación necesitan linaje.
• Las revisiones de diseño preceden a los nuevos binarios y APIs importantes. Envía la documentación con 24 horas de antelación.
• Modela amenazas de autorización y PII en las revisiones. Las APIs internas no se confían implícitamente.
• Vincula los PRs a la ADR o al documento de diseño cuando el alcance lo justifique. Detiene la arquitectura solo retrospectiva.

C - Revisión y barra de calidad

• Enseña en los comentarios de revisión con justificación y enlaces. "No idiomático" sin el porqué erosiona la confianza.
• Bloquea las carreras (races), los errores ignorados y las exportaciones rotas. El buen gusto cede a los linters.
• Requiere -race en cambios de paquetes concurrentes. Las pruebas no de carrera (non-race) verdes son insuficientes.
• Promueve el tercer nit repetido a linter o ADR. Los humanos dejan de repetir el mismo comentario.
• Segundo revisor en PRs concurrentes y sensibles a la seguridad. El estado mutable compartido merece más atención.
• Los autores adjuntan evidencia de CI en las descripciones de PR. La revisión comienza a partir de hechos.

D - Mentoría y crecimiento

• Las sesiones de mentoría usan agendas y artefactos semanales. PRs, pruebas o notas de documentación, no horas de oficina vagas.
• Empareja ejercicios con las bandas de la guía de niveles. Juniors en pruebas; intermedios en contexto; seniors en diseño.
• Rota los compañeros de mentoría mensualmente. Múltiples voces de revisión reducen el sesgo de un solo mentor.
• Haz pair programming en concurrencia antes de la propiedad principal de guardia. El apagado y la cancelación son enseñables.
• Los ingenieros de staff enseñan a los líderes técnicos, no solo a los juniors. Las habilidades de liderazgo escalan a través de los líderes.
• Registra los resultados trimestrales de mentoría para calibración. La evidencia alimenta los paquetes de promoción.

E - Deuda, cadena de herramientas y plataforma

• Los elementos del backlog de deuda técnica incluyen impacto y propietario. La deuda sin propietario nunca se programa.
• Reserva capacidad de sprint para deuda (a menudo 15-25%). Negocia con el producto usando lenguaje de riesgo.
• Planifica las actualizaciones menores de Go con notas de radio de explosión. Los cambios de GC y vet necesitan validación de carga.
• Rastrea los pines de módulos y reemplaza las directivas como deuda. Las versiones ocultas bloquean la respuesta a CVE.
• La política de golangci-lint es curada, no máxima. Bloquea la fusión en linters de corrección primero.
• Las bibliotecas de plataforma se envían con ejemplos y guías de migración. Las métricas de adopción superan los recuentos de LOC.

F - Desacuerdos y alineación

• Los debates técnicos usan opciones, criterios y un propietario de la decisión. Evita encuestas interminables en Slack.
• Registra los resultados de "discrepar y comprometerse" en las ADR. Las notas de disidencia son bienvenidas; las bifurcaciones silenciosas no.
• Limita el tiempo de las reuniones de decisión (a menudo 45 minutos). Posponer con fecha de revisión cuando falten datos.
• Documenta las excepciones de stdlib vs framework. La consistencia supera la optimización local.
• Escala las decisiones inter-equipos a sponsors de staff o arquitectos. Los líderes de escuadrón no establecen políticas de organización silenciosamente.
• Revisa las decisiones según el cronograma o nueva evidencia. Anula las ADR en lugar de la reversión informal.

Preguntas Frecuentes

Relacionado

• Liderazgo Técnico en Equipos Go - resumen conceptual del alcance del liderazgo
• Conceptos Básicos de Liderazgo Técnico - ejercicios prácticos para nuevos líderes
• Escribir ADRs para Decisiones de Arquitectura Go - plantillas de ADR
• Revisiones de Diseño para Servicios Go - manual de revisiones
• Mentoría de Desarrolladores Go a Través de Niveles de Experiencia - planes de mentoría
• Backlogs de Deuda Técnica para Bases de Código Go - priorización de deuda

Versiones de Stack: Esta página fue escrita para Go 1.26.x (Green Tea GC por defecto, go fix modernizers - verifica el parche en la compilación), chi (última - verifica en la compilación), gin (última - verifica en la compilación), echo (última - verifica en la compilación), google.golang.org/grpc (última - verifica en la compilación), sigs.k8s.io/controller-runtime (última - verifica en la compilación), kubebuilder (última - verifica en la compilación), tinygo (última - verifica los objetivos de placa en la compilación), wazero (última - verifica en la compilación) y golangci-lint (última - verifica el conjunto de linters en la compilación).