El código no se defiende solo: Por qué los mejores proyectos de software necesitan “política”, no solo ingeniería.

La mentira de la meritocracia técnica

Existe una creencia ingenua en el mundo del desarrollo de software: “la mejor solución técnica siempre gana”.

Si el código es limpio, la arquitectura es sólida y los tests pasan, el proyecto será un éxito. Los ingenieros a menudo operan bajo esta ilusión, asumiendo que las decisiones se toman en un vacío de lógica pura.

La realidad es mucho más desordenada.

He visto proyectos brillantes morir en el olvido y plataformas mediocres convertirse en el estándar de la industria. La diferencia rara vez fue la calidad del código. La diferencia fue que alguien, en una sala de reuniones, supo vender la idea, alinear los miedos del CEO con el presupuesto del CFO y la urgencia de Marketing.

A eso lo llamamos “política”. Y en la ingeniería de software, es una palabra sucia.

El peligro del desarrollador “purista”

Es común escuchar a desarrolladores decir: “Yo no me meto en política, a mí páguenme por programar”.

Esa frase, que suena a integridad profesional, es en realidad una bandera roja gigantesca.

El desarrollador que “evita la política” es el que permite que se tomen decisiones desastrosas. Es el que se queda callado cuando se elige una tecnología de moda pero inestable, simplemente porque no quiso tener la conversación difícil con el gerente de producto. Es el que deja que la deuda técnica se acumule hasta que el sistema colapsa, porque no supo explicar el riesgo en términos financieros.

La abstención no es neutralidad. Es negligencia.

Si tu equipo técnico no está en la mesa donde se toman las decisiones, no tienes un equipo de ingeniería; tienes una fábrica de tickets. Y las fábricas no innovan, solo ejecutan órdenes, incluso las malas.

Redefiniendo la “Política” como Arquitectura Humana

En Atelier Busco, tenemos una visión distinta. No vemos la “política” como manipulación de pasillo o chisme. La vemos como la ingeniería de las relaciones humanas necesarias para desplegar software.

Un sistema de software complejo no es solo código corriendo en servidores; es un sistema sociotécnico. Refleja la estructura de comunicación de la organización que lo construye (la Ley de Conway).

Por eso, nuestro trabajo como socios técnicos no empieza en el editor de código. Empieza entendiendo el mapa de poder y dolor de la organización:

• ¿Qué es lo que realmente le quita el sueño al Gerente de Operaciones? (Probablemente no es la latencia de la API, sino que los pedidos no salgan a tiempo).
• ¿Cuál es el riesgo real para el Inversionista?
• ¿Por qué el equipo de Ventas odia el CRM actual?

Hacer estas preguntas es “hacer política”. Y es la única forma de construir algo que la gente realmente use.

El Código necesita un Abogado

Las buenas decisiones técnicas a menudo son contraintuitivas para el negocio a corto plazo.

• “¿Por qué vamos a tardar dos semanas en refactorizar si no añade features nuevas?”
• “¿Por qué usar esta tecnología ‘aburrida’ en lugar de la nueva que salió en Twitter?”

El código no puede levantarse y defenderse solo. Necesita un traductor. Necesita a alguien que pueda mirar a los ojos a un directivo y decirle: “Si no hacemos esto ahora, en seis meses tu costo operativo se duplicará”.

Esa capacidad de persuasión y alineación es tan técnica como saber configurar un clúster de Kubernetes. De hecho, es más escasa.

Busca un Socio que entre a la Sala

La próxima vez que busques un socio tecnológico, no mires solo su GitHub. Pregúntale cómo maneja el desacuerdo. Pregúntale cómo convenció a un cliente de no construir algo.

Necesitas a alguien que no solo sepa escribir la solución, sino que sepa navegar la complejidad humana para que esa solución vea la luz.

Porque al final del día, el software no se trata de computadoras. Se trata de personas poniéndose de acuerdo para resolver un problema usando computadoras. Y eso, inevitablemente, es política.