[Applause].
TOM: Hello!
It's a real pleasure to be here amongst such great people you've all been lovely in all
the interactions I've had with you.
I'm Tom Booth, I work on infrastructure at uSwitch.
That's our website at the moment.
We try and help our customers with complexity and help them get the best deal that they
can.
That's generally things like energy, broadband, banking, insurance, that kind of thing.
So we have had the pleasure of living through a whole bunch of ways of building operating
and organising infrastructure over the time that our company has existed.
And our learning have led us to this: We think you should build a central team to empower
and support others.
We don't want to take ownership away from the teams that are building services for our
customers.
They are the ones with the context and the knowledge for their problems.
They know how to solve them best.
We just want to help them make better and easier decisions about the infrastructures
their services run on.
City don't by any means think this is an infrastructure problem, it is something that stretches all
over the different sort of technology disciplines as well as outside, and I think there are
some good front-end examples who try and do a similar thing sometime on a bigger scale
than we are trying but it is applicable outside.
So I'm going to look at the various different structures that we have had, some of the problems
that we have had, the learning and how we transition between them.
So to start off with centralised: So, if we jump back to sort of early 2010, we were a
modestly successful company that had been bought out by an American PLC.
We had some fairly interesting problems.
We weren't one business all focused on the same goal, we were a collection of competing
functional units.
Our goals were prettied misaligned, and there are some stark examples I got told about which
is our core product, so like switching customers' energy suppliers, and our advertising team,
were both motivated to make the most money they could.
And so the advertising team started selling adverts for the suppliers that could switch
to inside of our funnel to switch the user, so like you would be going on.
I want to get gas for the SSC, there would be a whopping great British Gas advert at
the top of it and pulled them straight out.
It is such a stark example of how somewhat good-sounding goals can just break apart a
company.
Our infrastructure team was similar.
It was a team removed from the development team and their motivation was to keep production
as stable as possible.
The development team, their job, to change the services, and so these are sort of like
inextricably against each other.
Through the kind of competition, that breeds protectionism.
That kind of thing contains many forms, most often through process, so you get things like
strict change control, provision request, a lot of physical, digital, mental paperwork.
I asked a colleague who has worked at uSwitch at the time for a picture to kind of sum up
how it felt back that.
He picked some Bosch which is pretty strong, but I know what he means.
Change was slow, so we had a three-weekly release cycle that we deploy all of the services
in one go, and it would look something like that!
That's not something people want, but three weeks is a long time.
It is enough time to pick up changes that poorly integrate across a wide variety of
services and people forget about various things which is no good.
Operations own the release cycle.
If it got broke during the release, they would get the blame.
Senior management would be at their desks.
This furthered that protectionism and mistrust between those two groups which is just not
great which is where the wool has come from.
So later in 2010, forward internet group bought uSwitch.
They thought they could come in there and improve it as business and see what they wanted
to do with it.
They started asking questions of the technology like why did my - why did their change break
my code.
They would be working along in their environment trying to make a change to a service and after
lunchtime, inevitably, the thing would just crash to a halt in environment environment.
Through successive cycles of consolidating services and breaking them apart again, they
built such a big ball of mud that understanding this thing was just a nightmare.
And the central ly provided tools to inspect it partly because of the - kept inside the
ops team so developers had to intro expect what was going on.
We were centralised, getting features to our users was slow which is awful - that's our
job.
Change was complex, also not so great.
Teams were stepping on each other, and functional ownership was causing all sorts of silliness.
Over time, we sort of started transitioning to a decentralised model for how our teams
functioned.
So at the core of this, it is one team needing to only their whole service, and that includes
things like commercial, marketing, development, design, and operations.
It was borne out of a want for agility, and a realisation that the things that we were
trying to let people compare were distinct enough that they should be treated separately.
They have their own regulatory bodies, the markets are different.
It started with our energy teams, because that was the first area that started being
rewritten.
And it meant that they could look a lot more like this, like a self-contained organism
that was able to respond quickly to the surrounding environment.
You have to embrace change.
You've got to structures yourself for it.
We can't avoid it.
Like the laws of thermodynamics say that change will happen so why fight it?
And so we started deploying continuously better for users and what is better for users is
better for business, reduces risk will be get, improve our funnels, and so forth.
In order to do this, the team had to only its own architectural infrastructure, couldn't
be blocked by whatever else was going on in someone else's team.
It bloomed.
We grew and grew.
All of these changes went great.
As we got bigger, communication across teams started to get harder.
Every team had their own direction with very little shared.
It can be hard sometimes like at that uSwitch to focus on targets that cut across the teams.
We started solving the same problems in similar ways with different implementations.
A team had difficulties with their database.
But because of a lack of communication between the teams, another team incidentally using
the same database had the same problem and spent the same week trying to fix theirs,
and it is just silly.
Like that's a week of what could have been great features delivered just gone.
The solutions were were built to built for the team rather than global maximum for us
as a company because there was not that one to take the things that were built inside
and push them that bit beyond.
And as well, with the scale, deeper knowledge of infrastructure was required.
And sometimes, this focus on infrastructure meant that they lost a bit of focus on delivering
direct value to the user.
So in comparison to some of the things we had when we were centralised, we were getting
features out to our users quicker, we've managed to move our architecture into teams and they
have had the power to fix that.
Functional ownership has gone, and that's like removed all of the silly issues that
came with that.
But we have new ones.
Same problems are evening solved repeatedly.
No-one has a picture because we second gated the architecture in different teams, someone
having an overarching view of how it fits together is now somewhat lacking.
We weren't focusing as much on the user as we should have been, and that's very important.
That's what we should all be about.
So, we decided to try recentralising.
We set up a team whose job was to help the infrastructure, people inside of the teams
delivering services for our customers.
The most important thing that is to try and retain ownership inside of these service teams.
Didn't want to take the infrastructure operations away for them, tried to make it easy to solve
the common problems they have as a team delivering to the cruisers.
A big part of that is trying to identify the common patterns.
We don't want to go and start new ones from scratch again, we want to look at what we
have, what is working at the moment, get our teams together and work out what is the best
way out of this, or what can we take from everything we've learned and agree that there
is it a new path we can take to solve this problem.
Ones you've agreed some of these patterns, we can build great tooling around it.
We don't want to be you have to go and use this new CI tool.
It should be a compelling thing that tools that we build should be so great and the patterns
we build that people prefer to use them than what they were using before.
As a team, we should be asking can we help each other.
As we build our tools, we don't expect for people just to migrate all of their stuff
immediately.
We need to be there as a team to help them along that path because we can't expect them
just to - for every whim and change to be able to facilitate that.
One thing that has been very important to uSwitch we also need to maintain is the room
for experiment.
So what we can't do as well is go and limit the supporting services, say, that they can
use.
They still know their problem space the best and we've got to let them pick the technology
that is appropriate for their problem space.
We've always had a survival of the fittest.
A piece of technology might start getting used in a particular area, then get adopted
if it works for them get adopted more widely until it becomes something the whole company
is using.
Sometimes, they will just disappear, and that is fine but we have to let people try and
find or experiment with new technologies that might be appropriate for the space that they
are working in.
So we've been bought by or we got bought by ZPG PLC back in 2015.
Once again, we are part of a public company.
Outside impressions start matter ing a little bit more.
The auditors coming in, from the shareholders, the regulators, people from other parts of
the company looking and trying to understand how it is that we operate.
We need them to have an expression that is not quite like that when they come and look
at our stuff, and we feel through the consistency that we are trying to bring through these
common patterns that we can start answering those questions once rather than auditors
having to go to each team getting the slightly different answers how they deal with their
data or so forth.
We can work out a way of doing that and mean that a lot of those questions are answered
for them by following the patterns that we've agreed and we've used.
At its core, it's working together and not apart.
No throwing stuff over the walls, and that goes either way, so like we're not going to
throw stuff at development teams and conversely, if they have a pro be with infrastructure,
we would like them at least to try and play with some of the stuff before they come to
us and have a look.
We need to work together on architecture, so we need to be working with teams to see
where they're going and what they're doing to see if another team has done it before
or whether we can can be informed where a team is planning on going.
We need to work together on issues.
It is very important that we don't just throw stuff over and when someone has a problem
with it, we leave it.
So every issue someone has, even if is it not relate ed to things people have, we need
to be there supporting.
Building that supportive relationship is incredibly key with this kind of team set-up.
Finally, working together on the bugs and production at 3 am!
In a similar vein, if you're not there at times when the need is most, how can you be
trusted to be there at all.
To revisit: Back when we were centralised, users were slow, we were still quick.
Architecture is still owned by teams.
We don't have any functional ownership.
That's still how it was in those self-contained cells of teams.
We've tried to - we've stopped solving the same problems repeatedly by having a kind
of team that will talk to teams, understand what they're doing and try and co-ordinate
and share patterns between, we've reduced a lot of repeated solving.
We've also kind of moved towards a place where we have a slightly better picture of our infrastructure
overall.
And we've by removing some of the overhead on managing infrastructure, we've let teams
go back to delivering value for the users that we are trying to assert which is the
most important thing.
So I would really recommend go and try it.
Building a team that is there for empowerment and support and ownership is great, and it
is a very important part of trying to run these decentralised and centralised teams.
Thank you very much.
[Applause].
MERI: Well done!