Hay algo que empieza a hacerse evidente cuando has trabajado en distintos equipos, en distintas empresas y en distintos momentos de madurez de producto. No tiene tanto que ver con las personas ni con las herramientas que se utilizan, sino con la forma en la que los equipos entienden el trabajo.
Me refiero a que algunos equipos, con el tiempo, tienden a simplificar. Y otros, sin embargo, tienden a añadir capas. Y lo interesante es que esa diferencia no suele ser casualidad, ni responde únicamente al contexto, sino que está relacionada con el nivel de madurez del equipo y con cómo entienden el problema que tienen delante. Porque simplificar no es hacer menos, ni es recortar por recortar sino que para mí significa entender lo que se está haciendo y el por qué de los proyectos en marcha.
El origen de las capas
Cuando un equipo empieza a trabajar sobre un producto, un servicio o sobre un proceso, lo normal es que aparezca cierta complejidad. Hay incertidumbre, hay dependencias, hay necesidades que cubrir y decisiones que tomar. En ese contexto, añadir elementos suele ser la forma más natural de avanzar. Se añaden funcionalidades, se añaden reglas, se añaden validaciones, se añaden pasos intermedios. Se añade por inercia.
Todo eso tiene sentido en un primer momento, porque permite construir algo que funcione y que responda a distintas casuísticas. El problema aparece cuando esa lógica se mantiene en el tiempo sin ser cuestionada. Poco a poco, cada nueva necesidad se resuelve añadiendo algo más encima de lo que ya existe. Cada excepción introduce una nueva capa, cada aprendizaje se traduce en un ajuste adicional. Y sin darnos cuenta, empezamos a construir sistemas que cada vez son más difíciles de entender, de mantener y de evolucionar.
Desde dentro, muchas veces no se percibe como complejo sino como una respuesta lógica a todo lo que ha ido ocurriendo. Pero cuando se toma distancia, se empieza a ver que gran parte de esa complejidad no viene del problema en sí, sino de cómo se ha ido acumulando la solución.
Lo que cambia cuando aprendes
Los equipos que llevan más tiempo trabajando juntos o que han pasado por más ciclos de aprendizaje suelen desarrollar otra forma de enfrentarse a esa complejidad. No porque tengan menos problemas, sino porque empiezan a entender que añadir capas no siempre es la mejor forma de resolverlos. Y en lugar de construir sobre lo que ya existe, empiezan a cuestionarlo.
Se preguntan si esa funcionalidad sigue teniendo sentido. Si ese paso intermedio es realmente necesario. Si esa regla responde a un problema actual o a uno que ya no existe. Y, sobre todo, empiezan a asumir algo que no siempre es fácil de aceptar. Que muchas de las soluciones que en su momento tuvieron sentido dejan de tenerlo con el tiempo.
Esa forma de pensar cambia bastante la manera en la que se trabaja. Porque en lugar de añadir constantemente, el equipo empieza a revisar, a eliminar, a reordenar. Empieza a buscar formas más simples de resolver el mismo problema, incluso aunque eso implique rehacer parte de lo que ya estaba construido. Y eso requiere criterio, porque simplificar sin entender puede ser tan problemático como añadir sin cuestionar.
La dificultad de simplificar
Añadir capas es relativamente sencillo. Responde a una lógica acumulativa que encaja bien con la forma en la que solemos trabajar. Hay un problema, se añade una solución. Hay una excepción, se añade una regla. Hay una necesidad nueva, se incorpora una funcionalidad. Simplificar, en cambio, exige otro tipo de esfuerzo.
Exige entender el sistema en su conjunto, no solo la parte sobre la que estás trabajando. Exige revisar decisiones pasadas, cuestionar supuestos y en muchos casos, renunciar a soluciones que en su momento costaron tiempo y esfuerzo. Y además, tiene un componente adicional que no siempre es evidente, porque simplificar implica asumir cierto riesgo.
Porque cuando eliminas algo, cuando reduces pasos o cuando replanteas una solución, estás cambiando un equilibrio que ya existía. Y eso no siempre es bueno, especialmente en entornos donde la estabilidad se valora por encima de todo. Por eso muchos equipos se sienten más seguros añadiendo que simplificando. Añadir parece avanzar sin romper nada. Simplificar obliga a tomar decisiones más profundas.
La relación con el producto
En producto, esta diferencia se nota mucho. Hay productos que con el tiempo se vuelven cada vez más complejos, no necesariamente porque el problema que resuelven lo sea, sino porque cada iteración ha ido añadiendo algo más encima de lo anterior. Nuevas funcionalidades, nuevas opciones, nuevos flujos. Todo tiene sentido de forma individual, pero el conjunto se vuelve cada vez más difícil de usar.
Y hay otros productos que, a pesar de evolucionar, mantienen una cierta claridad. No porque no cambien, sino porque el equipo ha ido tomando decisiones activas para simplificar, para eliminar lo que no aporta y para mantener el foco en lo esencial. Esa diferencia no suele estar en el tipo de producto, sino en cómo el equipo entiende su evolución.
Las conclusiones y a por mayo
Hay temas que merece la pena asumir cuanto antes y darles el espacio que necesitan, aunque solo sea pararse a pensar en ellos de vez en cuando. Uno de ellos es entender que la complejidad no siempre viene del problema que tenemos delante, sino de cómo hemos ido construyendo la solución a lo largo del tiempo, añadiendo capas sin revisar si siguen teniendo sentido.
También es importante entender que simplificar no es hacer menos, sino entender mejor, y que muchas veces el trabajo de más valor no está en añadir algo nuevo, sino en revisar lo que ya existe y tomar decisiones para hacerlo más claro, más coherente y más útil.
Y quizá lo más relevante es asumir que la simplificación no ocurre de forma natural, porque la inercia del trabajo empuja justo en la dirección contraria, hacia añadir, ajustar y acumular. Por eso simplificar es una decisión consciente que exige parar, revisar y, sobre todo, tener el criterio suficiente para distinguir qué merece la pena mantener y qué no.
Nuevo episodio en el podcast
En esta edición no hay episodio del podcast. Estoy planificando los siguientes y no ha dado tiempo a tenerlo.
Dicho esto, ya tengo el episodio 100 muy cerca. Y siendo sincero, era algo que ni siquiera pensaba que iba a llegar, pero que con el tiempo, sin pensarlo mucho ha terminado llegando.
Y lo mejor de todo es que cuando está ya aquí cerca te das cuenta de que no es solo un número sino que es todo lo que hay detrás. Las conversaciones, la gente, el tiempo, la constancia, los aprendizajes. Muchas cosas.
Mientras tanto, tengo el 99 que he grabado esta semana aún en proceso de editarlo, y te dejo por aquí los 10 últimos, por si hay alguno que se te escapó o te apetece recuperar.
Lo que he leído/escuchado estas semanas
Cómo construimos nuestro buscador en Mercadona Tech (y cómo construir el tuyo)
Cómo diseñar el futuro, con David Alayón (Tiempo de futuros)
Una frase
Find a purpose to serve, not a lifestyle to live. Criss Jami
Gracias por la mención, Juan. Espero que disfrutaras de la conversación con David.