Cómo tomar mejores decisiones tecnológicas sin ser experto

En algún momento, todo empresario o gerente se enfrenta a una decisión que suena técnica pero tiene patas de negocio. Tu equipo te dice que hay que elegir entre dos formas de construir algo. Tu proveedor te recomienda una tecnología que no conocés. Un desarrollador te advierte que si no migran a tal plataforma, el sistema va a colapsar.

Y vos tenés que decidir. Sin saber programar. Sin entender del todo qué implica cada opción. Con la sensación de que tu voto vale menos porque no entendés los detalles.

La buena noticia es que las decisiones tecnológicas importantes rara vez se juegan en los detalles técnicos. Se juegan en criterios que cualquier persona de negocio puede evaluar: costo a largo plazo, riesgo, dependencia de terceros, capacidad de adaptación. Este artículo te da un marco para participar en esas decisiones con criterio, no con conocimiento de código.

Por qué las decisiones técnicas no deberían ser solo técnicas

Cuando una decisión sobre tecnología se delega completamente en el equipo técnico, se responde la pregunta correcta — ¿esto funciona? — pero se ignoran otras igual de importantes: ¿esto nos deja dependiendo de un solo proveedor? ¿Cuánto cuesta mantenerlo? ¿Qué pasa si necesitamos cambiarlo en dos años? ¿Esto escala con el negocio o solo funciona para el volumen actual?

Estas preguntas no requieren saber programar. Requieren entender el negocio. Y ahí tu voz pesa más que la de cualquier desarrollador.

Las preguntas que deberías hacer ante cualquier decisión técnica

Cuando tu equipo o proveedor te presenten una recomendación técnica, estas preguntas te ayudan a evaluarla desde el negocio:

1. ¿Qué pasa si dentro de dos años queremos cambiar esto por otra cosa?

Toda tecnología elegida hoy puede volverse obsoleta o inadecuada mañana. La pregunta no es si esta tecnología es la mejor hoy, sino qué tan costoso y difícil sería migrar a otra si hiciera falta. Tecnologías muy propietarias, muy específicas o con comunidades muy chicas suelen implicar un costo de salida alto.

2. ¿De quién dependemos si elegimos este camino?

¿Dependemos de una empresa que puede cambiar los precios o las condiciones? ¿Dependemos de un proveedor que es el único que sabe cómo funciona esto? ¿Dependemos de una tecnología que solo domina una persona del equipo? La dependencia es un riesgo de negocio, no técnico.

3. ¿Cuánto cuesta mantener esto, más allá de construirlo?

El costo inicial de una tecnología puede ser bajo y su mantenimiento, alto. O al revés. Pedí que te expliquen el costo total estimado a tres o cinco años, no solo el costo de implementación. Incluí licencias, servidores, horas de mantenimiento y actualizaciones.

4. ¿Qué estamos sacrificando al elegir esto?

Toda decisión técnica implica un trade-off. Algo se gana y algo se pierde. Que te lo expliciten: "ganamos velocidad de desarrollo pero perdemos flexibilidad a futuro", "ganamos ahorro de costos pero dependemos de un proveedor externo", "ganamos una solución probada pero tenemos que adaptar nuestros procesos a cómo funciona esa solución". Entender el trade-off es más importante que entender la tecnología.

5. ¿Cuántas personas en el mercado saben trabajar con esto?

Elegir una tecnología que casi nadie conoce puede ser una ventaja competitiva, pero también puede significar que cuando necesites contratar a alguien que la domine, te cueste mucho encontrarlo y te salga muy caro. El tamaño de la comunidad y la disponibilidad de talento son variables de negocio.

Cómo evaluar una recomendación técnica sin entender los detalles

No necesitás saber si GraphQL es mejor que REST para evaluar una recomendación. Pero sí podés evaluar:

La calidad del argumento, no de la conclusión. ¿El equipo te explica el porqué en términos que podés entender o te responde con jerga técnica que no aclara nada? Un buen profesional técnico puede explicar sus decisiones en lenguaje de negocio. Si no puede, o no entiende el negocio o está ocultando algo.

La consideración de alternativas. ¿Evaluaron más de una opción? ¿Te pueden contar por qué descartaron las otras? Si solo consideraron una alternativa, la decisión no fue una decisión: fue una preferencia.

Los riesgos identificados. ¿Te mencionan qué puede salir mal, o solo te cuentan lo bueno? Si una recomendación técnica no incluye una sección de riesgos, es una recomendación incompleta.

La opinión de una segunda fuente. Si la decisión es importante, pedí que alguien externo — otro desarrollador, otro proveedor — revise la recomendación y te dé su opinión. No para que te diga qué hacer, sino para que te señale lo que la recomendación original no está diciendo.

Tres reglas para no delegar lo indelegable

Regla 1: La decisión de depender de un tercero es tuya, no del equipo técnico. Si la tecnología propuesta implica que tu empresa queda atada a un proveedor específico, a una licencia que se renueva anualmente o a una plataforma que puede cambiar sus condiciones, vos tenés que dar el visto bueno. Es una decisión de riesgo de negocio, no de arquitectura.

Regla 2: La decisión de cuánto invertir en el futuro es tuya. Cuando el equipo propone hacer algo "bien desde el principio" en lugar de "rápido ahora y después mejoramos", están planteando un trade-off entre velocidad actual y costo futuro. Ese balance lo definís vos, no el que escribe el código.

Regla 3: La decisión de cuándo algo es suficientemente bueno es tuya. Los equipos técnicos tienden a buscar la solución óptima. Pero en un negocio, lo óptimo técnico puede no ser lo óptimo económico. A veces alcanza con algo que funcione bien para los próximos dos años, aunque no sea la solución más elegante del mundo.

No saber programar no te inhabilita para decidir sobre tecnología. Te obliga a decidir sobre lo que realmente importa: el riesgo, el costo, la dependencia y el futuro de tu empresa. Lo demás son detalles que podés delegar. Para seguir profundizando, te recomendamos cuánto cuesta realmente una mala decisión tecnológica y qué validar antes de invertir en desarrollo.