Tomar el control de un área tecnológica puede venir con una presión inmediata: demostrar impacto rápido. Pero varios miembros del Forbes Technology Council sostienen que, antes de tocar sistemas o emprender una gran iniciativa, el primer paso debe ser entender qué existe, quién usa qué y dónde se concentran los problemas reales.
Jeetendra Gangele, de BluePill, dijo que su primer movimiento no fue un cambio, sino una lista de lo que no cambiaría durante 12 meses. A su juicio, los nuevos líderes subestiman el miedo que traen consigo y, por eso, la confianza suele ser más barata de construir antes de una reforma que después.
La misma lógica aparece en otras recomendaciones. Adarsh Naidu, de Amazon Web Services, planteó que lo más valioso es agendar reuniones uno a uno con cada actor clave y escuchar mucho más de lo que se habla. Pidió preguntar qué funciona, qué está roto y qué espera la gente que alguien arregle por fin.
Deniz Gezgin, de Eightpoint, también insistió en escuchar a quienes están más cerca del trabajo para saber dónde se pierde tiempo, dónde se traban las decisiones y qué sistemas realmente generan valor. Según él, comparar lo que la dirección cree que ocurre con lo que viven los empleados cada día ayuda a tomar decisiones más inteligentes y a construir confianza.
Nidhi Jain, de CloudEagle.ai, fue más allá: recomendó inventariar todo lo heredado antes de tocarlo. Mencionó aplicaciones SaaS, cuentas de servicio e integraciones en funcionamiento, y advirtió que no se puede rediseñar un sistema que no se ha mapeado. Para ella, el mejor primer paso es silencioso: pasar el primer trimestre averiguando qué hay realmente.
Marcin Nowak, de Decerto, propuso medir cuánto tarda un cambio pequeño en llegar a producción. Contó que en algunas aseguradoras ese número resultó ser de seis a nueve meses y que nadie en la dirección lo sabía. Ese dato, afirmó, dice más sobre lo que se puede prometer que una revisión de arquitectura o una evaluación de proveedores.
Otros ejecutivos apuntaron al costo de la improvisación. Dzmitry Lubneuski, de a1qa, dijo que es mejor dedicar tiempo a una preparación cuidadosa que gastar dinero y nervios en correcciones posteriores. Sivan Tehila, de Onyxia Cyber, recomendó mapear la pila tecnológica y el gasto en línea con los marcos de cumplimiento para detectar riesgos ocultos, herramientas redundantes y fallas de seguridad.
Shubhangi Srivastava, de NEP SERVICES, resumió el enfoque con una consigna directa: más útil que lanzar algo grande es detener algo que sigue por inercia. En su visión, cerrar bien un proyecto innecesario libera capacidad real y muestra criterio sobre cómo se usa el tiempo del equipo.
La lectura de fondo es clara: en tecnología, la velocidad sin diagnóstico suele terminar en más gasto, más dependencia y más parches. Para una organización, el costo de equivocarse no solo se mide en dinero, sino también en credibilidad interna, productividad perdida y margen para innovar.
El mercado ya votó por la prudencia. Capital busca reglas claras, incluso dentro de una empresa. Antes de prometer una gran transformación, conviene saber qué se hereda, qué se rompe y cuánto cuesta corregirlo después.
