Fundamentos de Liderazgo Técnico

9 ejemplos para empezar con Liderazgo Técnico - 7 básicos y 2 intermedios.

Prerrequisitos

• Eres un ingeniero senior o un nuevo líder técnico en un equipo Go con un módulo y un pipeline de CI existentes.
• Asegúrate de que exista la carpeta docs/adr/ o una carpeta de decisiones equivalente, o créala en tu primer PR de liderazgo.
• Lee Liderazgo Técnico en Equipos Go para conocer el alcance antes de ejecutar estos ejercicios.
• Ten acceso para programar una revisión de diseño de 60 minutos y un bloque de mentoría recurrente en el calendario.

Ejemplos Básicos

1. Redacta un esqueleto mínimo de ADR

Captura una decisión antes de que la implementación se extienda.

# ADR 0042: Usar errgroup para fan-out en el worker de ingesta
 
## Estado
Propuesto
 
## Contexto
La fan-out de ingesta utiliza actualmente goroutines desprotegidas; el apagado descarta tareas.
 
## Decisión
Usar golang.org/x/sync/errgroup con cancelación de contexto en internal/ingest.
 
## Consecuencias
+ Retorno de error unificado; - añade dependencia de x/sync.

• Los ADRs necesitan estado, contexto, decisión y consecuencias, no diferencias de implementación.
• Numera secuencialmente; enlaza desde README o docs/adr/README.md.
• Mantenlo propuesto hasta que la reunión de revisión lo apruebe.

Relacionado: Escribir ADRs para Decisiones de Arquitectura Go - plantillas ADR Go clasificadas

2. Indexa ADRs para la incorporación

Haz que las decisiones sean descubribles sin arqueología.

# Registros de Decisiones de Arquitectura
 
| ID | Título | Estado |
|----|-------|--------|
| 0042 | errgroup en worker de ingesta | Aceptado |
| 0041 | Monolito de módulo único | Aceptado |

• El índice es la primera página que leen los nuevos empleados después de los estándares de codificación.
• Valores de estado: Propuesto, Aceptado, Obsoleto, Sustituido.
• Sustituye en lugar de eliminar ADRs antiguos.

Relacionado: Liderazgo Técnico en Equipos Go - por qué los ADRs anclan el liderazgo

3. Ejecuta una agenda de revisión de diseño de 30 minutos

Limita el tiempo de la revisión antes de codificar un nuevo servicio.

## Revisión de Diseño - payments-api v2 (60m)
 
1. Objetivos / no objetivos (5m)
2. Esquema de API + modelo de error (15m)
3. Modelo de datos + migraciones (10m)
4. Modelo de amenazas: authz, PII (15m)
5. Operabilidad: métricas, rollout (10m)
6. Elementos de acción + ¿necesita ADR? (5m)

• Envía el documento con 24 horas de antelación; los revisores comentan asíncronamente cuando es posible.
• Registra los elementos de acción en el ticket, no solo en las notas de la reunión.
• Si la decisión bifurca la arquitectura, abre un ADR antes de fusionar.

Relacionado: Revisiones de Diseño para Servicios Go - manual completo de revisión

4. Añade un comentario de revisión que enseñe

Reemplaza las críticas vagas con justificación y enlaces.

Considera envolver con %w para que los llamadores puedan usar errors.Is para ErrNotFound.
Ver internal/errors/policy.md y ADR 0012.

• Los comentarios de enseñanza hacen referencia a la documentación del equipo, no al gusto personal.
• Bloquea por corrección y operabilidad; deja el estilo para gofmt y los linters.
• Si el mismo comentario aparece tres veces, promuévelo a linter o ADR.

Relacionado: Mentoría de Desarrolladores Go a Través de Niveles de Experiencia - enseñanza a través de la revisión

5. Programa un bloque de mentoría semanal

Reserva tiempo para el crecimiento estructurado.

## Mentoría - Alex (intermedio) - Martes 30m
 
Semana 1: pruebas basadas en tablas en internal/pricing
Semana 2: propagación de contexto en manejadores
Semana 3: co-revisión de PR de concurrencia

• Una agenda supera las "horas de oficina" abiertas para la transferencia de habilidades.
• Vincula cada bloque a un pequeño artefacto: PR de prueba, nota de documento o revisión.
• Rota temas basados en las brechas de la guía de niveles.

Relacionado: Mentoría de Desarrolladores Go a Través de Niveles de Experiencia - planes específicos por nivel

6. Registra un elemento de deuda técnica con impacto

Haz que la deuda sea legible para los socios del producto.

## Deuda: backlog de staticcheck de golangci-lint (42 problemas)
 
Impacto: el ruido de CI oculta defectos reales; los nuevos empleados copian patrones suprimidos.
Costo: 2 días de ingeniero
Propuesta: quemar en el sprint 12 con un 20% de capacidad
Propietario: @lead

• Los tickets de deuda necesitan impacto en el cliente o en la velocidad, no solo "limpieza".
• Talla en días para que la planificación pueda intercambiar contra características.
• Asigna un propietario; la deuda sin propietario nunca se envía.

Relacionado: Backlogs de Deuda Técnica para Bases de Código Go - marco de priorización

7. Facilita un desacuerdo con límite de tiempo

Cierra un debate de modismos con un resultado registrado.

## Decisión: router HTTP para notificaciones (45m)
 
Opciones: stdlib ServeMux vs chi
Criterios: necesidades de middleware, política solo stdlib, familiaridad del equipo
Decisión: chi solo para notificaciones; ADR 0043 documenta la excepción
Fecha de revisión: 2026-Q4

• Enumera opciones, criterios, decisión y fecha de revisión en el ticket.
• Una excepción documentada supera las bifurcaciones silenciosas por servicio.
• Escala solo cuando los criterios entren en conflicto con la política de la empresa.

Relacionado: Manejo de Desacuerdos Técnicos en Equipos Go - patrones de facilitación

Ejemplos Intermedios

8. Planifica una actualización menor de Go con notas de radio de explosión

Lidera el cambio de herramientas en todos los servicios.

go mod edit -go=1.26
go test ./...
go fix ./...
golangci-lint run ./...

## Plan de actualización Go 1.25 -> 1.26
 
- Imágenes de CI: actualizar .github/workflows + Dockerfile
- Notable: GC por defecto Green Tea; ejecutar prueba de carga en checkout
- Reversión: revertir etiqueta de imagen; directiva go de go.mod sin cambios hasta que esté en verde

• Ejecuta go test y linters en cada módulo afectado.
• Anota los cambios de comportamiento (GC, verificaciones de vet) en el documento de implementación.
• Empareja la actualización con un bloque de horas de oficina para preguntas del escuadrón.

Relacionado: Backlogs de Deuda Técnica para Bases de Código Go - deuda de módulos y herramientas

9. Define el estatuto de iniciativa de alcance de personal

Amplía la influencia sin perder la responsabilidad de entrega.

## Estatuto: biblioteca compartida de middleware HTTP
 
Problema: métricas de autenticación duplicadas en 4 servicios
Éxito: 3 servicios migrados; pruebas de middleware doradas en CI
No objetivos: reemplazo de framework; contenedor DI para toda la organización
Patrocinador: TL de plataforma; Cronograma: Q3

• El trabajo de estilo de personal requiere un problema, métricas de éxito y no objetivos explícitos.
• Envía una implementación de referencia que los consumidores puedan copiar.
• Mide la adopción, no solo las líneas de código compartido.

Relacionado: Ruta de Ingeniero de Personal en Organizaciones Go - expectativas de alcance e influencia

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