GitHub Universe 2018 - Scaling your business, 8 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: A journey into open development with Lloyds - GitHub Universe 2018 - GitHub Universe 2018

Description

Presented by James McLeod, Software Engineer Lead (Lloyds Banking Group).

Learn how Lloyds Banking Group journeyed into innersource with the formation of engineering guilds and how this lead to the adoption of GitHub Enterprise from proof of concept to widespread use. We’ll also explore how engineering guilds formed the GitHub Enterprise Working Group to share successes and educate on best practices, while safeguarding the operation of their engineering community. We’ll end with the story of how Lloyds Banking Group is moving fast toward open source, powered by the determination and ambition of engineers—and how GitHub Solutions Engineers are mentoring this enthusiasm to give back to the community.

About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.

For more information on GitHub Universe, check the website:
https://githubuniverse.com

A

♪ (music) ♪.

A

Hi! good morning, everybody..

A

Thank you very much for joining me here. Today..

A

My name is james mcleod..

A

I'm a software engineering lead at lloyds banking, group,.

A

And within lloyds banking groupm, I'm actually tasked with bringing engineers together through the formation of engineering guilds and engineering communities.. I've recently taken on the role of bringing github enterprise.

A

Into lloyds banking group,, which we did as an engineering community.

A

So we're kind of doing that by having engineering offsites,.

A

And we're being quite playful, as engineers,, so we're partaking in hackathons and other kind of playful means of collaboration as well.

A

But to give you a little bit about myself,, I've always been involved in external engineering, communities,.

A

And I'm also the organizer of a community in london.

A

Called react london bring your own project.

A

now,. I feel quite passionately.

A

About engineers, bringing engineering together,.

A

And so react london bring your own. Project is actually run by engineers for engineers.

A

And it's not just for people within lloyds., it's actually for people within lloyds and also from elsewhere within the reactjs community, as well.

A

Okay,, so I'm the kind of speaker who likes to get to know the people who are in the audience, and so hands up if you're from financial services.

A

Right, excellent., it's good to see you here. so hands up if you're, not within financial services,,.

A

But you're on a digital, transformation., right, excellent., it's good. hands up if you're with a startup.

A

Okay, and keep your hands up if you're, with a startup.

A

That's greater than 250 years old.

A

There we go., so that's the thing, right?, so lloyds banking group is an age-old organization.

A

We've actually been around longer than the formation of the united states,.

A

Which is actually quite tremendous.

A

within the u.k.,. It's quite easy for us to talk in terms of 250 years old.

A

Because we've got a huge history,, and so I don't have to do those comparisons..

A

But when I actually talk about how old lloyds banking group is.

A

Here in the u.s.,, it's actually quite remarkable that this is an age-old organization that I'm actually talking about.

A

And,, as you can imagine,, when you're actually going through 250 years worth of banking,.

A

You're actually there for the birth of a lot of things,.

A

And lloyds banking group was actually there at the dawn of engineering.

A

and so,. As you can imagine, we've picked up some pretty interesting engineering practices.

A

Along the way., and not only that, but lloyds, banking group is massive in the u.k.

A

We actually have multiple brands underneath our corporate umbrella.

A

I don't know whether you will know any of these on the high street.

A

Unless you've actually visited the u.k.,, but lloyds banking group has lloyds,.

A

It also has halifax,, it has bank of scotland,, and it also has scottish widows.

A

so we're actually all across the u.k.-- from the south. All the way up into scotland.

A

Now, hands up if you recognize this.

A

A

right.. Does anybody want to shout out what I'm holding up?.

A

If I can hear you. yeah, absolutely., so this is a monzo card,, and this represents challenger banks that we have in the u.k.

A

And actually, being here in san francisco, is absolutely amazing.

A

I absolutely love it.. I've been here a couple of days: now.

A

and I've been going around the place, walking here and there.

A

And I've noticed mopeds on the sidewalks that you scan the qr code.

A

And you can kind of just get on them and ride around.

A

And I guess that's disrupting uber.

A

within the u.k., within financial services,. We have similar disruptors.

A

We call them challenger. Banks.

A

monzo is probably one of the most well-known brands.

A

There are others., there's starling,, there's revolut, and there's others.

A

But for us it's kind of what these challenger banks actually represent.

A

That means that we've got to change the way that our engineering,.

A

That we've picked up for 250 years-- well, you know, within that span-- we've got to change the way.

A

That we're bringing our engineering teams together and the way that we're actually creating our projects and our products.

A

In order to kind of create the same customer-focused experience.

A

That a lot of technology disruptors are actually bringing to the marketplace right, now.

A

for me, and for the organization that we're moving to,.

A

Customer experience is actually heart of the organizational change.

A

But it's not something that you can do just by throwing engineers at it.

A

It just doesn't work like that.

A

So what I've just put up on screen now is kind of where we're moving from.

A

It's not where we are right, now,, but it kind of represents where we have been.

A

We,, as an engineering organization, have had monoliths.

A

We've had multiple teams doing individual engineering practices.

A

Where we've just kind of delivered a functional requirement.

A

To an engineering team to do something for us., but we don't have any say.

A

In the way that those engineering teams do their practices.

A

We've also kind of tested our software at the point of integration,.

A

So we would hand our requirements over to multiple, multiple,, multiple teams,.

A

And at the point of integration,, that's when we actually find out whether it's worked or not.

A

And if it's worked,, then that's great,, the team are satisfied.

A

But it it hadn't worked,. We then need to loop all of those changes back around.

A

Into the original development team or where we feel the failure has actually happened.

A

And so the feedback loop on that is just too slow.

A

If you're undertaking additional transformation,, do you kind of recognize this??

A

Are you coming from a place which is actually quite painful, where your cycle time is actually really quite slow?.

A

Because I understand how that feels.

A

and certainly, as an engineer,, I know engineers who get deeply frustrated.

A

That they just can't fix that bug, that's stopping their software from going live., and this isn't just a financial services thing..

A

This is actually within enterprise organizations.

A

Of any scale. you scale bad practices,, like you would scale, good, lean, practices.

A

But to compound that, I was describing just the software engineering, and the testing, and the integration, and how we actually get our products to the point where we need to go. Live.

A

At the point of going live, we're actually moving away from integrating all of those changes.

A

And all of those new products, and all of that deployable, code,.

A

From a huge merging, process.

A

So we're actually moving away from bringing all of that code together in monthly cycles.

A

It's extremely painful. we have,, or we had 12 releases, a year,.

A

And at one time it was also known for there to be a 365-day release cycle.

A

From concept of a product to actually getting it out, there.

A

And so, if you compare that to some of the disruptors who are using cicd,.

A

How can you operate an engineering team with a cycle time of 365 days?.

A

It just can't happen.

A

So this is where lloyds has changed.

A

so going from all of that pain, that's kind of held us back.

A

From getting the experience that our customers deserve,.

A

We've actually moved into a world of devops.

A

I don't think that's new to everybody., you go outside here and you see devops everywhere.

A

But the difference between what we're doing within devops--.

A

We're not centralizing anymore, we're actually federating and decentralizing.

A

A lot of our software engineering and engineering practices.

A

So we build a culture of leanness., we build a culture of collaboration.

A

We want our engineers to be self-service..

A

We want our engineers to play with technology and pick up the tools that they need, and say to their teams,, say to their product owners,.

A

"This is what we need in order for us to be able to create great engineering and great software.".

A

We also want our teams to measure things, because measurement, within software development,.

A

Is extremely important,, especially when you bring those cycle times, down., so introducing practices of measurement through systems. Thinking.

A

And also, though, automation and automated tests, and measuring all of our cycle times through tools like jira,.

A

Where we actually have our agile, practices, etc., is extremely important., and that is our movement. and the movement isn't just within software engineering..

A

The movement is within the mindsets of everybody who is part of that team.

A

That delivers all of this engineering and all of these new products.

A

But we need to remember, we're still a financial services company.

A

We're still a retail bank., we live on the high street., we do multiple billion of pounds sterling of transactions, daily.

A

We need to be safe., and so we have our devops principles that we need to not govern, but live our engineering rules by.

A

We can't just be too loose with everything.

A

because, at the end of the day,.

A

We still need to work within a safe environment..

A

We need to have our tests there that measure failure.

A

We need to make sure that all of our software engineering.

A

Is unit tested, so we can move forward at pace.

A

And we need to make sure that when we actually deliver,.

A

Against our agile definitions,, all of our tests are actually passing.

A

So we know that our software is also going to be reliable.

A

But, ultimately, this brings together all of our engineering practices.

A

We have software engineering, that I represent,.

A

But we also have quality engineering, and we also have our devops engineers.

A

And we call it being t-shaped, or being cone-shaped.

A

Our devops movement is about bringing engineering together,.

A

Including security as well, and educating people about what these practices are.

A

Within your feature, team or within your squad.

A

Now,, where we're at now is great.

A

So all of our feature- teams and all of our value streams- are moving. Fast. we've got automated devops.

A

our engineering teams, they're. Looking after.

A

Their own development pipelines and toolings,.

A

And together, within that team, they're moving super fast.

A

They're picking up requirements from product owners,.

A

From their scrum masters, and also from the customers as well,, because we're able to test, within our branches.

A

We're able to invite our customers in to know whether our products are actually successful or not.

A

But the one thing that we're not that great at is bringing engineering together across those boundaries,.

A

And you can see that from the red circles around our product teams there.

A

That's where we're kind of seeing our gap right now.

A

it's. How do we actually bring our engineers together.

A

Across team divisions?

A

so, for instance,, it's like me, working with you at the front there.

A

So I'm able to produce code. I'm able to release a product.

A

But I can't see your code, because actually I belong to a different team to you.

A

And the way that our repos have actually been set up in the past.

A

Means that if you don't need to see code,, you don't have access to that repo.

A

So you and I, we can be working on something, and we can see each other's code.. But can we see our companion's code over here??

A

We can't, because they're working in a different repository,.

A

For a different team., so within lloyds banking group, we're actually going through a change in the way that we bring people together.

A

And I say "people," because it's not just engineering,, it's everybody.

A

Everybody who has a profession within lloyds banking group.

A

Comes together through guilds and communities.

A

It just so happens that I represent engineering.

A

And I've helped to define how our engineering guilds are actually formed,.

A

And how those guilds are publicized, and the types of work that we do.

A

now, when we first formed our engineering guilds,.

A

We asked a question.: what is the biggest difficulty that you have within your teams right, now?,.

A

And unanimously our engineers, said, "we, can't collaborate.".

A

We can come to our guild meetings, and it's great.. We can talk to each other and we can educate each other verbally.

A

We can do presentations, like I'm doing here.

A

we can educate through powerpoint or doing brown bags.

A

But, actually,, when it comes to really learning,.

A

And really sharing knowledge, what it comes down to is code.

A

We need to be within our repos..

A

We need to be able to demonstrate changes--.

A

Within a social community, within our actual engineering.

A

Not just by stepping through things, or talking through our difficulties.

A

That is really important as well,, but every day we need to be able to go into each other's repos.

A

We need to be able to share code., we need to be able to exchange knowledge..

A

We need to be able to make recommendations of things that need to be changed.

A

And so, out of our engineering guilds, we actually formed something.

A

Called the github working group.- so we came together, and we said, okay,. So let's think about this.

A

How can we actually solve this?.

A

And so the github enterprise working group was born.

A

Now, we've actually been through quite a journey of centralization within lloyds,.

A

And actually our engineers like to have delegated authority.

A

And if you look at github enterprise, as a product,, it does kind of look.

A

Like a centralized tool., so in order to kind of mitigate that, and in order to bring our engineers on the journey with us--, because we want our engineers to leverage an excellent tool--.

A

We actually invited all of the engineers that surround github enterprise.

A

Into this working group.- and so within the working group we have engineering.

A

Engineering are actually our customers, because, to us,. Github enterprise is a product that enables engineering.

A

Our customers are actually the engineers who use it.

A

Within the github enterprise working group, we also have the operations team.

A

So we have our run team in there,, because engineers are quite inquisitive., so our customers like to know what's going on behind the hood.

A

It might be the case that they don't need to know a lot of things,.

A

But they like to know what the cpu utilization is;.

A

They like to know how much memory is being consumed;.

A

They like to know when the next version's being upgraded.

A

We're now on version 2.15.

A

Our engineers like to know all of this stuff.

A

and, actually,, we learned, through our journey into guilds,.

A

That bringing all of these different groups into that,.

A

Actually removes all of those feelings of not being in control as an engineer.

A

We've been in the position where a tool has been provided for us to use,.

A

And it can be like fitting a square peg into a round hole.

A

But we know, as the github enterprise working group,, because it's actually formed from our guilds,.

A

It's what our engineering teams actually want, and it's what they've actually asked for. and so bringing people in to the journey is actually super. Important.

A

And not only do we have our operations team,.

A

Not only do we have our engineers,, who are our customers--.

A

And believe me, they tell us when we're failing;.

A

We have to work extremely hard in order to make github enterprise operate.

A

Like a system that they actually want to use,- and we learned that the hard way--- but we also have our support teams there as well.

A

We have the people who are answering questions.

A

When an engineer or a member of our product team.

A

Or a member of our business team asks a question,.

A

When engineers need to be onboarded.,.

A

Our support team will come in, and they will let us know how many people are on the queue,, how many people have actually joined, and how many open tickets we've got--.

A

Just to keep people in the picture, and keep everything very, very open.

A

Now, through operating this model, we originally put github enterprise.

A

Into a sandbox environment for development,, just to see whether it was a system that people would use.

A

And we quickly maxed it out..

A

I think we had about 1,500 engineers within our sandbox,.

A

And there might be,, I believe, 1,200 engineers using github enterprise.

A

And so by testing that out and seeing that it works,.

A

And seeing that it's a system that our engineering teams actually want,.

A

We're now creating a bigger instance of github enterprise.

A

Within our main corporate network, where the rest of our engineering teams actually live.

A

And, in fact, it's such a desirable platform,.

A

And such a desirable tool., whereas before we were putting github enterprise into the sandbox.

A

In order for people to test and learn, now we're getting people saying,.

A

"When's this going to arrive in our corporate network, because we want to onboard." and so we're getting a bit of pressure about this., but even then,. Our new run team,. Our new support, team,.

A

And everybody who surrounds this second instance, they're all part.

A

Of the github enterprise working group.- they're all taking part in the conversation, and letting everybody know what's happening in there.

A

So,, as you can see, all of those red circles.

A

Which showed divisions between teams, they're all starting to blur now.

A

Github enterprise is sitting in the center of our value, streams.

A

We're getting a lot more engineers coming into the system,.

A

And we're getting lots of different libraries which are being created. and, in fact, they're, all being given all of these really interesting names,.

A

Because engineers are actually really creative., we're all extremely creative in the way that we solve problems,.

A

And we're coming up with creative brands., and so our internal library that looks after all, of our branding.

A

And all of our react components is called constellation.

A

It's like the stars, navigating all of our engineers.

A

Through all of our brands.- and I remember starting constellation on github enterprise.

A

It was a single button. and people would say, "so. Why have you created.

A

A reusable library with just a single button on there?".

A

And so we said, "well,, do you know how many buttons we have.

A

Within lloyds banking, group, across all of our brands and across all of our products?".

A

If you standardize on just one button,, you've got many thousands out there.

A

And that one saving alone, on a single button, can save you countless amounts of design, time,.

A

Engineering time, product owners, and everybody who actually goes into producing these things.

A

And so,, as you can see, github enterprise,, not only is it bringing all of the collaboration together.

A

Within our engineering teams, across our value streams,, but it's also contributing to a lot of cost savings and efficiencies.

A

And increasing quality,, especially when you integrate it into devops pipelines where you've got unit testing,, bdd,, selenium,, cucumber,,.

A

And all of these various different linting tools, and sonarqube., it actually kind of centers our teams very well,.

A

And it brings everybody together in that single place.

A

And what that actually represents,, along with our guilds,.

A

Is an engineering community. all of a sudden,? All of these silo teams who are battling to get their releases out,, who are battling to solve problems that they can't reach.

A

Because it's just out of reach for them, they're, now forming an engineering community where people are-- they're, not talking about access to code, anymore.

A

they're, now talking about solving engineering and development, challenges.

A

And that's exactly where we need to be. and that's exactly where we are., but the question is why?: why do we need engineering communities?.

A

And why do we need systems like github, enterprise?,.

A

I remember social media when that first kind of came about.

A

Everything was seo,, you know, kind of pay-per-click and organic rankings within google and other search engines.

A

I remember social media was actually really difficult to measure.

A

People didn't quite get how to measure.

A

Return of engagement through social media or anything to do with social is actually really difficult to measure..

A

But, actually, github enterprise is actually really cool..

A

It's got--with its reporting api, and with all of the various different organizations.

A

That are out there analyzing how github.com is actually representing engineering,.

A

We've got some pretty interesting stats that we can throw into this,.

A

Which is a lot different where social media was.

A

When everybody wanted to do it, but didn't know where their money was going.,.

A

So,, if you look at this, and these figures were actually provided.

A

By friends of ours from gitprime., I don't know if anybody from gitprime's here.

A

I've not seen them around here.

A

but, anyway, gitprime--, I'm working with them.

A

In order to help measure how our engineering communities are succeeding within github enterprise.

A

A lot of that is test and learn., but if you look at this simple quote--, so github-based teams are 30% more collaborative.

A

Now,, if you think about that,, 30%, more collaborative means.

A

That you've got 30% more eyes on code,.

A

Which means a reduction of code duplication.

A

All of that duplication of effort is being removed.

A

By collaborating across those silos, we're actually removing.

A

All of that wastage that once went into our repos.

A

And also, not only was it duplication of effort,.

A

But it was also compounding technical debt..

A

Github enterprise is actually-- and github.com is removing that.

A

Now,, this is the one for product owners and people who actually own the product.

A

Deliverables increase, and are 28.7% faster on github.

A

So you're actual throughput of engineering increases.

A

With the way, the people collaborate through github enterprise and github.com.

A

Which means--this is amazing-- when it comes to challenger banks, when it comes to competing with our competitor challenger banks.

A

Like these scooters are for uber,, it means that we can pivot really quickly.

A

having that throughput, and being able to get things from concept into production,.

A

And tightening those cycle, times, and tightening those feedback loops with our customers, means that we can actually hone our products and create things that our customers actually want..

A

And not just by perception., it's not our perception of what customers want.. It means that we can start engaging with them..

A

We can actually pick up requests and talk to our customers,.

A

Wherever they might be, and actually start increasing our velocity, and start getting all of those products out there.

A

and that's something that github and github enterprise.

A

Is actually helping engineering teams deliver.

A

Now,, this is an interesting one., so github-based engineers have 12% less code, churn.

A

So when we talk about code, churn,.

A

Some engineers, engineers in general, are perfectionists.

A

We like to make sure that we're actually creating code.

A

Which is the best that we can physically represent within our repos for our customers., but when we keep on going over, and keep on going over, our code,.

A

And keep on reworking it and creating things that don't need to be changed,. That's what code churn is.

A

So it's constant revisiting of code.

A

Now that might be for whatever reason. there's lots of different reasons why engineers will revisit their code,.

A

But the way that github enterprise and github's set up.

A

Makes collaboration a whole lot easier., that code churn is actually reduced.

A

and that revisit of code is actually reduced as well.

A

Which means that engineers are now focused on creating new features.

A

And creating new products,, rather than going back through, and changing, and reformatting,.

A

Which is amazing.

A

Okay,, so with all of these benefits that github enterprise is creating for lloyds,.

A

These engineering communities are actually starting to evolve. Now.

A

And whereas before we were talking about, how can we increase our velocity,.

A

How can we increase our quality,?

A

How can we remove technical debt--? All of these strong words and bold missions that we had--.

A

Now we're actually talking about innersource.

A

How can we come together within our communities to come up with ideas or share common libraries.

A

That would be useful to our engineering teams?.

A

So innersource is that pattern, very similar to open source,.

A

But it lives within the boundaries of your organizational firewall.

A

It means that all of our engineers can come together..

A

They can come up with great ideas.

A

so, whereas before engineers would be delivering stories.

A

The product owners and other members of the business would tell them to do,.

A

Innersource actually allows you to be creative, with your engineering.

A

It allows me, as an engineering lead in one side of the organization,.

A

To have a conversation with somebody else in a totally different side of the conversation,, both in terms of teams and in terms of physical location.,.

A

Constellation,, like what I was talking to you about earlier,, is an innersource library., it's not built by one team;, it's built by a collection of engineers.

A

Across the whole kind of area of lloyds banking group.-.

A

And it's not just for lloyds as a brand.

A

It includes halifax, bank of scotland,, scottish widows,.

A

And all of the other different brands that we represent as well.

A

And because it's actually a product of our engineering, teams,.

A

People love it,; they want to work in it., coming up with your own product idea,, coming up with your own library,.

A

You're kind of embedding your own features in there.

A

And you're creating something that you truly believe in.

A

Because it comes from yourself. it's what engineers want., that's the reason why engineers come to the meetup that I run.

A

It's because they're actually truly proud of the work that they're doing,.

A

Both inside and outside of work.

A

and innersource kind of prepares those engineers.

A

For the next step in the journey,, which is taking all of that ability to collaborate,.

A

Taking all of that great quality code and all of those devops pipelines.

A

And all of the usefulness that other teams can actually leverage,.

A

And actually taking all of that knowledge and moving into open source.

A

So lloyds is now,. I would actually class, an engineering organization.

A

We haven't always been an engineering organization.

A

Engineering has, at points within our history,.

A

Been a means to an end., we know that we need to produce banking products.

A

We know that our customers need banking products in order to interact with financial services.

A

We might have had an it team at one point,, but we weren't an engineering organization.

A

However, we've turned a corner on that now, and I'm proud to say,, and I know that my colleagues are proud to say,.

A

That lloyds banking group is an engineering organization, now.

A

Our engineers are actually stepping out into conferences like this.

A

We're flying across the world in order to tell our story.

A

To people who we don't know., I'm here on my own,, but I'm extremely excited to be here in san francisco.

A

Telling this story to people who I regard as friends,.

A

But we don't know each other., because we're really proud, with the steps that we're taking in order to create that bank of the future, that we actually call ourselves..

A

Not only did we do that for people who we don't know,.

A

But we actually invite the challenger banks to talk to us.

A

We're actually really interested in learning about what they're doing.

A

So monzo recently announced that they've gone from zero customers.

A

To now a million, and that's a great story.

A

in order for us to change ourselves, in order for us to create products that our customers can really engage, with,.

A

Through customer experience, and in order to create libraries that engineers and developers can actually engage, with,.

A

In open source, in our future,, we need to kind of be really open minded about who our competitors are and what they do.

A

And it just so happens that our competitors,, that they want to tell their stories. they're, really kind of eager and kind of pleased.

A

When we invite them in to do that., and, equally,, we want to tell our story to them,, because we, as engineers, like to share knowledge,, we like to grow,.

A

And we like to think that we're also evolving engineering practices.

A

Within the world., which kind of brings us on to our ambitions.

A

For where we're actually moving to., not only have we gone from a place where we were tied down by treacle.

A

Through really bad practices, and we've created our guilds,, we've created our systems of engineering,.

A

We're now collaborating in code.. We've now got working groups,, so we're bringing people on the journey.

A

We're also collaborating on innersource. we're creating libraries that other teams are leveraging., but now we recognize that open source needs to be where we've got to be.

A

And in order to do that,, we've actually put open source.

A

As an engineering mission for lloyds banking, group,.

A

Moving to the end of 2018 and into 2019.

A

And that's not just engineering ambition.

A

We're actually asking our experienced engineering leads,.

A

And all of our engineers who are around that, to come together to talk about what does that actually mean.

A

For us, as engineers., because as you move into open source,, you take on a lot more responsibility..

A

Not only do you have your internal teams who are reliant on you.

A

For innersource activities,, but as soon as you cross over the threshold into open source.

A

You've now got external organizations and engineers who are not only consuming your libraries,.

A

And not only really leveraging the work that you're doing.

A

In order to further themselves,, but you've got to be able to give time to query all of their issues,.

A

And answer questions, visit meetups, and really advocate your brand.

A

And the reasons why you're creating libraries.

A

But we've chosen to do that.

A

we've chosen to have open source as a mission of our engineering teams,.

A

And we're coming together to figure out how we can do that.

A

Not only does that mean that lloyds is an engineering organization,.

A

We'll be creating libraries for other banking organizations.

A

To leverage and reuse,, but it also means that we're potentially--, I'm not saying that we're actually doing this; we're still figuring this out--, but it could be that people will actually raise pull requests against that.

A

And not only does that mean that you would have engineers.

A

From within lloyds contributing to open source for other engineers to use,.

A

But if you take, for instance, reactjs,, that's an open source platform which is created by facebook.

A

They do accept, pull requests.

A

The people who accept those pull requests are than accountable for those changes.

A

But still, that means that people within engineering communities.

A

Around javascript are actually contributing into reactjs.

A

And as lloyds, we may choose to adopt that same approach.

A

But what this does mean is that lloyds,, as an engineering organization,.

A

Has gone from a place where we've been tied, down, unable to move.

A

We've realized this, and now we're kind of uncoupled.

A

We've released our shackles now, and we're moving faster.

A

And we're actually building up that momentum, and we're getting really excited about it.

A

and so,. From this point onwards,, not only will we be growing our innersource capabilities,.

A

But I'm hoping pretty soon we'll be able to demonstrate something open, source.

A

We'll probably start small,, but I can say that we've registered our organizations.

A

The conversations are actually being had about how we actually brand that,.

A

How we actually use a licensing model that suits us and suits the world.

A

So yeah, from my point of view, lloyds banking group is a financial services organization.

A

That represents the future of financial services within the u.k.

A

Thank you very much for listening to me talk..

A

I can see that I've just got under five minutes..

A

I don't know whether I can take questions..

A

I don't think so., but if you want to keep the conversation going,.

A

You can connect to me on linkedin,. You can find me on twitter,.

A

Or feel free to come and ask me questions after this.

A

So, thank you very much,, everybody. (applause), ♪, (music) ♪.