Me traté a mí mismo como un recurso infinito

Dediqué una cantidad enorme de esfuerzo a optimizar cuidadosamente cada parte del sistema, y casi nada al componente más importante y menos fiable que hacía funcionar todo lo demás: yo. Me traté como un recurso infinito y siempre disponible —una máquina capaz de funcionar a pleno rendimiento de forma indefinida— y el proyecto pagó por ese error, una y otra vez, y de manera costosa.

Esta es la lección a la que más me resistí, porque admitirla se sentía como poner excusas. No es una excusa. Es simplemente una descripción precisa de una restricción que me negué a modelar, y negarse a modelar una restricción real no hace que desaparezca. Solo hace que te sorprenda.

El único componente que nunca modelé

Me enorgullecía de pensar con cuidado sobre los límites. Razonaba sobre la capacidad de cada parte del sistema, sus modos de fallo, cómo se comportaría bajo carga, dónde se rompería. Cada parte, eso sí, excepto una. Nunca apliqué esa misma honestidad de ingeniería a mí mismo.

De forma implícita, sin llegar a enunciarlo nunca, había asumido que podía funcionar a pleno rendimiento para siempre: que mi energía y mi concentración eran ilimitadas y estaban disponibles de forma permanente, que la persona que hacía el trabajo no tenía un techo de capacidad ni modos de fallo dignos de planificarse. Ningún ingeniero competente modelaría jamás un componente de ese modo. Nunca diseñarías un sistema bajo el supuesto de que una pieza crítica tiene un caudal infinito y nunca necesita mantenimiento. Y, sin embargo, así es exactamente como me modelé a mí mismo, sin darme cuenta de que lo estaba haciendo.

Sprints que terminaban en cráteres

El patrón era siempre el mismo, y me costó un número vergonzoso de repeticiones verlo. Había un estallido de trabajo intenso y emocionante —tramos largos de concentración total, yendo mucho más allá de cualquier límite sostenible, porque se sentía productivo, urgente y bueno. Y luego, con total previsibilidad, el desplome. Días, a veces semanas, en los que apenas podía trabajar, en los que el pozo estaba simplemente seco y ninguna cantidad de esfuerzo lo volvía a llenar.

Y cada una de esas veces me culpaba a mí mismo. Mi disciplina, mi debilidad, mi incapacidad para seguir adelante. Trataba el desplome como un fallo moral personal, algo que una persona más fuerte no habría sufrido. Durante mucho tiempo no se me ocurrió que el desplome no era en absoluto un fallo de carácter. Era la consecuencia enteramente mecánica de llevar un recurso finito más allá de su límite. El recurso hizo lo que los recursos finitos siempre hacen cuando los rebasas. Lo único sorprendente era que yo seguía sorprendiéndome.

El agotamiento es un fallo de sistema, no un fallo de voluntad

Este es el replanteamiento que por fin cambió algo. Había estado tratando mis colapsos como fallos de voluntad: debería haber sido más fuerte, debería haber seguido adelante, debería haberlo deseado más. Pero el agotamiento no es un defecto de carácter, y tratarlo como tal garantiza que seguirás provocándolo.

El agotamiento es sencillamente lo que ocurre cuando llevas cualquier sistema más allá de su capacidad sostenible durante el tiempo suficiente. Es un fallo de sistema, no uno moral. Llamarlo un problema de voluntad es como llamar a un motor sobrecalentado un problema de cobardía: diagnostica de raíz mal lo que salió mal y, por tanto, prescribe exactamente la solución equivocada. La respuesta a un motor que se sobrecalienta no es exigirle que sea más valiente. Es dejar de hacerlo funcionar más allá del límite que siempre iba a tener. Aplicar más fuerza de voluntad a un operador agotado no produce más rendimiento. Solo produce un desplome peor.

La aritmética del ritmo

Bajo todo esto hay una aritmética que había ignorado por completo. Un proyecto largo y difícil no se gana con el rendimiento máximo en un instante cualquiera. Se gana con el rendimiento total integrado a lo largo de mucho tiempo. Y aquí está lo que debería haber sido obvio: la suma de un ritmo moderado y sostenible mantenido de forma constante durante muchos meses supera con creces la suma de sprints heroicos puntuados por cráteres.

El sprint se siente más rápido. En el momento, genuinamente lo es. Pero a lo largo de la distancia real del proyecto es mucho más lento, porque los desplomes cuestan más de lo que jamás ganaron los estallidos. Cada semana espectacular de exceso de trabajo compraba una quincena lúgubre de recuperación, y el intercambio siempre era una pérdida cuando hacías las cuentas con honestidad a lo largo de todo el trayecto. Había estado optimizando lo rápido que me sentía en el momento, que es precisamente la variable equivocada cuando la carrera se mide en meses.

El descanso es una entrada, no una traición

Parte de lo que me mantenía atrapado era cómo pensaba sobre el descanso. Lo trataba como la ausencia de trabajo: tiempo robado al progreso, un capricho por el que sentir culpa, prueba de una dedicación insuficiente. Así que lo minimizaba, y me sentía virtuoso por minimizarlo.

Pero para un recurso finito que realiza un trabajo cognitivo sostenido, la recuperación no es lo contrario del rendimiento. Es una entrada necesaria para el rendimiento. El descanso no es tiempo restado al trabajo; es parte de lo que hace posible el trabajo en absoluto. Negarse a descansar no es dedicación. Es hacer funcionar una máquina sin mantenimiento y luego tratar la avería inevitable como mala suerte en lugar de como el resultado directo y previsible de saltarse el mantenimiento. Había confundido el descuido de un requisito con una virtud.

Diseñar para el operador

Así que con el tiempo empecé a hacer lo obvio que había evitado durante tanto tiempo: diseñar el proyecto en torno a las restricciones reales de la persona que lo llevaba, exactamente como diseñaría en torno a cualquier otra limitación real. Un ritmo que pudiera sostener de verdad, en lugar de uno que pareciera impresionante y terminara en colapso. Márgenes deliberados para los días malos, porque siempre habrá días malos. Una contabilidad honesta de mi propia capacidad como algo finito, variable y mantenible, y no como un motor infinito al que no lograba estar a la altura.

Al principio esto se sentía como rebajar mis estándares. Era lo contrario. Era por fin tomarme en serio el sistema real, incluida la parte de él hecha de una persona, en lugar de fingir que esa parte era algo que nunca podría ser.

La lección más profunda: eres el cuello de botella que te niegas a modelar

A lo que se reduce es a esto. En cualquier proyecto sostenido en su mayor parte por una sola persona, esa persona es el componente más importante de todo el sistema y, perversamente, el que más nos resistimos a tratar como algo real, limitado y mantenible. Optimizamos el código con cariño y maltratamos al operador sin piedad, y luego nos preguntamos por qué todo el conjunto se sigue atascando.

Pero el proyecto solo avanza mientras el operador avanza, y el operador no es infinito. La sostenibilidad no es una concesión blanda, opcional y autocomplaciente a la que llegar una vez hecho el trabajo de verdad. Es la restricción dura dentro de la cual tiene que caber todo el resto del trabajo. Pasé mucho tiempo tratando la parte más crítica de mi sistema como la única parte que no merecía ser diseñada con ingeniería. El proyecto no pudo escapar de ese error, y resultó que yo tampoco.

— Sin señales, sin rendimientos, esto no es asesoramiento de inversión.