SPEAKER_00 0:20

Tech Unboxed with BBD. Here we are, another Tech Unboxed, and today I'm with Tony and Rudolph. Tony and Rudolph, can you please tell me who you are and what you do within BBD?

SPEAKER_01 0:34

Of course. My name is Rudolph Estreisen. Um, I work in a team called ATC. We do many, many things across many, many industries, but I think we're here to talk about our health check. Uh oh yes, yes indeed. Um which is something we've been doing for quite a while. Tony, do you want to introduce yourself as well?

SPEAKER_02 0:53

Yeah, I'm uh Tony Thunderlinen and I'm the CIO for BBD, but also very much involved in um these health checks that we will be talking about today.

What A Digital Health Check Is

SPEAKER_00 1:01

Indeed, that will be the topic of the podcast. We're gonna talk about digital health checks. So can you describe to the audience what it actually is?

SPEAKER_01 1:10

Health checks are many different things to many different customers. It's quite difficult to put it in one single box, but we kind of think of it as your your health check if you had to go to your general practitioner or your doctor. Just a general checkup just to see whether everything's running smoothly, see if something might be wrong. Um, sometimes you have to have your blood pressure checked just to just to have a second opinion. And I think that's my uh my simple answer about what a health check would be.

SPEAKER_00 1:38

Okay. So it's part of the BBD package to go to the doctor regularly.

SPEAKER_01 1:44

Everyone needs the doctor at least every six months, don't we?

SPEAKER_00 1:48

No, um, what has been the original spark and and which which was the problem that actually led into sort of creating this this idea of having a formal health check?

Why Health Checks Emerged

SPEAKER_02 1:58

So it's uh for for me, it comes out of uh the history of of doing um work for our our distributed teams for many years. Um so the the ATC team is very much involved in in helping our teams to be successful. Um and uh during the years we sort of realized that um some things sometimes go wrong. Um and they need experts to go and have a look at at what went wrong and how to fix it. Um and that sort of dates back to to about 10, 15 years ago that we started doing that. Um and uh over time we we realized that it's not just our teams that struggle with with technology sometimes, it's also our clients. Um and in certain cases they've got problems and they need experts to go and have a look at that. And that's sort of course uh um how how it sort of grow uh grew into this digital health check uh thing.

SPEAKER_00 2:45

When you compare it again to the doctor, then you obviously have your own doctor and you go regularly when something hurts. Is it also used uh literally as a pre-sales tool?

SPEAKER_02 2:55

No, so it's it's a product by itself, um, if I can call it that. Um it's not a pre-sales tool. Um, having said that, um, because of the service that we provide um and obviously the value that these health checks create, in a lot of cases, the clients do ask us um if we can help to actually solve the problem as well.

Not Pre‑Sales: Independent Product

SPEAKER_00 3:12

Well, I've heard that and I read about the focus framework, and I was really positively surprised about the structure that you put around a health check. So can you tell us a little bit more about uh what the focus framework is about?

The Focus Framework Origins

SPEAKER_01 3:25

The focus framework is is Tony's brainchild, I would say. And then with our with the rest of our team, we've we've we've evolved it over time. The important thing that that really led us to to putting a framework in place is that we realized that every client has has a different requirement. There's this there's something different bothering them. Um but over the over 15 years, we ended up like looking at so many different customers in so many different ways that we were able to kind of boil that down to these 12 pillars, um, which not only includes the technology stacks that you might choose or the architecture that you have built with, but it could include processes, it could include um team structure and team health, it could include governance. So that's that was that that's where where where it really started. I think Tony would have a better, a better in detail answer though.

SPEAKER_02 4:16

Yeah, also for me, the the inception of the the focus framework was to sort of add um a bit more structure in the way that it is um executed. Um so it obviously allows us to to maintain the quality of service that we provide, um, given multiple different areas in IT that can go wrong. Um, and the framework um as a foundation helps us to repeat this regardless of what the problem is in which um different um area, as uh Rudolph mentioned. Um I think that the framework also helps to sort of create trust in that it's not just a an engagement where you go in and look at a couple of things and come up with an answer. The framework obviously talks about different areas and different things that are done and why they are done, and obviously what uh what evidence will come out of those. And it gives um sort of the trust into a repeatable um uh uh process um that is going to add value to the client.

SPEAKER_00 5:09

No, understood. And would you mind walking us through what would be those steps that you go through?

Three‑Phase Execution Approach

SPEAKER_02 5:15

So the the frameworks got multiple pillars, and uh Rudolf um can um talk about that a little bit more, but the the execution is more um the thing that that um we worry about. So there's three different parts to that. It's obviously the initial part where we've been trying to collect as much information around the problem domain as possible. Um, this is typically sort of to help to define the scope and to sort of try to um eliminate things that potentially cannot be problem or won't be problems rather, um, uh in order to get the information that is going to help us to sort of um investigate deeper into those those different errors. The second portion or the second uh step is to um is to then go and investigate those. So we've got uh information, be it through through interviews or data that we've collected from different systems or documentation that we that we've reviewed. Um we go into a uh the the actual problem space and we we try to evaluate um how that uh that problem um uh developed. And um in in a lot of cases, um because of that investigation portion, sometimes um the the problem sits in a different area. Um so that's the second um phase. And the last phase is then to then go and um collect everything that we've collected from a data perspective to go and put it together and come up with plausible solutions and perhaps even a um a time frame or some type of roadmap on how a client can solve those.

SPEAKER_00 6:43

Well, you talked about 12 pillars. What what are those 12 pillars?

SPEAKER_01 6:47

We look at uh at strategy, um which would include high-level digital strategy all the way down to this the strategies that the teams might use to deliver projects. We look at people, business processes, the quality aspects of your oper uh your operations, um, experience, information, software, infrastructure, security, governance, and risk, and all third-party things that we might be able to look at as well. So those would be our 12 pillars.

SPEAKER_00 7:13

That's a mouthful.

SPEAKER_01 7:16

12 is a lot.

SPEAKER_02 7:18

So for me, the 12 pillars are um uh 12 different areas that we we consider to be primary around um a uh a solution, um, a solution in terms of some type of technology that's being used by um an organization, um, be it people or processes, or even the technical implementation like an application that um that sort of guides those. And a 12 pillars sort of look at multiple different aspects that um is going to or can potentially add um uh problems or could be flawed or um uh could also be uh augmented, perhaps. Um so when we talk about strategy, um the strategy obviously uh goes all the way from the organizational strategy all the way through to a technical implementation strategy on like what technologies to use, um, what approaches to tackle. Um and the 12 pillars very much looks at all of those different uh areas for um the client.

Surprising Findings From The Field

SPEAKER_00 8:15

Since you both have been doing these health checks for a while, I'm a curious person. So, what has been the most surprising outcome that you ever came about?

SPEAKER_02 8:23

There's a recent one for me. Um uh the client was very worried about um their ability to deliver um quicker into a market. So a high frequency um environment where they there's a lot of changes in application that often has to be relieved, uh released. And um they felt that their ability to get new changes into a production environment was slowing down. Um and they uh at that stage, I think they were were sort of concerned that the technology um was a problem. Um what was surprising at the end of the day is that we felt uh we found that there was actually an operational problem in terms of of people um in the way that they work and uh the structures that sort of guided them rather than actual technology. So that one quite surprised me.

SPEAKER_01 9:12

Rudolph, yours? I think for me it was the same one. Um we we went in expecting there to be technical issues, and we we did we found that the technical part was actually fine, and that was that was very surprising to me as well. Usually the customer knows their own environment so well that they haven't it's like going to the doctor once again. When you go to the doctor, um you kind of have an idea about what's wrong um or what could be wrong, like how are you feeling? And most companies have that too. So companies are generally not surprised by our findings. Um, but in this case, we um we surprised them as much as they surprised us.

Triggers And How Engagement Starts

SPEAKER_00 9:51

You mentioned that uh a client is actually knowing that you sort of have to go to the doctor when something is wrong. What what are the potential other triggers that you come about uh for a customer to take a health check? And how does that work? Do they just raise their hand or how does it work? What's the process?

SPEAKER_02 10:07

So I think in a lot of cases you um you you go to the doctor because you're feeling ill or there's something wrong. Um in some other in other cases you don't. So what we've seen is um even with some of the teams that we have working in our clients, the the teams may actually find something that is not working well and then ask opinions from us, which then ultimately then becomes a health check for that client. Um so it's initiated by by by perhaps maybe a team member rather than an executive. Um uh in a lot of cases, obviously, um, because it's a well-known product in the market, um, comes to approach us from an executive perspective, knowing that there is something wrong and need somebody to to give a uh an opinion.

SPEAKER_01 10:47

Um otherwise it might be an acquisition that that the company might have made or or something like that, where uh it's part of due due diligence sometimes where where you kind of have to know what you have from a from a perspective completely outside of of of the company you're buying to know whether whether there might be issues that you face if you were to to purchase them.

SPEAKER_00 11:10

We we're taking that analogy a lot now with the doctor, but uh if you look at doctors nowadays, they are trained to give bad news. So, how does that work on your end? Um, are you guys taking a methodology there too? Because I can imagine that sometimes you have to highlight risk gaps and other stuff.

SPEAKER_01 11:27

A spoonful of sugar makes the medicine go down, I think would be a good way to always um so so we never just find a bunch of bad because we were investigating the whole thing. We have a lot of good things to say, and and in there there might be a little bit of medicine as well.

SPEAKER_02 11:44

Do we we we don't sugarcoat the outcome though? Um so yes, a spoonful of sugar is the the bits that we put around the the great things that are um around um what we're investigating. But um there's a reason why clients are wanna wanna do this, is because they want to know the truth. So we never try to sort of package this as something that you that that it's not. If it's a severe problem, we will we will call it a severe problem. Um but it's not just about finding a problem, but it's uh it's also about um proposing potential solutions to that problem as well as a potential timeline on how to solve that. And and obviously the time timeline can boil down to uh to uh to a cost as well, so they can understand what the impact is. Um, and I think for me, the the fact that we don't um uh sell it as anything else but the truth um makes it uh something that that people believe and want to yeah makes it very valu uh valuable because you you f you actually give transparency in advance.

Tech Roots And Transformational Fixes

SPEAKER_00 12:41

Um you earlier gave an example where um the outcome was people. Have you also got like outcomes that were technology and and therefore led to a very transformational project at the other side?

SPEAKER_02 12:53

The health checks were born out of a a peer technology um perspective. So it was the early days was very much about going and finding um implementation problems where code was was uh potentially not written as well as it could, or had embedded um technical debt that um that that um uh happened over many, many years. Um so uh obviously the the foundation being technology now supports the rest of the uh the different areas, but we still find where uh a lot of focus is about going and finding a technology problem um and then obviously providing uh solutions to those.

Handling Regulation And Compliance

SPEAKER_00 13:32

I was also wondering um because you also have a lot of clients within the financial industry and in the health industry, so highly regulated. So, how do you bring in the dimension of regulations in this health check?

SPEAKER_01 13:43

That's a hard one to answer. Um, I think we're very lucky that all the customers that that that are in these heavily regulated spaces, they know the regulation really well. And and we also have a lot of experts in those fields because we work with a lot of customers in those fields. So we have experts that we can rely on inside of the business as well, that we will bring in on health checks that are related to a particular um uh regulatory framework or or anything like that. Um that being said, we're usually lucky like most people do not have problems with governance and regulation if they're in a room in an already regulated field. Um more often than not, is it's a telecommunications company that wants to become a financial service provider, they might not know, and we have the experts that can really help with that.

The Core Team And Expert Network

SPEAKER_02 14:34

And um for for me, um the we the the health check is is not an audit process. We're not there to go and audit um uh any regulatory requirements. Um, so uh where we are are required to do and where where it makes sense to include this as part of a health check, it's more about the the the compliance in terms of what is being built from a system solution people perspective in terms of of those things that they have to comply to. So we don't go and audit a compliance um requirement. We would look at um alignment to those in terms of the implementation rather.

SPEAKER_00 15:10

Considering that you actually touch upon so many uh aspects of uh of a solution or a product or a situation, you must have a mega team.

SPEAKER_02 15:20

We we do, if I can call it that. We I could say that we've got a mega team of about the thousand two hundred people. Um VBD is about uh thousand two hundred people um big, and um the actual core of the execution only um lives in about four core people. Um so four core people is typically the uh um the Rudolph's team, which is the ATC team, um and then we'll include the experts that were required to uh to guide certain areas. Uh for instance, um uh both Rudolph, myself, and the rest of the team are are uh software engineers um by nature. We're not very good at doing pretty the pretty things. So when it comes to doing an experience um review where we're looking at um user experience um uh graphical design type things, we will include one of our experts in the area to help to sort of tackle the the portion that they are an expert on where we're not. So at any given point, we we can include as many people as we want. So at yes, if uh I think a um a 1,200 um member uh health check team is going to be slightly big, but uh fortunately we don't need all of them all the time.

SPEAKER_00 16:24

I was also wondering because um we very often now talked about doing health checks with others. Have you done health checks as well internally?

Internal Checks And Objectivity

SPEAKER_01 16:32

Like Dodi said, oftentimes there we've we've uh we've had a health check kicked off internally. So we might have a team of people at a particular customer and they would like a second opinion about their own work as well. Um and that's what what kicks this off. We don't do that much development for ourselves, but yes, our we have teams at clients who go, we're going down a rabbit hole here. Are we sure this is the right thing to do? Or they they notice a performance issue or anything like that. And like we want to bring in some experts and then the c then they work with the client to bring us in on health checks as well. And it's a little bit of a Chinese wall where we don't allow those team members to form part of the of the health check so that we really get a an opinion that is is new and not not just based on on our team.

SPEAKER_00 17:21

So happy to hear that you eat your own medicine.

The Future: AI And Speed

SPEAKER_02 17:23

I would extend on that. It's um that the health checks are also a uh a primary uh mechanism um in in uh due diligence exercises for the acquisitions that we've made over the years as well.

SPEAKER_00 17:34

The health checks, obviously, Tony, have been uh a construct from you. Um so I'm wondering how do you see the future of it? How do you see that evolving over the next few years?

SPEAKER_02 17:45

Um, I think we're in um an exciting time with uh everybody's talking about AI, and a lot of people are still trying to find a spot for AI to live in. Um I um we don't consider the the type of work that we do. Um I do believe that um if we incorporate technology such and uh such as AI is going to help us to understand information a lot a lot quicker where we're currently doing it normally. Um, in some cases, here do use a bit of AI to sort of um help to define things. But I think um the ability to sort of process things a lot faster um allows us to actually do a lot more. So the the health checks are typically structured around a certain period of time. And um the team that's included to do the work only has that period of time to do the work. And we do this on purpose, so we don't sit for months and months and months doing something that that everybody eventually um is gonna forget about. So we try and do it as quick as possible and try to give um good insight as quick as possible. So I think all these tools that are are becoming um enterprise ready and um uh uh context uh const context um way will help us to to do a lot more during that actual uh time. So it's gonna be really exciting to see uh how check is growing to a massive product uh product purely because of those uh technology aesthetic system.

SPEAKER_00 19:02

Rudolph, from your perspective, doing them on a day-to-day basis, how does your future the future of HealthCheck for you look like?

SPEAKER_01 19:08

The future of health checks, um we like to do a lot more of them. And as Tony said, because we have we've built the framework, but because tools are getting smarter and better, um I we're seeing uh being able to do them in less time. So you so where we might have needed six weeks to do a particular kind of health check before, we might now be able to do it in three or four weeks, which means it will be cheaper for the customer, and we will be able to do more of them without burnout. Because if we have run two or three of them concurrently with a core team of four, it can get a little bit uh a little bit hairy, I would say.

SPEAKER_00 19:46

As we're actually getting towards the end of our podcast here, and I'm sure we inspired a lot of people with this health check, but the big question that we would all have is how do we start one?

SPEAKER_02 19:56

Everybody's aware of uh things that they uh that They want to do better, or perhaps of something that is wrong that needs an intervention. Unfortunately, there's not always time to go and look at the problem and understand it because people obviously want to operate. They need to make money. So on our website, we've got a number of different um descriptions on what these health checks are about. And everybody can get hold of us through the website to have some type of conversation in terms of how we can potentially assist.

SPEAKER_00 20:30

Oh, brilliant. Thank you very much, both Tony and Rudolph for this participation in our podcast. And thank you to the audience. Please stay tuned for more Tech Unboxed. Thank you so much.

SPEAKER_01 20:41

Thanks for having us.