Engineering leadership – the decisions that created Access Worldpay

Building something from scratch involves lots of decision-making, and Access Worldpay is a great example.

The challenge was to build a set of payment services and interfaces delivering Worldpay from FIS products quicker, more safely and simply, with better service quality and the ability to scale globally in capacity and cost.

“A reasonably non-trivial request,” says Simon Welland, Director of Solutions Architecture and Co-Lead of Access Worldpay.

Stating the obvious

The first decision Welland and his colleagues made was to make Access Worldpay cloud-first in order to deliver the necessary scalability and speed. In addition to GitHub and Nexus, the team opted for proven open-source software.

“Typically, it offers the best engineering and innovation and also the best quality and good value for money,” says Welland.

To help ensure a viable supply chain, the team decided to invest in key open-source providers and share any future developments or improvements made by their engineers to open-source projects.

Autonomy and automation

The need for high speed, responsiveness and service quality triggered other decisions.

“We pushed for investment in automation, testing and in the use of software agents to have zero defect pipelines,” Welland explains.

Another decision involved fully harnessing “the power of the squad.”

“The squads are full of incredibly capable people who are living the problems on a daily basis, so we push as much autonomy in their direction as we can,” says Pat Bateman, Co-Practice Lead - Build. The team’s BRO model (Build, Release, Operate) gives squads responsibility for building, releasing and maintaining software, thereby improving service quality.

First, principles

Since autonomy requires decision-making, success requires clear guidelines, principles and leadership. One founding principle is leveraging individual knowledge and experience through collaboration. For example, helping Worldpay colleagues understand wider applications based on the team’s decisions, and discussing the experience with developers.

Another guiding principle is test-driven development (TDD). While commonplace for software developers, TDD represents a new frontier in cloud and infrastructure engineering.

“My job has been to ensure people feel comfortable in this journey, understand the challenges and are clear on the direction,” says Paul Wright, Head of Cloud Engineering.

Just enough, just in time

Setting clear guidelines and principles has empowered the squads to make the decisions to fulfil their tasks.

“We ask the squads to try and meet the requirements they’ve been asked to meet and avoid the hypothetical things,” says Bateman. “This helps create a ‘just-enough, just-in-time, every time’ architecture to produce results very quickly.”

Effective autonomy also requires clear limits and leadership.

“You need a strong feedback loop because some decisions matter more than others,” says Bateman. “If it’s a really important decision, we’ll try to make it for the entire team because it can help the other squads who’ll also hit these problems at some point.”

Four-wheel decisions

Welland, Wright and Bateman are all on the leadership team, which makes decisions based on everyone’s collective knowledge and experience and opinion. Together, the team has over 100 years of systems leadership experience. This helps them develop the knowledge and skills to help the squads work autonomously.

“We’ve worked hard on supporting our people to grow to the full-stack, extending from front end to back end to infrastructure,” says Welland. “We’re developing those skills in individuals so that, ultimately, we can take our architecture decisions anywhere within our team.”

“That’s what we decided from the start,” Wright adds. “To build strong, cross-functional teams that know what they’re operating and owning.”