Franquicias de proyectos independientes: por qué las grandes empresas de software deberían desprenderse de la innovación en lugar de matarla

      TL;DRLas grandes empresas de software suelen construir herramientas internas que demuestran ser valiosas, y luego las dejan decaer cuando cambian las prioridades. Robert Brownstein propone el "franquiciado de proyectos independientes": permitir que los ingenieros más cercanos a una herramienta interna validada la desarrollen como una empresa autónoma, con la empresa matriz como primer cliente y socio de licencias. Los datos de PwC muestran que el 42% de los CEO temen no estar transformándose lo suficientemente rápido; Deloitte advierte que los competidores nativos de IA ágiles están reduciendo el costo mínimo para el software.

      La innovación no suele morir porque un experimento falle. Muere cuando desaparece la propiedad. Las grandes empresas de software pueden construir una herramienta auxiliar, demostrar que resuelve un problema real y aún así dejarla de lado una vez que la dirección redirige al equipo hacia el producto insignia o la próxima iniciativa urgente. Mi argumento es simple: cuando un proyecto interno útil ya no se ajusta a la hoja de ruta corporativa, las empresas deberían considerar darle independencia antes de abandonarlo.

      El momento importa. En la Encuesta Global de CEO de PwC 2026, el 42% de los directores ejecutivos dijeron que su mayor preocupación era si se estaban transformando lo suficientemente rápido para mantenerse al día con el cambio tecnológico, mientras que el 29% cuestionó si su capacidad de innovación era adecuada. Sin embargo, un análisis relacionado de PwC encontró que, aunque la mitad de los CEO consideran que la innovación es central para la estrategia, solo el 8% había implementado sustancialmente al menos 5 de 6 prácticas asociadas con su apoyo. La industria no carece de ambición. Carece de estructuras duraderas para llevar trabajos prometedores a través de un cambio en las prioridades.

      Los ingenieros de software conocen el patrón. Una empresa decide que necesita una capacidad, asigna personas para construirla y crea impulso alrededor del trabajo. Meses después, el proyecto se declara "suficientemente terminado". Los ingenieros se mueven a otros lugares, pero los informes de errores, las preocupaciones de seguridad, las necesidades de integración y las solicitudes de funciones permanecen. Llamo al ciclo repetido "iniciativa de desgaste": los equipos construyen contexto y convicción, luego pierden ambos cuando llega una nueva directiva.

      El costo no se limita al presupuesto de desarrollo original. En mi experiencia, los ingenieros continúan asumiendo el riesgo del código que ya no tienen tiempo para mejorar. Cuando se van, su conocimiento institucional se va con ellos. El siguiente equipo debe reconstruir decisiones antiguas, trabajar alrededor de una arquitectura descuidada o reescribir lo que no puede mantener con confianza. Por lo tanto, un proyecto aparentemente completado puede convertirse en un pasivo organizacional recurrente.

      Este problema se vuelve más urgente a medida que cambian las economías del software. El Informe Global de la Industria del Software de Deloitte 2026 dice que la creación de software se está volviendo más rápida y más barata, mientras que los desafiantes nativos de IA ágiles están presionando a las empresas establecidas. Sin embargo, una producción más rápida no crea propiedad a largo plazo. Simplemente puede ayudar a las organizaciones a producir más proyectos que luego compiten por el mantenimiento.

      Propongo un camino intermedio entre mantener todo dentro y matarlo: el franquiciado de proyectos independientes. No estoy describiendo una franquicia minorista convencional. Me refiero a permitir que las personas más cercanas a una capacidad prometedora y no central formen una pequeña empresa independiente en torno a ella. La empresa matriz podría convertirse en un cliente ancla, retener una licencia o interés económico minoritario y proporcionar financiación de transición limitada. La nueva empresa ganaría la libertad de servir a otros clientes y construir un producto duradero en lugar de una característica interna única.

      Ese arreglo puede contener riesgos en ambos lados. La empresa matriz evita hacer un compromiso indefinido con un producto no probado. La empresa emergente obtiene un primer cliente conocido, ingenieros experimentados y un problema ya observado en la práctica. Si la demanda no surge, el experimento permanece limitado. Si el producto tiene éxito, la empresa matriz puede continuar licenciándolo, profundizar la asociación, adquirirlo o traer la capacidad de vuelta a la casa. La independencia se convierte en un mecanismo de prueba, no en un ritual de separación.

      Mi propio paso del desarrollo de software corporativo a la construcción de productos independientes cambió cómo veo este problema. Ahora desarrollo y pruebo productos de manera independiente, incluidos herramientas gráficas basadas en navegador. Sin prioridades corporativas que redirijan mi trabajo cada pocos trimestres, puedo seguir el mismo problema técnico a través de productos y clientes. Esa continuidad no garantiza el éxito. Hace que el aprendizaje sea acumulativo porque las personas que reciben retroalimentación siguen siendo responsables de lo que el código se convierte a continuación.

      Este modelo debería ser selectivo. Una empresa no debería separar su producto insignia, infraestructura estratégicamente sensible o software que no se puede separar de manera segura de datos y sistemas protegidos. Tampoco debería el emprendimiento convertirse en una etiqueta educada para transferir el riesgo corporativo a los empleados sin financiación, derechos o una base de clientes realista. La encuesta de EY 2026 de líderes tecnológicos en Irlanda encontró que el 36% citó brechas de talento y aproximadamente el 30% citó límites presupuestarios como desafíos clave. Un escisión no resolverá ninguno de los problemas si comienza con falta de personal y subcapitalizada.

      Antes de aprobar una, los líderes deberían requerir evidencia de demanda más allá de un solo patrocinador interno, un propietario técnico comprometido, límites claros de propiedad intelectual y de datos, un acuerdo de soporte, hitos de financiación y un proceso de cierre acordado. El equipo debe saber lo que posee. La empresa matriz debe saber lo que puede usar. Ambos deben saber qué sucede si el mercado dice que no.

      Las grandes empresas de software siguen preguntando cómo preservar la innovación dentro de la corporación. Esa pregunta puede ser demasiado estrecha. Deberían preguntar cómo una buena idea puede recibir suficiente autonomía, tiempo y propiedad responsable para demostrar si merece un mercado. El mayor riesgo para la innovación corporativa no es que cada experimento pueda fallar. Es que el trabajo prometedor nunca se permitirá convertirse en un experimento real.