Turning financial regulation into velocity with Team Topologies: the Golden Path advantage
By Meri Williams
Photo by Ray Bilcliff from Pexels: https://www.pexels.com/photo/green-plants-on-the-ground-5748370/
Results:
450% increase in work delivered
40% improvement in average cycle times
Significantly fewer operational problemsThe operating context of the modern enterprise
Over my career, I’ve served as CTO at places like Monzo, MOO and built the team at GOV.UK. Recently, I spent a few years leading technology at a major European financial software provider, and today I want to talk to you about the messy reality of Platform Engineering. Specifically, I want to talk to CIOs & CTOs in banking and payments about why your regulatory constraints are actually your biggest strategic advantage.
Let’s set the context. The business I joined provided prepaid cards to help companies manage their expenses—basically, a financial product that people didn’t hate. Because our customers topped up their accounts before spending, we were taking in and holding significant chunks of money on behalf of other businesses. We weren't officially a bank, and from a branding perspective, the company didn't want to be called one. But under the hood? We looked a lot like a bank, and when you describe the constraints we operated under, it is very obviously a bank-like environment. We had to maintain strict compliance with the UK Financial Conduct Authority (FCA), the Payment Card Industry Data Security Standard (PCI DSS), and the Danish Financial Supervisory Authority (FSA). Brexit [the UK’s exit from the EU] had even forced us to pursue a separate licence to operate in the UK, with the FCA’s famously strict compliance.
When I arrived, the engineering organization was struggling. We had about 200 engineers, but our throughput had completely flatlined. We had hired more people, but we weren't getting more bang for our buck because of massive interdependencies and messy ways of working. The company had already attempted a version of platform engineering, but they called it "Product Development Enablement"—a misnomer that didn't exactly roll off the tongue. I found about 20 engineers in this area who were deeply unhappy because they weren't actually writing any code. Their entire philosophy was to provide "maximum optionality" to the product teams. They were trying to give everybody every option available, which meant they spent most of their time writing 17-page Notion documents full of processes rather than building usable products. Out in the stream-aligned product teams, things weren't any better. Those engineers were frustrated because they were being handed maximum optionality that they simply didn't have the skillset to use, forcing them to mess around with infrastructure much more than they wanted to.
To fix this, my VP of Product, Stefan Christensen, and I completely reorganized engineering, heavily anchoring our strategy around the key themes and principles of Team Topologies. This wasn't just a re-org; it was a fundamental shift in our operating model, guided by several core concepts:
1. Stream-Aligned and Platform Teams as First-Class Citizens:
We clearly articulated the split between stream-aligned product teams and platform teams. We bundled our financial services, engineering, data, and internal IT platforms into one unified structure of about 80 people. This structural clarity ensured that stream-aligned teams could focus purely on delivering value to the customer, while the platform teams focused entirely on creating a robust foundation and in turn delivering value to the product teams.
2. Optimizing for Cognitive Load:
We deliberately used the concept of "cognitive load" as a guiding design principle. We had stream-aligned teams that were utterly overwhelmed by the sheer possibilities of what they could do and the infrastructure they had to manage. Our goal was to drastically reduce this burden. We implemented a "single front door" approach. If a product engineer needed something, they didn't need to navigate our internal organizational chart to figure out if it belonged to DevX, Security, or the SRE / Infrastructure team; they just knocked on the platform door, and we handled the routing internally.
3. Platform as a Product (The Golden Path):
The absolute heart of our strategy was transitioning from teams that focused on enablement processes to true platform teams that built products. We shifted away from forcing rigid standards—which engineers inherently chafe against—and introduced the concept of sensible defaults, or a "golden path". Our philosophy was simple: if there is no reason not to do it this way, you do it this way.
For CIOs in heavily regulated environments, here is the thesis you need to internalize: in a regulated business, the golden path is a compliance asset, not just a developer convenience.
I explicitly told our product teams: "If you do it this way, you don't have to worry about audits anymore. You don't have to worry about regulatory anymore. You don't have to worry about infrastructure anymore". By making the right thing to do the easy thing to do, we allowed product teams to stop wrestling with backend infrastructure and focus entirely on assembling great customer experiences. When engineers built on our golden path, they got massive amounts of infrastructure for free, including automated scaling, observability, logging, monitoring, and alerting.
Furthermore, compliance-by-default must live in your default path. When you are managing PCI-DSS and FCA constraints, you cannot rely on product engineers to manually implement label-driven controls or remember the nuances of complex data-retention rules on a feature-by-feature basis. By shifting to an API-first architecture and embedding continuous monitoring directly into the core platform, we guaranteed that every new service spun up on the golden path was secure and compliant by design. We also created a central database in Notion called "How We Build Things" that enshrined these paths as the foundational pillar of our engineering onboarding.
Many leaders assume that heavy regulation makes platform engineering and agility harder. I argue the exact opposite: it is actually more doable under heavy regulation, not less. Heavy regulation gives you the ultimate mandate to be opinionated. It naturally curbs "CV-driven development"—that unfortunate tendency for engineers to choose random, shiny new technologies just to put them on their resumes. When you are holding millions in customer funds and facing FSA audits, you have an unarguable business case for standardizing your tech stack. The golden path becomes an easy sell because it is the only way to scale safely.
Of course, the transition had a messy reality. Implementing Team Topologies isn't just about drawing nice organizational charts; it requires changing daily operations and interactions.
4. Leadership as a Platform:
We had to adopt a philosophy of leadership as a platform, focusing on the principle of making it easy for others to succeed. One highly effective tactic was simply renaming our "status meetings" to "support meetings". That simple naming change immediately shifted executive interactions from aggressive reporting-line interrogations into collaborative problem-solving sessions.
We also had to tackle the startup culture of building absolutely everything from scratch. Startups grow fast because $100k feels like a lot of money early on, but later you realize you're paying three full-time engineers just to maintain a tool you could have bought off the shelf for that same $100k. We transitioned to ruthless buy-versus-build decisions, choosing to build ourselves only where it truly set our financial platform apart.
Additionally, we learned that standard product management techniques fall apart when your user base is an internal population of 200 engineers. You can't run high-volume statistical A/B testing on your own developers. Furthermore, tracking OKR percentages just caused endless, useless debates about task estimation. We shifted our teams to reporting "confidence levels" instead—asking how confident they were that a feature would ship in a given quarter—which led to much healthier conversations about risk.
To support the humans in the system, we established six clear engineering principles—like "build for humans," "focus on impact," "API first," and "think safe and secure"—to guide our architectural change without overwhelming the teams. The platform's complexity also became an engine for internal talent growth, allowing engineers to tackle deep technical challenges and progress toward Staff Engineer roles in ways that simply weren't possible over in the product organization.
The results of this organizational and architectural restructure were staggering. According to Swarmia, our metrics tool, our investment in the platform yielded a 450% increase in work delivered. We reduced our average cycle times from over 5 days down to just 3.2 days—a 40% improvement—with significantly fewer operational incidents.
Closing reflections - make it easy to do the right thing
I always have to laugh when people ask me about engineers gaming DORA metrics. I actually love DORA metrics because even when engineers try to game them, they accidentally help themselves. If an engineer decides to divide their work into tiny, bite-sized pull requests just so it looks like they're doing "more" work on the dashboard, guess what? They just inadvertently optimized our delivery pipeline and cut our cycle times down from 5 days to 2 days.
To the CIOs out there: stop viewing your regulatory burden as an excuse for engineering sluggishness. A well-designed, product-led platform—anchored in the clear boundaries and cognitive-load principles of Team Topologies—turns the FCA, PCI-DSS, and FSA from a constant terror into a solved problem. Build a golden path so compelling that your engineers actively want to use it, bake your compliance directly into the pavement, and watch your cycle times plummet. Make the right thing the easy thing.
About the authors:
Meri Williams, CTO, NED, Advisor, @Geek_Manager
Meri is an experienced CTO who has led and scaled technology organisations that build & run brilliant products and services, in a range of sectors including medtech, fintech, government, ecommerce, telco and manufacturing.
Accustomed to high-pressure, business critical environments, usually requiring 24x7x365 operations, and delivering excellent services and optimising costs simultaneously.
Excels at scaling up teams, transforming processes and organisations to go from good to great. Passionate about technology and building smart multi-functional teams and organisations to develop brilliant products.
Read more on Team Topologies
