El precio de tener razón

Publicado el 4 de mayo de 2026  •  14 minutos  • 2805 palabras

La informática sería un sitio bastante más agradable si lo único que chocase fuesen ramas de Git. Pero no: chocan egos. Y cuando dos egos bien alimentados se encuentran en una daily, el merge conflict deja de estar en el código y pasa a estar en la sala.

En teoría, el desarrollo de software es ingeniería: requisitos, datos, benchmarks, decisiones razonadas. En la práctica, muchas discusiones técnicas se parecen sospechosamente a una pelea de bar, pero con términos como “idempotente” y “eventual consistency” en lugar de “me debes una caña”.

Lo sé de primera mano, porque he estado en los dos lados. He ganado discusiones que no merecía ganar y he perdido otras en las que tenía razón. Y en más de una ocasión he sido exactamente el odioso personaje que voy a describir a continuación, lo cual me da cierta autoridad moral para escribir sobre el tema, aunque también me exige reconocer cosas que, francamente, preferiría no reconocer.

Vamos a hablar de por qué nos importa más ganar la discusión que resolver el problema, de cómo se lía cuando entra en juego el ego de un CIO / CTO / Arquitecto Supremo del Universo, y de qué tácticas podemos usar para sobrevivir sin acabar odiando el oficio ni a nosotros mismos.

El problema de fábrica

La programación tiene un pequeño defecto de origen: te pasas el día tomando decisiones. Pequeñas, medianas, gigantes. Desde “¿cómo llamo a esta variable?” hasta “¿qué arquitectura definirá el futuro de este producto durante cinco años?”.

Eso, día tras día, refuerza una idea muy cómoda: mi criterio importa mucho. Y no está mal que sea así, el criterio importa. El problema empieza cuando el criterio y la identidad se fusionan hasta hacerse indistinguibles, de modo que cuestionar una decisión técnica se siente como cuestionar a la persona que la tomó.

La psicología lo explica con más elegancia de la que merece el asunto y le han llamado el efecto IKEA , que demuestra que valoramos desproporcionadamente las cosas que hemos construido nosotros mismos, independientemente de su calidad objetiva.

Aplicado al software: tu arquitectura te parece impecable en parte porque es tuya, no solo porque sea buena. Y la de tu compañero te parece peor, en parte porque es suya. El experimento original usaba muebles de IKEA a medio montar, pero tu cabeza reacciona igual que cuando alguien critica tu esquema de base de datos en una revisión de código.

A eso súmale que la mayoría hemos pasado por el síndrome del impostor, lo hemos combatido estudiando, currando y sacando cosas adelante, y estamos rodeados de gente igual de tozuda que nosotros.

El cóctel está servido: en muchas conversaciones técnicas no se enfrentan “dos opciones técnicas”, se enfrentan “mi identidad profesional” contra “la tuya”.

Y debajo de los argumentos sobre tabs vs espacios, monolito vs microservicios, o SQL vs “nos montamos un data lake y ya iremos viendo”, hay siempre el mismo subtexto: si acepto que tú tienes razón, ¿qué dice eso de mí?

Cuando el ego que tienes enfrente viene con cargo en LinkedIn

Una cosa es discutir con un compañero de tu mismo nivel. Otra muy distinta es cuando el ego viene acompañado de título: CIO, CTO, CISO, Head of Something, Arquitecto Global, Tech Lead de Cliente, “Responsable de Tecnología desde 1998 cuando esto era COBOL y los hombres éramos hombres”.

El escenario es tan predecible que casi tiene coreografía propia. Tu equipo llega con una propuesta razonada (habéis mirado requisitos, restricciones, presupuesto, os habéis peleado entre vosotros antes de presentarlo, que también es parte del proceso) , y el responsable del cliente ya ha decidido que la solución buena es otra “porque lo he visto en otra empresa / me lo ha dicho un colega / lo vi en una charla / me gusta su logo”.

Entonces tú presentas datos. Él asiente despacio con la cabeza mientras tú hablas, con esa cara que tiene la gente cuando está esperando que termines para decirte lo que ya había decidido antes de entrar en la sala.

Y cuando acabas: “ya, pero aquí siempre hemos usado esto y nos ha ido bien”. Y cuando señalas riesgos concretos: “eso será en otros sitios, aquí no nos afecta”.

La traducción simultánea de todo eso es: no voy a cambiar de opinión porque llevo meses vendiéndosela al comité de dirección. Si ahora cede, no es cambiar de criterio: es admitir que igual ha estado vendiendo humo. Y eso, en muchos entornos, es peor que equivocarse.

La psicología social lo llama consistencia comprometida (Influence ): una vez que alguien ha expresado públicamente una posición, el coste psicológico de cambiarla es enorme, porque cambia la percepción que los demás tienen de su coherencia.

Dicho de otra manera: tiene más miedo a parecer inconsistente que a estar equivocado. Y la racionalidad, ante eso, tiene tan poco que hacer como una PR bien documentada contra un “no, es que no me gusta”.

He estado en esa situación más veces de las que me gustaría. Y he de reconocer que no siempre mantuve la cabeza fría. En alguna ocasión me dejé llevar por la frustración y convertí lo que debería haber sido una conversación técnica en algo parecido a un combate de boxeo de baja intensidad, donde ninguno de los dos ganó nada útil y la relación quedó tocada.

La rabia cuando sabes que tienes razón y el otro no quiere escucharla es una emoción genuinamente difícil de gestionar, y quien diga que siempre lo hace bien, miente o no ha estado en situaciones suficientemente intensas.

El ego técnico: cuando la discusión es sobre rendimiento pero lo que nos jugamos es el orgullo

Dejando aparte los títulos y el organigrama, hay otro tipo de batalla de egos que es más cotidiana y, en cierto modo, más perniciosa porque es más difícil de identificar. Es la discusión sobre “la forma correcta” de hacer algo entre pares: dos seniors, dos arquitectos, dos personas que llevan años en esto y tienen opiniones fuertes y bien fundadas.

El patrón es siempre parecido. Una persona defiende que su solución es más eficiente. La otra dice que la del primero es sobreingeniería y que la suya es más simple. El primero responde que no es sobreingeniería sino pensar a futuro, y el segundo replica que pensar a futuro en este contexto concreto es complicarse la vida por si alguna vez crecemos como Netflix, cosa que probablemente no ocurrirá.

En realidad los dos suenan razonables. El problema es que ninguno está dispuesto a decir “vale, quizás en este contexto concreto gana la tuya”, porque eso se sería como rendirse, y rendirse, incluso ante un buen argumento, activa los mismos mecanismos cerebrales que una amenaza física.

Amy Arnsten , una neurocientífica de Yale, ha documentado cómo el estrés del ego amenazado reduce el flujo sanguíneo al córtex prefrontal, la parte que nos hace razonables. En lenguaje humano: cuando alguien te lleva la contraria en algo que consideras tuyo, tu cerebro entra en modo pelea-o-huye antes de que puedas procesar si el argumento contrario tiene algún mérito.

Y esto es importante porque significa que la mayoría de las discusiones técnicas que degeneran no degeneran por falta de inteligencia ni por falta de información, sino que degeneran porque el cerebro de los participantes ha dejado de estar en modo “resolver problemas” y ha entrado en modo “ganar el combate”. Lo cual es un desperdicio monumental de talento técnico y, además, aburre a todo el equipo que está alrededor mirando.

Cómo sobrevivir (y a veces ganar) sin hacerse daño

Lo que sigue viene de mezclar experiencia propia, algunos (muchos) golpes, bastante lectura (y videos de youutube) sobre psicología aplicada y el consejo de gente que navegaba mejor que yo estos mares.

No es una receta infalible, es lo que me ha funcionado con más frecuencia.

Cambiar el ring

Mientras la discusión sea “tu idea” contra “mi idea”, estamos fastidiados.

La palanca más útil es intentar mover la conversación de “dos personas con dos posiciones” a “un equipo con un problema”.

Frases como “¿qué riesgo estamos aceptando si vamos por aquí?” o “imaginemos que esto falla en producción dentro de un año, ¿qué escenario preferimos estar gestionando?” sacan a la gente del modo gladiador y la ponen en modo responsable.

No siempre funciona, pero cuando funciona, funciona bien, porque el otro ya no tiene que perder para que tú ganes: los dos estáis mirando hacia el mismo lado.

Poner datos encima de la mesa, pero con cariño

Los datos ayudan, pero usados como arma son contraproducentes.

Nada de “ves, te lo dije”, ni de presentar un benchmark como si fuese una sentencia del Tribunal Supremo. Aunque la tentación de hacerlo es fuerte, y momentaneamente satisfactoria, como dar una bofetada con el dorso de la mano, así como con desprecio.

La forma que mejor funciona, sin entrar en duelos con navaja y manta, es hacer pequeñas pruebas de concepto con métricas claras, presentar resultados como “esto es lo que vemos, no lo que yo opino”, y darle a la otra persona una salida digna.

“Con A tardamos X y con B tres veces más. Si el rendimiento pesa, parece que A nos da más margen. Si preferimos simplicidad ahora, podemos ir con B sabiendo qué estamos aceptando.”

Le estás dando al otro la posibilidad de cambiar de opinión porque los datos han cambiado la situación, no porque “tú eras más listo”. La diferencia, en términos de cómo se procesa emocionalmente, es enorme.

La táctica del “consta en acta”

Hay casos en los que simplemente no vas a ganar. El responsable tiene más poder, el cliente paga, o la decisión política ya está tomada antes de que nadie te haya preguntado.

En esos casos, la opción más sana para ti, para tu equipo y para tu futuro yo cuando alguien pregunte “¿y quién decidió esta locura?”, es exponer tus argumentos por escrito, de forma clara y sin dramatismo: riesgos, alternativas, costes previsibles.

Has de dejar constancia de que tu recomendación técnica es otra, de que acatas la decisión, y de que los riesgos identificados son los que son.

No es pasivo-agresivo si se hace con buenas formas. Es simplemente proteger al proyecto de la amnesia selectiva corporativa, que es un fenómeno tan documentado como el efecto IKEA y bastante más dañino a largo plazo.

Elegir las batallas, aunque duela el orgullo

Hay una frase que se aprende a base de golpes: tener razón es carísimo.

No todas las colinas merecen que mueras encima de ellas.

Antes de enrocarte, merece la pena preguntarse si este tema va a importar de verdad dentro de seis meses, si el coste de pelear (tiempo, desgaste, relación) compensa el beneficio técnico, o si hay una solución suficientemente buena que te permita vivir con ella.

Dejar pasar una API discutible o un naming que no te gusta, a cambio de conservar el crédito para cuando toque pelear por algo gordo (seguridad, arquitectura de fondo, deuda técnica que va a hundir el producto) es a menudo la decisión más inteligente disponible.

No la más satisfactoria, pero sí la más inteligente.

Trabajar el ego propio: el único que sí puedes tunear

La parte menos divertida de este tratado es que tu ego también está jugando. Siempre. Incluso cuando “objetivamente tienes razón”.

Se nota cuando te cuesta horrores decir “no lo sé”, cuando te enfadas más por el tono que por el contenido, o cuando solo aceptas una idea ajena después de pasar por una fase en la que la reformulas tú para sentirla como tuya.

Lo reconozco porque me ha pasado todo eso y probablemente me seguirá pasando. La diferencia entre ahora y hace diez años es que ahora lo identifico antes, aunque no siempre a tiempo.

La gente que navega bien en entornos llenos de egos suele saber escuchar de verdad, sin estar mentalmente preparando la réplica mientras el otro habla, sabe ceder en cosas pequeñas sin sentir que pierde prestigio, y sabe poner límites cuando hace falta sin montar un drama.

Tres cosas aparentemente sencillas que, en la práctica, cuestan una barbaridad.

Tratar con el ego del cliente: ni alfombra roja ni ariete

Cuando el ego complicado es el del cliente (externo o interno da igual), entra en juego dinero, contrato y una asimetría de poder que hace todo más delicado. Hay algunas cosas que funcionan con más frecuencia de la que cabría esperar.

Nunca ridiculizar en público. Si tienes que llevarle la contraria a alguien con cargo, mejor en una conversación uno a uno o en un foro reducido donde no se sienta acorralado delante de su equipo. El ego herido en público es gasolina pura: consigues que la persona se cierre en banda, que el resto de la sala se ponga de su lado por solidaridad de tribu, y que tu argumento técnico, aunque sea impecable, quede asociado al momento incómodo en lugar de a su contenido.

La psicología social tiene un nombre para esto: el efecto backfire , que describe cómo las personas con creencias fuertemente arraigadas a menudo se afianzan más en ellas cuando se les presenta evidencia contraria de forma amenazante. Es contradictorio y exasperante, pero es real.

Aliarse con quien sufre las consecuencias. A menudo hay gente dentro de la propia organización del cliente que ve los mismos riesgos que tú (operaciones, soporte, el equipo de seguridad que lleva meses diciendo lo mismo que tú acabas de proponer). Si alineáis mensajes, el peso es muy distinto al de “el consultor externo pesado que quiere vender más horas”.

Y hablar en el idioma del interlocutor: a un CIO le importan riesgos de negocio, compliance, costes que aparecen en un titular de prensa; a un CTO le importa la deuda técnica y la velocidad del equipo; a un CMO le importa lo que puede afectar a la marca. Traducir los argumentos técnicos a esas monedas funciona mucho mejor que hablar de patrones de diseño a alguien que lleva veinte años sin escribir una línea de código.

En última instancia, si aun así no entra, toca decidir si tu papel en esa relación es el de asesor que recomienda y documenta o el de mártir que se deja la salud intentando salvar a quien no quiere ser salvado.

Ambas son posiciones legítimas. Solo conviene elegir la que eliges, no quedarte en tierra de nadie por incapacidad de aceptar que a veces la gente prefiere equivocarse a que le ayudes.

Menos gladiadores, más adultos con logs

El desarrollo de software ya es bastante difícil por sí mismo: requisitos cambiantes, tecnología en movimiento perpetuo, bugs que solo aparecen cuando mira el jefe, estimaciones que todo el mundo sabe que son ficción pero que todo el mundo firma igualmente. Si además convertimos cada decisión técnica en un combate de egos, no es raro que acabemos quemados antes de tiempo.

No se trata de aspirar a un mundo sin conflictos, eso no existe y, francamente, tampoco sería saludable; la tensión constructiva produce mejores sistemas que el consenso amable y tibio.

Se trata de discutir fuerte sobre ideas sin que se convierta en guerra sobre identidades, de usar datos como faro en lugar de como arma, de aprender a perder batallas pequeñas para ganar guerras grandes, y de dejar constancia de cuando vemos venir el iceberg, aunque no para gritar “¡te lo dije!” cuando encalle, sino porque quizás la próxima vez, si el historial está ahí, alguien escuche antes.

Al final, todos queremos lo mismo: que el sistema funcione, que producción no arda todos los viernes y que podamos irnos a casa con la sensación de haber hecho un trabajo decente.

Si para eso hay que pinchar un poco el propio ego, y yo sé por experiencia propia que no siempre está uno dispuesto a hacerlo, y hemos de aprender a manejar el ajeno, quizá sea un precio razonable.

Aunque siempre podemos hacer un fork mental y fantasear con un universo paralelo donde la mayor pelea del día es si el README va en inglés o en castellano.

Y donde yo, en ese universo, siempre mantengo la cabeza fría.

Fuentes y referencias

No todo en este artículo es experiencia en carne propia. Aquí están las personas que se tomaron la molestia de demostrar con datos lo que muchos ya intuíamos a base de reuniones.

• The “IKEA effect”: When labor leads to love - Norton, Mochon y Ariely (2012). Estudio sobre por qué valoramos desproporcionadamente lo que construimos nosotros mismos.
• Influence: The Psychology of Persuasion - Robert Cialdini. El libro de referencia sobre persuasión social y consistencia comprometida.
• Stress signalling pathways that impair prefrontal cortex structure and function - Amy Arnsten (2009). Sobre cómo el estrés reduce la capacidad de razonamiento del córtex prefrontal.
• When Corrections Fail: The persistence of political misperceptions - Nyhan y Reifler (2010). El estudio que documentó el efecto backfire: cómo la evidencia contraria puede reforzar creencias erróneas.