How Starling Builds a Bank - Part I

From the outside looking in, it's hard to assess a company's engineering maturity. You can review a stack, but the true measure lies in the Ways of Working and the day-to-day delivery flow. At Starling we've cultivated a culture and set of practices that minimises the friction and maximises velocity, with a focus on Developer Experience. This post, written by an Engineer, pulls back the curtain to explain the operating principles that define life as an Engineer at Starling.

A day in the life

Let them cook. At Starling we foster an environment that maximises deep focus and the time that engineers can spend writing code.

Commitments each day are thin. You may have a standup or two for the project(s) you're working on, but these standups are purely for you and your team. So if they're too frequent or too lengthy, your team can agree to condense them. If they're not delivering value, your team can optimise as they see fit.

Protecting your time is a shared responsibility. If there's an unclear agenda for a meeting, or it's hard to see the value of your attendance, we encourage you to seek clarity from the organiser. We want you to own your calendar and optimise the outcome: ensure that your presence is genuinely useful so as to maintain your focus when needed.

Autonomy. It's our favourite word. We work hard to hire smart, talented and enthusiastic engineers. We're adults, and we trust each other to spend our time working on things that matter. If it's for the overall improvement of our systems or our company, then it's valuable work.

Our Team Leads and Engineering Leads will help to guide priorities on the scale of days and weeks. But as for each minute and each hour, it's yours to determine how to spend your time.

Delivery over discussion. We try to avoid big-bang releases at Starling. When we build, we iterate. Typically the release of a feature is a single configuration line change: 'off' to 'on'. Preceding that are many tens or hundreds of releases that incrementally build out the feature.

We release frequently. Many services get released multiple times daily. A small proof-of-concept, a Pull Request, or a schema diagram is more effective to facilitate design discussions than meetings and hypotheticals. Many of our features are developed iteratively in our Demo environment before being deployed to production behind the scenes. This allows the code to live in our prod environment while remaining invisible to the public, so that we can gradually roll out the feature to users on our own terms.

"agile" not Agile. We focus on the core meaning of the word, not the specifics of the framework. We're not prescriptive about practices - the tools or the methodology are flexible. We do have principles, however. We favour simplicity: small iterative changes over long complex projects. There's no long specifications, iterated over for months. We're not prescribed with a list of requirements to tick off. We invest time in understanding problems or use cases and then enjoy the freedom to design and develop solutions. We adapt, and as such we need to be comfortable with uncertainty. Our priorities forever evolve, so engineering must be mobile enough to react.

Minimise deadlines

At Starling we have the privilege of building software for a company with a single product.

We are a bank, our product is exactly that: the bank.

A major benefit of this is that we get to choose what we work on and what priority it takes. The caveat here is that we have knowledgeable and inventive customers, who often become a big driver in what we choose to build. And, as a UK bank, we are regulated by the FCA & PRA. So there are certainly some external factors that can influence what and how quickly we need to deliver.

What this means is that for the most part, we're free to prioritise our efforts. As engineers we can choose when it's appropriate to accept tech debt, and when we need to architect a complete solution.

We launch new features when they're ready, when we're comfortable that they're fit for both use and maintenance. On occasion we're held to deadlines due to external pressures, but we work hard not to impose deadlines on ourselves.

When we're under pressure, we ask ourselves:

"What will happen if we don't do this?"

It's important to know the consequences (if any) of choosing to take no action before we drop everything to pursue a change or a fix. Through this lens, often things reveal themselves not to be quite so pressing after all.

Sometimes we are eager to get a feature to market sooner rather than later, or we have a bug that is causing a headache. But engineers are empowered & trusted to prioritise and, through good communication, we can ensure that anything being delivered under time pressure can receive the right quantity and balance of resources.

When those rare deadlines do come along, or when we're under time pressure, there are four solutions:

• Increase output: bring in more developers
• Negotiate deliverables: adjust the timeline
• Negotiate deliverables: adjust what will be delivered on the date
• Increase output: work harder (longer hours? More corners cut?)

At Starling, we use the first three liberally, so that we never have to use the fourth.

Our autonomy in Engineering does come with a cost. We take input from many sources - other Starling departments, customers, regulators, plus our own engineering goals. Consequently, we then work closely with these stakeholders to understand their collective needs, so that we can be sure to expend our energy on the right thing at the right time. It is a complex and difficult practice. It may well change from one week to the next. And as the saying goes:

"If everything is urgent, nothing is urgent."

A clarifying note

We're not saying we've nailed it. We're not saying everything here is perfect. If there was a correct answer for how to deliver software, everyone would be doing it that same way. What we have here is what works for us, right now. And as times change, as our business or industry changes, we will change too.

We like how we work. We think you might too.

Want to hear more?

Check out Part II, where we talk more about how there's No JIRA.

Like the sound of this? Curious to know more? Keep an eye on our Careers Page for openings.