Mejores Prácticas de Liderazgo
Los líderes técnicos de Solana se sitúan entre auditores, producto, comunidad e ingenieros que envían programas de Anchor a las 2 AM. Estas prácticas mantienen alta la calidad sin convertirse en el cuello de botella del equipo.
Cómo Usar Esta Lista
- Autoevaluarse mensualmente como líder técnico o EM
- Usar en 1:1s con ingenieros que aspiran a liderar
- Emparejar con métricas DORA e de incidentes para obtener resultados
A - Juicio Técnico
- Cada decisión irreversible tiene una ADR dentro de las 48 horas. Sin conocimiento tribal.
- Revisiones de diseño programadas antes de grandes PRs en
programs/. Revisor de seguridad asignado. - Spikes con tiempo limitado a 72 horas. Los datos terminan los debates de arquitectura.
- Versiones de stack fijadas en el manual del equipo. Agave 4.1.1, Anchor 0.32.1, kit 7.0.0.
- Tickets de deuda técnica visibles en el roadmap. No solo "sprints de limpieza" ocultos.
B - Personas y Crecimiento
- SLA de revisión cumplido para los PRs de los reportes directos. O se nombra un revisor delegado explícito.
- Los juniors presentan una RFC por trimestre. Desarrolla músculo de comunicación.
- Respaldo de runbook asignado para cada ruta crítica. Factor autobús > 1.
- Facilitación sin culpa post-incidente. El líder no asigna culpa personal.
- Rúbrica de nivelación compartida y utilizada en promociones. Crecimiento basado en evidencia.
C - Equilibrio de Entrega
- El lanzamiento go/no-go incluye checklist de seguridad y operaciones. No solo la fecha del producto.
- Desacuerdo y compromiso con la disidencia en la ADR. Sin resistencia pasiva.
- Proteger el 20% de la capacidad para incidentes no planificados. Especialmente TVL pre-mainnet.
- Delegar despliegues en devnet antes de la temporada de mainnet. Fortalecer la reserva.
- Decir no al alcance con compensación escrita. Ofrecer una porción más pequeña y entregable.
D - Partes Interesadas Externas
- Auditor comprometido temprano con el paquete de RFC. No un volcado de PDF al final.
- Comunicaciones comunitarias alineadas con hechos de ingeniería. Sin promesas antes de la ADR.
- Actualizaciones ejecutivas: métricas, no jerga. DORA + tendencia de incidentes trimestralmente.
- Alcance del bug bounty publicado pre-mainnet. Reduce informes caóticos.
- Las relaciones de RPC de proveedores tienen un propietario designado. No "quien tenga la clave API".
Preguntas Frecuentes
¿Líder técnico vs ingeniero staff?
El líder es responsable de la entrega + personas; el staff es responsable de la profundidad de la arquitectura inter-equipos - los roles pueden superponerse en startups.
¿Todavía codificando?
Objetivo del 30-50% de manos a la obra pre-PMF; cambiar a revisión/arquitectura a medida que el equipo crece.
¿Señales de agotamiento?
Cada PR espera por ti; saltarse la mentoría; temer las páginas de incidentes - delegar el sprint.
¿Líder técnico que no usa Rust?
Posible con un fuerte líder de cliente/operaciones + un socio arquitecto de programas senior.
¿Medir el liderazgo?
DORA del equipo, MTTR de incidentes, SLA de revisión, retención, diversidad del pipeline de promociones.
¿Conflicto con el fundador?
ADR + memo de riesgo; escalar con un marco de seguridad del usuario.
¿Liderazgo remoto?
Comunicar en exceso las decisiones escritas; tiempo adicional asíncrono para RFC.
¿Cuándo volver a ser IC?
Cambio de rol explícito; no abandonar las responsabilidades de liderazgo a mitad de trimestre.
¿Liderar a través de zonas horarias?
Guardia "follow-the-sun"; horas de solapamiento solo para RFC.
¿Primera semana como líder?
Leer todas las ADRs, ejecutar simulacro de incidente, conocer los objetivos de carrera de cada ingeniero.
Relacionado
- Toma de Decisiones Técnicas - marcos de decisión
- Delegación y Difusión de Contexto - reducir el cuello de botella
- Mejores Prácticas de Entrega - excelencia en lanzamientos
Versiones de stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.