Cuando éramos niños, nuestra palabra favorita era un proyectil dirigido directamente a la línea de flotación de la paciencia de nuestros padres: «¿Por qué?». Lo preguntábamos todo. Queríamos saber por qué el cielo es azul, por qué había que comer verde (con lo bien que entraba un bocadillo de chocolate) o por qué el perro se empeñaba en ladrarle a la nada. No buscábamos molestar —bueno, a veces un poco sí 🫣—; buscábamos entender el sistema en el que nos había tocado caer.
Sin embargo, algo triste ocurre cuando cruzamos la puerta de cristal de una oficina. Esa curiosidad natural parece evaporarse, sustituida por una aceptación resignada o por la prisa de quien vive permanentemente «apagando fuegos». En la gestión moderna, nos hemos vuelto tan sofisticados —o tan aburridos— que llamamos «Análisis de Causa Raíz» a lo que, en el fondo, es simplemente recuperar la honestidad brutal de un niño de cinco años.
La trampa de la superficie (o el parche de toda la vida)
A menudo, cuando algo sale mal —un sistema falla, por ejemplo—, la respuesta estándar es buscar un culpable rápido o poner un parche que dure, al menos, hasta que el jefe se vaya de vacaciones. Decimos: «El código era una castaña, corrígelo». Y nos quedamos tan anchos, como si hubiéramos descubierto la pólvora.
Pero si nos detenemos ahí, estamos fracasando como gestores. La verdadera gestión no consiste en ponerle una tirita a una hemorragia, sino en diagnosticar por qué demonios estamos sangrando. Si el código falla, hay que preguntar por qué. Si descubrimos que es porque el equipo vive bajo presión constante, la pregunta obligatoria es: ¿Quién diseñó este sistema y con qué gafas de madera estaba mirando?
Aquí es donde la cosa se pone incómoda. Al rascar un poco, solemos encontrar que el problema no es un error humano puntual, sino un sistema viciado. Quizás el equipo tiene un KPI (que no es más que una «métrica» o regla para medir si alguien hace bien su trabajo) que solo premia la velocidad. Si mides a alguien solo por cuántas cosas entrega en un Sprint (un periodo corto de trabajo, normalmente de dos semanas), no te eches las manos a la cabeza si el sistema se cae a pedazos. Has premiado la rapidez, no la solidez. Es como pedirle a un constructor que levante una casa en tres días y luego sorprenderse de que las paredes sean de cartón pluma.
Luces y sombras de preguntar demasiado
Implementar esta mentalidad de los «5 Porqués» (preguntar sucesivamente hasta llegar al origen del lío) tiene beneficios claros, pero también riesgos que no te cuentan en esos cursos tan caros de certificación:
- La Fortaleza: Ataca el origen. Al llegar al fondo (que suele ser la falta de criterio en la «planta noble»), la solución es definitiva. No solo arreglas un fallo técnico; arreglas la forma de trabajar de la empresa para siempre.
- La Debilidad (o el peligro de que te pongan la maleta en la puerta): Es un ejercicio de vulnerabilidad que muchas empresas no aguantan. Preguntar «por qué» cinco veces suele acabar señalando a decisiones no maduradas o a esos procesos sagrados que «siempre se han hecho así». Si la cultura de tu oficina es de las de «sálvese quien pueda», el que pregunta demasiado se convierte rápido en el enemigo público número uno. Ya sabes lo que dicen: en boca cerrada no entran moscas, pero en mentes cerradas no entra el progreso.
Mi recomendación: Menos tiritas y más ingeniería
Si en tu equipo siempre tropezáis con la misma piedra, la respuesta no es poner mejor señalización. Es preguntaros por qué demonios sigue ahí esa piedra y quién la trajo.
Tres cosas que puedes hacer mañana mismo sin necesidad de contratar a un consultor con corbata de seda:
- Audita tus incentivos. Antes de buscar culpables, mira qué estás midiendo. Si el departamento de «Hacer cosas» tiene un bonus por velocidad y el de «Mantener cosas» tiene un bonus por estabilidad, tienes un conflicto de diseño, no un problema de personas. Arregla el sistema, no a la gente.
- Convierte el «¿por qué?» en rutina, no en interrogatorio. La diferencia entre una cultura que aprende y una que se defiende es cuándo aparece la pregunta. Si solo preguntas cuando algo explota, la gente asocia el «¿por qué?» con la guillotina. Úsalo también cuando las cosas vayan bien.
- Apunta al proceso, no a la persona. En cuanto alguien nota que el análisis es una soga disfrazada de metodología, el juego termina. Nadie te va a decir la verdad si sospecha que la conclusión final llevará su nombre en el finiquito.
El problema real no es que tu equipo no sepa hacer las cosas. Es que el sistema no está diseñado para que nadie pregunte demasiado. Y eso no lo arregla el software más caro del mercado: lo arregla alguien con autoridad que prefiera las respuestas verdaderas a las respuestas cómodas.
Si esa persona no eres tú, quizá el «por qué» que deberías estarte preguntando es qué haces todavía trabajando ahí.