Great to meet you. Um, I'm Ben Grinnell. Been working for North Highland and helping organize some of the DevOps summits for the last 10 years. Um, do you want to give us an introduction?

Yeah. Hey, Ben. Great to meet you. Uh, David Keen, uh, I'm here to talk about HSBC's, um, DevOps journey.

Thank you. And I really enjoyed your talk this morning. Um, one thing that struck me was the size of the organization and, uh, the scale and the number of different cultures. You said you're regulated in 70 countries or something like that, and you've got a workforce bigger than about 50 of the countries in the world.

Yeah. So when you look at working, um, across some of those, uh, cultural boundaries and cultural norms and things like that, what are the biggest learnings you've had from trying to get a team to work when they've all got very different starting point, I guess? Yeah. You know, it, it's, um, it can be equally challenging and frustrating, I suppose, working in such a large, uh, organization.

Um, there's 50,000 or so people in, in, in technology, uh, a quarter of a billion or more, uh, in, in the entire organization. Uh, and in our tech footprint. You know, we have a lot of people in India, as you expect. We also have a lot of people in China, uh, and then in Poland, uh, in Mexico, uk and in about 40 other countries as well, but the top four or five.

So all in different time zones, uh, all in, uh, you know, different cultural, uh, starting points. Uh, and the way a lot of our organizations are, you know, they're very global in nature. Uh, particularly the investment bank and the commercial bank. And the teams tend to be global in nature too.

So, so this idea of everybody being able to meet in the room, you know, um, you know, we're, we were, we were already well practiced on Zoom and other ways of, of, of, of, of, of meeting long before we had to with, uh, with, uh, COVID. So some of those sort of transitions were a little bit easier for us. I, I, I, I suppose, um, it, it from the different, you know, cultural, um, uh, you know, start starting points, you know, I think the, the secret sauce if, if we hit it was, um, uh, you know, trying to figure out what's in it for the individual. You, you can't move 50,000 people with high level slogans, and we're doing it for the share price you have.

You have to, it has to be a little bit more in, in, in, in it for them. And I think we struggled until we got to that point, you know, and that was, that was a real mover, and it didn't matter what group, uh, or or where they came from that kind of had, uh, had a significant impact. And the last thing I'll say in that is, you know, the, the way we went to measure, you know, it, it's, it's agnostic of, of team, but we've encouraged teams and we allow teams, uh, to, to measure themselves against their own history, right? So you're not, you're not always being measured against somebody else.

It's a how mu how have I improved against where I was yesterday and where am I trying to get to? And that cut out a lot of, um, uh, I guess, uh, false battles, put it that way. Yeah, I think that's hugely important. I see so many people create a perverse competition when you're trying to create sharing and collaboration, um, by comparing teams with other teams.

Um, you spoke about different cultures in different countries. Um, are there different employment models as well? I mean, I'm not sure what the makeup of your technology organization is, but presumably you've got some, some outsourced partners providing you with some staff, and how's the makeup of the team and what's the, what's the, the high level view of that? Yeah, so H SS b C doesn't make the same use of outsourcing partners like some of the other firms that I worked at previously where they would outsource the work and, and, and, uh, you know, have contracts with, with an agency or a a, an organization to do that for them.

Uh, we certainly make use of, of, of those sorts of partners, but more, uh, as augmentation to our staff to allow, allow us to flex at least historically, that that's what we did. So some of the questions I got and some of the other people I heard speaking, you know, that's, that's probably a bigger challenge for, for them. Um, and I'm curious to know what impact it will have on that industry. You know, if Agile and DevOps becomes a norm and, and having to, um, uh, you know, have everybody, uh, focus on the same outcomes, that's not an easy thing to achieve.

Uh, when you're dealing with different partners. It's not impossible. And we have done it in places, but we're probably not as challenged in that regard as, as some of our peers. Yeah, I often looked at the, the big firms and thought their DevOps transformation is far more challenging than most of their clients because it can only run at the pace of each client, and they've got thousands of them to run concurrently.

So yeah. Huge challenge. Yeah, it is. I mean, I, I, I, I feel sorry for myself for the number of silos that I have to deal with and get, uh, trying to get people to, to, to agree and come to a common way.

That must be an impossibility when you're dealing with, you know, different industries and, and completely different organizations. Um, uh, uh, very challenging for, for those, for those teams. Yeah. So you said you're using mainly a staff org model rather than thrown work over the fence, which is great, but when you bring, when you bring those people in, you talked about incentivizing individual.

How are you, how are you getting the contracts outta the way and, and focusing on the individual? What, what are you doing to make that work? Yeah, I, I hope that we, you know, we, we, we treat people, you know, the same, irrespective of whether they're, you know, we have a red badge or a green badge depending on, on, on, on your, on your status, uh, with your perm and, and so, or, or not. Um, so we certainly, uh, incentivized the teams and the pods.

And again, you know, I talked about the, the metrics that we put in place, fairly simple and fairly few, uh, and each team, there is some good, some good gamification that, that, that, that, that goes on. Um, I think people try and improve their own status, right? And it teams tend to be a mixture of internal and ex external people. And I think you'll get that cultural buy-in to the team, right?

You, you, you'll get that, that unification happening at the, at the simplest level if, if, if you like. Um, and so we see the, the change driving there. I'm not sure that, um, because we don't do large outsource programs with vendors and it's, it's contract driven that we, we've had to address that, that that challenge. So You haven't gotta get the management out the way on their side.

No, I, I, I, you know, just re reacting to your question, I, I, I, it's not something that I've spent too much time on, right? And I think that just reflects that it's not the biggest issue for us. Certainly I can probably reflect on, you know, trying to get some management on our own side out of the way, uh, our on side, uh, maybe is, is a better thing, thing, thing to do, uh, thing to say. Um, that's really been a challenge.

And, and, um, you know, I reflected myself, you know, I've come on this journey too, right? Uh, you know, when, when, uh, when the, the teams that we were, that were innovating and they said to me that they wanted to go faster, I just thought that was madness. It was going to lead to, you know, greater outages and, and the rest of it. So we all go in the learning journey.

Um, but I think that conversation is an internal one. Trying to influence people and the external one's not something that we've had to be overexposed to. That's good to hear. Yeah.

Um, So you spoke about, um, Getting, getting started and then scaling. Um, and part of that is, um, you have these trailblazing teams, and I always call them flashes of brilliance. Uh, and that's all they are. Unless you can scale it, um, quite often I think organizations forget that if you've got trailblazers disrupting and breaking the rules, you need to change the rules afterwards.

So it sounds like from your talk, you're well on that journey and you've, you've got to a degree of scale. What have you done to, um, change the rules after the trailblazers have found that they're in the way? Yeah, But it's very interesting. I it's a 13 year journey, right?

And, you know, maybe some might argue it's 14 or 12, you know, not an exact, an exact science. Um, and so if I come here 13 years ago and said, this is our plan, and this is what we're going to do, and this, this is the innovators, you know, every would've thought I was mad. And, and, and not particularly ambitious, but you, that's reality in a large, complex organization. It's not that you have some innovators, uh, and, and then you, you, you switch the organization.

It's a process of persuasion, right? And I was a part of that as, as, as, as I just said, right? So you, you, you use the innovators, you encourage them, you give them some latitude, but you, you demonstrate the value that they bring and successes and how they can do things better, right? And you use that to persuade the next person and then the next person.

And that's why it's takes so long. Now, you do get to a critical mass, and we, you know, with the, with the first group of innovators, it took a while, you know, a year for that rest of that department to come on, on board, and then maybe a couple more years for the rest of the entire investment bank to come on board. You could argue some of that is still happening, but they're the, the late majority or the laggards now, as the case might be. So it is a, it's a continuous exercise of repetition, uh, and, and demonstrating the good that can come from these things and persuading those people who are, you know, the guardians in one way or another.

And I was in the guardian kind of role myself, that by, by changing the way we work, we're not making it riskier. 'cause that's people's concern, right? You're doing something dangerous, you're being agile, you're, you're being risky. Um, and actually it's quite the opposite to that, but that's not what people hear, right?

And so you have to take your time and you have to persuade people, and you have to bring people with you. You can always run over your occasional wall, right? But you can't do it continuously. And that's why, you know, certainly in my experience, you know, it takes time.

It, it does. Yeah. And it sounded like you were doing it almost sort of business product or business unit by business unit, rather than doing it across technology. So you spoke about what you, you mentioned there several different aspects of banking.

Is that aligned to the value stream? So you are able to demonstrate how's the integration with technology in the business when you're doing this? Yeah. Um, you, we, we used to argue about this.

You, we, we had a certain, uh, relatively small capability in the center. You know, how do we help the transformation as much as possible? Where do we put our energy? Where do we put our resources?

Where do we put our dollars? And, and we, we probably had lots of formula that we came up with and, and, and, and theories about it. Uh, but actually at the end of the day, we decided we would just go where they cared the most, right? Where you had the leadership that cared the most, uh, that were interested, um, that that's where we invested our time.

So it didn't, it didn't follow a, a, a neat line. You'd move from one department to the next or upper department or anything like that. We, we, we took it by opportunity, I have to say, certainly in the early days. And you know, that, that that first story that I talked about, the innovators in, in FX evolve, that started with a disaster, right?

And I'm not recommending everybody wait for disaster or, or engineer a disaster, but you have to make use of the opportunities that present your, uh, that themselves. So it wasn't a nice, neat plan. We'll do a, then we'll do B, then we'll do c. We, we, we definitely went where the opportunity arose and there arose in all sorts of different reasons.

Uh, you know, you might have somebody new came into the organization who liked this way of working. You might have somebody who, who, who, who discovered, you know, their friends were enjoying it in a different, in, in, in a different part. And you made use of every single one of those opportunities that you could. And you got the critical mass.

I can't say that's the best way or, or that's what the theory books would say, but that was our experience. Just keep building momentum. Never let a, an opportunity go to waste. Uh, um, you know, where you have innovators and people who are, uh, uh, trying to do the right thing, but to do it in a new way, give them as much love as you can, give them as much backing as you can.

You have to bring a certain amount of technical competence if you, if you, if you lack it in certain places. But tooling and systems generally aren't the issue. It's much more about the people and the mindset. Yeah.

We've spoken a lot about people and how important they are. Uh, totally agree. How much of a, well on, on the journey you've been on, um, what are you doing to, um, attract and retain the talent that you need to do this? And, um, and perhaps how much growing your own are you doing versus, uh, experience hires and things like that?

Yeah, especially I, um, two interesting stories about that maybe. So I remember I was in, uh, China where we have a, a large IT center, H S B C staff mostly. Um, and, and as a, as a senior manager, when you go there, you do something called an exchange session. And, and that's, uh, you know, an event where you turn up and you meet 10 to 20 members of staff, not from your department, they're from wherever.

And it's an opportunity for them to give you feedback on anything, right? Uh, and I was running one of these sessions, uh, last time I, I was there, uh, and you know, I was going around the table and I was hearing all the usual things, right? The food in the canteen's not great, you know, um, don't get enough holidays, you know, my friends left because they weren't getting paid enough. All how you up.

You listen to all of these things and it's an opportunity for people to, to, to talk about anything. And I got to the end of the table and I, there was this guy sitting at the end, he a big smile on his face, and I was a bit nervous, I have to say, what's he going to say when I get to him? And remember, he just said, you know what, I wrote some code last week and today 3000 people are using it. And, you know, I dunno if you read Daniel Pink, you know, uh, autonomy, mastery and purpose, I just thought that hit the nail on the head for me.

Maybe he didn't like the food in the canteen, right? Maybe he'd like a pay rise. I don't know. But you know, the thing that was so, uh, great about that is the energy that he had, you know, he, he had that sense of purpose, right?

He'd done something that he felt was cool, you know, his mastery, uh, and lots of people were using it straight away, that real fast feedback loop, right? And I just thought, you know, if we could, if we could bottle that and give it to everybody, we, we would truly have an awesome organization and a great place to, to work, right? So, so at a, at a, at a bottom up level, I, I just felt personally that was a, you know, great feedback that I got, right? Yeah.

Um, uh, other things that we're trying to do, one of the other things that I do in, in the bank is, is I chair the external fos, uh, uh, committee for, for the bank. And so for a long time, the bank had this desire to give back to the, the free and open source, uh, community, uh, and kinda went nowhere, uh, to be honest, you know, there was, uh, barriers in the way natural ones, legal, you know, all sorts of different things. Um, uh, and so about 18 months or so, I, I reestablished that, that board, I was asked to reestablish that, that board. And in March of last year, H SS b c uh, became maybe the first major British bank to actually, uh, give back, right?

Uh, and over the course of 22, we, we, we created a number of, of of things that we've put out there, uh, for the community. Uh, and um, this month, actually just right now, uh, we are contributing first to the first project that H S B C didn't originate. So contributing to somebody else's I idea. And, and so I, I say I tell that because that strategy was put in place five years ago, but not acted upon in order to attract and retain top talent.

Because some top talent, they like to be able to give back. Everyone uses, uh, foss, right? And so to be able to contribute back and contribute back in your H S B C name as opposed to what lots of people used to go home and write it, and then send, and then maybe bring it in, you know, uh, to be able to do that and the, and the enjoyment that people get from it, you know, that's something else that we've done that I think, uh, appeals certainly to your top, top talent. Yeah.

I master admit, it reminds me of one of the first talks I heard here was Topo Powell talking about how he was doing that at Capital One and finding as a byproduct, it was a massive way of advertising the engineering competence of the organization and what they were doing. You know, just open source, their dashboards, showing how much they're investing in, uh, making the developers' lives easier and things. And it was a amazing way of advertising to a very targeted audience of the best developers. So You really important, I find too, you know, when you do that externally, actually, it's sometimes the most powerful way to advertise internally about what you can do.

Uh, because trying to communicate internally, you know, it's a real challenge. You know, it's a big organization and you're in all these different countries. Um, and, and, and once you, once you do your best and, and, and, and there's lots of different channels that, that you can pull. Sometimes when you do something external like that, actually people hook onto that, you know, in your own organization, and it's the first time that they discover it.

So it, it's a great internal communications tool too. Right. Yeah. That's interesting.

Um, so overall, um, when you look at, um, growing your own talent versus hiring talent in versus, uh, using, uh, staff augmentation, is there a direction of travel or does it differ in every country? Or how are you seeing that? Um, I think it's changed o over time. I think we are becoming a more engineer led organization.

Um, we're, we're possibly moving from a, a, a position where, where we didn't value engineering as much. We were maybe an organization that bought more and built less. Uh, and we're moving into a, a pace where we were valuing that, that hardcore engineering skills, uh, uh, a a lot more. So we're putting in places, uh, things that recognize, uh, competency for an engineer.

So for a long time, you know, in the traditional organization, like, like, like ours, people felt to get ahead, they had to become a manager, uh, and they had to kind of move out of that technical stream. Uh, and we've, so we've put the structures in place so people can get to the very highest levels in the organization, you know, in terms of titles and reward and the rest of it, uh, but still stay true to their, to their technical delivery. And that breeds, you know, success 'cause other people see that and, and, and, and they latch onto it. So I think we're on that journey to, to, uh, to, to respect the talent that we have, to reward the talent that we have and to attract more in.

It's definitely been a, a, a shift in focus over, you know, I've been with the bank 12 years and I think it's shifted quite a long way in that direction over that time. That's great to hear. We've got a talk later on from Rosner Radcliff that I b m distinguished engineer about how well they've done with that, that that career path and avoiding taking your best engineers and making their managers. 'cause yes, they're not, not often the best people managers.

No, Sometimes they're, sometimes they're not. You know, and, and, and, uh, if people are, are, are producing great stuff, you need to be able to reward them for that. Uh, and, and have others see it as this is a career path that I, I can progress on. Yeah.

Great. Are there any other, um, pertinent points in your talk we haven't touched on yet? Uh, I, I think, you know, the, the, the metrics is a big debate. So when I did the q and A session afterwards, there was lots of discussion about that.

I probably spent more time of my life talking about metrics than I, than I, than I care to remember. I think the only, you know, or the secret sauce things about that, for us it was simplicity. You know, we kept with the door metrics. Uh, we, we absolutely made them things that were, uh, one of the principles that we followed is this had to be something that was available to everybody without effort, you know, not filling in the spreadsheet, you know, we've made all those mistakes previously.

Fill in the survey. Tell me how DevOps you feel today. How agile are you today? You know, so, so moving to the, the, the simple metrics that we did, uh, but we can have in an automated way, really was very significant for us.

You know, we know we're heading in the right direction. We're confident at least that we're heading in the right direction. That, and the, uh, the thing about it controls as products, right? Um, you know, that, I think that resonated with a lot of people, again, in the q and a session afterwards, particularly people who work in financial services, naturally we have right?

Uh, lots of controls That's right. And proper. And we look after people's money, right? Isn't, it's an important thing.

Um, but if I can, you know, exaggerate for effect, if, if you like, you know, the job of, of a control owner historically might have been to make the control as hard as possible to ensure that you reach reaching a very, very high, high standard and not really thinking about the person who had to consume it. And we could have turned that on its head. And we, we, we turned a, what was perceived to be a big weakness or a big blocker, actually into an enabler. And that was a real game changer for us.

So treating controls as products and considering our, uh, consumer base, our users or engineers as the people that we needed to get feedback from to ensure that they were, you know, it was a consumable product, right? Uh, that was, that was a huge thing for us. Now it's just as, uh, uh, as rigorous a control, if not more, but that different approach to it, you know, really significant game changer for us, I think. Yeah, that's one thing I thought was quite unique.

I hadn't heard that before, so that's really useful. Um, and your metrics? The only thing I didn't find simple was the acronym at the first one. What was it again?

Pd. Pd. P P B Y. I think production deployments per 10 person team per year.

Yeah. We won't, we won't patent it just yet. We'll try and we'll try and get rid of a couple letters. I, I did like the way when you filled it out, it was very meaningful.

It made flu sense to everyone, so it's good. Um, alright. Well thank you for making the time to chat to me. That's been great.

Okay. Thanks very much. Thank you. It's great.