Ser agnóstico en tecnología no es lo mismo que ser generalista

“Agnóstico en tecnología” aparece en los sitios web de muchas empresas de servicios. A veces significa algo útil. A veces significa que la empresa acepta cualquier proyecto y resuelve el stack sobre la marcha. Para quien compra, la diferencia importa mucho.

Este artículo explica qué entendemos por el término, por qué importa para empresas con sistemas ya establecidos y cómo distinguir a un aliado de verdad agnóstico de uno generalista.

Dos problemas de los aliados con un stack favorito

Muchas firmas de desarrollo están construidas alrededor de una tecnología. Ese enfoque puede ser una fortaleza, pero crea dos problemas para los clientes que ya tienen sistemas en producción.

La recomendación es predecible. Pregúntale a una firma construida alrededor de un framework cómo resolver tu problema y la respuesta casi siempre incluirá ese framework. A veces es lo correcto. Muchas veces significa reescribir algo que funciona o sumar una tecnología que tu equipo tendrá que soportar sin las personas que la eligieron.

El equipo es difícil de escalar según tus necesidades. Tus sistemas evolucionan. Puedes tener una plataforma principal en un stack, integraciones en otro, una app móvil en un tercero y un CRM con su propio modelo de desarrollo. Un aliado que solo cubre uno de ellos se vuelve un proveedor más que gestionar.

Agnóstico como empresa, especialista en cada proyecto

La definición útil de agnóstico en tecnología tiene dos partes:

• Como empresa, el aliado no tiene un stack que vender. Trabaja con distintos lenguajes, frameworks, nubes y plataformas, y elige según la situación del cliente.
• En cada proyecto, el equipo es especialista en el stack del cliente. Los ingenieros asignados a tu equipo conocen bien tus tecnologías y adoptan tus convenciones, herramientas y patrones.

La segunda parte es la que separa a un aliado agnóstico de uno generalista. No quieres ingenieros que sepan un poco de muchas cosas trabajando en tu producto. Quieres ingenieros que conozcan a fondo tu stack, de una empresa capaz de conformar equipos para cualquier stack.

Por qué importa adoptar el stack nativo

Cuando un equipo aumentado adopta tu stack nativo en lugar de introducir el suyo, pasan varias cosas:

• Tus ingenieros internos pueden revisar, mantener y ampliar el trabajo. No queda nada que solo entienda el aliado.
• Tus herramientas actuales siguen funcionando: pipelines de CI/CD, observabilidad, escaneo de seguridad, estándares de código.
• Contratar sigue siendo sencillo. Si más adelante internalizas el trabajo, las habilidades que necesitas son las que ya contratas.
• El riesgo se mantiene bajo. Cada tecnología nueva en producción es una nueva fuente de incidentes, actualizaciones y vulnerabilidades. Evitar las innecesarias es una decisión de confiabilidad.

Esto es especialmente importante para empresas que han crecido mediante adquisiciones o que acumulan años de sistemas. El objetivo es mejorar lo que existe, no agregar otra capa.

Cuándo una tecnología nueva es la respuesta correcta

Ser agnóstico no significa no recomendar nunca un cambio. A veces el stack existente es el problema: un framework sin soporte, una plataforma que no escala, un riesgo de seguridad. En esos casos, un aliado agnóstico está mejor posicionado para recomendar el cambio, porque no tiene interés en qué tecnología gane.

La prueba es si la recomendación viene con una razón clara ligada a tu situación (costo, riesgo, escala, contratación) y un plan para migrar de forma incremental. Nuestro artículo sobre modernizar un monolito sin detener la entrega describe ese tipo de plan.

Donde manda la especialización

Hay plataformas en las que la profundidad importa más que la amplitud desde la primera conversación. Salesforce es el ejemplo más claro. Una empresa que opera sus ventas, su servicio o su canal de aliados sobre Salesforce necesita ingenieros que entiendan su modelo de datos, su automatización, su modelo de seguridad y sus límites, no un generalista que los aprende en el camino.

En esos proyectos lideramos con nuestra experiencia en Salesforce y no con el agnosticismo, y la composición del equipo depende del cliente y del estado de la org. Nuestro artículo sobre conectar apps de campo con Salesforce cubre un ejemplo de ese trabajo.

Cómo distinguir agnóstico de generalista

Al evaluar un aliado que se describe como agnóstico en tecnología, pregunta:

1. ¿Qué ingenieros trabajarían en nuestro stack y qué han construido con él? Busca experiencia específica, no afirmaciones a nivel de empresa.
2. ¿Cómo se incorporan a un código existente? Una buena respuesta incluye entender la arquitectura, adoptar las convenciones y trabajar dentro de los pipelines existentes.
3. ¿Cuándo fue la última vez que recomendaron a un cliente mantener su tecnología actual? Un aliado agnóstico puede mostrar casos donde la respuesta correcta fue no cambiar.
4. ¿Qué pasa cuando un proyecto necesita una tecnología que el equipo asignado no domina? Busca una forma de sumar especialistas, no un plan para aprender con tu tiempo.
5. ¿Quién apoya al equipo en los problemas complejos? En nuestro modelo, ingenieros senior y tech leads intervienen a medida que crece la complejidad, desde desbloquear al equipo hasta horas on-demand para trabajo complejo.

En resumen

Ser agnóstico en tecnología debería significar que el aliado se adapta a ti, no al revés: ningún stack favorito que vender y un equipo que trabaja en tu stack como si fuera propio. Así trabajamos en Imagina Devs, con el respaldo de más de 20 años de entrega en muchas tecnologías.

Si necesitas ingenieros que puedan trabajar dentro de tus sistemas existentes, hablemos.