Starling Bank: How to Nurture an Innovative Culture in Banking


My name is Jason Maude and I am from
Starling Bank, and I am Starling Bank’s Chief Technology Advocate and what that
means is I go around and talk about the technology behind the bank. How it works
and our technology culture as well which I will be talking to you about a lot
today. The reason I do that is because Starling Bank is a digital bank. It’s 100% online and on the mobile phone so, in order to trust the bank and we
need the trust of our customers and the wider industry and regulators and so on
we need to have trust in the technology. So my job is to go around and encourage
trust in our technology and our technology processes. So I’m going to be
talking about how we see innovation and how we nurture innovation within Starling
Bank. My background is as a software engineer, before I was a technology
advocate, I was for many years a software engineer working in the finance industry
in general. So a lot of what I’m going to say now is about innovation specifically
with regards to software. Which is a lot of what we’re talking about and thinking
about when we talk about digital and innovation and so on. But some of the
lessons I’m going to talk about are specific to software. There is
innovation in other areas and so on, but innovation in software is something slightly different so although some of these lessons are more
applicable in a more wider sense, a lot of them are going to be very specific to
how your software, how your digital transformation happens. What is life like at Starling Bank? Starling bank started about five years
ago, six years ago now and we launched publicly, ourselves, about three years ago.
We are a bank, we are growing and we are seeking to disrupt the
industries. How have we managed to do that? Well when we talk about innovation and
encouraging an innovative culture, we have to realize that innovation is not
really something that you can just dredge out of people like more widgets
in a factory. You can go up to your staff and say to them I’d like you to be 30%
more innovative next quarter but that doesn’t really do anything.
Some places have innovation labs or innovation departments. I’m afraid I’m a
little skeptical of innovation labs and innovation departments. Apologies to any
heads of innovation in the room, I often see them as places where you keep the
innovation to stop it getting out. To stop it infecting the rest of the
organisation. You keep the innovation over here. I’m sure that’s not
the case wherever you’re working but in many organisations and you sort of place
the innovation over here so it doesn’t come out and start affecting the actual product because risk and compliance get a little bit
annoyed about that. So innovation is something that you have
to encourage by creating a culture in which innovation can flourish. You have
to remove a lot of the barriers that are in the way of innovation being created
naturally. If you are providing people with the wrong tools or the wrong
mindset then you basically go down the road of trying to eat your boiled egg with
a mallet. You’re not going to get very good results, so you have to go around
and try and remove those barriers out of the way. What I’m going to do now is,
I’m going to talk you through three of the common barriers to innovation I hear
people talk about when I go around to events like this and they say “yes we would love to innovate but du du du durr”. I’m
going to talk you through some of those and I’m going to say where the
barrier comes from and also what Starling has done differently to try and
remove that barrier to innovation. Now I would point out very quickly here that I’m going to present three of the top ones I hear about. These
are by no means all the barriers to innovation but these are three of the
most common ones I hear. So we would love to innovate but… 1. Even the
simplest change takes months to implement. Oh God, it’s so difficult we’ve got to get it through five different committees and
six different test environments and oh God it takes so long to even just change
two fields around on the screen or change the colour of a button! What’s the
point? So why are we in this space? Why is
it so difficult and why does it take so long to innovate new changes? Let’s go
back to the start of software engineering. So software engineering
became a commercial concern around 40 years ago. 40, 50 years ago.
approximating. When software engineering first came around to the
industry in general. People thought “ah software engineering, this is like
engineering, we know about engineering because we’ve been doing it for
thousands of years”. What is engineering? Engineering is this, it’s building
bridges, its building all of the beautiful buildings that you can see out in the
window. It’s those cranes standing up there. It’s building things, we know about
engineering. Now when you’re engineering in general, the way you engineer is you
sit down you, have a long planning phase where you write out a specification of
what you’re going to do. You check that specification a number of times, you
might create some models, you do some math to make sure that
it’s going to work and then when you’ve got all of this plan through, all signed
off and so on. You then go and actually build the thing. Build the building, the
bridge whatever. You go through that. Now the reason the process is like
that is because engineering has a couple of big advantages and one big
disadvantage. The big advantages of engineering are, we have been doing it
for a long time. If you go and look out that window there you can see buildings
from many, many eras out of the window. One of my favourite views in London is
the view from an office that PwC has down by Tower Bridge where you can see
in a big sweep City Hall, very modern building, Tower
Bridge, Victorian. The Tower of London, almost a thousand years old. We’ve been
doing this for a long time. We know the principles involved. Also your
specification, the other big advantage, doesn’t have many moving parts to it.
This is a bridge, how many people does it need to take? Where does it need to go
from and to? How long does it need to last? What’s its maximum load? That sort of thing. That’s the sort of questions you’re asking.
We know the questions we’ve got to answer and we know the variables
involved. So specifying how the bridge should act does not require, you know can
be specified upfront. It is possible for you to write down a document specifying
all of the things. So the big disadvantage if you start building your
bridge and you build one half that goes like this… and another half that goes like that. Then you’re in trouble and you’ve got a
knock one half down and you’ve got to start again. So this big upfront design
phase is both possible because you’ve got all the knowledge and you’ve got a
limited number of variables and necessary because you can’t start
building the bridge without getting into a lot of problems if you haven’t planned it correctly. So when people came along to software
engineering, they went “this is engineering, therefore, we shall do it in
the same way. We shall write big long specification documents and we shall
implement them and…” it didn’t really work. Things started going wrong, people
started finding that what they planned didn’t really deliver the value that was understood to be delivered. The specification document seemed not to
define exactly what was going on. What was being delivered by the engineer’s
wasn’t what was intended by the specification document. In my days as a consultant, I had to spend days where I would be basically reading down the
phone, specification documents to a client saying “well no actually I think
you’ll find that it could possibly be interpreted that we did the right thing
and delivered what you needed even though you don’t think that
that is the correct thing that should have been delivered”. And then we went
into the budgeting problems. Why does technical debt accumulate? Why
do we keep getting these budgeting problems? Why is it that everything
overruns either in terms of time or in terms of manpower we need to put into it?
Why is all of this happening? The reason is because software is not like bricks
or stone or what have you. It’s different it’s more malleable. You can do anything
with software. You can do huge amounts of things, therefore, specifying exactly what
it should do is really difficult because exactly what you want means that the
software can change a little bit of a way to do something slightly different.
You can move buttons around on the screen, which you don’t have to do with a bridge. Even just the placement of buttons and
fields have a massive impact on how good the software is, so specifying what
needs to be done is really difficult. Also we only have 40 years experience
with this and things keep changing. We don’t have thousands of years of experience, building buildings and bridges. But if I start building my software and
one part comes in like this… and the other part comes in like that then I can
just go control X, control V and now it’s done. I fixed it in situ, I don’t need to knock one bit down and start again, I can
just correct it as its running and deploy something. So that
big problem that you can’t change things once you’ve committed to it and started it is gone. It’s not a problem anymore and what this
means is you need to work your software in a different way and so in 2001 a
group of software developers got together and created something called
the “Agile Manifesto”. Now when Agile gets mentioned, it can
often have different meanings. In software terms when we use the word Agile we’re generally referring to the Agile Manifesto and the philosophy and
principles behind it. I know that sometimes people will use Agile to mean
reactive to change and that’s a bit of what the Agile Manifesto is about but
it’s not entirely about that. It has a lot of stuff in it about, you
need to do things this way, to do things that way, but it’s generally a
philosophy document. It’s not a methodology. It’s not a process document.
It’s not a document that tells you exactly how to run your business. It’s a
set of principles about how it is best to deliver software acknowledging all of
the things that are in software and the way that software needs to be developed.
So what happens is, this was presented at various software
conferences and software engineers went “yes that is for how we
want to develop, these people get it. They understand”. And they took it back to
their CTOs and said “we need to work in an agile manner” and their CTO said “no”. So they then went away from another conference where Agile was talked
about and they came back and said “oh we need to work in an agile manner. Look there are several other companies that are doing this” and eventually after
much badgering the CTO said “fine I will go and take this to the
executive”. So they went to the board, to the executive and said “we’d like to
work in an agile, iterative manner” and the board went “the what? What, yeah you
know, obviously, we need to be flexible but what are you talking about? Alright, you go and work in an Agile manner yeah, yeah you can
implement best practice. Go away and do that in your department we’re going to
work in the way that we’ve always worked”. Which is with Gantt charts and
spreadsheets and project plans and thus was developed this the “Pseudo Agile” or
wagile or agile fall methodology. By which you have a business project
management team working with Gantt charts and spreadsheets and project
plans and timelines and budgets and then, on the other hand, you have the
engineering IT department trying to work in an iterative Agile, reactive fashion. In the middle of these two you get a group of people called “scrum masters”
“Kanban wizards” “Agile methodology supremo’s”, who come along with a giant huge bag of post-it notes every quarter and get you to stick the
post-it notes to the board in an effort to try and desperately get the two
completely different worlds to communicate with each other. I feel for
those people it is a difficult job. This isn’t really Agile. You’re not Agile simply because you put post-it notes on something. Agile is about, as the prince will say it, is about doing things, like preferring talking to people rather than writing down a giant document. It is about preferring, working software to comprehensive documentation. If
I have something that works, even if it doesn’t quite work. Even though it
doesn’t work in exactly the way I’d expect. I prefer that to a giant document
speculating about how something could possibly work, like what value is
that? I don’t need a giant document I need working software and the giant
document isn’t required for working software in the same way that the giant
document is required to build a building. So how do we do things at Starling? We
work in a product-based fashion, not a project-based fashion. We have 800 people
in the bank and we have about two project managers and their job is to interact with the outside world who don’t understand things unless you talk about them as
projects. So we do not have any projects internally. We have a series of products
that we are continually working on to improve and if we need to accelerate the
improvement of one particular product we will gather together a load of people
and we will make sure that those people, from across the company, across the different disciplines, across the different departments, are a cross-functional team. That group is then empowered to deliver the change that is
necessary and push it through. We don’t have budgeting or that sort of thing. We don’t try and allocate an amount of money to a product. We do but we will analyze that on a ongoing basis. We will say is this thing getting traction? Does it need more money? Yes okay, we
will allocate it more money. No it’s not a priority right now, okay we will move
people off that and so on. It’s very much more reactive budgeting, the way you do.
We also do not ask engineers for numbers about how long things will take. Here is
a tip from an engine a software engineer… If you ask a software engineer how long
something will take and they give you a number. One of three things is true: A,
that number is massively padded. B, it is a lie. C, the engineer does not have the competence to realize that they should
give you a massively padded number or lie to you. You are dealing either with a
liar, someone who is massively padding or an incompetent. One of those three. The
only engineers you should trust are the engineers who, and this is software
engineers again, say to you I do not know how long this will take. How long is
a piece of spring? And the reason they can’t answer you is because
if they said to you, specify exactly what the software should do down to the last detail, you will not be able to answer them or if you are, your answer will
take until the heat death of the universe to be able to read out. So that
is why you should never ask a software engineer how long something should will take. Moving on, “we’d love to innovate but it’s
too risky or the regulators will not like it”. This is number two in my
list of innovation blockers. Well this is where risk and compliance come in and
we’ve heard a bit about them and how risk and compliance view technological
changes, that technological change is risky, it is a problem. It’s going to come
back and bite us at some point and in fact it has done in the past and what
you often get with risk and compliance controls with IT is that, there’s a basically a problem occurs and someone says “right we need a policy to make sure
that problem never occurs again” and the policy is developed and then someone
says “ah another problem has occurred we need another policy to make sure that
that never happens again” and you get layers upon layers of plasters basically
trying to prevent previous problems from coming back as things that will affect you in the future. So you get these technological changes
wrapped in vast amounts of procedural cotton-wool. Vast amounts of sign-off. Vast amounts of moving it through different testing
environments. Vast amounts of giving it to different groups of people to see if
they like it and so on and this means that the technological change
takes a long time. So you develop but you’re not developing any slower, you don’t develop a week’s worth of code and then the developers sit on their hands, while it goes through all sorts of risk and compliance, you’re developing
the same amount of code. You’re developing huge amounts of code and it’s all
getting wrapped up in this procedural cotton wall and is delivered into
production. At least that procedural cotton wool means that
banks never suffer large banks never suffer IT failures though right? No? Joke to
see if anyone’s awake in the room. Of course big banks suffer IT failures. This model does not prevent you from suffering IT failures. What it does is
consolidates all your smaller IT failures into one giant month-long catastrophe,
where your entire Bank goes down and everything’s off and no one can access
their accounts and their mortgages are being incorrectly calculated and
everything’s on fire and the regulators are going “have you fixed it yet, have you fixed yet, have you fixed it yet” and you’re going, “I have no idea” and you’re asking your engineers how
long will it take to fix it and they are of course, lying to you to make you go
away and solve the problems so they are saying three weeks at random and so on
and so on. This does not actually do anything for you and what I’ve realized
is a lot of this procedural cotton-wool that you are wrapping your technological
changes in is not actually for the benefit of mitigating your risk. It’s not
actually there to mitigate the risk of the organization or the risk of the
customers having a bad time. What it is therefore is to mitigate the risk of
someone getting blamed. It is arse covering mitigation and that is what it is there for.
So what have we done at Starling? We’ve done this. We have shrunk the size of the
release because it is not change that is risky it is large change. It is doing a
lot of change all at once because not only can you not look through all of the
change when something goes wrong to find out where the problem is. You’ve also got
the potential that two things that are independently working fine can
conflict with each other and cause a problem. So actually if you shrink your
change down as small as you possibly can with the minimum
amount of regulatory required procedure and you release, you can actually make
sure that your risk is actually mitigated and that when something goes
wrong you can roll it back or fix forward or identify the problem quickly and so on. This is what we do at Starling. We release every single day, code to production. There was a code release on
Friday, there will be a code release today at least one, there will be a code
release tomorrow and the day after that and the day after that. If we ever go a
day without a code release the engineering department goes into a wild
panic and shuts everything down until we can get code out. So the engineering
department, the idea of risk and managing risk is well embedded in the engineering
department, we just view it in a completely different manner and now, not
only means that we are innovating and pushing changes now faster, it also means
actually we are less risky. I think that Starling Bank is less risk, is more
risk-averse, sorry, than the big incumbents in the room. I think we have a
greater avoidance of risk than the new guys because we are pushing out
changes rapidly. We also have less emotional commitment to all of our
releases. If one of our releases fails and we need to roll it back, that’s fine,
it’ll go out tomorrow. I can’t imagine what it would be like in a big
organization, bank or otherwise, were three months worth of work was about to
go out and someone said no we have to roll it back. The fight, the arguments, the
you know, “no goodness, no we can’t roll it back” must be immense because the pressure to get the changes out must be huge. So we
have removed that emotional commitment to releases by making them all small and
disposable. Finally “we’d love to be innovative but we have legacy code”. Technical debt, we’ve got so much, we’ve got a giant backlog of changes, we’ve got all these regulatory changes, we’ve got all this legacy and so on. So, we can’t do that. You’re lucky Starling Bank, you’re lucky. You have you started with a greenfield site, everything’s fine with you. The understated bit of that conversation that I have many times is, for now. You’re good for now but
soon you’ll develop legacy too Starling. You’ll develop legacy and then you’ll be
just like us, we’ll be stuck in the mud and this sort of comforting lie that people tell themselves, that eventually we’ll get
stuck too. Where are these guys legacy? They’ve been around for twenty years
Amazon, developing software twenty years is about half the time that the software
has been a commercial concern. Why aren’t they stuck? Why are they continually
innovating and driving things forward? How have they managed not to get stuck with
legacy code and how has Starling managed not to get stuck with legacy code? Well
the answer is in continual development and improvement. There is no such thing
as business as usual at Starling. There is no business as usual phase
where software is deployed and then it’s stuck. Software is not a building or a
bridge. Software is a garden, a garden continually needs improvement you
continually need to weed and grow and develop. Water and feed the
plant,s even if you’re not digging up an entire flower bed and replacing it with
a rockery you still need to maintain all bits of the garden all the time and
that’s what we’re doing. Your legacy is not in your, the reason code becomes
legacy is not just because it’s old, it’s because people forget how to maintain it. You have the code that controls some vital process that was written in COBOL
by Dave in the 80s and Dave is now retired or is dead, so no one knows how
to maintain this bit of code anymore. It sits on a server in the basement running
but it is worth nine million pounds a year and therefore cannot be switched
off or changed or any difference made to it. It’s just stuck there
running continuously without the ability to innovate. If you had maintained that
code and kept changing it, kept developing and so on, Dave would have
been able pass down to someone else who would have
passed it down to someone else, etc… and the code would have remained a
living thing. A living thing that you could maintain and develop and innovate
on. Therefore the barrier to innovation is not in your technology,
it’s in the mindset. It’s in the mindset this is stuck here and the only way to replace it isn’t replace it all wholesale. That might
be true but the problem is, replacing it all wholesale is you’re now giving it to
Gareth who you know in 40 years will have retired or died again you’re going
to be stuck in the same position again. If you don’t change your culture, you
need to change the culture because the culture influences the tech, not the
other way around. So in conclusion, if changes take too
long then treat what you’re doing as products that you’ve got to develop not
projects that you’ve got to manage and then there’s a business-as-usual phase.
If you think it’s too risky then try asking your risk and
compliance department would they prefer to have a day’s worth of changes going
in every day or every three months like to roll the dice on a huge
change which could go catastrophically wrong. And if you have legacy code you need to
replace it you need to replace it bit by bit and you need to keep understanding
of what it does in a living fashion and not just let it wither and die there is of course another one which has been alluded to in the
previous fireside chat. The final one I won’t talk about which is and this is
what I’m not going to be able to give you an answer to because it’s the
hardest… “we would love to we would love to innovate but we are used to eating
boiled eggs with a mallet”. That’s how things are done here. That’s
how things are done in this industry, we’ve always eaten boiled eggs with a
mallet and if it ain’t broken then don’t fix it and then someone like Starling Bank comes along and starts eating their boiled eggs with a
spoon and you go “why are these guys so much faster than we are?” and it’s because we have replaced the tools and the culture and the processes
in order to encourage innovation to flourish and you have to – if you want
to keep up.

Leave a Reply

Leave a Reply

Your email address will not be published. Required fields are marked *