Cuando hice la transición de desarrollador senior a consultor IT, asumí que el movimiento era principalmente aditivo. Ya tenía la profundidad técnica. Solo agregaría perspicacia empresarial encima, aprendería a hablar con stakeholders no técnicos, y el resto se daría naturalmente.

Esa suposición me costó aproximadamente un año de frustrantes interacciones con clientes antes de entender qué era realmente diferente.

El Modelo Mental del Desarrollador

Como desarrollador senior, mi trabajo era resolver problemas técnicos correctamente. Corrección significaba: el código funciona, es mantenible, sigue buenos patrones, maneja casos borde, no crea problemas futuros. El rendimiento se medía en compilaciones limpias, tests que pasan y entregas a tiempo.

Este modelo mental es genuinamente valioso. También es completamente inadecuado para la consultoría.

Qué Están Comprando Realmente los Clientes

Los clientes no contratan a un consultor para obtener código correcto. Contratan a un consultor para obtener un resultado de negocio. El código es un medio para ese resultado, no el resultado en sí mismo.

Esto suena obvio por escrito. Es mucho menos obvio en la práctica, porque la brecha entre "técnicamente correcto" y "valioso para el negocio" es donde falla la mayoría de los consultores junior.

Una vez pasé dos días diseñando una elegante arquitectura orientada a eventos para un cliente que necesitaba su problema de sincronización de datos de clientes resuelto antes de una feria comercial en tres semanas. La arquitectura elegante era la respuesta correcta a largo plazo. Era completamente la respuesta equivocada para ese momento. Lo que necesitaban era una solución pragmática que pudiera implementarse en una semana, demostrarse en la feria, y migrarse a la mejor arquitectura después — en ese orden. Les di un diagrama en pizarra cuando necesitaban una fecha de entrega.

La Lente del P&L

El cambio de mentalidad que cambió todo para mí fue aprender a traducir cada decisión técnica en un impacto empresarial.

Cuando recomiendo microservicios sobre un monolito, el encuadre relevante no es "los sistemas distribuidos son más escalables" — es "así es como se ve el ciclo de despliegue de tu equipo hoy, así es como se vería después, este es el valor de ese ahorro de tiempo por trimestre, y este es el costo de la migración".

Cuando señalo una vulnerabilidad de seguridad, el encuadre relevante no es "esto viola las directrices de OWASP" — es "esta es una exposición de GDPR con una multa potencial de X, y un costo de remediación de Y, y esos dos números son por qué te lo estoy diciendo esta semana y no el próximo trimestre".

Cada recomendación necesita un número adjunto — ya sea el costo del problema o el valor de la solución. Sin esa traducción, estás hablando un idioma que suena extraño para un dueño de negocio, sin importar cuán técnicamente correcto seas.

Las Verdades Incómodas

Tu opinión importa menos de lo que pensás. Como desarrollador, construís lo que creés que es correcto y lo defendés. Como consultor, construís lo que el cliente necesita, explicás por qué es lo que necesitan, y a veces observás cómo eligen algo diferente — y luego ayudás a implementar ese algo diferente de la mejor manera posible.

El alcance es un entregable. Una de las cosas más valiosas que hace un consultor es definir qué NO está en el alcance. Los desarrolladores tienden a expandir el alcance cuando ven problemas interesantes. Los consultores definen límites y los protegen, porque el alcance no controlado es cómo los proyectos fallan presupuestos y plazos.

Las relaciones duran más que los proyectos. La reputación de un desarrollador se construye sobre lo que entregó. La reputación de un consultor se construye sobre si los clientes vuelven a llamarlos — y si esos clientes refieren a otros. Esto cambia cómo manejás las conversaciones difíciles, cómo entregás malas noticias y cuánta honestidad aportás cuando un cliente está a punto de cometer un error.

Lo que la Transición Realmente Requiere

Requiere ser genuinamente curioso sobre el negocio, no solo sobre el problema técnico. Cuando un cliente describe un flujo de trabajo, estoy escuchando la lógica del negocio, los puntos de dolor, las restricciones organizacionales y las dinámicas políticas — no solo el modelo de datos.

Requiere comodidad con la ambigüedad. Un desarrollador trabaja desde una especificación. Un consultor a menudo escribe la especificación. Esa es una posición de partida fundamentalmente diferente.

Y requiere aceptar que tu ego técnico tiene que tomar un asiento trasero. La solución técnicamente más impresionante raramente es la más apropiada. La solución más apropiada es la que se implementa, se usa realmente y entrega valor medible — independientemente de cómo sería recibida en una revisión de código.

Si sos un desarrollador senior pensando en hacer este cambio, lo más útil que puedo decirte es: pasá seis meses prestando mucha atención a las decisiones de negocio que rodean a las técnicas. Ahí es donde realmente sucede la consultoría.

Si querés hablar sobre cómo podría verse esta transición para tu situación específica, contactáme.