6 min read
Dos ingenieros senior, mismo nivel, sin jerarquía entre ellos.
Uno quiere resolver el problema con un microservicio nuevo.
El otro insiste en que un módulo dentro del monolito actual es suficiente y más simple.
Ninguno está técnicamente “equivocado” — son dos trade-offs (intercambios) válidos con distintas prioridades.
La conversación lleva cuarenta minutos, el tono empezó a subir, y ya no se está discutiendo arquitectura: se está discutiendo quién tiene razón.
Este escenario es distinto al de un code review, donde suele haber cierta jerarquía implícita (quien revisa, quien envía el código) o al menos un cambio concreto sobre la mesa.
Acá hablamos de decisiones de arquitectura o enfoque entre pares, donde ambos tienen legitimidad técnica igual, y el desacuerdo puede escalar mucho más fácil hacia lo personal.
¿Por qué estas discusiones se vuelven personales tan rápido?
Cuando discutís código ajeno en un review, hay cierta distancia: el código es de la otra persona, vos das tu opinión sobre él.
Cuando dos personas discuten un enfoque de arquitectura que ninguna escribió todavía, la discusión se mueve al terreno de las ideas propias — y defender una idea propia se siente mucho más personal que comentar código ya escrito.
Sumale que ambos tienen experiencia real respaldando su posición, y es fácil que el desacuerdo técnico se convierta en una competencia de ego sin que nadie lo haya buscado.
El primer paso: separar el “qué” del “por qué”
La mayoría de los desacuerdos técnicos que se sienten irreconciliables, en realidad esconden un desacuerdo sobre prioridades, no sobre hechos.
Antes de defender tu posición, hacé explícito el criterio detrás de ella:
- “Yo prioricé velocidad de desarrollo a corto plazo.”
- “Yo prioricé facilidad de escalar el equipo — que distintas personas puedan tocar distintas partes sin pisarse.”
Cuando ambos ponen su criterio sobre la mesa, muchas veces se descubre que no hay un desacuerdo técnico real — hay una diferencia legítima de qué se está optimizando, y esa es una conversación de negocio, no de “quién sabe más de arquitectura”.
Disagree and commit (discrepar y comprometerse)
Este concepto, popularizado por Amazon en sus principios de liderazgo, describe algo simple pero poderoso: podés seguir en desacuerdo genuino con una decisión, y aun así comprometerte completamente a ejecutarla como si fuera la tuya.
No es resignación pasivo-agresiva (“bueno, hagan lo que quieran”) — es un compromiso activo con el resultado, incluso sin estar 100% convencido.
¿Cuándo aplica?
Cuando ya se escuchó el argumento completo, cuando la decisión no es catastrófica si resulta equivocada, y cuando seguir discutiendo tiene más costo que simplemente probar un camino y aprender.
La alternativa — bloquear indefinidamente hasta lograr consenso total — paraliza equipos enteros por decisiones que, honestamente, ninguna de las dos opciones iba a hundir el proyecto.
Cuándo SÍ vale la pena seguir insistiendo
Disagree and commit no significa ceder ante cualquier decisión. Algunas señales de que vale la pena insistir más:
- La decisión es difícil o costosa de revertir (elegir base de datos, lenguaje, proveedor cloud).
- Tenés evidencia concreta — no solo intuición — de un riesgo real que la otra persona no está viendo.
- El desacuerdo revela un problema más profundo que vale la pena resolver antes de avanzar (por ejemplo, objetivos de equipo poco claros).
Mecanismos para desbloquear el empate técnico
1. Traer datos, no solo opinión
“Yo creo que esto va a ser más lento” pesa menos que un benchmark rápido de treinta minutos que muestre números reales.
Cuando el desacuerdo puede resolverse con evidencia, conseguir esa evidencia suele ser más rápido — y más objetivo — que seguir debatiendo en abstracto.
2. Hacer un spike acotado en lugar de decidir en el aire
Si ambos enfoques son razonables en el papel, un spike (investigación breve y acotada) de un día implementando un prototipo mínimo de cada opción puede revelar problemas que ninguna discusión teórica iba a sacar a la luz.
3. Escribir un ADR con ambas alternativas documentadas
Ya hablamos de los ADR (Architecture Decision Records) como forma de documentar decisiones.
En un desacuerdo entre pares, escribir el ADR juntos — incluyendo explícitamente la alternativa que no se eligió y por qué — tiene un efecto adicional: obliga a ambas partes a articular el trade-off con precisión, lo cual por sí solo suele destrabar la conversación.
4. Pedir una tercera opinión, sin que sea un desempate jerárquico
Traer a alguien más del equipo no para que “decida quién gana”, sino para que aporte una perspectiva que ninguno de los dos consideró.
El objetivo es ampliar el criterio disponible, no delegar la decisión en una autoridad externa.
Frases que ayudan a bajar la temperatura
- “Creo que estamos optimizando cosas distintas. ¿Qué estás priorizando vos con este enfoque?”
- “No estoy convencido, pero entiendo el razonamiento. ¿Probamos tu enfoque y revisamos en dos semanas cómo se sintió?”
- “¿Qué tendría que pasar para que yo cambie de opinión, o para que vos cambies la tuya?”
Conclusión
Los desacuerdos técnicos entre pares no son un problema a evitar — son una señal de que hay personas pensando con criterio propio, que es exactamente lo que querés en un equipo senior.
El problema no es el desacuerdo en sí, es cuando se maneja sin estructura y termina midiendo egos en lugar de evaluando trade-offs.
Separar el qué del por qué, saber cuándo aplicar disagree and commit, y apoyarse en datos en lugar de solo opinión — eso es lo que convierte un desacuerdo incómodo en una decisión mejor de la que cualquiera de los dos hubiera tomado solo.
Recordá suscribirte aquí para recibir los próximos posts directamente en tu correo.
Referencias:
Amazon Leadership Principles — Have Backbone; Disagree and Commit
Crucial Conversations — Kerry Patterson, Joseph Grenny