- Las empresas gastan mucho para alcanzar capacidades operativas como la capacidad de manufactura al estilo Toyota, la calidad six-sigma o la cadena de suministro al estilo Dell, pero es raro que los programas de mejora se traduzcan en desempeño sostenido
- TQM fue un caso que, tras usarse ampliamente durante un tiempo, perdió terreno rápidamente; menos del 10% de las empresas Fortune 1000 tenía un programa TQM bien desarrollado
- La causa del fracaso no está tanto en la elección de una herramienta específica, sino en la forma en que el nuevo programa se acopla con estructuras físicas, económicas, sociales y psicológicas; al final, la mejora se vuelve un problema de sistemas
- Cuando la brecha de desempeño crece, las organizaciones eligen entre Work Harder, trabajar más tiempo, y Work Smarter, desarrollar capacidades, pero esta última opción suele quedar relegada por las demoras y el riesgo de fracaso
- Los Shortcuts, que reducen el tiempo dedicado a mejorar, son atractivos porque elevan la producción a corto plazo, pero si la degradación de capacidades que aparece tarde se acumula, pueden atrapar a la organización en una Capability Trap
La paradoja de los programas de mejora que fracasan
- Las empresas invierten activamente en mejora de procesos para desarrollar capacidades operativas como manufactura, calidad, comprensión del cliente y gestión de la cadena de suministro
- En 1997, el gasto combinado de las empresas estadounidenses en consultores de gestión y capacitación fue de más de 100.000 millones de dólares, y una parte considerable se destinó a alcanzar las capacidades operativas de empresas líderes
- Pese a algunos éxitos espectaculares, muchos programas de mejora no generan resultados significativos
- TQM ilustra bien esta paradoja
- Impulsado por el éxito de las empresas japonesas en la década de 1980, se volvió muy popular entre las empresas estadounidenses
- A mediados de la década de 1990, el interés de la academia y de los medios de negocios disminuyó, y fue desplazado por nuevas innovaciones como la reingeniería
- Las empresas que se comprometieron seriamente con la disciplina y los métodos de TQM obtuvieron mejor desempeño que sus competidores
- En un estudio, menos del 10% de las empresas Fortune 1000 tenía un programa TQM bien desarrollado
- En otro estudio, TQM fue la tercera herramienta de negocios más usada en 1993, pero cayó al puesto 14 en 1999
- Las técnicas de mejora del pasado a veces reaparecen con otro nombre
- Las disciplinas centrales del control estadístico de procesos y la reducción de variabilidad continuaron en six-sigma
- Los quality circles pasaron a llamarse high-performance work teams
Lo más difícil no son las herramientas, sino la estructura de implementación
- Las herramientas y técnicas de mejora del desempeño crecieron rápidamente, y el aumento de las tecnologías de la información y de los consultores también hizo más fácil aprender qué técnicas usa quién
- Para la mayoría de los gerentes, la mayor barrera no es conocer un nuevo método, sino implementarlo con éxito en el trabajo cotidiano
- Capacidades como un programa de calidad six-sigma no pueden comprarse como productos llave en mano; deben desarrollarse dentro de la organización
- Durante más de una década se realizaron más de 12 estudios de caso en profundidad en industrias de telecomunicaciones, semiconductores, química, petróleo, automotriz y productos de ocio
- Se usaron observaciones, entrevistas con participantes, materiales de archivo e indicadores cuantitativos
- También se desarrollaron modelos para capturar la dinámica de la implementación y la mejora
- La razón por la que la mayoría de las organizaciones no obtiene todo el beneficio de las innovaciones de mejora tiene muy poca relación con la elección de una herramienta de mejora específica
- Un nuevo programa de mejora opera donde se entrelazan herramientas, equipos, trabajadores, gerentes y estructuras físicas, económicas, sociales y psicológicas, por lo que se vuelve un problema sistémico
La física básica de la mejora: tiempo y capacidad
- El desempeño real de un proceso está determinado por el tiempo dedicado a trabajar (Time Spent Working) y la capacidad del proceso (Capability) para realizar ese trabajo
- En manufactura, la producción neta utilizable se determina por el producto entre las horas de trabajo diarias y la productividad, es decir, la producción utilizable por hora de trabajo
- El desempeño puede elevarse trabajando más o invirtiendo más en mejora, pero los resultados de ambos enfoques son distintos
- Si las horas de trabajo semanales aumentan 20%, la producción puede aumentar 20% mientras se mantengan las horas extra
- Mejorar la capacidad del proceso eleva la producción de todas las horas de trabajo que se inviertan después
- Las horas extra para retrabajar productos defectuosos aumentan la producción solo mientras continúen, pero eliminar la causa raíz de los defectos reduce de forma sostenida la necesidad de retrabajo
- La capacidad se trata como un stock, un activo que se acumula con el tiempo
- El tiempo dedicado a la mejora aumenta la inversión en capacidad
- Como toma tiempo encontrar causas raíz y descubrir, probar e implementar soluciones, hay una demora entre las actividades de mejora y los cambios en la capacidad
- La capacidad que no se mantiene con regularidad se deteriora por desgaste de máquinas, desviaciones de proceso, obsolescencia del diseño y procedimientos desactualizados
- Las demoras de mejora dependen de la complejidad técnica y organizacional del proceso
- En procesos relativamente simples, como el rendimiento de máquinas en un job shop, las demoras de mejora son del orden de meses
- En procesos complejos como el desarrollo de productos, las demoras de mejora pueden ser de años o más
- En organizaciones con altas tasas de cambio de productos y personal, la vida útil de las capacidades mejoradas también se acorta
La tensión entre Work Harder y Work Smarter
- La dirección establece objetivos como demanda de clientes, volumen de procesamiento de reclamos de seguros o número de nuevos productos lanzados por trimestre como Desired Performance
- La diferencia entre el desempeño real y el objetivo se convierte en la Performance Gap, y en las organizaciones estudiadas era raro encontrar procesos que superaran las expectativas
- En organizaciones reacias a ampliar recursos o contratar más personal, hay dos opciones básicas para cerrar la brecha de desempeño
-
Bucle Work Harder
- Cuando hay una brecha de desempeño, los gerentes aumentan la presión de trabajo mediante mayor velocidad de trabajo, horas extra, objetivos más agresivos o penalizaciones por no cumplir metas
- Formas más sutiles, como la frecuencia de las revisiones de desempeño, el nivel de detalle de las revisiones y el rango de quienes revisan, también forman parte de la presión de trabajo
- En una empresa, un vicepresidente sénior revisaba el desempeño de cada máquina en la planta, lo que se convirtió en el mensaje de mantener las máquinas funcionando a cualquier costo
- Un gerente de proyecto, al atrasarse el cronograma del subsistema a su cargo, recibió la exigencia de llamar cada hora para reportar el estado hasta que el prototipo cumpliera las especificaciones
-
Bucle Work Smarter
- Los gerentes pueden intentar elevar la capacidad del proceso iniciando programas de mejora, alentando la experimentación con nuevas ideas e invirtiendo en capacitación
- Si tienen éxito, con el tiempo la capacidad mejora, el volumen de procesamiento aumenta y la brecha de desempeño se reduce
- La inversión en mejora puede generar un efecto mayor a largo plazo, pero hay una demora considerable hasta que se ven los efectos y también existe el riesgo de fracasar al descubrir causas raíz o aplicar nuevas herramientas
- En problemas urgentes, Work Harder suele ser la opción elegida
- Si se detiene una línea de manufactura que atiende a un cliente importante, es fácil que el gerente opte por volver a poner la línea en marcha y empujar horas extra hasta terminar los envíos, en lugar de capacitar en mejora de confiabilidad
- Si después de la respuesta temporal no se vuelve a las actividades de mejora, trabajar más duro se convierte en el modo operativo estándar
Bucle de reinversión y trampa de capacidad
- Como las organizaciones tienen pocos recursos ociosos, cuando aumenta la presión de trabajo las personas reducen actividades no laborales, como el descanso, y aumentan las horas extra
- Las horas extra de los trabajadores del conocimiento a menudo se extienden sin pago a noches y fines de semana, quitando tiempo a la familia y a las actividades comunitarias
- Cuando el tiempo ya no puede ampliarse más, no queda más opción que reducir el tiempo de mejora para atender una brecha de desempeño que sigue creciendo
-
Bucle Reinvestment
- Si la inversión en mejora tiene éxito, el desempeño sube y la brecha de desempeño disminuye, lo que permite dedicar más tiempo a la mejora y genera un círculo virtuoso
- En cambio, si se responde a la brecha de volumen con presión de trabajo, el tiempo de mejora se reduce, la capacidad se deteriora y la brecha de desempeño crece aún más, lo que lleva a mayor presión de trabajo y menos mejora: un círculo vicioso
- En casos de mejora exitosos, los recursos liberados por el aumento de productividad se asignan explícitamente de nuevo a actividades de mejora, reforzando el proceso de reinversión
- En muchas organizaciones, la presión de costos y cronogramas lleva a downsizing o a metas de desempeño más altas, quitando recursos de mejora y haciendo que la capacidad se estanque o caiga
-
Bucle Shortcuts
- Atajos como omitir reuniones de mejora, postergar mantenimiento preventivo programado o ignorar requisitos de documentación aumentan de inmediato el tiempo de trabajo
- Como el deterioro de la capacidad no aparece de inmediato, los atajos parecen eficaces y atractivos a corto plazo
- Un gerente que posterga el mantenimiento preventivo gana un período de gracia al evitar el downtime programado y ahorrar costos de mantenimiento, pero más adelante el envejecimiento y desgaste del equipo reducen el rendimiento y el tiempo en operación
- Un ingeniero de software que omite documentación puede terminar el proyecto a tiempo, pero paga el costo semanas o meses después al corregir bugs encontrados en pruebas
-
Capability Trap
- Work Harder al principio aumenta de inmediato el throughput total, y el costo de reducir el tiempo de mejora aparece tarde, creando una situación better-before-worse
- Work Smarter reduce la producción a corto plazo, pero con el tiempo el aumento de capacidad compensa la menor dedicación al trabajo y eleva el desempeño, con una dinámica worse-before-better
- La interacción entre Shortcuts y Reinvestment puede crear una Capability Trap que encierra a la organización en un círculo vicioso de caída de capacidad
2 comentarios
Opiniones en Hacker News
Tengo un buen ejemplo, aunque mi memoria está un poco borrosa.
En una organización había un procesamiento de pedidos importante, pero no se podía confiar en que toda la información necesaria llegara, ni en que llegara correctamente. Así que se creó lógica de validación para limpiar los valores de entrada y cambiar la forma de procesarlos, y se dejaron métricas sobre qué validaciones se disparaban en cada pedido. Cuando se agregaba una nueva validación, también se le ponía fecha.
Al publicar esas métricas y compartirlas de vez en cuando, cuando alguien preguntaba “¿qué pasa si ocurre XYZ?”, se podía responder: “ya lo manejamos, y evitamos que #### pedidos se bloquearan por XYZ”.
Quedó claro que el equipo trabajaba con cuidado, que este tipo de trabajo era necesario para que el sistema siguiera funcionando bien, y que se podía respaldar con datos. Gracias a eso, las conversaciones dentro de la organización pasaron de “¿por qué no pensaron en eso?” a “¿qué hacemos ahora?”, y el reconocimiento por la calidad preventiva también empezó a subir en la jerarquía.
La mayoría de los equipos se habría quedado solo mirando métricas como la tasa de éxito de pedidos, pero tomar como métrica la cantidad de veces que se manejaron datos malos permite escapar de la trampa de que lo bueno pase desapercibido.
Hace poco viví exactamente lo mismo en el trabajo.
Como líder técnico/arquitecto de la organización, revisé proyectos lanzados recientemente y encontré partes que era imprescindible mejorar por problemas graves de confiabilidad/rendimiento. Varias releases de un equipo estaban al principio de la lista, pero el PM de ese equipo, el gerente de ingeniería y la gente de más arriba ignoraron todas las preocupaciones diciendo que había que priorizar las actualizaciones de funcionalidad.
Unos meses después, mientras estaba de vacaciones, todo explotó: hubo una escalación sev 1, varios clientes se enojaron y hasta el CEO/CTO se involucraron. El mismo equipo que había escrito ese código desprolijo e ignorado las advertencias trabajó día y noche para restaurar el servicio, y ahora son héroes. En particular, ese gerente mejoró su reputación en la empresa por comunicarse activamente durante la caída y mostrar liderazgo.
Me impresiona más quien arregla problemas creados por otros. No me dan ganas de llenar de elogios a alguien por corregir sus propios errores, y yo tampoco esperaría elogios por corregir los míos. Para empezar, me disculparía con todos por haberlo arruinado.
El problema del título me hace pensar constantemente en relación con mi propio valor.
Si ayudo en 40 minutos a alguien con algo en lo que llevaba 3 meses atascado, mi valor queda claro para todos. Pero si trabajo junto a esa persona todo el tiempo y nadie queda atascado durante 3 meses, mi valor se vuelve difuso. No sé cómo manejar esta paradoja.
Si dedicas más esfuerzo y tiempo, muchas veces la recompensa queda rezagada mientras se espera de ti todavía más esfuerzo y tiempo. El valor y las oportunidades se parecen más a un proceso caótico en relación con el esfuerzo y el tiempo.
Al final, hay que intentar mantener una carga de trabajo lo bastante razonable como para tener la mente clara y poder tomar las oportunidades cuando aparezcan. Ayuda tener colegas honestos y equilibrados, pero en última instancia es algo que uno tiene que hacer por sí mismo.
Aunque tu jefe intente explicarlo, en la próxima ronda de despidos la cabeza que ruede podría ser la tuya.
Les contaron a otras empresas que yo era bueno en ese tipo de cosas, pero no salió nada de ahí. Ese fue mi primer y último día como contratista para empresas pequeñas.
Por eso no se desmoraliza el equipo. Los miembros del equipo necesitan, psicológicamente, que se reconozca su contribución individual.
Muchas veces estos jefes fueron colaboradores individuales competentes antes de convertirse en líderes de equipo, y como ellos mismos dominan esa habilidad, están en la mejor posición para evaluar a los colaboradores individuales que gestionan.
Hay que describir con viveza los desastres evitados para que la gente pueda formarse una imagen clara.
Otra variante es asignar recursos de más para evitar un problema que de hecho ocurrió una vez, y atender menos otros problemas más graves pero que aún no han ocurrido.
Esto es un problema de gestión. Porque aunque hubiera sido razonable hacer otra cosa más importante, nadie quiere hacerse responsable si el mismo accidente se repite.
Una pequeña herida termina reemplazada por una organización rígida y poco flexible. Que algo haya ocurrido una vez no significa que necesariamente haya que cambiar todo para que nunca vuelva a ocurrir, y esa sobrerreacción puede convertirse en una gran carga en el futuro.
Puede ser mejor aceptar esa pérdida y reconocer que podría volver a ocurrir, en vez de sobreevitarlo con la promesa de impedirlo por completo.
Una política de no asignar recursos de prevención hasta que algo ocurra de verdad es razonable hasta cierto punto.
Pasé un año miserable intentando convencerlos de que estaban sobrerreaccionando ante una falla y de que el problema real tenía una solución muy simple. Pero si un directivo alto siente que su puesto está en riesgo por una recurrencia, ordena a todo el departamento revisar y corregir código con problemas similares. Y, por alguna razón, termina escuchando a las voces más fuertes que proponen soluciones absurdamente sobreingenierizadas.
En otra ocasión, la pila de trading se cayó por la expiración de una contraseña. Fue ridícula la cantidad de esfuerzo que se metió en una solución casera absurdamente compleja para que “nunca volviera a ocurrir”. Al final, después de más de un año de trabajo, se descartó todo y se cambió por una solución centralizada mucho más simple, que era lo que se debió hacer desde el principio.
Me recuerda a un lugar donde trabajé antes. Cada vez que pedíamos feedback, nos repetían: “aquí nada se prioriza si no hay PIR (post-incident response)”.
Hacia el final, cuando aparecía un ticket relacionado con un PIR, lo marcaba como duplicado del ticket real que llevaba muriéndose en el backlog y que habría podido evitar el incidente. No tener ninguna influencia para prevenir problemas previsibles en nuestra área afectó mucho la moral del equipo.
La mayoría del equipo dejó por completo de proponer mejoras, porque la gerencia no nos permitía traer tickets por nuestra cuenta.
Describe muy bien el infierno en que se está convirtiendo el Scrum corporativo.
Agile, literalmente, se trataba de trabajar rápido y mejorar capacidades en ciclos cortos. Pero Scrum se volvió una versión peor del proceso de planificación que pretendía reemplazar.
La forma en que Scrum fragmenta el trabajo en problemas inmediatos empeora este ciclo. A largo plazo, se convierte en un sistema de tickets donde los incendios se empujan hacia arriba y la deuda técnica hacia abajo.
Además, escupe números de eficiencia fáciles de rastrear pero sin sentido, con los que consultores y ejecutivos pueden jugar a optimizar.
Está bien decirlo. Algunos de mis mejores amigos son scrum masters.
Entiendo por qué. Entre la enorme cantidad de cosas que se podrían hacer, alguien tiene que decidir qué se hará. ¿Esta función generará dinero? ¿Y qué hay de trabajos que no son funcionalidades pero reducen costos de recursos? ¿Y la deuda técnica que ralentiza la entrega de funcionalidades?
No soy alto directivo, pero al final alguien arriba es responsable de que la empresa sobreviva, gane dinero y nos pague el sueldo. Ellos también tienen que tomar decisiones con la poca información disponible, igual que nosotros. Por eso necesitan una forma de comparar “cuánto cuesta esto y cuánto valor tiene” contra “cuánto cuesta aquello y cuánto valor tiene”.
Necesitaban una forma de estimarlo, y cuando la industria tecnológica promovió Agile como ese medio, se aferraron a eso. ¿De quién es la culpa?
Así llegaron las estimaciones frecuentes, el seguimiento de cronogramas y las ceremonias. Hay quienes no creen que eso deba seguirse naturalmente, y estoy de acuerdo. Pero, de todos modos, esas ceremonias se volvieron parte del culto.
Nosotros abandonamos Scrum, y también dejamos las reuniones de refinamiento, las estimaciones de historias y los story points. Ahora nos reunimos formalmente con el PM una vez al mes y, como equipo, solo vemos dónde estamos usando estimación por tallas de camiseta. Fuera de eso, actualizamos al PM cuando lo pide o cuando sentimos que hace falta. Gracias a eso la autoridad queda en nuestras manos, pero también asumimos la responsabilidad de avisar a tiempo si la situación empieza a verse inestable. Todavía tenemos que “estimar”. Al final, la alta dirección tiene que tomar decisiones. Pero en general es bastante ligero y se siente realmente liberador.
Todos estaban comprometidos con el proceso, y el equipo Scrum reservaba 20% del esfuerzo para priorizar el pago de deuda. La velocidad de cada quien también era bastante precisa, así que podíamos incorporar otro 20% para trabajo de interés personal, y las prioridades de los stakeholders llenaban el 60% restante.
En algunos sprints, si había que empujar para terminar un epic o un objetivo del equipo, o si surgía una emergencia/bug que obligaba a cambiar prioridades, cambiábamos de rumbo.
Agregar mucho proceso solo porque quieres agregar proceso no genera valor.
Me recuerda a esta caricatura que tenía pegada en la oficina: https://naksecurity.medium.com/the-detriments-of-hero-cultur...
Por eso, en muchas culturas corporativas, si un problema no está en tu área inmediata de responsabilidad, conviene más para tus recompensas no prevenirlo proactivamente aunque sepas cómo arreglarlo. Deja que el problema salga a la luz, que se convierta en la emergencia de alguien, y entonces arréglalo.
Claro que, a largo plazo, una organización así no va a prosperar, así que también conviene planear la salida.
Me viene a la mente “Nadie recibe crédito por arreglar un problema que nunca ocurrió” (2001) [pdf]
Cada vez que un youtuber o algún clickbait en redes sociales afirma que el bug Y2K no fue gran cosa, me queda esa idea
La razón por la que no fue gran cosa es que muchísimos veteranos como yo pasamos noches enteras durante meses antes para hacer que todo funcionara
Todavía recuerdo la tensión durante la cuenta regresiva a la medianoche UTC. Luego volví a estar tenso en la cuenta regresiva de la hora del Este, y otra vez con la hora local. Recién pude relajarme cuando la hora del Pacífico llegó al año 2000
Lo sabremos en 2038
Si hablamos de la misma época, Y2K también es un muy buen ejemplo. Casi no pasó nada visible, pero si la gente simplemente lo hubiera ignorado, probablemente habrían pasado muchas cosas
Y no porque mi sueldo dependiera de eso. Obviamente había muchas otras oportunidades de trabajo. Era un problema que realmente podía paralizar la industria energética y habría afectado a las grandes empresas y a muchísimas organizaciones que dependían de ellas. Por esa experiencia, creo que muchas industrias, como finanzas o extracción de recursos, habrían sufrido el mismo impacto, directa o indirectamente
Por eso es un buen ejemplo. Todavía me encuentro con gente que recuerda Y2K como un alboroto sin importancia. No lo fue. Si no fue un problema para ti, fue porque mucha gente trabajó duro para evitarlo
Esos problemas no eran tremendamente complejos, pero estaban muy extendidos, eran importantes y requerían una enorme cantidad de trabajo. Más que un problema de ingeniería del nivel del alunizaje para presumirlo como una hazaña de la humanidad, era más parecido a corregir un montón de problemas tontos de O-rings del Challenger antes de que explotaran
Por eso, ese día solo quedaban algunos bugs residuales menores. Hubo algunos chistes en los periódicos, pero el público en general simplemente siguió adelante
Trabajo en el área climática y esperaba, o sigo esperando, que ocurra lo mismo. Pero parece que pronto va a captar la atención de todos inevitablemente
Si estás preparado, no pasa nada interesante, la vida continúa y la gente lo recuerda como si alguien hubiera abierto una laptop y apretado un par de botones
Si no estás preparado, la red eléctrica de Texas se congela, muere gente, se pierden ahorros y todo termina en “nadie imaginó que sería tan malo”
Confieso que yo también participé en ese trabajo. Lo gracioso es que me volvieron a llamar a un cliente anterior para corregir un problema que, literalmente, había creado mi propio trabajo anterior. En cuanto vi el problema, lo arreglé en 20 minutos. Y luego siguió el “ya que estás aquí, ¿podrías mirar esto también…?”, y duró unos 2 años, hasta que cerraron ese departamento y lo trasladaron a Nueva York
Al menos me lo reconocieron como horas facturables
Como este texto fue escrito justo después, pensé que sería sobre Y2K
Durante varios años a fines de los 90 trabajé en proyectos Y2K y ayudé a que infraestructura clave del Reino Unido no se detuviera a medianoche. Por ejemplo, sin nuestro esfuerzo, Gales no habría tenido agua ni gas
Pero después escuché cosas como “si no pasó nada, obviamente no era un problema; ¿por qué gastaron tanto dinero en Y2K?” o “Y2K fue una estafa inventada por la industria de TI”
Ganamos. Evitamos con éxito el bug Y2K, fue un trabajo duro y ni siquiera estábamos seguros de haberlo atrapado todo antes de la medianoche. Pero en vez de felicitarnos, algunos lo vieron como prueba de que les habíamos cobrado de más. La gente es rara
Lo molesto es que, con el cambio climático, el mejor escenario posible es igual a esto. Si realmente logramos evitar el fin del mundo, todos los “negacionistas del clima” sentirán que tenían razón
Comentarios de Hacker News
El título me recordó una anécdota china antigua. También es un poco irónico que Toyota se haya visto envuelta recientemente en un escándalo: https://www.bbc.com/news/articles/c1wwj1p2wdyo
Cuando el rey Wen de Wei le preguntó a Bian Que: “Si tus tres hermanos son médicos, ¿quién es el mejor?”, Bian Que respondió: “Mi hermano mayor es el mejor, el segundo es el siguiente, y yo soy el peor”.
El hermano mayor detectaba la enfermedad antes de que siquiera tomara forma y la eliminaba en secreto, así que su reputación solo era conocida dentro de la familia; el segundo la trataba justo cuando empezaba a manifestarse, por lo que su nombre no salía de los callejones del pueblo; Bian Que, en cambio, pinchaba venas, usaba medicinas fuertes y cortaba carne, así que gracias a esas acciones visibles su fama se extendió entre los señores feudales.
He trabajado en empresas donde el “departamento que sufre” recibía elogios y aumentos de presupuesto el siguiente trimestre por haber resuelto heroicamente problemas que ellos mismos habían creado.
Mientras tanto, mi departamento, que funcionaba bien y en silencio, apenas podía mantener las luces encendidas.
Esto se vuelve un problema serio en esta industria por la desconexión entre una gerencia no técnica que apenas entiende el doble clic y la ingeniería que realmente sostiene a la empresa. No se me ocurre una solución clara aparte de que la dirección venga de ingeniería.
Algunos problemas deben enviar señales de dolor hacia arriba antes de ser reparados, para que el liderazgo tenga la oportunidad de aprender.
Pero diseñar incentivos es difícil, y la estructura no debe hacer que la alta dirección impida que subordinados y departamentos muestren dolor y problemas. También es común que la gente oculte señales con buena intención, así que en organizaciones grandes puede ser más eficiente dejar que algunos problemas se desarrollen y enseñar a no reaccionar de forma excesiva.
Cuando todos diseñan asumiendo condiciones normales y operaciones perfectas, hace falta alguien que encuentre cómo romper el diseño, el servicio, la infraestructura y la aplicación.
Un compañero de TI podía haber recibido un poco más de 2,000 euros por cambiar certificados comerciales por Let’s Encrypt y eliminar requisitos EV, pero al final no le dieron nada. Dijeron que eso era “parte de su trabajo”.
Los equipos que sí construían servicios que funcionaban veían su presupuesto congelado e incluso perdían personal.
Cuando otro equipo tiene un incidente, nuestro equipo puede mostrar la lista de trabajos completados para explicar por qué nosotros no tuvimos el mismo problema. El trabajo ya se hizo; simplemente se hizo en un mejor momento, uno que evitó el tiempo de inactividad.
Esto pasa mucho. Me gusta especialmente que las soluciones elegantes, vistas después, casi siempre parecen simples.
Te rompes la cabeza durante mucho tiempo, encuentras una solución ingeniosa y la explicas, y la otra persona responde: “Sí, claro”.
Mientras tanto, el de al lado, que volvió el problema innecesariamente complejo, recibe elogios por haber hecho algo tan difícil.
Las grandes empresas tal vez todavía sigan atrasadas en eso de admirar la complejidad, pero para quienes reciben resultados de IA, directa o indirectamente, la complejidad ya no impresiona tanto como antes.
Cuanto más milagrosa es la recuperación, más te cuentan la historia de cómo “mi sobrino resolvió un problema menor de inmediato”, como si estuvieran subrayando que yo no pude hacerlo así.
El responsable le aconsejó usar la forma compleja, porque así sí se publicaría. No porque fuera más inteligente, sino porque una solución debía sonar compleja para ser reconocida.
Eso encaja exactamente con esta realidad donde se elogia el proceso complejo más que la solución hermosa, y probablemente así también nació la burocracia.
Ese código se olvidaba 15 minutos después del lanzamiento y nadie volvía a leerlo, pero se usaba durante años. Por eso creo que la IA podría quitar trabajos mucho más rápido de lo que mucha gente piensa.
Cosas como código limpio, separación de responsabilidades y mantenibilidad —a las que dedicamos más tiempo— en realidad nunca fueron valoradas. Si está “lo suficientemente bien”, los gerentes quedan satisfechos, y cuando aparezcan problemas, la IA podrá parchearlos aunque sea al estilo espagueti.
En un trabajo anterior tuve un problema parecido. Casi todo mi tiempo se iba en trabajo administrativo entre bambalinas como coordinar reuniones y asegurarme de que la gente tuviera la información necesaria antes de entrar
Pero cuando llegaba la evaluación de desempeño, lo único que importaba era que, por estar ocupado evitando que todo se desmoronara, no había completado muchos story points
Así que dejé por completo esas tareas administrativas y me concentré solo en completar story points; una o dos semanas después, el manager le preguntó al equipo: “¿por qué todas las reuniones están saliendo tan mal? Cuando entramos a una reunión, nadie sabe qué está pasando”
Después de pasar casi dos años haciendo una enorme cantidad de trabajo de redes, hardware e IT por la preparación para Y2K, empecé a moverme a marketing. Al final, como “no pasó nada”, casi todas las empresas consideraron que ese tiempo y dinero habían sido un desperdicio
Una empresa incluso exigió un reembolso total, y cuando dije que lo haría si podía revertir el trabajo que había hecho, aceptaron. Al día siguiente, todo el sistema de esa empresa colapsó
También era difícil hacerme cargo del soporte de red de la empresa de mi padre porque nunca quería pagar mi tarifa. Después de que otras dos personas no pudieran resolver el problema, yo lo arreglé en 15 minutos, y eso hizo que quisiera pagar todavía menos porque “solo tomó 15 minutos”
Nunca se reconocía la capacidad de mantener las cosas funcionando sin que se rompieran; solo se reconocía arreglarlas después de que se rompían. Marketing pagaba mejor y todos los días podía justificar mi sueldo con cifras reales. Me gusta mucho menos, pero recibe más respeto que cualquier trabajo de IT que haya hecho
Lo que sí recibe reconocimiento son cosas simples: arreglar impresoras, arreglar problemas A/B/C de computadoras, o un Android Sudoku sin anuncios que hice para amigos
El trabajo central por el que me pagan no recibe reconocimiento. En muchas industrias, cuando entra dinero de por medio, cumplir el rol contractual pasa a darse por sentado y disminuye el agradecimiento
La gente que no sabe de tecnología cree que los desarrolladores trabajan desde casa y solo trabajan 30 minutos al día, y la IA ha empeorado todavía más esa imagen
Ian Rush lo dijo bien: “Ser delantero es lo máximo. Puedes fallar cinco veces y si metes el gol del triunfo eres un héroe. Un portero puede hacer atajadas brillantes, pero si le meten una sola, se vuelve el villano”
En todos los lugares donde he trabajado, recompensaban al bombero más que a la persona que evitó que hubiera un incendio. Lo peor es que todos entienden claramente ese cálculo, excepto quienes deciden los incentivos
También existe el lado opuesto. Hay personas que pasan todo su tiempo preocupándose por cosas que nunca van a ocurrir, así que no es un problema que se resuelva simplemente recompensando una actitud defensiva
Así es como funcionan los ascensos en el trabajo. Rompes algo, se escala, te vuelves visible y le llega un correo a un ejecutivo. Luego “lo arreglas” y todos te dan las gracias por el buen trabajo
Otra versión consiste en retrasar durante mucho tiempo algo que de todos modos había que hacer para aumentar su visibilidad. Los ejecutivos no ven el trabajo de quienes se hacen responsables y lo terminan antes de que se vuelva un problema
En cambio, sí recuerdan el nombre de quien rompió algo y “salvó” el día
Mientras tanto, le hacen la pelota al ejecutivo y dicen cosas como “mejor no dejarlo en manos de doublerabbit” o “no parece ser un team player”. Y eso que toda la infraestructura era mía
Por eso la gente me pregunta por qué odio a los seres humanos
Es algo que ya aprendí en primer grado de primaria. Los niños que se quedan quietos en clase y hacen la tarea no consumen mucho tiempo ni esfuerzo del maestro
Los niños problemáticos que no siguen las reglas y necesitan elogios constantes cada vez que hacen el más mínimo esfuerzo académico son los que se llevan la atención del maestro
Mi tiempo en IT osciló entre dos extremos
“Todo está funcionando bien. ¿Para qué le pagamos a IT?”
“Todo está roto. ¿Para qué le pagamos a IT?”
Personalmente prefiero lo primero a lo segundo. Solía decir: “si hago bien mi trabajo, ni siquiera sabrán que estoy aquí”. Pero me despidieron por eso
Como una especie de karma, sigo en contacto con gente de esa antigua empresa, y ahora aquello es un caos total. Eso al menos me consuela un poco
Una vez que conoces la trampa de competencia, la ves en todas partes
Sterman, Repenning y otros colaboradores escribieron varios artículos más después de este, y todos son interesantes, aunque casi todos son deprimentes
Resulta aún más deprimente que MIT Sloan, donde la dinámica de sistemas se estableció por primera vez como disciplina, esté justo al lado de Harvard Business School, donde la dinámica de sistemas fue ignorada por primera vez