Tecnología
- Exigir que se reescriba el sistema central durante 6 a 18 meses. Culpar al CTO anterior.
- Fomentar que cada quien use un lenguaje y framework distinto.
- Dividir el sistema con límites arbitrarios para que muchas partes del sistema estén involucradas en cada funcionalidad.
- Crear un entorno de desarrollo complejo. Hacer que se ejecute una malla de servicios con al menos 12 servicios incluidos.
- Hacer que el entorno de producción y el entorno de los desarrolladores sean lo más diferentes posible.
- Hacer despliegues lo menos frecuente posible. Recomendar extrema cautela con cada despliegue.
- Introducir procesos muy complejos para cambios de código y para el flujo de trabajo general. Poner como excusa la "seguridad" o el "cumplimiento".
- Registrar todo el trabajo en un rastreador de tareas y hacer que un grupo de al menos 5 personas lo revise, lo priorice y lo apruebe.
- Prohibir todo lo que quede fuera del alcance original del trabajo. Por ejemplo, prohibir limpieza de código u otras mejoras.
- Construir internamente casi todo lo que no sea una capacidad central. Justificarlo con "para evitar la dependencia del proveedor".
- Insistir en agregar una capa de abstracción a todo. Usar proveedores abstraídos y agregar capas de abstracción adicionales.
- Fomentar decisiones técnicas basadas en una escala irrealmente optimista. Planear al menos 3 veces la carga actual.
- Fomentar la copropiedad de los sistemas. Hacer que nadie sienta responsabilidad por el mantenimiento.
- Insistir en centralizar casi todo como una "plataforma". Mantener al equipo de plataforma con poco personal y evitar que otros equipos construyan lo que la plataforma podría llegar a poseer.
- Hacer que el equipo de plataforma itere sus APIs con frecuencia y obligar a los demás equipos a refactorizar su código hacia la versión más reciente.
- Contratar "arquitectos" y exigir una "revisión de arquitectura" hasta para cambios pequeños.
- Exigir una "revisión de seguridad" incluso para cambios pequeños.
Producto
- Ignorar métricas útiles por razones académicas. Por ejemplo, llamarlas "sesgadas" o "indicadores rezagados".
- Elegir métricas de vanidad que no se relacionen con el valor de negocio. Elegir métricas ruidosas.
- Tratar todo como una "gran apuesta" e insistir en no lanzar nada hasta que todo esté completamente terminado.
- Considerar que todas las funciones son "imprescindibles" y partes críticas de la "versión cero". No ceder jamás.
- Desarrollar planes "estratégicos" extremadamente detallados.
- Cambiar de dirección con frecuencia.
- Descartar mejoras evidentes como "optimización local".
- Amarrar recursos a la última tendencia. Iniciar una "estrategia de IA" superficialmente convincente. Gastar mucho dinero en proveedores y consultores para ello.
- Fomentar que los gerentes de producto dediquen la mayor parte de su tiempo a la "estrategia" y la "planeación".
- Hacer que a ingenieros y gerentes de producto les resulte difícil o imposible usar el producto internamente.
- Desestimar internamente a los usuarios como "idiotas".
Liderazgo
- Vincular las recompensas a los títulos y al tamaño del equipo para fomentar la inflación.
- Hablar en grande sobre estrategia, funcionalidades o complejidad técnica.
- Hacer adquisiciones costosas para entrar en nuevas áreas de producto. Mencionar "sinergia". Desechar el producto adquirido.
- Usar muchas líneas punteadas en la estructura de reportes.
- Hacer que la mayor cantidad posible de personas reporte a gerentes de otros equipos, ubicaciones o funciones. Hacer que los gerentes no puedan supervisar a sus reportes.
- Reubicar con frecuencia a las personas de bajo desempeño a otros equipos.
- Asignar a las personas de alto desempeño a proyectos de I+D muy especulativos con resultados inciertos.
- Exigir reuniones para hasta las decisiones más triviales.
- Insistir en que todos los "stakeholders" deben asistir a las reuniones.
Contratación
- Crear un proceso de contratación que parezca objetivo pero que en realidad sea subjetivo.
- Rechazar al mejor talento por "falta de encaje cultural" u otros criterios vagos.
- Contratar al candidato más débil por su "potencial", "actitud" u otros criterios vagos.
- Contratar líderes senior muy costosos con grandes compromisos de headcount.
- Usar títulos inflados y roles inventados para atraer oportunistas.
- Contratar "especialistas" muy especializados y luego crear proyectos artificiales para que no renuncien.
- Usar la especialización como justificación para contratar a otra persona complementaria.
Gestión de proyectos
- Exigir estimaciones extremadamente detalladas para todos los proyectos.
- Fomentar proyectos que atraviesen tantos equipos como sea posible, idealmente equipos en distintas ubicaciones.
- Agregar nuevos requisitos que dependan del trabajo realizado por otros equipos.
- Usar agencias costosas con frecuencia. Mantener el alcance ambiguo y pasar prototipos inconclusos al equipo interno para que los termine.
- Construir sistemas complejos de "autoservicio" para stakeholders de otros equipos.
Resultado
- Reducir la productividad es difícil. Pero si aterrizas en paracaídas detrás de las líneas enemigas y consigues trabajo como CTO, puedes lograrlo.
- Para las personas no destructivas: esto trata sobre cómo sacar el máximo de productividad de un equipo. La productividad se construye a partir de muchas cosas pequeñas.
- Si 100 cosas pequeñas imponen cada una un impuesto de productividad del 5%, todo se vuelve 131 veces más lento. Para mantener felices a los ingenieros, hay que rechazar 100 pequeñas cosas plausibles y aparentemente razonables.
Opinión de GN⁺
- Este artículo explica de manera humorística varias formas de perjudicar la productividad en el desarrollo de software. A través de ello, deja claro qué comportamientos deben evitarse en la práctica.
- Es importante reducir la deuda técnica y mantener una cultura de desarrollo eficiente. La clave es evitar la complejidad innecesaria y la burocracia.
- Es importante crear un entorno que eleve la moral del equipo y fomente la colaboración. Esto impacta directamente en la mejora de la productividad.
- Este artículo ayuda a entender la complejidad de la ingeniería de software y de la gestión. En particular, ofrece ideas útiles para ingenieros junior.
- Entre otros proyectos similares está el libro "The Phoenix Project", que trata sobre cómo mejorar la eficiencia en TI y DevOps.
11 comentarios
¿Hay alguna empresa que no haga eso? T_T
Parece que incluso las empresas pequeñas y exitosas, cuando crecen, terminan volviéndose así...
Parece que ahí están incluidas la mayoría de las cosas que me ordenaron en mi empresa anterior: obligarnos a usar plataformas que ni siquiera sirven, ignorar métricas estándar de rendimiento, volver a pedir tareas que ya se habían hecho, etc.
Eh..?
Esto es totalmente "Cómo programar para que sea difícil de mantener: tú también puedes vivir del cuento toda la vida como desarrollador"...
Me iré a la mierda.
Ay... ¡ay!... ¡aaah!... ¡ah!... aa......
Es una pena ver que varias de estas cosas también aparecen dentro de nuestra organización. snif
Me recuerda al libro legendario "Cómo programar para que sea difícil de mantener".
¡Yo también este libro!
Puede que pienses: “¿Tanto así?”, pero me da la impresión de que una sola persona o una sola organización podría lograr todo lo anterior.^^
Comentarios de Hacker News
Falta de certeza sobre si la propuesta de la CIA realmente funcionó: Nunca he visto una razón convincente para creer que la propuesta original de la CIA realmente haya funcionado, y las organizaciones tienden naturalmente a ignorar a ese tipo de personas.
Cómo arruinar una empresa: Promover a gente incompetente a puestos de gestión y hacer que optimicen cosas no rentables puede golpear muy duro a una empresa.
Cómo convertirse en un CTO destructivo: Es fácil no hacer casi nada, eliminar a la gente competente y fomentar una cultura de trasladar la responsabilidad hacia abajo.
Trabajo a través de canales oficiales y exigencia de órdenes por escrito: Para algunas personas, trabajar a través de canales oficiales y exigir órdenes por escrito puede ser más productivo.
La diferencia entre la OSS y la CIA: La OSS (Office of Strategic Services) produjo un gran libro durante la Segunda Guerra Mundial, y la CIA se fundó en 1947.
La importancia de la visión: El paso más importante es eliminar a las personas que tienen una visión coherente de cómo funciona el producto en su conjunto o de un futuro mejor.
Hace falta actualizar la sección de contratación: Es necesario exigir que se resuelvan problemas difíciles de Leetcode en 30 minutos y no tolerar la incertidumbre ni la duda.
La diferencia entre el entorno de producción y el de los desarrolladores: En la arquitectura moderna hay tantos servicios externos que el entorno de producción y el de desarrollo inevitablemente son distintos, lo que significa que los desarrolladores siempre deben estar conectados a internet.
Decisiones para protegerse a uno mismo: Muchas decisiones de "sabotaje" tienen que ver con convencer a la gente de que uno está intentando encubrir sus propios errores.
Las "mejores prácticas" en la empresa: Las ocho reglas presentadas al inicio del artículo se siguen estrictamente en la empresa como "mejores prácticas".
El comportamiento de los consultores: Muchos consultores hacen la mayoría de estas cosas, o incluso todas.
Problemas en la industria tecnológica: En la industria tecnológica hay mucha gente que actúa así, y creen que están ayudando.
Experiencia en grandes empresas: Mi experiencia limitada en grandes empresas coincide muchísimo con lo que dice este texto.