In a talk at QCon London, Rachael Wonnacott explained the challenges in building a developer platform in an organisation with legacy processes and how a golden path leading to either a Kubernetes Hotel or a Public Cloud House might be necessary.
Wonnacott, Associate Director for Container Platform Engineering, discussed the developer experience story at Fidelity International, cautioning that organisations should design platforms with business value as the primary goal rather than fixating on the developer experience.
She opened by discussing the need for platforms – with the enterprise wanting software delivered faster, more predictably with a lower cost and complexity, and with standardised processes, whilst development teams look for reduced cognitive load, context switching and wait times, and don’t really care about infrastructure.
“Platforms are really about business value, and while developer experience is a leading factor in achieving this, it is secondary to it,” Wonnacott explained, addressing what is seen as the elephant in the room in debates over contemporary platform engineering. She highlighted how platform teams must acknowledge that they are part of a larger organisation and that dropping a contemporary platform onto an enterprise with long-established structures, and legacy processes and systems may not go well.
She described how technical organisations built in the past might have specialised teams focused on specific technologies and rigid siloed relationships between the application and infrastructure groups, leading to the classic “throw it over the wall and hope for the best” approach. As parts of the organisation moved to cloud computing, this led to differing levels of DevOps maturity, she explained. Building and running their own software in production improved the well-being and productivity of some teams, but others struggled with it.
Fidelity wanted to evolve this to a model where every team worked on DevOps principles, and created a developer platform engineering group to unify tools, security, cloud services, and Kubernetes-based hosting.
Wonnacott’s team determined that there should be a “fork in the road” for developers, where they could choose between the “Kubernetes Hotel” (a fully managed platform) and the “Public Cloud House” (with self-managed infrastructure without support from the central team). She compared the options to staying at a hotel where service is provided but customisation is limited, versus owning a home where you have freedom to change the colour of the walls but also full responsibility when something goes wrong.
Wonnacott turned to her experience of releasing a minimum viable product that didn’t meet the expectations of early adopters within the organisation. She explained how the older CloudFoundry platform took care of a large amount of the software delivery lifecycle, and the platform they moved to didn’t initially fulfil all these needs. “The more features you try to predict, the more risk you’ll build things that people don’t want,” she advised, emphasising the value of early adopter feedback.
A key insight from Wonnacott’s experience was recognising that “the platform is also knowledge and support,” and not just about technology. They appointed platform advocates and ran communities of practice to support developers. Wonnacott stressed that platforms must integrate with all stages of the software development lifecycle, including committing, building, testing and security scanning – some of which may be owned by different teams.
“The platform’s real job is integration,” she said, describing platform teams as bridges that connect capabilities together and amplify them by building in security and cost controls rather than bolting them on afterwards.
The arguments are now philosophical, not technical. Your customer will never be truly happy.”
To help others apply these lessons, Wonnacott recommended mapping the developer journey across the entire software development lifecycle and identifying all team handoffs, as it’s here that delays and communication discord often sets in. “You will need to bring the people together, and please don’t underestimate this,” she cautioned.
She acknowledged a fundamental tension at the heart of platform engineering: “Developers thrive on autonomy. Engineering is an identity, not just a job. They want tools to empower, not processes to slow down. Meanwhile, the business likes predictability, reliability, cost controls; these are not negotiable. In between these truths lies the humble platform team.”
Wonnacott concluded by highlighting what makes a platform truly valuable – both in business and in developer experience terms. She recommended that the audience view platforms not as islands, but as bridges, and to make them add real strategic business value by transforming them from mere technical solutions by fully embracing their context inside what might be a highly complex organisation.
