Invisible
Performance

Seeing What Others Walked Past

In a fast-moving product organisation, infrastructure improvements rarely compete for attention against new features. The roadmap is always full. The backlog is always longer than the sprint. And the work that keeps the foundation strong is often the work that never gets prioritised.

While working across Entain's digital betting platforms, I noticed that our web delivery stack was running on HTTP/1.1 — a protocol designed for a different era of the web. HTTP/3, built on the QUIC transport layer, offered meaningful improvements in connection establishment, resilience on mobile networks, and head-of-line blocking elimination. For a platform serving millions of users across regulated markets, these weren't theoretical gains.

The opportunity was real. But identifying an opportunity and turning it into an initiative are two very different things.

Translating Technical Value Into Business Language

The first challenge was not technical. It was narrative. In a product-led organisation, every investment competes for the same finite resource: engineering time. To win that time, you need to speak the language of the people who allocate it.

I built a business case that connected protocol-level improvements to outcomes that leadership cared about: page load performance on mobile networks, session resilience during high-traffic events, and the long-term cost of technical debt in the delivery layer. The goal was not to explain HTTP/3 — it was to explain why customers would benefit and why now was the right time.

This required synthesising data from performance monitoring, competitive analysis, and industry adoption trends into a clear, compelling argument. Not a technical specification — a strategic recommendation.

The Art of Influence Without Authority

Platform initiatives rarely have a single decision-maker. This one touched engineering leadership, product management, infrastructure teams, and compliance stakeholders — each with different priorities, different risk tolerances, and different definitions of success.

I approached alignment as a series of individual conversations before any group decision. Understanding each stakeholder's concerns — and addressing them directly — meant that by the time we reached a formal review, there were no surprises. The meeting was a confirmation, not a negotiation.

For engineering leadership, the conversation was about risk and rollback. For product, it was about customer impact without feature disruption. For compliance, it was about regulatory considerations in our licensed markets. Each conversation was different. The underlying message was the same: this is the right investment, and here is why it is safe to make.

Designing for Safety in Regulated Environments

Betting platforms operate under strict regulatory requirements across multiple jurisdictions. Any change to the delivery layer carries inherent risk — not just technical risk, but reputational and compliance risk. The rollout strategy had to reflect that reality.

I designed a phased approach: beginning with internal tooling and non-customer-facing services, progressing to lower-traffic markets, and only then expanding to high-volume regulated platforms. Each phase had defined success criteria, monitoring thresholds, and explicit rollback procedures.

This was not caution for its own sake. It was a deliberate strategy to build confidence — in the technology, in the process, and in the team — before committing to full-scale deployment.

Driving Delivery Across Organisational Boundaries

Infrastructure initiatives rarely belong to a single team. This one required coordination across frontend engineering, platform infrastructure, DevOps, and QA — teams with different tooling, different rhythms, and different definitions of done.

My role was to create clarity at the intersection of those teams: defining interfaces, resolving blockers, and ensuring that each team understood not just their own deliverable but how it connected to the whole. This meant regular cross-functional syncs, shared documentation, and a single source of truth for rollout status.

The most important leadership skill in this context was not technical expertise — it was the ability to translate between teams. To take an infrastructure concern and frame it in product terms. To take a product constraint and communicate it to an infrastructure team. To keep everyone moving in the same direction without creating unnecessary process overhead.

Impact That Customers Feel But Never See

The migration completed successfully across Entain's regulated betting platforms. The results were significant and measurable: weekly user volume grew by 5×, and landing page load time dropped by 90% — from 21 seconds to just 2 seconds. Users experienced faster connection establishment, improved resilience on mobile networks, and more consistent performance during high-traffic events — without any visible change to the product.

Beyond raw performance, the move to HTTP/3 unlocked capabilities that were previously impractical. Multiplexing and batching of large asynchronous calls became possible across the platform — enabling engineering teams to build faster, more resilient features without the head-of-line blocking constraints of the legacy protocol.

That invisibility was the point. The best infrastructure work does not announce itself. It simply makes everything else work better — and in this case, it opened doors that had previously been closed.

What This Project Demonstrates

Invisible Performance is not a story about HTTP/3. It is a story about the kind of engineering leadership that creates large-scale impact even when customers never directly see the work.

It demonstrates the ability to identify strategic opportunities in the infrastructure layer, build a compelling case for investment, navigate complex stakeholder landscapes, design safe delivery strategies, and drive execution across organisational boundaries — all in service of an outcome that benefits every customer interaction, invisibly and continuously.