Danielle Horney

Hi, everyone. Hope you're all safe and well.

Welcome to our session at this DOES Summit, where we're going to talk about HSBC's value stream journey and the approach we've taken to driving the right culture as the baseline for this evolution we've gone on through the process.

My name is Danielle Horney. I've worked at HSBC for nine years. Previous to that, I was at BNP Paribas for 12 years, and before that, I did seven years at M&G. My career has pretty much spanned the change lifecycle, starting in operations, working in the test team. I've been a developer, a BA, PM, and now into the role that I do today.

Lee Smith

And I'm Lee Smith, and I'm probably what you'd call an HSBC lifer. I joined in 1998 as a graduate, having studied sports science at university, where HSBC then trained me to become a COBOL programmer. Similar to Danielle, I've taken many guises in my roles through that time since '98, from a developer to a BA to a PM, to managing BA teams, and now to leading a technology function within HSBC Security Services.

In today's session, we're going to set the context a little bit, just to a small extent, of what our business is, what Security Services is, just as the size, where we fit into that business as a delivery unit. Then we'll tell you a little bit about where we started from, the challenges and opportunities we faced and were looking to address from that starting point, how we tackled those challenges, and a bit about that journey so far.

Then we'll cover what lies ahead for us next, what we've learned along the way, and how you guys can help us as we become part of this community.

Okay. I won't go into detail about this slide, but just put it up to show the size and complexity of HSBC Security Services and the business context. You can see there from the countries that we're covered in, the core of our approach is to support our clients, who all themselves have a global value chain, with local, regional, global clients, and asset owners, asset managers, banks, and broker dealers based around the globe. We ourselves then are, in essence, a global value chain ourselves, and we'll cover a little bit in the next slide where we fit into this business.

Danielle Horney

So transaction management for fund services: where do we fit in? I am the lead for product delivery, which means I sit on the business side, looking after the business analysts. We cover analysis work, client onboarding, and anything around system testing and UAT support.

Lee Smith

And myself, I sit on the technology side, looking after the pure technology side of things: the development, the support, the core architecture of those transaction management platforms that Danielle's team are doing the analysis and the onboarding for.

We're a global delivery team of 120 people across eight locations, covering core processing function for managing clients' incoming transactions across middle office and fund administration. We're platforms processing direct client transactions from multiple clients, core transaction management for feeding global fund accounting, middle office, and global custodian platforms.

A little bit about Danielle and myself: from when we started working together, we're both very closely aligned in our core values and principles, from a people perspective, from a way-we-work perspective, and that's given us a great base in building out the culture of this delivery organization that we're going to talk to you about here.

So where did we start from? What was the starting point? What were the challenges and opportunities we were trying to address in this? At the core of this, we were aligned to our core platforms, if you like: from an ingestion and trade management perspective, a pricing point of view, and then a matching and settlement point of view. We aligned ourselves around those core platforms. They did interact, but they weren't closely aligned. They weren't collaborative in nature at the core of those. We also had, and still have, a vendor suite at the core of a lot of those platforms as well. That gives us challenges itself that we'll talk about, and a lot of you will be aware of already.

Team satisfaction: we wanted to look to improve our team satisfaction engagement, bring them close to that business context of what they were delivering for, why they were here. They were delivering the change that was asked of them, but were they really aware of what that change meant? Were they part of that evolution of that change? Did they understand it from the start? Were they part of designing that as well?

We also looked at the speed of delivery. Were we focused on the right areas to deliver that maximum business value? It appeared that we were churning through change, but was it the right change again? Or was it just delivering the change for the person who was shouting loudest at that point? Therefore, what was the value that we were truly giving to the business and giving to our clients as a result of this?

From a team empowerment perspective, the teams again were given change. They were told what to do to deliver change, and they delivered that change well. But how do we create that space for teams to really ideate, experiment, and, more than anything and at the core of everything from a high-performing team perspective, how do we create that truly psychologically safe environment where people could voice their concerns, they could challenge each other, they could talk openly, and they can also challenge the business appropriately when we're talking about design and needs?

Then we had client satisfaction: looking to improve how we work with clients, how we onboard clients better, and just that overall client experience, especially around speed of delivery and getting that change through quicker.

Then we also had our project mindset around project funding models. Yet we had platform-aligned teams, then we had business and function aligned functionally, and then functionally aligned strategies.

Danielle Horney

So the journey so far. How do we take all of that, and how do we look at where we want to move forward?

There are a number of different areas that we have focused on. One of them was around our new ways of working and creating value streams. This would give us what we call a four-in-a-box model, where we would have operations, product, product delivery, and our tech leads from each of those areas working collaboratively together to agree priorities and the direction of where we wanted to move from a team. One single roadmap, one single set of OKRs, all heading in the same direction.

Next area we looked at was our data-driven decision-making. This was using tools that would allow us to look at where are our blockers, where are our problems, where are we getting change through, what is the speed of that change? Using all of that data to help us look at areas for improvement, so that we could stop starting and start finishing and really move forward.

Off the back of that, that allowed us to bring in agile coaches to help and support us. Also things like we played the feature ban game, which is a game that we could take out basically to all of our stakeholders and down. It was a real simple process that allowed people to see what was the difference in how we could work and make improvements. It was a real light bulb moment, using that game for quite a lot of the team that we were working with.

Then we also wanted to look at, from a psychological safety point of view, how we could use maybe some more coaching techniques with our teams, whether that be leader coaches or mentoring, so that we could really build that safety. In that, we did a lot of one-to-one executive coaching, as well as something we call group supervision, which was bringing a number of the teams into a group and then really building that trust with one another to be able to have open issues around issues that people were having in the team, and then sharing the team's experience to help address those problems. That has really had a big effect on the team and how we've moved forward.

Lee Smith

As a result of all the pieces that Danielle talked about there, what have we started to get really? At the core of this, as we talked about before and Danielle referenced, is developing that culture of psychological safety. It's something we're passionate about ourselves, but also the organization are passionate about, embedding that psychological safety as part of our DNA of our organization: empowering people to challenge, empowering people to experiment, and giving them the space to experiment and to fail and to learn to fail and discuss their problems without fear. I think there's a core element of that in everything we talk about here and everything we've embedded in the organization and look to embed.

As a result of creating that psychologically safe environment, under the pieces that Danielle again has talked about to drive the engagement side of things, we've started to get an empowered and dynamic and collaborative delivery function. We had that core team, we had the people, we had the knowledge, we had the expertise. What we've now got is a team that truly does collaborate together. We'll talk about some of those pieces in a second, but we're back to a team. We've got a team of 120 people across eight locations globally. They all interact with one another. They talk on a personal level, regardless of location. They get to know each other, and that has created that truly empowered and dynamic function that delivers well together.

Again, as part of that function, and as part of empowering particularly the technical teams in this space and working with Danielle's team and educating the business, we've got to a culture now, not necessarily for our core vendor apps, because as a lot of people know in this call, we have challenges with vendor apps and releasing frequently. But around the peripheries of those vendor apps, how do we release quicker? So we release in midweek. We release smaller bites of releases into smaller pockets of releases. At the core of that, again, is part of the strategy that's been driven through Markets and Securities Services Technology within HSBC, which is the principle of go faster, break less. Smaller releases, less risk around those releases, less issues as a result of those releases, and therefore our release cadence increases. Our actual incident volume goes down as a result of that. We have a more stable environment. Again, as a result of that, we have happier people. We have people who are empowered again and want to continuously improve and have that passion to continuously improve.

Danielle Horney

Some of the things that the team have come up with out the back of that is around rapid client onboarding. We came up with the idea of what we call flexible trade capture, which is a tool that meant we could remove the need for development when mapping in new trade capture files and move that into the business areas so that those could map those in themselves, speeding up the process and not needing the dependency for any release or any development.

Another one that they came up with was around the business value calculator. This was a very simple tool that allowed us to prioritize delivery of our backlog using a number of set categories that would then be scored to give us a value. Those categories would be things like the type of change, the volume of maybe the trades that are coming through for that change, the impact of not delivering that change, whether it was regulatory, and a number of other items. Once scoring that across every CR or change that came in the same, that would then give us a value. We know by delivering change with the highest value, we would then be delivering the most critical changes to the business, and it takes away the whole debate of whose change is more important.

Lee Smith

I think again, that whole piece is back to empowering the teams to make those decisions and drive that innovation in that space. One of the points that Danielle referenced there about the rapid client onboarding: this is taking the pressure off developers, not doing developers out of a role. It's taking the pressure off developers so that they can then focus on other value-add areas as well. It gives the power to the business to do that onboarding and gives the developers the power then to continuously improve in other areas in true value-adding.

A lot of things we've talked about here, it is also aligned to HSBC's tech strategy, which is termed as Vision 27. It's called Vision 27. Particularly the speed of work and people pillars that we're referencing here, that reference again the psychological safety, the career aspect from a people perspective at the heart of our organization there, and the speed of work: how do we increase that delivery of value to clients, to our operations, to our teams themselves?

Danielle Horney

So what's next? There are a number of areas that we still want to continue with as our journey moves forward.

We want to continue to develop full end-to-end pods, cross-functional teams. At the moment, our pods are made up of cross-functional teams that we own, and we want to extend that to really give us that full end-to-end lifecycle for products that are coming in.

We also want to build out FTC, or flexible trade capture as it was called on the last screen, and make that even more simpler for the business to use, what we're calling an FTC widget, and just simplify that process but increase the speed of onboarding even further.

Then we have our flow measurements to identify and track improvements. As again we spoke about on the previous slide, we really want to use that more, and as we progress and continue to experiment, we can really track where we're seeing things that work, things that maybe don't, where we maybe need to now refocus our efforts on what we need to look at going forward.

Then we want to look at our WIP limits. This is an experiment where we really want to stop starting and start finishing. Today, we definitely start to pick up things new, rather than looking at what we can complete before we move on to those new items. That's definitely an area we're currently experimenting with, and hopefully see some success off the back of.

Lee Smith

Again, seeing some real value off these already. I think when you talk about it there, Danielle, of the FTC widget aspect, at the core of that again is a low-code principle. Not true low-code, if you like, but low-code principle of giving the power to the BAs and even the business at the end of the day to map out incoming client files. As a result of that mapping on a GUI drag-and-drop, that's creating the pipeline of code that then the transactions come in through entering into a live environment. I think again, it just shows what empowerment can do and the innovation that can bring and the thought process it can bring by allowing the teams to drive that through.

Another element that is a challenge and has been a challenge, but again we're working through this certainly, is changing the budget process that we have from a project-funded approach to more of a product-funded approach, keeping a stable pipeline of funding for each value stream or each product. That gives the teams that stability. It reduces the classic feast-and-famine funding approach that we see at times where we fund a project and then that project stops or completes or finishes, and we drop the funding and the teams disappear, or they move into other projects, and they have to re-form. Keeping that stable platform for delivery teams, empowering those value streams then that Danielle referenced in the previous slides on the four-in-the-box, to really make those decisions on what is going to add value for them, what's going to drive their product forward, and here's the budget that they've got to use and the capacity they've got to use to do that. So make those decisions. As you can imagine, for a large organization like HSBC, that is not a simple process to undertake. But it's something we're on the journey of at the present time, and how do we approach that as we start to move into our next budgeting cycle.

And then finally, team supervision. Again, as I spoke on the last slide, this is something we're seeing real value from. We now want to roll this out across the teams, get more people involved, make sure it's covering everybody at all levels, and really continue to create that truly trusted and secure environment that we've started to build.

So I suppose now to probably some of the most important topics in a way is, what did we learn? What can we share, hopefully? What did we learn along this journey?

I think a core part of this, as with a lot of the journeys that I'm sure we'll hear on the DOES Summit, is start. Just start now, get perfect later. It sounds a little corny, but it's true. Start now, get perfect later. Don't wait for the path to be perfect or for the stars to be aligned. They won't be. In any organization, they won't be. But we can make real strides just by starting and doing things.

Second point: don't let blockers get in the way. We all have blockers. We have challenges within the organization, the budget cycle that we're still addressing at present time. It will stop us getting all the way, but it doesn't stop us getting some of the way and making progress regardless. The core of that, again, is the culture we've created and giving teams the empowerment to work around those blockers and to work through those blockers where they can do, and supporting the teams in getting through that. We're there as leaders to help them move forward, not to tell them what to do. I'm not the expert. We're not the experts. We need to support our teams and then help them move the blockers, but also don't let them get in the way of progress.

Learn from each other. Share successes within the teams, but even more importantly, share the failures. Share the attempts we've made, share the experiments we've done, share the times that we've not quite succeeded, share the actual system failures we've had. What can we learn from that, and how can we promote that open culture where failure's shared as much as success? It is part of progress. We learn a lot more from failing or having a challenge in front of us and what we learn from that than we do from success after success. It's important we talk about that and we share it across the group.

Probably lastly, and certainly not least: do it with a smile on your face. Work can be stressful at times. We're all under that pressure. But be there to support each other. We've created, or we've looked to create, that culture of a safe environment where teams are talking to each other globally. They're supporting each other globally. The smile on your face makes a big difference. It helps people, I'd say. Enjoy the journey. If you're going on this journey similar to us, try and enjoy the ride. It won't be simple. It will have its challenges, but enjoy it as you go along as well because it is a good journey to take.

So here's the help we're looking for. Does anyone have experience of successful value streams within large, complex organizations? We're always open to learn from others, and definitely take in any failures or bonus points that we can pick up along the way. Sharing of any lessons that others might have on similar journeys, again, could be benefit for us as we look to progress on our journey. Danielle.

Danielle Horney

Thank you everyone for listening to our value stream journey. We hope you've taken some lessons from it, some learnings from it. We're open to obviously listen to your questions and supporting where we can do. We've talked you through our challenge and our opportunities, how we tackle those, how we continue to tackle those. We're only partway through. We've only started, really, and what we've learnt along the way. As I say, hope you found some of that useful, and look forward to hearing from you all in the future, as Lee says, for your help and where we can potentially help you as well, guys. Thank you very much.

Lee Smith

Yep. Thank you.