Legacy systems are applications that have been in place for years, quietly doing essential work while becoming harder to change and more expensive to run. Over time, they absorb layers of process, assumptions and fixes that reflect past needs rather than current realities. While many tech teams still rely on these systems to run core products and services, the ways engineers and product leaders work around them can drain momentum, slow decision making and make innovation feel risky instead of routine.
Faced with this pressure, many technology organizations respond by chasing new tools or emerging platforms, assuming innovation is a problem to be solved through software choices or hiring alone. For Kendrew Peacey, Fractional Chief Technology Officer, that framing misses the root cause. The barriers to innovation are rarely technical. They are cultural, structural and, above all, human.
“Technology should serve as a bridge, connecting innovation with real business outcomes,” Peacey says. “If you are not building with the user in mind, you are just adding complexity.”
Innovation Begins With Ownership, Not Technology
When Peacey enters an organization bogged down by clunky legacy systems, he looks first at the team rather than the architecture. “You need a team that wants to learn and evolve with the technology and the application,” he says. “They have to own the product and take responsibility for meeting the user’s needs.” Teams that see themselves as custodians rather than owners rarely innovate.
Too often, development teams are reduced to executors of predefined tasks, rewarded for delivery speed rather than judgment. In these environments, innovation becomes something that is talked about but rarely practiced. Peacey points instead to mindset as the decisive factor, arguing that genuine ownership turns engineers from passive participants into active problem solvers who question why a feature exists and whether it still delivers real value.
Creating Psychological Safety Through Listening
A culture of innovation cannot exist without psychological safety. For Peacey, this comes through listening, particularly in how leaders engage with their teams. “The first question is always why,” he says. “Why do you think this approach works? And then you have to listen. Not just let them talk, but genuinely pay attention and ask more questions.”
By turning directives into discussions, leaders signal that curiosity is valued. Engineers become more willing to propose bold ideas when they know those ideas will be examined thoughtfully rather than dismissed reflexively. Over time, this creates an environment where experimentation feels safe, and learning becomes part of daily work rather than an occasional initiative.
Breaking Down Silos to Align Innovation
Many organizations claim to prioritise innovation while structurally preventing it. Siloed teams, particularly between product and development, often work toward competing incentives. “Everybody has to be involved in the discussion, from the C-suite to the developers,” he says. “If product and development are in separate silos, people are not on the same page.”
True alignment means shared context and shared accountability. Product teams should not be focused solely on keeping systems running, just as engineering teams should not be shielded from business realities. When finance, HR, product and R&D operate with a common understanding of goals, innovation becomes embedded into culture.
Modernization Through Subtraction, Not Reinvention
One of Peacey’s most contrarian views concerns legacy modernisation. The default response for many organizations is to rewrite applications in a new tech stack, a strategy that appears bold but often recreates old problems in modern languages. “That is the easy answer,” he says. “The harder question is whether you still need the functionality at all, or whether it needs to evolve.”
Over decades, applications accumulate technical debt and features that no longer serve users. Peacey advocates for deliberate subtraction as a form of innovation. Deleting unused or outdated functionality requires a deep understanding of both users and code, but it also unlocks clarity, performance and resilience.
“The first question should be what we should be deleting,” he says. “If we are not deleting, then we are not understanding our user base or our code base properly.”
Culture Determines Whether Innovation Lasts
The significance of this approach extends beyond individual projects. Organisations that build cultures of ownership, listening and alignment are better positioned to adapt as technology and user expectations shift. Innovation becomes a continuous process rather than a series of disruptive resets.
By focusing relentlessly on user needs and business outcomes, Peacey argues, technology leaders can move from merely keeping the lights on to building platforms that remain relevant for decades. The result is not just better software, but organizations that learn faster, waste less effort and create lasting value.
Follow Kendrew Peacey on LinkedIn or visit his website.
