The group agreed that there has always been a disconnect between the engineering and commercial spheres. This era of software abundance is exacerbating that friction in several ways.
Engineering teams are accelerating output tenfold, but, as one IT leader noted, “We accelerated the factory, but we don't have enough people who can tell us what the outcome should be!"
This was a common theme throughout the discussion: where is the division now between software engineering and product management? If software can be built at minimal cost in minimal time, the more important issue is, “what should I, in fact, build?”, a question traditionally in the product management domain. And that also requires a hard look at the roles within organizations and how teams should be structured. As one participant put it, “The wrong lesson is that product managers think they can build software. What's needed is the ability to communicate the why. The business model, customer knowledge, and commercial understanding. Judgement and restraint are the most useful skills in software engineering right now."
There was a broad consensus that traditional org charts are no longer fit for purpose. With fewer people needed for a given mass of work, right-shaping matters as much as right-sizing. “There are always going to be silos - the goal isn’t to get rid of them. The question is, what shape are those silos going to be and how should they interact?”
Another dimension was the skillset of engineers, who might need to manage armies of agents simultaneously. "You're the head of an organization of collaborating agents — just like when you’re managing a team, the responsibility is still yours."
One participant also shared their concerns about the impact of uncontrolled building and consumption on morale. "Token-maxxing is a big issue. People just work more. There's rampant consumption on one side, and invention on the other — and both are exhausting the people involved."
Concerns were also raised about the unintended technical debt resulting from unfettered building. "The CEO doesn't want to be talking about re-engineering a CRM from 30 years ago; they want to be building digital. So what we're seeing is the pressure to build the new, backdooring into the old. And I think we're creating a mess." He went on, "Years of standardization have been applied to these systems of record. It's pretty naive to think you can just vibe code that in a weekend. The legacy has to be modernized; it's not tenable for these two worlds to coexist at scale."
Another participant, with decades of experience building technology at banks, agreed, "If you want to reimagine what you do, you had better re-baseline it first. Step one: prove it does what it already did. That's essential, but not sufficient."
That tension between reimagining and not breaking anything came up repeatedly. "You need the business to be confident you won't break anything. But that's incorrectly viewed as invisible table stakes, with everyone focusing on the ‘reimagination’ part.”
So, the thought becomes, if the “bright shiny things” are now freely available, can we now focus on firming up the foundations on which they’re built? One IT leader shared, “Every company I've ever been in, you go to the business, and they've got ten years' worth of backlog that nobody has ever developed — because the constraints of legacy systems make it impossible to implement business agility or try new things."
Another mused, “We can now finally attack some of these dragons that have been ruling big companies for so long."
The spiralling cost of building new on old was also surfaced.“The agentic thing is actually costing more, because you never retired anything. You create a whole new set of applications backdooring into your own legacy world. Security goes out the window."
“You can't delegate responsibility to AI. It doesn't matter whether you're complying with one authority or fifty; you still have to develop those requirements. The buck stops with a person.”
Security surfaced surprisingly late in the discussion. But the group shared serious concerns about the slow pace of creating new governance structures fit for the new era. Again, human capacity was at the center of the argument. “Continuous compliance - the ability to prove, continuously, that nothing is broken - is really interesting. But we don't yet have the people educated to do it."
The group agreed it would probably take something catastrophic to happen to bring this issue fully into focus. "Engineers are having more fun, but governance is not there. It doesn't add up to something coherent yet. We haven't had a catastrophic event yet - we haven't even had a fine - but it's coming."
One participant opined on the risk of unintentionally developing a shadow IT culture: “Are we looking at a well-governed situation where we can run as many experiments as we want and keep the best ones? Or are we looking at a proliferation of things in actual production with no oversight? That second scenario is shadow IT, and governance simply can't handle it."
AI is upending the economics of software development, and in turn, the economics of how a company builds and grows. The fundamental challenges of business transformation remain the same, but there was acknowledgment that the calculation of tradeoffs now looks very different.
As one participant put it, "The types of decisions that need to be made haven't changed. What has changed dramatically is the speed at which we need to make them, and whether we have the wisdom to make them well. We've been talking about transforming the operating model to meet the needs of customers for a very long time. The difference now is the urgency."
Board pressure makes the temptation for quick wins understandable. But the group agreed that careful deliberation and systems thinking are more important than ever. This means bringing engineers closer to the business, and the business closer to the customer. It means building governance that can keep up with capability. And it means resisting the pull toward surface-level fixes that create the very complexity they were meant to solve.
The question was raised, “There’s a gap between what you can do with technology and what the business decision makers can do. What learning journey do we take them on?”
Throughout the conversation, the default leanings of large organizations - stability, prediction, safety - and the tumult that AI is bringing to these systems, felt jarring. AI demands a discovery orientation, and the immune system of large companies actively resists this. "Large companies need to weaken their immune system because the people who work well in industrialized, optimized organizations tend not to be innovators."
So what does it take to speak up about what changes and what doesn’t? Who is brave enough to ask more foundational “idiot questions”? Courage was a word that resonated with the group. However, while courage was admired, there was a note of caution. "Courage is dangerous. I used to have CEOs tell me I was their canary in the mine. The canary died. It's a terrible story — how do we make courage needed less?"
One participant had a wise suggestion for business leaders: "What works is starting with small promises and architecting the sequence carefully."
Despite raising many legitimate issues about software abundance, there was a genuine excitement around the opportunity to create competitive differentiation. “Organizations can use software as a moat - completely customised, less off-the-shelf, more creating a source of competitive advantage."
Another agreed, “If we're reducing the number of people required to build decent software, the key driver is going to be medium-sized and large businesses that right now are buying off-the-shelf, suddenly saying: I want my software to give me a competitive advantage. Companies that don't do it are going to fall by the wayside."
Alongside product advantage, the group kept returning to which human characteristics have the most leverage. The engineer who understands a sector deeply - commercially and technically - who can sit with a customer and know which problem is actually worth solving - that person is more valuable than ever. "You're not just an engineer who codes in certain languages anymore. You're an engineer who understands a sector, a business, a type of user. Equipping engineers to do proper user research is really important." Another added, "The scarcity has shifted, from developer capacity and development budgets, to human capital and understanding what the business problems actually are." A great one-liner: “Taste is the scarce resource.”
But with power comes responsibility.
The era of software abundance represents a huge opportunity for organizations. But there is still much to think through, lest hasty decisions go against the best interests of the enterprise, its customers, and its people. Asking the tough questions and engaging a systems thinking mindset will be the difference between quick wins and sustainable prosperity.
Thank you to all our participants for such a rich and engaging discussion.
We believe that every company deserves to realize their vision, free of constraints from the past. Our team's technology, and experience can help them move into this evolving version safely, reliably, fearlessly.
