Hyman Rickover es probablemente el gestor de proyectos más influyente del que nunca has oído hablar. En los años 50, lideró el desarrollo del primer submarino nuclear estadounidense, el USS Nautilus, en un proyecto sin precedentes técnicos, con plazos imposibles y bajo presión política extrema. Lo que aprendió entonces sigue siendo extraordinariamente aplicable a los proyectos de software y producto digital de hoy.
01Responsabilidad sin excusas
Rickover no aceptaba delegación de la responsabilidad. Si algo fallaba en el submarino, el responsable del área rendía cuentas — sin importar si la causa estaba en un proveedor, en otro equipo o en una decisión política. Esta actitud parece dura, pero es la única que genera equipos que realmente se preocupan por la calidad del resultado.
En Kanban esto se traduce en tener responsables claros para cada tipo de trabajo y para cada bloqueo. La visualización del tablero hace que sea imposible esconder la responsabilidad detrás de ambigüedades.
02Conocimiento técnico en profundidad
Rickover exigía que los líderes del proyecto entendieran los detalles técnicos. No podían gestionar desde la distancia: tenían que saber lo suficiente para hacer las preguntas incómodas. Este principio contrasta con el modelo de manager como puro coordinador que prevalece en muchas organizaciones.
03Simplicidad en el diseño
Ante la complejidad, Rickover buscaba siempre la solución más simple que funcionara. Cada componente añadido era una fuente de fallo potencial. En desarrollo de software, esto se traduce en la preferencia por arquitecturas simples, código limpio y reducción de dependencias — principios que Kanban refuerza al hacer visible el coste real de la complejidad.
04Redundancia en los sistemas críticos
Un submarino nuclear no puede fallar. Rickover diseñaba sistemas críticos con redundancia: si un componente fallaba, otro tomaba el relevo automáticamente. En los equipos de producto, esto se traduce en documentación, conocimiento compartido y prácticas de pair programming que evitan los cuellos de botella de conocimiento.
05Aprendizaje sistemático de los errores
Cada incidente en el programa nuclear generaba un análisis formal y una mejora de proceso. No buscaban culpables — buscaban causas sistémicas. Esto es exactamente lo que hace una buena retrospectiva o un post-mortem de incidente bien facilitado.
06Estándares sin compromisos
Rickover no aceptaba "suficientemente bueno" en sistemas de seguridad crítica. El estándar era el estándar, sin excepciones. En Kanban, la Definición de Done (borrowed from Scrum) o los criterios de salida de cada columna cumplen esta función: hacer explícitos los estándares de calidad y no dejar que la presión de entrega los erosione.