The Phoenix Project y el costo de administrar una empresa a base de urgencias

Hay empresas donde ciertas personas parecen indispensables por una razón que al principio resulta admirable. Son quienes reciben la llamada cuando algo falla, conocen las contraseñas que nadie más recuerda, saben qué proveedor puede resolver una emergencia y encuentran soluciones que el resto de la organización no consigue imaginar. Todos terminamos diciendo lo mismo: “pregúntale a él, porque él sabe”. Durante algún tiempo esa persona parece uno de los mayores activos de la compañía. El problema comienza cuando descubrimos que también se ha convertido, involuntariamente, en uno de sus mayores riesgos.

Ese es uno de los temas centrales de The Phoenix Project, novela empresarial publicada originalmente en 2013 por Gene Kim, Kevin Behr y George Spafford. Inspirados en buena medida por The Goal, de Eliyahu Goldratt, los autores trasladaron la lógica de las restricciones y del flujo hacia el mundo de la tecnología y las operaciones. El protagonista, Bill Palmer, recibe inesperadamente la responsabilidad de dirigir tecnología en Parts Unlimited, una empresa donde prácticamente todo está saliendo mal. Sistemas caídos, proyectos retrasados, cambios mal ejecutados y enfrentamientos entre departamentos forman parte de una operación donde muchas personas trabajan muchísimo y, sin embargo, la organización parece cada vez menos capaz de cumplir.

Lo interesante es que el libro realmente no trata solamente de tecnología. Trata de empresas.

Después de más de cuarenta años dirigiendo negocios, reconozco perfectamente esa sensación de llegar a una mañana en que varias cosas parecen urgentes al mismo tiempo. Un proveedor no entregó, una cobranza se retrasó, una obra necesita una decisión, un cliente importante solicita algo inesperado y un sistema dejó de funcionar. Resolver forma parte del trabajo empresarial y nunca desaparecerá por completo. Lo peligroso es cuando la emergencia deja de ser excepcional y se convierte en nuestra manera normal de operar.

Cuando todos los días son una crisis, algo está mal diseñado.

The Phoenix Project muestra cómo una organización puede acumular trabajo sin entender realmente cuánto tiene en proceso. Cada departamento solicita cambios, aparecen nuevos proyectos y las prioridades se modifican constantemente. El resultado es que las personas comienzan muchas cosas y terminan pocas. Quienes son considerados más capaces reciben todavía más responsabilidades precisamente porque saben resolverlas, hasta convertirse en cuellos de botella.

Esta situación no pertenece únicamente al área tecnológica. La he visto en construcción, administración, ventas y prácticamente cualquier actividad. Hay un arquitecto que conoce todos los detalles del proyecto y termina participando en cada decisión. Existe un contador sin cuya aprobación parece imposible cerrar cualquier asunto. Un director comercial concentra todas las relaciones importantes. Mientras esas personas están disponibles, la empresa funciona. Cuando se enferman, renuncian o simplemente reciben demasiado trabajo, descubrimos que nunca construimos capacidad alrededor de ellas.

En mi experiencia, una de las mejores señales de que una empresa está madurando aparece cuando deja de admirar al héroe que resuelve todo y comienza a preguntarse por qué siempre necesitamos un héroe.

No se trata de restarle mérito a quien salva una situación complicada. Al contrario, esas personas suelen ser extraordinariamente valiosas. Precisamente por eso debemos protegerlas de una organización que ha convertido su conocimiento en una dependencia. Mi recomendación es identificar qué personas reciben constantemente asuntos extraordinarios y estudiar por qué. Quizá necesitamos documentar procesos, formar un segundo responsable, automatizar determinadas tareas o eliminar decisiones que nunca deberían haber llegado hasta ellas.

Uno de los conceptos más conocidos del libro son los llamados “tres caminos”, una filosofía que posteriormente se desarrollaría con mayor profundidad dentro del movimiento DevOps. El primero está relacionado con mejorar el flujo del trabajo desde que aparece una necesidad hasta que finalmente se entrega valor al cliente. El segundo busca desarrollar ciclos rápidos de retroalimentación, de manera que los errores puedan detectarse cerca del momento en que ocurren. El tercero se relaciona con construir una cultura donde experimentar, aprender y mejorar de manera permanente forme parte de la operación.

Más allá de cualquier terminología tecnológica, estas ideas tienen una aplicación empresarial muy sencilla. El trabajo necesita moverse, necesitamos enterarnos pronto cuando algo salió mal y debemos aprender para no resolver veinte veces el mismo problema.

Parece evidente, pero ocurre constantemente lo contrario. Una organización detecta un error y alguien lo corrige rápidamente. Todos agradecen que el asunto haya quedado resuelto y regresan a trabajar. Tres semanas después aparece exactamente el mismo problema. Volvemos a solucionarlo, felicitamos nuevamente a quien intervino y seguimos adelante. La empresa cree que tiene personas extraordinariamente resolutivas cuando, en realidad, está pagando repetidamente por no haber aprendido.

Con los años he adquirido cierta incomodidad frente a los problemas que aparecen por tercera o cuarta vez. Una falla puede ser un accidente. Cuando se repite, comienza a convertirse en responsabilidad administrativa. La pregunta ya no debería ser solamente cómo resolverla hoy, sino qué cambio debemos realizar para que dentro de seis meses nadie tenga que volver a hablar de ella.

Esta disciplina exige tiempo, y precisamente allí aparece una de las grandes contradicciones. Las empresas atrapadas en urgencias sienten que nunca tienen tiempo para mejorar los procesos porque están demasiado ocupadas resolviendo urgencias. Es una espiral muy difícil de romper. Cada emergencia consume el tiempo que habría permitido eliminar la causa de la siguiente.

He vivido momentos en los que resulta tentador decir: “primero resolvamos todo lo pendiente y después organizamos”. El problema es que lo pendiente nunca se termina. Siempre aparecerá algo nuevo. La organización tiene que reservar deliberadamente capacidad para mejorar, incluso mientras continúa operando.

Otro de los aprendizajes importantes de The Phoenix Project es limitar el trabajo en proceso. Cuando las personas tienen demasiadas tareas abiertas simultáneamente, los tiempos de terminación aumentan y la prioridad real se vuelve confusa. Todos están ocupados, pero los proyectos pasan semanas esperando que alguien termine aquello que comenzó antes.

Esto tiene una aplicación directa en cualquier grupo empresarial. Abrir cinco proyectos no significa tener cinco proyectos avanzando. Puede significar tener cinco proyectos esperando por las mismas personas, el mismo dinero o las mismas decisiones. Cada frente nuevo tiene un costo invisible que casi nunca aparece en el presupuesto original: fragmenta la atención.

Después de cuatro décadas de actividad empresarial, cada vez me parece más importante proteger la capacidad de concentración de nuestros mejores directivos. Si una persona verdaderamente capaz puede transformar un negocio, no tiene sentido repartirla entre diez asuntos hasta convertirla en alguien que solamente responde mensajes y asiste a reuniones.

El libro también muestra los conflictos que aparecen cuando distintas áreas persiguen objetivos locales. Tecnología intenta proteger sistemas, comercial necesita lanzar productos, finanzas controla costos y cada departamento interpreta el comportamiento de los demás como una dificultad para cumplir sus propias metas. Lo que falta es una comprensión común del resultado final.

Esta situación es extraordinariamente frecuente. En una empresa inmobiliaria, comercial puede querer entregar rápidamente mientras construcción necesita resolver pendientes; administración intenta controlar gasto mientras operación exige recursos. Cada área puede tener razones legítimas. El problema surge cuando nadie tiene suficiente perspectiva para decidir qué necesita realmente el conjunto.

Hay otra enseñanza del libro que considero particularmente importante en la actualidad: los sistemas tecnológicos dejaron de ser responsabilidad exclusiva de “la gente de sistemas”. Prácticamente cualquier empresa moderna depende de información, comunicaciones, plataformas de pago, bases de datos y procesos digitales. Cuando alguno falla, la operación completa puede detenerse.

El propietario no necesita convertirse en programador, pero sí debe comprender sus dependencias críticas. ¿Qué información perderíamos ante una falla? ¿Quién tiene acceso? ¿Existen respaldos? ¿Qué ocurriría si determinado sistema dejara de funcionar durante dos días? Estas preguntas pueden parecer técnicas hasta el momento en que se convierten en un problema financiero.

Para las empresas familiares existe además una versión humana de esta misma reflexión. También tenemos información crítica almacenada dentro de personas. Un fundador conoce acuerdos históricos, condiciones negociadas y razones detrás de determinadas decisiones que quizá nunca fueron documentadas. Si queremos construir continuidad generacional, necesitamos transformar gradualmente esa memoria personal en memoria institucional.

No significa escribir absolutamente todo. Significa reconocer aquello cuya pérdida realmente podría perjudicar al grupo.

Durante muchos años, el empresario se acostumbra a resolver mediante experiencia. Vemos un problema y recordamos otro parecido ocurrido hace veinte años. La siguiente generación todavía no tiene ese archivo mental. Nuestra responsabilidad no debería consistir en exigir que adivine lo que nosotros aprendimos con décadas de práctica, sino en transmitir suficiente contexto para acelerar su formación sin impedirle desarrollar su propio criterio.

The Phoenix Project me deja, finalmente, una reflexión sobre la diferencia entre trabajar duro y construir bien. Hay organizaciones llenas de personas extraordinariamente comprometidas donde todos terminan agotados. Eso no es necesariamente una señal de excelencia. Puede significar que el sistema está consumiendo talento para compensar defectos que nunca corrigió.

A medida que pasan los años, me interesa cada vez menos una empresa que necesita actos heroicos todos los días. Prefiero una organización donde las cosas importantes ocurran con cierta normalidad, donde los problemas excepcionales reciban atención precisamente porque son excepcionales y donde las personas más capaces tengan tiempo para pensar además de reaccionar.

La verdadera institucionalización se parece mucho a eso. No significa eliminar para siempre los problemas. Significa evitar que cada problema dependa de una improvisación y que todo conocimiento importante termine concentrado en unas cuantas personas indispensables.

Después de más de cuarenta años en los negocios, considero que uno de nuestros mejores legados empresariales sería dejar una organización donde nuestros hijos no tengan que vivir permanentemente apagando los mismos incendios que nosotros. Porque resolver una crisis demuestra capacidad. Construir una empresa que aprende a no repetirla demuestra algo todavía más valioso: madurez.