Ejecutar o pensar
Cuando dices a alguien exactamente qué tiene que hacer y cómo debe hacerlo, estás poniendo su valor en la ejecución, no en el resultado.
Bienvenido, bienvenida a Rodobo, un boletín quincenal que explora cómo mejorar la forma en la que trabajamos, decidimos y colaboramos. Soy Juan Rodríguez Talavera y trabajo en la intersección entre analítica digital, CRO, estrategia de producto y experiencia de usuario.
En esta ocasión me gustaría escribir sobre una reflexión que tiene que ver con la forma en la que entendemos el valor de las personas con las que trabajamos, pero también con la responsabilidad y la confianza que generamos. Es una idea que parece obvia cuando la lees, pero que en el día a día se incumple más de lo que pensamos. Es la diferencia entre trasladar tareas y trasladar problemas.
Porque cuando dices a alguien exactamente qué tiene que hacer y cómo debe hacerlo, estás poniendo su valor en la ejecución, no en el resultado. Estás diciendo, quizá sin darte cuenta, que lo importante no es cómo piensa, cómo decide o cómo entiende la situación, sino que siga instrucciones. Y eso tiene consecuencias mucho más profundas de lo que parece.
Durante años he visto equipos muy competentes funcionando muy por debajo de su potencial no por falta de cualidades sino por cómo se les pedían las cosas. Personas con criterio, con experiencia, reducidas a ejecutores de tareas. Y cuando eso ocurre, el sistema se vuelve frágil, dependiente y poco creativo. Funciona mientras todo va bien, pero se resiente en cuanto aparecen los momentos jodidos, lo complejo.
Y de eso es sobre lo que me gustaría que fuese este texto, de entender por qué construir ejecutores, incluso cuando parece que es eficiente, no lo es del todo, y por qué aprender a trasladar problemas en lugar de tareas cambia por completo la dinámica de un equipo.
Cuando el valor está en la tarea
Decirle a alguien qué hacer y cómo hacerlo puede parecer una buena práctica. Reduce la incertidumbre, evita errores, acelera la ejecución. Sobre el papel, todo encaja. El problema aparece cuando esa forma de trabajar se convierte en la norma y no en una excepción puntual.
Si defines la tarea al detalle, estás asumiendo que el diseño de la solución es tuyo. La otra persona solo tiene que ejecutar. Su margen de decisión es mínimo y, con el tiempo, también lo será su implicación. Porque si su papel es cumplir instrucciones, deja de sentir el resultado como propio. El trabajo se convierte en algo que se entrega, no en algo que se construye.
En ese contexto, evaluar el resultado es complicado. Si el resultado es bueno, en realidad confirma que tu planteamiento era correcto, no que el equipo haya aportado valor. Y eso, aunque suene duro, es una mala noticia. Porque significa que no estás aprovechando lo que supone trabajar en equipo sino que solamente estás amplificando tu propio criterio.
Y si el resultado es malo, la situación empeora. Porque entonces aparece el reproche, explícito o implícito, hacia quien ejecutó la tarea. No lo ha hecho bien, no ha entendido, no ha seguido el proceso como debía. Pero el problema no es de ejecución, es de planteamiento. Si tú decides el qué y el cómo, el resultado también es responsabilidad tuya.
Esta forma de hacer las cosas genera una paradoja incómoda. Si todo sale bien, el equipo aporta poco valor diferencial. Si algo sale mal, el equipo queda expuesto como el problema. En ambos casos, el sistema no aprende y las personas tampoco.
Trasladar tareas, recoger tareas
Cuando trasladas tareas, lo que recibes de vuelta son tareas. Listas de acciones completadas, checklists cerrados, entregables, etc. Todo parece avanzar, pero en realidad se está moviendo en superficie. No hay cuestionamiento, no hay mejora del enfoque, no hay aprendizaje, no hay una visión critica que cuestione lo que se está haciendo.
Este tipo de dinámica suele aparecer en entornos muy presionados por el corto plazo. Hay que llegar, hay que entregar, hay que cumplir. Y en ese contexto, pensar parece un lujo. Pero lo que no solemos ver es el coste oculto de esa forma de trabajar. Dependencia constante, saturación de quien decide, desmotivación de quien ejecuta.
Además, cuando las personas se acostumbran a recibir tareas cerradas, dejan de plantear alternativas. No porque no las tengan, sino porque no se les pide. Y poco a poco aprenden que pensar más allá de lo que se les dice no es necesario y que incluso puede ser molesto. El sistema no recompensa la iniciativa, recompensa la obediencia.
Con el tiempo, esto genera equipos muy eficientes haciendo exactamente lo que se les dice, pero muy poco capaces de adaptarse cuando el contexto cambia. Y el contexto siempre cambia. Ahí es donde empiezan los problemas de verdad.
Trasladar problemas, construir soluciones
Trasladar un problema es muy distinto. Implica explicar el contexto, el objetivo, las restricciones y el impacto. Implica confiar en que la otra persona o el equipo sabrá encontrar el camino. No significa desaparecer ni desentenderse, sino cambiar el rol. Pasar de decir cómo hacerlo a acompañar el proceso de decisión.
Cuando trasladas un problema, estás diciendo que confías en el criterio de los demás, en la capacidad para entender la situación y proponer una solución. Y eso cambia por completo la relación con los demás porque el resultado deja de ser algo ajeno y se convierte en algo propio.
Aquí sí tiene sentido evaluar el resultado, porque el camino también ha sido del equipo. Si la solución funciona, el aprendizaje es colectivo. Si no funciona, también. Se puede analizar qué supuestos eran incorrectos, qué información faltaba, qué señales se interpretaron mal. El error deja de ser personal y pasa a ser sistémico.
Además, cuando trabajas así, las soluciones suelen ser mejores. No porque una persona piense mejor que otra, sino porque hay más personas involucradas, cada una con sus capacidades, más contexto y más capacidad de ajuste. Y quien traslada el problema no es que pierda control sino que gana en perspectiva.
Diferenciar entre tareas y problemas
Una de las habilidades más importantes que valoro es saber cuándo tiene sentido bajar al detalle y cuándo no. No todo problema debe trasladarse tal cual, ni toda tarea debe definirse al milímetro. Hay momentos para enseñar, para guiar, para acompañar, pero eso no puede ser el estado por defecto.
La clave está en ser consciente de qué estás trasladando. Si lo que necesitas es que alguien aprenda un proceso concreto, definir la tarea puede ser de utilidad para ello, pero si lo que buscas es criterio, autonomía y crecimiento, necesitas trasladar el problema. Confundir ambos casos es lo que he visto muchas veces que genera la mayor parte de las frustraciones.
Y creo, que trasladar el problema también requiere aceptar algo incómodo, que es que las soluciones que proponga el equipo no siempre serán las mismas que tú habrías elegido. Y que eso no es un problema sino que es precisamente la señal de que el sistema funciona. Gestionar no es clonar tu forma de pensar sino que es generar y crear un entorno donde otras formas de pensar puedan aportar valor.
Como siempre hago, algunas conclusiones
Durante mucho tiempo confundimos control con seguridad. Pensamos que definiendo cada paso evitamos errores, cuando en realidad solo los aplazamos y los hacemos más costosos. La seguridad aparece cuando construyes equipos capaces de entender problemas y adaptarse, no cuando ejecutan sin cuestionar nada del sistema y de lo que se les traslada.
Y es que trasladar problemas en lugar de tareas no es más lento ni más arriesgado sino que es más útil en el largo plazo, porque pone el valor donde debe estar, en la capacidad de pensar, decidir y aprender. Y eso, como decía, es a la larga lo que hace que los equipos crezcan, que los resultados mejoren y que el trabajo tenga más sentido para todos.
Nuevo episodio en el podcast
Con Ignacio Arriaga, cofundador de Acumbamail y autor de la newsletter Disaaster, donde escribe sobre software, producto, marketing y las decisiones reales que hay detrás de construir empresas durante años.
La conversación fue derivando de forma bastante orgánica, sin necesidad de seguir un guión cerrado. Fuimos tocando temas, conectando unos con otros, y eso permitió que fuese muy honesta.
Durante la charla hablamos, entre otras cosas, de:
Qué implica mantener un SaaS en España durante más de una década
Cómo se toman decisiones difíciles cuando no hay red ni atajos
Por qué el momento importa más que la idea en muchos productos de software
Cómo mantener el foco en producto cuando el entorno empuja a seguir modas
Por qué replicar modelos de empresas grandes suele ser un error para equipos pequeños
El papel del fundador en la venta y lo que ocurre cuando se delega demasiado pronto
Cómo gestionar la presión de crecer cuando el negocio ya es rentable
Gracias por pasarte por el podcast, Ignacio.
Puedes escucharla aquí abajo o a través de este enlace.
Lo que he leído estas semanas
Una frase
Wind extinguishes a candle and energises fire. Likewise with randomness, uncertainty, chaos: you want to use them, not hide from them. Nassim Nicholas Taleb
Me ha recordado al modelo de liderazgo situacional, y cómo pone el énfasis en el proceso de desarrollo de las personas (y en el comportamiento del líder en cada paso)