How Starling Builds a Bank - Part II

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.

Part I explores the Engineering Culture at Starling, and should be read before proceeding here. It focusses on what a day looks like for a Starling Engineer. Part II is going to be more about the tools that we use in that day to day. Part I ended with a clickbait-ey mention that there's "No JIRA". Let's start there.

No JIRA? (!)

We do still have JIRA (a 'ticket' management system, others are available). But we've dramatically reduced its day-to-day usage by engineers.

We record high-level goals as "Epics". These are the goals of the business: we want to launch a Joint Account, we want to allow parents to order a card for their child, we want our Business customers to be able to open a USD account.

Against these Epics we detail as much as we can about the "why" - but it's up to the team to work out the "how".

Once we get up and running with a project, we have a dedicated Slack channel. We may have more than one, it's totally up to those involved to decide how best to communicate. We catch up on calls or in person as often as we need to. We might choose to create a GitHub Task Board, use Confluence, a Google Sheet, or a Slack Canvas. It can be any combination of these, and more. Whatever we use will be owned by and exist purely for the team. It's not there to be externally managed.

But there are still bugs

Tickets requires management. They need to be defined, described, assigned, reassigned, prioritised, progressed, dropped, and picked up again, before finally being completed. Putting bugs into JIRA slows us down. Over years, it can become an infinite backlog of tasks that will never get addressed.

If something's broken, then someone is fixing it. If it's not being fixed, it's not a bug.

Those closest to the issue are trusted and empowered to prioritise it against their project work.

If a bug has wider impact, it's an incident, and it's treated as such. We focus on impact mitigation and resolution. Always with constant & frequent communication.

If we want to change our patterns or practices, we communicate. We use GitHub discussions, internal blog posts, and fortnightly forums to discuss our ideas & concerns, and to rally people around initiatives.

We don't maintain a backlog. All that matters is now and next. What are we doing right now? If we finished that this second, what would we do next?

Now & Next

Life comes at you fast, you have to be flexible and adapt to the challenges that you face. It's no different in business, and it's certainly no different in software.

We could spend many weeks; or even months; plotting what the next year will look like, maybe even creating a five-year plan. We could have every department do this. We could break down next year into quarters, and specify what we'd like to deliver and when. We can estimate projects, both in terms of time and developers required. What would we get from this? Would we get it right? Would we actually end up building {fun-feature-abc} in Q3 of the-year-after-next?

Next week we might find that there's a new FCA directive, or an external integration is deprecating an API. We might find that there's a global pandemic. We might find that the Bank of England Base Rate starts rising. We need to be ready to quickly shift our priorities. We can't quickly shift if we've prescribed the next three years down to the calendar month.

We're ambitious. There is a big picture. There is a vision. But, we can see long-term challenges, and we're empowered to invest effort early on to address them before they become more of a headache.

Day-to-day? We focus on what's happening right now. What are we building, what are we fixing? There's less likely to be value found in picking tiny details about deliverables in Q3 of the-year-after-next.

By focusing on just now and next, we remain lean. We're ready to adapt.

Documentation

Good code is readable code. The very best documentation is our codebase itself.

Any document written to exhaustively outline the current behaviour of our systems would soon be outdated. It would require many full-time jobs to maintain.

Our code is as readable as possible, with descriptive variable & method names. Better still, it is covered in automated unit tests that dictate behaviours and describe expectations.

100.00% test coverage is not expected or enforced, but we hold one another to high standards. The benefits of unit tests go far beyond validating logical flows - they protect us from regressions, and document functionality.

We do have some documentation. We maintain a broad vision and a narrow focus. At the high level, we keep track of the things we'd like to do.

These are forward looking & aspirational. They go beyond the day to day of incidents, refactoring, or exceptions. They describe the wider features or improvements that we're building or will soon build - the "now and next". They are designed to be consumable by everyone in the business, technical or not.

We keep a log of past decisions to reassure our future selves that our thinking was rational. We trust that they were the right decisions for that time and with the context that was held, but we may have learned more since then.

To ensure our systems are highly-available, our On-Call engineers have access to a comprehensive library of runbooks. These cover everything from routine maintenance to complex edge-case scenarios, ensuring that we maintain resilience.

Documentation for the sake of documentation is a time sink. But we maintain the forms of documentation that we find beneficial, so that the overall effort required for document maintenance is minimised.

We have a duty to communicate how we're using our autonomy - we're empowered to manage ourselves, so we must openly communicate the decisions we're making and how we've come to them. This is something that we are continuously improving. For the business to continue to provide Engineering with trust and autonomy, Engineering must broadcast our choices and our progress as we build the bank.

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 the business or industry changes, we will change too.

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

Eager to learn more?

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