El incidente en que le mentí al CTO y evité una crisis

La historia de un desarrollador que le mintió al CTO

• Es una historia de hace algunos años, de cuando trabajaba en una empresa del Fortune 500
• En ese momento, el CTO consiguió un gran proyecto para un cliente importante con quien tenía una relación personal, y decidió tercerizar la parte clave a un gran proveedor de servicios tecnológicos
• Pero el "producto" del vendor en realidad requería una personalización masiva para ajustarse a los requisitos, y esa era la peor opción posible
• En las reuniones de seguimiento con el CTO, nadie pensaba que esta idea fuera buena, pero todos solo decían: "Es una buena idea, jefe"
• Al final, cuando el vendor entregó el "producto", ya era septiembre, y comenzó la marcha forzada para lanzar en octubre
• Durante las pruebas se descubrieron errores graves, como problemas de rendimiento y el choque con el límite de documentos de 16 MB de MongoDB
• Mientras se le decía al cliente que el lanzamiento se retrasaría un mes, al mismo tiempo se decidió iniciar un proyecto secreto para reemplazar la integración del vendor
• Yo era un desarrollador joven y entusiasta, y me asignaron a 3 miembros del equipo para comenzar a desarrollar el sistema alternativo
• A mediados de diciembre, después de casi completar el software alternativo durante el último mes, todos estaban en estado de burnout
• Entonces llegó el CTO y dijo que se cancelarían las vacaciones, y yo respondí: "Entendido"
• Pero recordando el consejo de mi padre, les dije a los miembros del equipo que se fueran de vacaciones y luego asistí solo a la reunión de seguimiento de la marcha forzada con el CTO, donde mentí
  • "El equipo está trabajando duro. Hoy llegamos al punto de integración del hito número 73"
  • "Ayer el equipo avanzó bastante. Terminó otro servicio web"
• Una semana después, los miembros del equipo regresaron descansados, y en enero pudieron lanzar exitosamente a tiempo

La opinión de GN⁺

• Es un caso en el que destaca el liderazgo que llevó el proyecto al éxito incluso en un entorno deficiente y con exigencias excesivas. En particular, es llamativo que se haya prestado atención al estado físico y mental del equipo
• Sin embargo, mentirle al CTO no es deseable. A largo plazo, puede hacer que se pierda la confianza dentro de la organización y provocar problemas mayores
• Aunque gran parte de la responsabilidad por haber fallado en la selección del vendor y en la gestión de la tercerización recae en el CTO, parece que en el proceso para corregirlo habría hecho falta una comunicación más transparente y proactiva
• Para evitar el burnout de los desarrolladores, desde el principio se debió haber establecido un cronograma más realista y asignado suficiente personal. El modo crunch es una práctica que debería evitarse
• Una alternativa útil para tomar como referencia ante situaciones similares es la metodología ágil. Al repetir ciclos cortos de desarrollo y retroalimentación, se pueden minimizar los riesgos y regular mejor la carga de trabajo del equipo

[GN⁺]

Opiniones de Hacker News

• Sobrecarga de trabajo y cancelación de vacaciones:
  • Trabajar en exceso y cancelar vacaciones para cumplir plazos irreales no es una decisión inteligente y termina generando arrepentimiento después
  • Una empresa que depende de que sus empleados sacrifiquen sus vacaciones para entregar el producto está contribuyendo a una cultura laboral problemática
• Empresa sana vs. empresa insana:
  • En una empresa sana, personas con experiencia habrían anticipado los problemas del enfoque de outsourcing y habrían planteado sus preocupaciones desde temprano
  • La comunicación abierta, trabajar juntos para encontrar soluciones y que los managers defiendan el bienestar del equipo son señales de un entorno saludable
  • La historia describe una situación insana en la que un manager le miente repetidamente a sus superiores
• Prácticas absurdas de los vendors:
  • El enfoque del vendor de guardar todas las transacciones en un enorme documento JSON y tener que leerlo completo en cada actualización es ridículo
  • Otro ejemplo es una startup que guardaba los datos de tickets de usuario como columnas adicionales en la tabla de usuarios, creando cientos de columnas
• Situación disfuncional y liderazgo:
  • El enfoque del líder del equipo de mentir sobre las vacaciones es inaceptable y constituye una falta por la que podrían despedirlo
  • Un mejor enfoque sería oponerse a exigencias irracionales de horas extra y defender un alcance de proyecto razonable junto con la responsabilidad del vendor
  • El líder del equipo tiene la responsabilidad de proteger al equipo de exigencias descabelladas, incluso si eso pone en riesgo su propio trabajo
• Nadie sale beneficiado:
  • El vendor entregó baja calidad, el CTO estaba en la ignorancia, los desarrolladores estaban sobrecargados de trabajo y el protagonista dependía de mentiras
  • Es una situación de locura que nadie debería tolerar. Lo deseable es irse a un mejor lugar de trabajo
• Honestidad y transparencia:
  • A algunas personas les ha funcionado bien ser honestas con la dirección sobre problemas técnicos, de rendimiento, cambios de alcance y demás
  • Mentir para cumplir plazos arbitrarios fijados por un liderazgo desconectado no es un buen enfoque
• Brecha de confianza entre desarrolladores y dirección:
  • A menudo existe una asimetría de información y falta de confianza entre los desarrolladores y la dirección no técnica
  • Los managers no pueden evaluar fácilmente el avance y sienten incertidumbre sobre el éxito del proyecto
  • Como el riesgo está del lado del negocio, los desarrolladores tienen que presionar y entregar resultados para cerrar esa brecha de confianza
• Prometer menos y entregar más:
  • Que el protagonista mintiera diciendo que ya había terminado un trabajo que de hecho ya estaba terminado puede verse, hasta cierto punto, como "prometer menos y entregar más"
  • Mentir sobre trabajo no terminado es más riesgoso y puede desmoralizar al equipo cuando tenga que volver sobre ello
• Organizaciones impotentes y herramientas low-code:
  • Las pésimas prácticas del vendor y el alcance modesto del proyecto muestran cuánta impotencia sienten algunas grandes empresas frente a los proyectos de software
  • Esto puede ayudar a explicar la popularidad de herramientas low-code como Retool entre el liderazgo tecnológico, aunque no necesariamente entre los ingenieros
• Integridad y saber decir no:
  • Una verdadera "rockstar" tiene integridad y el valor de rechazar la estupidez y las exigencias irracionales
  • No es responsabilidad de una persona compensar una incompetencia extraordinaria ni cargar con el peso de todo el equipo