Mucho management tradicional falla en entornos como los nuestros, porque trata de separar a las personas que toman decisiones de las que simplemente “ejecutan”.
Acá la distinción no es tan clara. En los equipos que veo en mis clientes, en startups y dentro de Continuum, cada miembro del equipo tiene que tomar decisiones súper importantes cada día.
Y nos cuesta.
Nos cuesta porque hacemos cosas complejas, que son parte de “sistemas”. Creamos soluciones compuestas de muchos componentes que colaboran entre sí para conseguir algún tipo de resultado. También formamos parte de un sistema (nuestro equipo, nuestra organización) compuesto por personas, procesos y herramientas que colaboran entre sí para conseguir algún tipo de resultado.
Entonces es súper común que nos toque decidir algo sin poder ver el bosque completo.
Por ejemplo: Te toca elegir un framework front-end y la verdad es un tema que parece bien técnico y donde puedes tomar una decisión en base a cual parece más productivo, más simple, o el que parece adaptarse mejor a lo que necesitas. Eliges Phoenix LiveView.
Hasta que alguien te dice que no tan rápido, que cómo se te ocurre elegir eso. ¡Donde vamos a conseguir desarrolladores que sepan Elixir! ¡Y todo el mundo en frontend usa React o Vue o Angular!
Ups.
No se trataba sólo de escoger tecnología. También se trataba del ritmo de aprendizaje de compañeros de trabajo y de facilidad para encontrar nuevas personas para cuando el equipo crezca o tú te vayas de ahí.
Lo curioso es que tu decisión de usar Phoenix LiveView puede ser súper buena.
Hace 15 años atrás Python era el lenguaje que casi nadie sabía y sin embargo podía ser excelente elección pensando en la parte de armar equipos. Porque paradojalmente al ser un lenguaje no tan popular, nadie aprendía Python para conseguir trabajo. Entonces quienes aprendían el lenguaje eran personas interesadas en aprender por su cuenta lenguajes mejores o diferentes. Armar un equipo con esas personas era muy potente.
¡También puede ser buena decisión escoger un lenguaje popular!
El truco es que en las cosas más importantes no suele haber una decisión correcta y otra que sea incorrecta. Simplemente es un trade-off. Ganas por un lado y pierdes por otro. Y toca evaluar en el contexto cuál combinación de ganar-y-perder parece más razonable. Eso para el “sistema” que estás creando pero también para el “sistema” del que formas parte.
No se trata tanto de acertar o errar en una decisión (casi todo el tiempo la respuesta es incierta y subjetiva). Acá lo que más importa ejercitar es mirar el bosque completo y no quedarse sólo en un par de arbolitos. De esa forma puedes tener claro qué estás sacrificando con tu decisión. Porque:
“Todo es un trade-off”
— Yo, muy seguido (a veces se ríen en Continuum por eso)
¿Cómo podemos mirar mejor el bosque?
Primero que todo a nivel individual tienes que tratar de tener alguuuna idea de esos otros árboles que no son tu trabajo directo. Hay muchas formas de hacerlo, pero acá van un par de ejemplos:
Si desarrollas, no olvides tomar contacto con los usuarios de vez en cuando, que para ellos suele ser lo que estás creando. Es genial descubrir que a veces puedes escribir menos código para conseguir resultados similares. No por tratar de hacer lo mismo en menos líneas, sino porque puedes ofrecer soluciones alternativas que resuelven los problemas de los usuarios y que son más sencillas de implementar.
Si diseñas, comprender más sobre los procesos internos o el modelo de negocio te ayuda a entender por qué algunas cosas que tus usuarios necesitan tal vez tu producto/organización no estará dispuesto/capacitado/interesado en resolverlas.
Más allá de lo individual, a veces tienes un rol derechamente especialista en un equipo/organización grande. Ahí suelen haber personas que hacen de “bisagra” entre múltiples mundos, sin necesariamente saber demasiado de todos, pero lo suficiente de cada mundo para permitir que la comunicación fluya. A veces tendrán una buena intuición del trade-off, pero muchas otras el aporte será saber a quién recurrir o facilitarán alguna instancia donde múltiples partes pueden aportar más perspectivas.
Ellos son tus aliados a la hora de tomar decisiones (Y si esas personas no existen, haz lo que esté a tu alcance para que existan. Quizás tú quieras crecer hacia allá también). Porque se trata de buscar óptimos globales en lugar de locales para el sistema que estás creando y también para el sistema del que formas parte.
En la práctica, para tomar mejores decisiones tenemos que ser escépticos del template:
❌ Esta es nuestra/mi decisión porque A, B y C.
Porque muuuchas veces el tema no es tan simple y en realidad debiéramos decir que:
✅ Esta es nuestra/mi decisión a pesar de que X, Y y Z. Porque A, B y C parecen valer la pena en este caso.
No es fácil. Yo por ejemplo suelo fallar en no explicitar el tradeoff que tomamos.
Así que acá va el segundo tip (que también es un auto-tip, quizás al decírmelo públicamente me vaya mejor para no quedar como el cura Gatica):
Para tomar mejores decisiones tenemos que compartir con el resto (equipos, pares) la razón de nuestras decisiones, incluyendo los trade-offs.
Así, aunque uno esté seguro que evaluó los tradeoffs, otras personas pueden aportarte en los puntos ciegos. Y también todos vamos entendiendo por qué diablos tomamos las decisiones que tomamos.
Creo que esta es una de las cosas que menos enseñan y más cuesta aprender, porque en el camino hay que fallar y meter la pata tomando malas decisiones, hasta que calibras y aprendes a qué "otros árboles" considerar en la decisión.
Analizar el radio de explosión es relevante, porque no sólo uno toma decisiones, también se hace cargo de las consecuencias de ella. Y me parece podrías hablar en algún momento de ello: la responsabilidad.