Hay una creencia cómoda en los equipos técnicos: que si uno programa bien el tiempo suficiente, lo demás llega solo. Que a los diez años uno ya sabe hablar con el negocio porque lo vio muchas veces.
No pasa. Un desarrollador con veinte años de oficio puede seguir sin saber qué contestar cuando un director le pregunta por qué la migración no se puede hacer en un fin de semana. Y no es por falta de inteligencia ni de experiencia: es porque nunca nadie le mostró la estructura de esa conversación, y la experiencia sola no la revela.
Por qué la experiencia sola no alcanza
Uno aprende de la experiencia cuando recibe una devolución clara. En lo técnico eso pasa todo el tiempo: el código compila o no, la prueba pasa o no, el sistema aguanta o se cae. La realimentación es inmediata, inequívoca y barata.
En la conversación con el resto de la empresa, nada de eso ocurre. Uno sale de una reunión donde le recortaron el plazo y no sabe si fue porque argumentó mal, porque el otro tenía una presión que no le contó, o porque la decisión ya estaba tomada antes de entrar. La devolución llega meses después, disfrazada de otra cosa, y casi nunca apunta a la causa.
Sin devolución clara no hay aprendizaje por repetición. Se repite el error con más años encima. Por eso hay gente con dos décadas de oficio que sigue entrando a las mismas reuniones y saliendo con el mismo resultado.
Las seis cosas que decide un proyecto y no están en el código
1. Estructurar una estimación para que se pueda defender
No estimar bien: presentar la estimación de forma que la discusión no sea un regateo. Un número solo se acepta o se recorta. Un rango con supuestos se discute, y discutir supuestos es una conversación que se puede ganar.
2. Traducir un problema técnico a consecuencias
«El módulo está acoplado» no significa nada del otro lado de la mesa. «Si tocamos facturación sin separar esto antes, cada cambio futuro va a costar el triple y el riesgo de romper la emisión de comprobantes es real» sí significa algo, porque habla de plata y de riesgo, que es el idioma de quien decide.
3. Decir que no sin decir que no
La negativa directa quema crédito y casi nunca es necesaria. Casi siempre existe una versión de «sí, sacando esto» que devuelve la decisión a quien corresponde y deja el recorte documentado.
4. Dejar rastro de las decisiones
Quién pidió, quién autorizó, qué se acordó. No por burocracia: porque a los tres meses nadie se acuerda, y el que no tiene el rastro pierde la discusión aunque tenga razón.
5. Anunciar un problema en el momento correcto
Un riesgo comunicado temprano es información y se agradece. El mismo riesgo comunicado tarde es una excusa y se castiga. La diferencia no está en el contenido: está en la fecha.
6. Escuchar lo que hay detrás del pedido
El pedido que llega ya trae una solución adentro, casi siempre mala. Encontrar el problema real antes de comprometerse ahorra semanas de trabajo que nadie iba a usar.
Por qué a nadie le enseñan esto
Vale preguntarse cómo puede ser que algo tan decisivo quede sistemáticamente afuera de la formación de un técnico. Hay tres motivos y ninguno es casual.
No entra en un plan de estudios. Una carrera enseña lo que se puede evaluar con un examen. Esto no se evalúa así: se evalúa mirando cómo alguien sostiene una posición cuando lo aprietan.
Se confunde con carácter. Existe la idea de que hay gente que «se maneja bien» y gente que no, como si fuera un rasgo de personalidad. No lo es. Es un conjunto de movimientos que se pueden describir, mostrar y practicar. La persona callada que aprendió la estructura sostiene una estimación mejor que la extrovertida que improvisa.
Los cursos de comunicación no lo cubren. Los talleres genéricos de comunicación o liderazgo trabajan con situaciones genéricas: escucha activa, asertividad, manejo de conflictos. Nada de eso le dice a un líder técnico qué contestar cuando auditoría le pide evidencia que no guardó. Es correcto y es inútil, porque la dificultad está en lo específico.
Lo que la formación agrega, en concreto
La diferencia práctica entre alguien formado en esto y alguien que no, se ve en cuatro situaciones que se repiten en todas las empresas:
- Cuando piden recortar un plazo. El no formado repite el número o cede. El formado ofrece una alternativa con su costo explícito y deja la decisión del otro lado.
- Cuando llega un pedido nuevo a mitad de proyecto. El no formado lo absorbe y se atrasa. El formado lo acepta mostrando qué se corre de fecha.
- Cuando algo se rompe en producción. El no formado explica la causa técnica. El formado comunica primero el impacto y el plazo de solución, y la causa después, si la piden.
- Cuando hay que pedir plata o gente. El no formado argumenta con necesidad técnica. El formado argumenta con costo de no hacerlo.
Ninguno de esos cuatro movimientos requiere saber más de tecnología. Los cuatro requieren haber pensado antes cómo se estructura esa conversación, y haberla practicado con alguien que devuelva qué funcionó y qué no.
Cómo se nota la diferencia en una reunión
Un ejemplo concreto, porque en abstracto todo esto suena razonable y no se ve.
Un gerente pregunta por qué el informe mensual no está listo. El desarrollador sin formación contesta lo que es cierto: que el proceso de cálculo tarda seis horas, que corre de noche, y que anoche falló porque el servidor de la base se quedó sin espacio. Todo verdadero, todo irrelevante para quien pregunta, y el efecto es que el gerente escucha una excusa técnica que no puede evaluar.
El mismo desarrollador con la estructura aprendida contesta en otro orden: «Lo tenés hoy a las tres. Falló el proceso de anoche por un tema de espacio en el servidor, ya está corriendo de nuevo. Para que no vuelva a pasar necesito que compremos disco, son tal cifra, y lo puedo pedir hoy si me lo autorizás.»
Mismos hechos, mismo tiempo de habla. La diferencia es el orden: primero cuándo lo tiene, después qué pasó, y al final un pedido concreto. El gerente sale de la conversación con una fecha y una decisión para tomar, en vez de con una explicación que no entiende.
La objeción honesta
Hay una objeción que merece respuesta: ¿no es esto simplemente política de oficina, y no debería un buen técnico poder trabajar sin eso?
La respuesta corta es que sería lindo y no es así. Un sistema de gestión no lo usa el equipo que lo hizo: lo usan áreas enteras con sus propias prioridades, sus propios jefes y sus propios miedos. Moverse ahí no es política sucia: es el trabajo. Ignorarlo no lo elimina, solo garantiza que las decisiones las tome otro.
Y hay algo más incómodo: cuando el equipo técnico no participa de esas conversaciones, las decisiones técnicas se toman igual, pero las toma alguien sin criterio técnico. Ese es el costo real de no aprender esto.
Se aprende como cualquier oficio
Con una situación por vez, practicándola, y recibiendo devolución de si funcionó. Igual que se aprende a programar: no leyendo sobre programación, sino escribiendo código y viendo qué falla.
Por eso nuestra formación no es un curso teórico sobre comunicación. Es una clase semanal donde se trabaja la conversación que alguien tuvo el jueves pasado, con las frases exactas, y donde la semana siguiente esa persona vuelve a contar cómo salió el intento.
Vea los tres planes o escríbanos para conversarlo con su caso.
