Lo barato que sale decir que sí

En una reunión alguien propone algo nuevo. Una tecnología, una arquitectura, una herramienta, en 2026 casi siempre algo con IA adentro. La propuesta suena bien, tiene un caso de éxito atrás, y el que la trae está entusiasmado.

Alrededor de la mesa hay tres o cuatro personas más. Es muy probable que al menos una piense que eso no hace falta, y casi nunca lo dice. Por qué no lo dice no es algo que sepamos, pueden ser muchas cosas, el asunto es que no va a poner objeción.

De esa reunión salen dos decisiones, aunque después se cuente una sola. Está la decisión de adoptar la cosa, que es del que la propuso y de la persona que suscribe a la decisión. Está también la decisión de no abrir la boca, que es de cada uno de los que estaban sentados ahí. Esa segunda no queda escrita en ninguna minuta, no tiene responsable asignado, y es de la que me interesa charlar ahora.

De esto conté una versión hace un par de años, en un episodio del podcast (Es la nueva sensación). Un compañero propuso partir en microservicios una aplicación que andaba bien, yo dije que sí, y dos meses después estábamos manteniendo una base de datos con la mitad de los datos duplicados para hacer exactamente lo mismo que ya hacíamos. La conclusión que saqué entonces fue que no conviene copiar las soluciones de las empresas grandes cuando no tenés sus problemas, sin embargo, había más al respecto que me di cuenta un tiempo después.

La parte que no conté

Lo que no dije en ese episodio, más que nada porque no lo tenía claro, es que yo ahí no decidí nada. No era mi propuesta y no era mi llamada. Lo único que hice fue decir “dale, vamos a modernizar esto”, pensando que realmente era lo que teníamos que hacer, además que suelo entusiasmarme con las tecnologías nuevas.

Esa es la parte incómoda. No me pasaron por encima, no me guardé ninguna objeción por miedo, ni siquiera se me ocurrió que hubiera algo para objetar. No se me ocurrió porque decir que sí no me costaba absolutamente nada, mientras que preguntar tenía un precio.

Echarle la culpa al entusiasmo de la época es cómodo. Uno queda razonablemente bien parado en su propia historia y no lo obliga a cambiar nada para la próxima.

Lo que sale caro

Pensá bien lo que arriesga el que pregunta en esa reunión… Quedar mal un rato es lo de menos. Lo caro es que te ubiquen como el que no se actualiza, el que frena, el viejo que te manda a leer el manual, intransigente. Discutir una arquitectura sale barato, pero que te muevan al casillero de los que se quedaron no se arregla en la misma reunión, ni en la siguiente.

Después está la asimetría, que es la parte que más tiempo me tomó darme cuenta…

Si decís que sí y sale mal, la culpa se reparte entre todos los que estaban en la sala, y la mayoría de las veces ni siquiera se nombra: se dice que el proyecto se complicó, que hubo que ajustar el alcance, que el contexto cambió. Si decís que no y te equivocás, la culpa es tuya sola, tiene tu nombre puesto, y seguramente hay alguien que se acuerda dos años después. Con esos números nadie apuesta al no, lógicamente.

Por eso el que dice que sí no es un tibio. Está leyendo bien los incentivos de la sala, que es exactamente lo que uno hace cuando quiere seguir trabajando ahí. Lo que falla es el equipo donde preguntar cuesta más que aceptar, y eso lo arregla el que conduce la reunión. Mientras tanto hay algo que sí está a tu alcance, y es más chico de lo que parece.

Dos preguntas que no necesitan que tengas la firma

De los seis filtros del método hay dos que podés usar aunque no decidas vos, porque no hace falta cargo para hacer una pregunta.

Ahí está la diferencia, que parece un detalle de forma y no lo es. Una pregunta no es una objeción. Cuando decís “esto está mal” te ponés enfrente del que propuso y alguien tiene que perder. Cuando preguntás “¿qué problema resuelve?”, el que propuso contesta, y si no tiene respuesta se da cuenta solo, delante de todos, sin que vos lo hayas empujado a ningún lado. Salís de curioso, no de conservador.

Problema real. ¿Qué resuelve esto, concretamente? ¿Es algo que nos pasa hoy o algo que podría llegar a pasarnos? ¿Por qué no alcanza con lo que ya está andando?

Estas tres las venía usando desde hace años sin saber que eran parte de nada, y de hecho las conté en aquel mismo episodio como si fueran un hallazgo personal. No tienen nada de brillante. Lo llamativo es la cantidad de veces que la respuesta honesta a la primera es “no sé, pero está bueno estar actualizado”.

Contexto. La escala, el equipo, la plata y el momento del caso de éxito que te trajeron, ¿se parecen en algo a los tuyos?

Este es el que más rinde y el que más incomoda, y son las dos caras de lo mismo. Aplicarlo de verdad implica decir en voz alta que no somos la empresa que nos gustaría ser: que no tenemos ese equipo, ni ese presupuesto, ni ese volumen de usuarios, ni esa madurez. En una sala donde todos quieren sentirse un equipo moderno, eso es bastante más impopular que discutir una tecnología. Discutir la tecnología te deja como alguien con criterio técnico. Discutir la escala te deja como alguien que le bajó el precio al equipo.

Fijate que cuando alguien trae un caso de éxito casi nunca se discute el caso. Se discute la implementación, el cronograma, quién lo va a mantener, si conviene hacerlo ahora o el trimestre que viene. El contexto se da por comparable sin que nadie lo haya revisado, porque revisarlo obliga a mirarse. Ahí es por donde se cuelan las decisiones que después nadie sabe explicar cómo se tomaron.

Es comparar peras con manzanas, y se hace igual, todo el tiempo, porque la comparación halaga.

La próxima vez que estés sentado en esa reunión lo más probable es que no digas nada. Yo tampoco dije nada durante años y no vengo a hacerme el que aprendió la lección de una vez y para siempre. Igual hay una diferencia entre no preguntar y ni siquiera haberte hecho la pregunta por dentro, y esa diferencia aparece dos meses después, cuando alguien comenta que el proyecto se complicó un poco y vos ya sabés por dónde.