← Back

A Paradigm shift in Software; Optimising for Fast Feedback

I stumbled across another brilliant discussion from David Farley on the Engineering Room podcast this week, and it got me thinking. These kinds of visionary conversations about developing products always spark ideas I want to bring back to my team, so I’m sharing some thoughts here.

This episode focused on leadership in software quality and how the landscape is shifting. Many companies aiming to be “tech-first” start from an assumption that they already know what great software delivery looks like; and they may do at the operational level.

But the truth is, these initiatives need to be supported by product, hiring and lean budgeting strategies to be successful and durably embedded into the culture. The old methods—focused on predictability and control—just don’t work anymore.

Automation, DevOps, and AI now unlocking engineers from toil, to focus on real user problems, represent a paradigm shift in creating software products.

It’s clear as we'll see, teams need to optimise for fast feedback if they want to thrive. In this little meander, I dive into why traditional organisations struggle to adapt, how modern practices can help, and why embracing this shift is crucial for building quality in our software even staying competitive.

We might assume—or perhaps they do—that organisations aspiring to become a true tech company inherently understand what excellent software delivery even implies and are equipped to implement it effectively across their teams.

This assumption often stems from the assumptiong that present leadership skills and mindsets learned in old paradigms that once secured competitive advantage and, for now, have continued to sustain it. But the landscape is no longer yielding to these outdated approaches. The game has changed, the tools are no longer big tech's reserve, and thriving in the business of modern software delivery, with motivated teams to do it well, demands a shift toward Team Topologes enabling fast flow, feedback, and continuous learning throughout the org.

The protective shield of scale enjoyed by product companies that once held dominance in their space has now become a millstone, hindering the adoption of the continuous, agile delivery practices and decoupling available to new players with customer-focused cultures; now real alternatives for users.

Evolving landscape of software delivery and product-thinking

Creating and delivering software undergoes dramatic evolutions, multiple times within a single career. Each implies that the "rules" of one paradigm may no longer apply in another, and now, challenges that once seemed unsolvable—such as achieving agility in regulated sectors or attempting to coordinate different teams—can now be tackled with technical strategies available in the form of our cloud platforms, decoupled architecture, and pipeline automations.

Companies who cling to old paradigms of delivery and measurement are missing out on the benefits of engineering proctices we've long known to be hallmarks of high performing product teams; TDD, extreme programming, and true continuous integration and delivery (CI/CD).

Common objections—such as concerns about too much "devolution," an implied lack of accountability or governance, or the need to adhere to "regulations"—are all unfounded oppositions to evolving our work, that we can actually mitigate and de-risk with modern delivery methods, such as Continuous Compliance.

Manually checking for security vulnerabilities and adhering to regulations can slow down development and introduce errors. As an alternative, organisations can automate compliance checks and audits...

Yet many industries' tech leaders at the operational level are batling with the job of this transformation despite it being well understood, against entrenched funding structure upstream, and a lack of technical understanding leading large companies. However I feel this will soon be a non-negotiable leaders will acknowledge; table-stakes for delivering software sustainably; even, perhaps more-so, the most safety-critical!

A similar idea important for this new paradigm, captured by Marty Cagan in Team Topologies, elevates the importance of team interactions and boundaries in achieving fast flow in teams aligned around the value streams as they are represented in your product. Matthew Skelton suggests in an insightful, fun interview recently that, rather than some magic formula, this is just the natural outcome of how we organize if we prioritize the right things in terms of streams of value.

The goal is to deliberately un-align teams, decoupling them to reduce their individual cognitive load and increase trust—fundamentals of high-performing teams.

In chaotic organisations with an incidental culture [1] or a lack of clear product vision, identifying the specific aspects of value within the product around which to align teams becomes the real challenge.

However, doing so forces leaders to really understand and communicate in the team structure where the value is.

For business leaders seeking to understand and be less fearful of the liability of their unlocked tech teams and the inherently creative and emergent business of software development, the key isn’t to measure output or rely on superficial metrics...

It’s to optimize around feedback.

Optimize for Feedback

Optimizing for fast feedback means creating an environment where teams can safely, easily, and frequently release software. This allows them to quickly gather insights, learn from real-world use, and adapt continuously.

The way to de-risk releases is to do them more often, then fix forward and plug the gap in your pipeline tests.

As Dave Farley points out in the discussion, what worked before to deliver good-enough software won’t work in this new paradigm for long. The accumulating tech debt paves the way for reduced product quality, team health, and, ultimately, retention of the best engineers and users.

Organisations in this new era, now have to want to learn for themselves what will work for their teams in their specific context rather than cargo-culting ceremonies, to ensure retention, safety and quality in the product.

You can't inspect quality into the system.

By prioritizing continuous adaptation and delivery, this approach increases the speed at which teams can respond to feedback and improve the product.

Releasing should be a non-event, and I’m working to drive this vision of the future within my team.

Conclusion

Mature, market-leading organisations, without a drive to proactively evolve the culture by bringing in new perspectives, often lack exposure to modern software delivery practices—not at the operational level but at the organisational level to support it.

Unsurprising, as Larman’s Law tells us, companies are implicitly optimised to resist change, and discourse on transformation tends to be re-appropriated to support existing models.

The shift in the skills and mindset necessary for transformation and sustaining advantage means delivery teams increasingly need to be enabled and empowered for outcome-driven, iterative delivery rather than the short-term incentives sought further upstream.

Perhaps the mark of a true tech organisation is not simply the practices the individual teams have adopted but the fast flow, value-stream thinking evident in lean budgeting and product strategy too.

Without that, there’s only superficial reorganising of work to fit old paradigms and a fundamental antithesis between what engineering teams need from the business in order to best fulfill what we do best: drive value at the front end, and what is still incentivised further upstream.

The time is now for engineers to evolve into product engineers, and recognise our responsibility to promote fast-flow, trust, and feedback-driven software delivery. The future of our product and our fulfillment as engineers to deliver the best outcomes at work, depends on it.