Hello, everyone. A very warm welcome and a very warm welcome from Netherlands.I'm really happy to be here today to talk about a topic that has stayed close to me throughout my career. I have spent more than twenty years in IT infrastructure and platform engineering. And if there's one word you keep hearing again and again in this field, it's resilience. Resilience is everywhere. Resilient systems, resilient architecture, resilient platforms, and many more. We design for it. We test for it. We monitor for it. But over the years, I realized something. The most resilient systems I have seen were not built only through technology. They were built by teams with resilient culture. And before I dive into that story, let me quickly introduce myself and the journey that has shaped this perspective. So I am Ramay Subwaya.

I come with over twenty plus years of IT infrastructure and platform engineering experience. I started my career with an IT services company called Cognizant. I was there for sixteen years, and then I moved to a Japanese bank called MUFG in The Netherlands. I was there for thirteen months, and then I started my career with ING Bank in The Netherlands, and now it's gonna be almost five years in ING. I have an executive MBA from Erasmus University Rotterdam School of Management in The Netherlands. And when I get some free time, I do IT volunteering. I do yoga, Zumba, and I'm very and I'm a very passionate DJ spinning the decks for cultural and corporate events in The Netherlands. So before we get into the crux of the topics, let's check our understanding. What comes to your mind when you hear these words? Reliability, availability, and resilience.

You can give me your answers in the chat. Okay. I am not able to check my chat because of my screen share, but I will still continue. I'm gonna use an example to explain the meaning of these words and the difference. Let's take a car as an example. I believe most of us drive a car. Is the car available to use right now? When I get into a car and I need to go to and I need to commute to a place and I start my car, Does my car start and I'm able to use my car now? That is availability. Does the car work consistently over time? That is reliability. For example, every single day, I need to commute to work. I get into the car. I start my car, and every single day, I'm able to drive my car with very less issues on maintenance. That is reliability.

Let's assume we had a flat tire, which can happen. As a resilient driver, how did you manage the situation and ensure the journey continues despite the failure? That is resilience. In short, availability means the car starts. Reliability means it keeps running well. Resilience means even after a breakdown, you still find a way to reach your destination. That is resilience. Resilience is not about avoiding failure. It is about how you respond, recover, adapt, and learn from it. When you hear the word resilience, especially in tech word tech world, words like redundancy, failover, backup, high availability, disaster recovery, and all these things comes to our mind. We often think resilience is something something we can simply install or configure later, like redundancy, like backups. But resilience is much deeper than that.

For example, a company installs fire extinguisher everywhere, but no one knows how to use them. Are they resilient? No. So here is my story. This was not a theoretical exercise. The situation I encountered was truly eye opening where I learned to stop asking how do we build resilient systems and started asking how do we build resilient teams, A shift in thinking. Platform engineering is critical by nature. But when it's for a critical banking application, the pressure and responsibility multiplies very quickly. I started as a lead for the platform team three years ago. As you might know in banking environment, failure is expensive. Change is constant. Regulation is very strict. For you to understand the complexity of this environment, imagine changing the engine of a plane mid flight.

I know it's a bit over exaggeration, but still, that's what platform engineering and banking feels like. So when I started as a platform lead, one of the first things I did was spend time talking to my engineers in the platform team, not about the technology, but about how they felt about their work. And I realized there is a problem that I need to address. And what was the problem? The problem statement was what we do doesn't really matter. Nobody sees platform team when everything works. In fact, they even made a joke as well stating, platform teams are a bit like plumbing. Nobody compliments the plumbing until the toilet stops working. We understand. Right? So I organized a team off-site. When I mean off-site, we didn't go to some nice mountainous region and do our yoga retreat place.

All I did was I took the team, and we went to another building in the same office campus. So that was the budget that I had for the team off-site. And the first half of the session was about asking three basic questions and trying to understand what we arrive at from those three basic questions. The questions were, who are we? What do we do? Why does it matter? At first, the answers are very technical. Like, we manage the servers. We manage the network. We manage the database. We manage the systems, and so on. And I started asking follow-up questions. And I asked them, okay. We manage the servers. Can the server be down for two hours, let's say? And they were like, no. We cannot imagine a server being down for two hours. No. That's not possible.

That cannot happen. I said, okay. Understand. And I said, okay. We are platform team. We are back end team, so we don't need to be available round the clock. They said, no. No. That is not the case. We are platform team. We have to be available 24 by seven round the clock. We need to support. We need to fix things if something happens in the platform. I said, I understand. So I kept asking more and more follow-up questions, and we were doing this exercise. They started realizing something deeper. At the end of the session, what I realized, which I mentioned and the team also realized was this. We are not just the back end team. We are not just platform team. We are the reason everything works. We are the foundation. When I said that, I could see in the room everyone nodding, and everyone agreed to I mean, we're agreeing to what I said.

That was a real confirmation that they really see the impact that they were create that they were do creating. For me, transformation first starts with reflection. So this was the first half of the off-site. The second half of the off-site was about for the team to come up with a team motto, which I will share at the end of the presentation. Let's keep the suspense until then. As the team started recognizing the impact they were creating, I asked them what did we actually unlock through this journey? And three powerful shifts emerged. Pride. They could see real pride in what they do, that we are the beating heart of the bank. The second one was ownership. When pride increases, ownership naturally follows.

I remember in one of one of I I believe last year during the Christmas load Christmas Day where the we were expecting peak load, I was casually discussing with the team. Should we scale up our infrastructure? Should we do anything about the peak load? And then they said, our platform works like a charm. We have a beast. We can handle the peak load. That's the kind of pride and ownership they had about the platform. And the third shift was about clarity of purpose. They understood their higher purpose. Earlier, they used to say, we manage back end systems, but now they say, we enable seamless experience for our customers. In short, pride gave the team energy. Ownership gave the team accountability, and clarity of purpose gave the team meaning. So with that in mind, we also understand a mindset shift and a motto does not miraculously build teams with resilient culture. It's a daily practice.

It has to become part of everyday behavior, everyday practices. And that eventually led us to create a simple framework for building teams with resilient culture. There are six practical steps that would help you achieve that. Because resilient teams should not just survive pressure. They should be able to thrive through it, and that framework is called thrive framework. So what does Thrive stand for? T stands for transparency and communication, h stands for human centered leadership, r for readiness and adaptability, I for improvement through continuous learning, v for the voice and psychological safety, and then v for empowered shared ownership. Let's understand each of the six pillars and what it really means. The first and the foremost is transparency and communication. I would like to ask you a question. What is the difference between transparency and honesty? You can give me answers in the chat. Okay. I'm still not able to see my chat.

I will continue to explain this with an example. Let's assume one of my engineer is doing a production implementation this morning. I had to do a production implementation this morning. So I walk up to the engineer, and I ask my engineer, how did the implementation go? And then the engineer says, okay. We did, but we had to roll back for this and this an issue. Okay. That is honesty. Transparency is different. Transparency is once the change has to be rolled back, the engineer communicates to me that we had to roll back the change because of so and so reason. That is transparency. They are two different things. I always encourage transparent communication because transparent communication helps resilience become part of the culture because you stop hiding problems, you start collaborating earlier, and you build trust through everyday interactions.

The second pillar is about human centered leadership. What is human centered leadership? It is about leading with empathy, trust, and empowerment, and always putting people at the center. And leaders play a very important role because teams often mirror how leaders behave, communicate, and respond under pressure. With empowerment and autonomy, leaders help create ownership instead of dependency. Leaders have to remain calm under pressure because if leaders panic, teams panic. If leaders stay calm, teams can think clearly. And it's a huge responsibility for the leaders to celebrate every single milestone, every single success, and every single achievement. And I'm very popular in my department for all kind of celebration that happens. Finally, leaders should showcase purpose driven leadership. Why? Because leaders help teams understand why their work matters. The third pillar is about readiness and adaptability. Resilience is not about controlling everything.

It's about responding effectively when things do not go as per your plan. So prepared teams recover faster because they expect disruption instead of fearing fearing it. So how do we do this in our team? Every year in the road map that we make, we allocate some time to simulate disaster recovery scenarios. We really put in time to simulate these scenarios. We execute the test. We prepare runbooks and see and finally, we see the outcome. Is the outcome meeting our expectations? Are we fully ready to handle the scenario, or should do do we need to improve something? So this is an exercise which we do every year to simulate the Doctor scenarios, always anticipating failure and see how prepared and how ready we are. The fourth pillar is about continuous learning, improvement through continuous learning. Failure is unavoidable. Teams that fear mistakes become defensive. Teams that learn continuously becomes adaptive.

And this, I have to give an example. One of our engineer in the team always says, never compromise and treat everything as an opportunity, and we really do that. The next pillar is about the psychological safety, the voice and psychological safety. This is very, very, very important in the thrive framework because in many teams, people stay silent because they fear blame, judgment, or looking incompetent. But silence delays problems. Resilient teams bring up issues early because they know that honesty will always be supported and appreciated. Finally, the last pillar is empowered shared ownership. It's about building collective accountability instead of siloed responsibility. We work together as a team, and it's not about my own responsibility. It's a team responsibility. It's a team accountability. And every success we in see in our team is seen as a team success. We don't see it as an individual success.

So these are the six important pillars in the Thrive framework that'll help you to build resilient culture in your teams. Role was not built in a day, and resilient teams with resilient culture are not built through one off-site, one motto, or one process. They are built slowly through consistent behaviors, shared experiences, and how people show up for each other every single day. Because in the end, resilient systems are built by resilient people. Because my presentation wasn't working and I had to show it as a PDF, you could already see my motto. So this is the motto that the team came up with. We are the backstage champions that let the magic happen on the front stage.

With that note, I really thank you for listening to my presentation, and I believe you could really take away something very useful that you you could do with your teams and build resilient teams.