Крупные IT-компании должны превращать успешные внутренние инструменты в независимые стартапы

TL;DR Large software companies routinely build internal tools that prove valuable, then let them decay when priorities shift. Robert Brownstein proposes “independent project franchising”: letting the engineers closest to a validated internal tool spin it out as an autonomous venture, with the parent company as first customer and licensing partner. PwC data shows 42% of CEOs fear they are not transforming fast enough; Deloitte warns lean AI-native competitors are lowering the cost floor for software. Innovation does not usually die because an experiment fails. It dies when ownership disappears. Large software companies can build an ancillary tool, prove that it solves a real problem, and still starve it of attention once leadership redirects the team toward the flagship product or the next urgent initiative. My argument is simple: when a useful internal project no longer fits the corporate roadmap, companies should consider giving it independence before they abandon it. The timing matters. In PwC’s 2026 Global CEO Survey, 42% of chief executives said their biggest concern was whether they were transforming quickly enough to keep pace with technological change, while 29% questioned whether their innovation capability was adequate. Yet a related PwC analysis found that although half of CEOs consider innovation central to strategy, only 8% had substantially implemented at least 5 of 6 practices associated with supporting it. The industry does not lack ambition. It lacks durable structures for carrying promising work through a change in priorities. Software engineers know the pattern. A company decides it needs a capability, assigns people to build it, and creates momentum around the work. Months later, the project is declared “done enough.” The engineers move elsewhere, but the bug reports, security concerns, integration needs, and feature requests remain. I call the repeated cycle “initiative thrash”: teams build context and conviction, then lose both when a new directive arrives. The cost is not limited to the original development budget. In my experience, engineers continue to own the risk of code they are no longer given time to improve. When they leave, their institutional knowledge leaves with them. The next team must reconstruct old decisions, work around neglected architecture, or rewrite what it cannot confidently maintain. An apparently completed project can therefore become a recurring organizational liability. This problem is becoming more urgent as the economics of software change. Deloitte’s 2026 Global Software Industry Outlook says software creation is becoming faster and cheaper, while lean AI-native challengers are pressuring established companies. Faster production, however, does not create long-term ownership. It can simply help organizations produce more projects that later compete for maintenance. I propose a middle path between keeping everything inside and killing it: independent project franchising. I am not describing a conventional retail franchise. I mean allowing the people closest to a promising, noncore capability to form a small independent venture around it. The parent company could become an anchor customer, retain a license or minority economic interest, and provide limited transition funding. The new company would gain the freedom to serve other customers and build an enduring product rather than a one-off internal feature. That arrangement can contain risk on both sides. The parent avoids making an open-ended commitment to an unproven product. The venture gains a known first customer, experienced engineers, and a problem already observed in practice. If demand fails to emerge, the experiment remains limited. If the product succeeds, the parent can continue licensing it, deepen the partnership, acquire it, or bring the capability back in-house. Independence becomes a testing mechanism, not a severance ritual. My own move from corporate software development into independent product building changed how I see this problem. I now develop and test products independently, including browser-based graphical tools. Without corporate priorities redirecting my work every few quarters, I can follow the same technical problem across products and customers. That continuity does not guarantee success. It does make learning cumulative because the people receiving feedback remain responsible for what the code becomes next. This model should be selective. A company should not spin out its flagship product, strategically sensitive infrastructure, or software that cannot be separated safely from protected data and systems. Nor should entrepreneurship become a polite label for transferring corporate risk to employees without funding, rights, or a realistic customer base. EY’s 2026 survey of technology leaders in Ireland found that 36% cited talent gaps and roughly 30% cited budget limits as key challenges. A spinout will not solve either problem if it begins understaffed and undercapitalized. Before approving one, leaders should require evidence of demand beyond a single internal sponsor, a committed technical owner, clear intellectual-property and data boundaries, a support agreement, funding milestones, and an agreed shutdown process. The team must know what it owns. The parent must know what it can use. Both must know what happens if the market says no. Large software companies keep asking how to preserve innovation inside the corporation. That question may be too narrow. They should ask how a good idea can receive enough autonomy, time, and accountable ownership to prove whether it deserves a market. The greatest risk to corporate innovation is not that every experiment might fail. It is that promising work will never be allowed to become a real experiment at all.