• • Nuno Miller, Chief Information Officer, Sonae Fashion

Download Podcast
Apple Podcast, Google Podcast, Spotify, iHeartRadio, SoundCloud, TuneIn, and Stitcher. Find other syndication channels here or search CIO Talk Network podcast on any other app.
Explore More

• • From Problem to Productive Workforce
  • Who Goes There? Overcoming the Password Problem
  • Using Problems to Drive Focus
  • Using Digital to Solve Analog Problems
  • The Problem with ROI
  • Large Application Delivery: Solving a Good Problem

Transcript

Sanjog Aul [00:00:23]:

Hello, and welcome to the CTN. To learn more about the show, please visit ciotalknetwork.com, and today, we have a very interesting topic, which is Fixing Problems Before They Happen. Wish we all had that crystal ball, but then is there a way to do that? So we always have some daily fires that we fight, and we are spent at the end of the day, but how many of us think about what if I could take a pause and prevent these problems from happening in the first place? How much time and how much energy would I save? And instead of tolerating these problems and even turning blind to the ones which are gonna come tomorrow, how much are we losing? So what should we change in our culture? The work habits, the organizational structure, and even the leadership style so that we could enable our enterprise where we fix problems before they happen. Let’s dig in. We have Nuno Miller, who’s the chief information officer with Sonae Fashion. Hey, Nuno. How are you?

Nuno Miller [00:01:34]:

Hi, Sanjog Aul. I’m fine. Thank you.

Sanjog Aul [00:01:37]:

Great. Great to have you. So now you see this topic, of course, we all live with these issues. Right? We are spent by the end of the day, and we fight fires. So let’s talk about agility to set the context. We want to go for agility. You want to get things done yesterday or be very nimble, but then we always have some chronic issues which undermine our, this intent to achieve agility. Are we allowing these issues related to these chronic issues to persist because we just have inertia? We do not want to change things for good, or is it our inability which is holding us back? Because what’s at stake is huge, but we keep tolerating the issues that we face.

Nuno Miller [00:02:32]:

Yeah. So I think that you are right. So there are multiple reasons for this to happen right now. I’d say that depending on the cases, we have both cases where we have inability to solve them, some cases where inertia happens, but also, this is quite connected to things I would say as pressure to delivery and complexity behind our architectures, and I think that from my experience, this is common to most of the companies. It does not really relate if it is a small or a large company, if it is a new, a startup, or a node company, I think that globally, as a matter of fact, is one of the biggest challenges that we all face as IT leads and the responsible of IT department. I remember cases, some years ago where the CFO of a large, fast-moving consumer goods company, was telling me that we need to make sure that we move IT from the front page of our internal newspaper regarding all the problems that we face and the inability to support the business in a quick and agile way, and we need really to make sure that the IT function is supporting as on these movements to be faster, to be robust, to do the things the right way, and this was a large company. I also remember smaller companies, startups, in several cases that were telling us that it’s really difficult to mix to have the right balance between developments and projects and new stuff and while keeping the car moving and making sure that we are able to support all the stuff that happens all the day. So on first, I’d say that and you are speaking about agility. I think that there is sometimes a confusion between agility and anarchy. Agility is not anarchy, so we need to be agile. We need to have methods, processes, a proper mindset, everything set in place so that we are able to be faster and to respond to the request that we receive from multiple areas on the business, and I do think that as we are speaking of, there are some cases where we have inability to solve. This means that most of the times, people who identify the issues or people that are notified of issues that are happening depend on other people, depend on other skill sets, depend on other teams to be able to resolve them. Most of the times, they receive the issues. They receive the ticket, but they are not able to close the ticket by themselves. So they escalate the ticket to some other person. So one of the issues that probably we have is how to make sure that we organize teams properly so that the teams themselves have the right set of skills, not on a personal level, but on a team level to handle all these issues, all these tickets, some that are, you know, some quick fixes that must be put in place and some that requires more analysis, more teamwork, more efforts to be handled. So I think that one of thing is really the inability to solve, and then we need to have the proper organization. On the other hand, the second one might be inertia. So in some cases, people just look at their own work, and they say, okay. If I’m able to close the ticket and say that this is not my concern, then I’m not responsible for it any longer. So I look at my own table, my own set of tickets, of requests, of work, and I don’t really care a lot about what’s happening to my neighbor on the next desk or with other teams, and this is something that, obviously, we need to fight and to be very hard on this because inertia of all of the reasons why we have tickets is the one that we should tolerate the least. Then there are pressure to deliver because, as you were saying, agility and speed of delivery is always putting a lot of pressure on the IT teams, and most of the pressure is to offer new stuff, to deliver new projects, to offer new products, to be able to offer new things to our customers, new products, new processes, new suppliers, new methods, and there is usually not a lot of effort on the global terms in the company to address these small issues that no one sees. Well, they feel it because it’s still coming to the table a lot of time, but it’s kind of undercover on the technical tasks and kind of undercover on the technical efficiency or lack of efficiency that some of our teams have, and on top of that, I’d say that complexity is also one of the main reasons. Complexity, I mean, we have complex architectures. So sometimes it’s not easy at all to resolve the core problem and not really just fix the ticket that’s open and do a quick fix and that’s it. I think that we have complex architectures. I think that we have core architectures that were built over years. Some of the architectures are 10, 20, or over 20 years old, or some of the parts on the architecture have multiple years, and sometimes those are the ones that are really hard to fix and complex to put the right way. So I think that we have complexity on the architecture on some of the solutions that are built on older technologies that we are not really comfortable with changing, fixing. We don’t have the proper skill set sometimes in the company to make sure that it works, and sometimes we don’t have the proper mindset to make sure that we should fix the problems in an organized way in order not to have them coming back to the table and have to back to table again, and obviously, complexity on the organizational structure that sometimes also avoids us from having the different skill sets that we need to make sure that something happens. So I think that this is a complex issue that probably requires multiple actions both on the architecture, both on the team organization, on the mindset of the different people, and also on the communication behind the way that the IT team is facing the rest of the teams and facing the rest of the business.

Sanjog Aul [00:10:43]:

So, in pretty thorough response that you gave, and you kept agility as the focus in how we can get over this and what are the things people face. So now connecting it back to not agility, but connecting back to the fixing problems before they happen, which is, you know, when we try to build any systems, most people in technology, they would look at what they’re dealing with today, and in many cases, they would even try to extrapolate or anticipate potential scenarios they will deal with in future, and try to make it as front-end design-heavy exercise, so that system will be relevant for times to come. We, of course, try to do that, but then as we go on, once the system is built, some issues come up, and we sometimes live with them to say, okay. We have too much to do, coming back that agility and the speed of business and delivering everything yesterday. We start living with those issues, and we call them minor, but then that same very issues as we keep building things on top of those issues with those foundations of what that system was, it starts building up, but the foundation had some flaws, and that’s what comes and haunts us. So where are we losing? Initially, you start with a lot of design and a lot of anticipation of what the future is going to hold, but once we have that in place, then we don’t pause, take a step back, and go and fix the very issue that could have been created because you identified it later. Why don’t we do that? And what’s preventing us? And what are we missing here?

Nuno Miller [00:12:37]:

One of the things that I think that’s happening is that usually we have very goodwill, but not all the time the ability to deliver the right way. So a lot of time, the issue starts exactly on the project because you design it in a proper way. You receive the right requirements from all the parties that are involved. We try to work internally or with the different integrators or developers to try to deliver this, but I’d say that most of the times, what you are able to deliver is not exactly what you wanted to deliver when you did the design. So we must make sure that we can live with this and that we deal with this every day and that our digital architectures are able to help us out on doing this the proper way. So I do think that we still have, in most of the cases, some very rigid architectures that also avoid us from dealing with these the right way, and also silos within the organizations regarding the program and project manager and then the support and operations team and the 1st level of support and the 2nd tier of support and the 3rd tier of support that sometimes creates some issues on fixing the real stuff. So I was saying that, when we look at the projects, we try to have a rigid scope in most of the waterfall projects, and we try then to deliver the scope, but we also are facing a moving target. We face delays on the delivery and the project, and then when we really want to go live and start using it, we face a gap between what’s the real need at that time and what has been delayed, and this is on the feature side, on the features that you are offering as part of the application, as part of solution, but also on the technical side. Sometimes, you think of doing things one way, and you deliver things working on the different way, and also, sometimes, you rely on a substantial set of activities that are meant to be done by the support team in order to support the system when it goes live, and then you say, we will fix this. We will be able to handle this in the future, but then the pipeline of projects keeps on pressing you, and you really need to make sure that you have the right skills and the right effort allocation to be able to handle this. I can say that, for instance, in one of the cases, on one of my past experiences, the major issue was the effort doing integration when putting any of the new projects in place. We might be implementing an ERP or a warehouse management system or a website, ecommerce site, or so on, and we always had problems integrating the different parts because they were all speaking on different languages, on different organizations in terms of integration layers, programming languages, and so on. So that was probably the main problem when putting something in place. Right now at Sonae Fashion, we have the option to start defining what we call our digital architecture, and by doing so, we’re starting defining what we call the main technical principles that we want to put in place and that we want all the different parties inside the technical team to follow when they are implementing any solution, and some of them are things as empower the user. So we have, as a designer principle, that we should focus on solutions that improve user autonomy, user control, user ownership of its own data, user ownership to access to its data, so to allow users to work by themselves instead of being depending always on third parties or the IT team. A second principle is be agile, and the be agile is really how to design and adopt solutions that are open to change in the future. How are we able to speed up to have a fast time to market for business changes? Because that’s sure that what we designed to know today will be different from the need that we’ll be having tomorrow. Another principle is run in real time. So capture, integrate the data in real time, and act on knowledge in real time. So moving from batch processings to real time. One other is serve the business, reach customers and clients through partners, integrate with partners, with suppliers, with customers, and so on. So to be able to make sure that our architecture in the future will be able to be accessible and access others. One other is enforce single source of truth. By doing that, we want to master each data in one single place, control data quality and integrity, collect data at source or at owner of the data. One other is zero redundancy solutions, and one other is enable 24/7 business. So this is a set of principles, of guidelines that I make sure that all the different people inside my team know by heart so that when they are developing or designing a solution, they need to have this as a checklist. So are we able to make sure that this solution that we are designing will be agile, will run on real time, and so on. So we were able to design these principles and then to set in place a new organization for the digital architecture that has different systems, systems of engagement, of enablement, of orchestration, of insights, of record so that when we put this in place, we make sure that all the different parts communicate the right way. So this is kind of the easy part because it’s based on putting together a new architecture and then designing how are we going to move from the different solutions that we have, and we have kind of a complex architecture because, due to merges and acquisitions over time, we right now have 3 different architectures for different brands, and we are trying to move them all into a single instance, multi-company architecture so that we are able to follow these principles. So we really want to have kind of a glue that puts all together as the same principles, as the same shared vision so that the different teams and different systems will make sure that they are able to put this in place. Another option when we are now able to fully design the architecture from scratch and then put this in place is to have kind of a transitional model. I think that in terms of architecture, if you are able, for instance, to put in place and some large consultancy companies are promoting this kind of a data layer between different parties, we’ll be able to speed up the way of moving faster depending on the current architecture. So I think that the architecture and the design from scratch plays a major part on this, and then, obviously, we need to have the organizational structure, the performance to set in place, and so on, but I think that the architecture plays a major part on the ability to handle this.

Sanjog Aul [00:21:46]:

Now we have also seen that while, you know, all the things that you’re recommending, people can put one put them in place, but many times when it comes on the ground that you’re working on something and a flaw comes up, but you’re in the heat of things, you’re delivering. Or a lot of people say, you know what? There is a flaw. Let’s live with it, but if we could create or or maybe there’s a flaw we should, you know, bring that issue up, but who’s gonna listen? Or will I be seen as someone who’s trying to unnecessarily stall the process? And that’s why people don’t bring up the issue in the first place. So can we create some role independence, some immunity, some empowerment where people, when they see the flaw, they literally go and almost like ring a bell and say, guys, pause. This is something we will have to deal with now, otherwise it’s gonna get worse and we will keep tolerating something which is gonna have a huge cost. Typically, the person at the top has to be convinced, and that person has to further convince an executive management to say, we have to solve this issue, and otherwise, we will have a lot of problem, but because of dependence and because of hierarchy, because of the fear, people don’t even talk about those flaws when they discover because it seems either no one will listen or they will be seen as people who are trying to stop things. So what would you do at the org structure level so that people are enabled and empowered and fearless in bringing up the flaws the moment they discover? The more delay we create after we discover a flaw in fixing it, the worse it gets for all parties.

Nuno Miller [00:23:36]:

As you are saying, this is a completely new mindset. This requires us to completely shift from the siloed based mindset into a global cross-functional teams mindset, and this is so important. This is so difficult, on the other hand, to accomplish. So I think that you are completely right. I think that sometimes no one wants to raise their hand and say, we have a problem. We need to stop everything, and we need to put this in place, and this is not easy because the company usually asks the IT teams to deliver, asks the IT team to create new projects because the pressure is always there. So one of the things that I have been looking at over time on this kind of changing our culture and changing our mindsets so that people are not afraid of coming up to this is to make sure that we have the organizational structure able to handle multiple speeds at the same time. I mean, on the company level, you always have large programs, multi-year large programs. So when you are replacing the ERP, putting in place the warehouse management system, setting up the new ecommerce platform, creating a large, loyalty, management platform, and so on. So moving to the cloud. So we always have programs that are very complex to handle, and on those programs, people that are doing that, they need really to organize themselves and to focus themselves to deliver on a multi-year. They might be doing smaller releases every month or every 6 months, but their mindset, their organization, the processes, the tools, the systems that they are embracing are meant for long term purposes. At the 2nd level, you have projects, and projects are smaller than programs. They are not so complex in the organizational level, in the company wide level, but they are also very important because they usually depend on multiple areas, and they take several months to accomplish, and those teams also need to be able to set their own pace and resolve their own demands and their own expectations. The 3rd speed level that we have is what I will call usually the sprint level. You know, 2 weeks, 3 weeks delivery models where you are able on this part to define priorities and to respond to the business needs in a much quicker, faster, and agile way. So, I mean, if I’m able to deliver every 2 or every 3 weeks, I can define the priorities just a couple of weeks before and making sure that we have the proper user stories or requirements in place because we are going to deliver these on a fixed time frame. The scope might vary, but the time frame will be fixed. The advantage of this is that sometimes, if you want to handle some of these problems, you are able to have a proper team with multiple skill set, skill set not only able to look at the problem or answer the ticket, but also to look at the code, look at the database, look at the infrastructure, and be able to fix it in a different way, and then you have the 4th speed, which is what I call the fast track speed, and this fast track speed is the one that is able almost to deliver hot fixes at a daily basis or multiple times per day. So I think that on an organizational level, we should set different paces and live with multiple paces even for the same architecture or the same part of the architecture. I mean, if I’m putting in place a new ecommerce site, I might have one team handling a project as international. I might have a team handle a technical project as moving to microservices, but I might have another team just handling issues that happen on the checkout or on the catalog page or on the payment gateway. So this allows us to be much, much faster on the ability to answer because I’m able to have resources, teams focused on short terms while I have teams focused on long term. So I think this is really important. Each one of these teams, to be able to deliver something, must depend on cross-functional capabilities. So if I have, for instance, a bespoke platform for my ecommerce site, for instance, I should make sure that the team that’s working on the sprint level, for instance, has proper UX capabilities, UI capabilities, machine learning or artificial intelligence capabilities, front end development, back end development, quality assurance, product management, agile management, project management. So this must be kind of a living cell, and the concept behind the cell, I think that’s very important to be able to handle these kind of needs that come to the table and try not to impact our projects and our longer term commitment. So this way, I’m able to keep the road map, keep the projects going, but still fixing issues. Because the goal of this team is delivering smaller things but also reducing my technical debt inside the company. By doing this, usually, I say to my teams that we have kind of the, as an army, I have the infantry, and I have the cavalry, and if I don’t protect the infantry, they will come dead quite easily and quickly. So I must make sure that I have a back end army, the cavalry that is going to protect them from all the bullets that they are able to face. So what I say usually is that the support teams are the infantry guys, and that’s the back end teams, the sprint teams, the fast track teams, are protecting them. So if they don’t work as a whole, it won’t work at all. So we won’t be able to handle these issues. If they work as a living object, a living part, they will be able to handle and support this level. So, obviously, we have independence rules as I mean, quality assurance should be independent. Compliance should be independent. Security management should be independent, but I see most of these skills reporting to head of the different area. I mean, all the QA guys report to the QA management. All the AI guys report to the AI manager. All the UX guys report to the UX manager in kind of a hierarchical way, but on a daily basis, I have a functional team as a living cell that is composed by people coming from different skill sets, from different hierarchical organizations, but that team has a goal, and its own goal must be aligned to what we ask the team to deliver. So if I want to have the team to reduce my technical debt, I should define a KPI and the goal for that team regarding the technical debt. I mean, usually, there are things as sprint execution, as the number of bugs in production, not on QA, but in production in order to reduce the number of bugs that go live, and stuff like this. So the performance, the KPIs are also very important to make sure that these cross-functional teams work as a whole and are not as different parts that do not work together, and I think that this also relates obviously to the way that you organize your team. So I I’ve been cases where the IT team is organized into different service levels. So if I look at the project management, I have a team looking at design, a team looking at build, and a team looking at operations, and I do think that this is a model that has some issues working on the daily basis because if you don’t make sure that the teams have the different skill set across the different areas from design to development or build and to DevOps and operations, then we won’t be able to handle these requests and this challenge that we have from the different teams. So I’d say having the organization with hierarchical structures, but making sure that the functional teams work as a team, as a cell, as a living object.

Sanjog Aul [00:33:41]:

So, you know, organizational structure is okay, and you gave a good approach to how to handle something like this. Now we have issues with us putting the right structure in place, but then we have different expectations from the people. So people don’t do typically what you expect. They do what you inspect, which means if you have performance management in place, and you did talk a little bit about performance, but something that you’re gonna look at them quarterly or every year about how did they do something, we only look at what they delivered. They don’t get brownie points for bringing up issues because we also tell people, hey. You bring the issues, but also bring suggested solutions, and frankly, not every time those individuals who are bringing up issues would have solutions. So they’re gonna hold back on even telling issues because you’re telling, bring the solutions along with it, but that hurts all of us. So if you had to fundamentally go to HR or look at your company or your department and say, let me set different expectations that what I’m gonna measure you on John Smith, who is working your department or anyone else working in their own department, how should we change that whole performance management so that people start reporting issues right away?

Nuno Miller [00:35:12]:

Well, I think that’s the first thing, again, is changing the mindset. So I think that one of the things that we should not look only at the goals achievement once or twice per year. I think that we should make sure that all these indicators are very visible to us all because this brings a good pressure on us all working on the team because it allows you, as the head of an area, to highlight what’s happening in front of everyone on the team or a large part of the people in the team. So I do think that to make sure that this works, we need to change the mindset, and we need to make sure that we make this quite visible to us all, and, I mean, on the performance management level, we have different ways of doing that. First of all, is defining the KPIs that we should look at, and you are right because sometimes no one looks at problem fixing or at the number of bugs. You just look at the projects that you’re delivering, if you deliver them on time and pretty much on time and on budget, and everything else gets a little bit behind this. So I think that we need to make sure that all these pending subjects coming from the operations and support line to the 2nd level of support to the 3rd level of support and to the different teams that we just spoke about needs to be highlighted, and highlighted, I mean, put on the wall, on the TV screens, on the data shows that you have, everywhere on the team that we bring the subjects to our management meetings where different people from the different areas speak together so that we make sure that they know that you highlight that. So if they think that you are not looking at it, they won’t be doing anything on that space. So we should make sure that we highlight this, and it’s not really a case of having a complex system or a complex tool to support us all. I work on many different cases where just having kind of Excel and dashboards to monitor this issue is quite enough. You don’t need a complex system to evaluate the performance and so on because those are usually the ones that you only look once or twice per year. So you must be able to show this on a daily basis, make sure that you have all the different teams knowing that this is important for you so that they really look at it, and then the kind of KPIs that you should be evaluating should be, I’d say, on one level, a lot of them looking at the customer level. So, I mean, the customer feedback, the number of answers to the tickets that you are closing, because sometimes you see just tickets getting closed because someone is reporting it, but I just fix it with a workaround and that’s done. So you need really to make sure that you have the analysis behind the magic. So you need to know what is the feedback from the customers, from the users. You need to make sure that you have some analysis on the root causes of the tickets that you have been facing, and for those root causes for those tickets, you make sure that you have a proper problem opened or that you escalate it and you pass it to a different team so that you make sure that the guys don’t just close the ticket and that’s it. So you need to make sure that when you analyze the KPIs, the SLA for closing tickets, you look not only on the 1st level of support, and I just closed the ticket because I opened a different ticket for a different team. Instead of this, I need to look at end to end resolution for my ticket so that I make sure that the problem is fixed, and so you need to look at customer feedback and customer indicators and, obviously, also to process indicators as the issues, the problems, the SLA, the technical debt if possible, and then you need to make sure that you have the teams with their reserved capacity to fix problems. So a lot of times, you just receive requests from the business, mostly on functional stuff, and you just try to handle those requests and deliver value to business. So in order to make sure that this works, you also need to make sure that the business, different teams, operations, sales, marketing, and so on, they are quite aligned to the importance behind making sure that you have the proper solution in place. So you need to show them that sometimes the system is working but is slow. You have downtimes on it. It takes too long to resolve an issue or to develop a new feature on it, and he wants to make sure that they are part of the solution together with you and that they are not kind of the part of the problem, and you are the problem yourself because you just have the issues and you don’t know how to fix them in a proper and fast way. So I think that making sure that you have the different internal users and stakeholders on your side is very important to make sure that you are able to go to your teams and say, guys, 20% of our capacity will be based on fixing issues that you have, and this is defense. This is it. So, whenever I’m trying to add efforts to a team, to a project, to my backlog, I know that 20% of that effort will be spent on fixing issues and on delivering things that users are able to feel. Sometimes it’s also important to define KPIs, for instance, as system performance, and I don’t mean the processor percentage of usage or the memory usage or the disk usage. I mean, what is the speed of the system when I look at the consumer or user standpoint? Is it fast? How long does it take to produce a report, to load a form, to perform an algorithm or an operation? So if I’m able to have these kinds of KPIs or drivers that I’m monitoring, then I’ll be able to go back to the guys, to the business, say, you didn’t notice, but we were able to improve the speed by 20% or 30% because we were fixing technical debt, technical issues that most of the times we are not able to do. So this is very important, making sure that the business is on your side, making sure that you have the proper KPIs in place, and making sure that you communicate these with your teams in a very, very impressive way so that they know what you want and what you mean by it.

Sanjog Aul [00:43:38]:

Last question for you. Leadership. So a lot of things that you mentioned that we ought to do this or some specific ideas that you gave, which could very well fall flat on their face if we don’t demonstrate the right type of leadership style. So if you want to enable that environment where we identify and then fix issues before they happen, what type of leadership style and approach would you recommend people use?

Nuno Miller [00:44:10]:

I think that you need to make sure that you communicate, that you delegate. So instead of command and control, you need to move into a delegate and monitor as we were speaking. So, I think that this is important because if you try to command and control it at this level, you’ll never be able to handle all the issues because they are spread amongst the different teams and the different areas. So we really need to make sure that the teams themselves are empowered to come back to you and say, we have an issue here, and we must fix it because we want to make sure that our customers are happy with this and that we have a better quality of life whenever we do a new project or in the future, and this is something that obviously makes sense in the usual and friendly term, but most of the times in the company itself, it’s very, very difficult. So one of the things that I did last year, for instance, and it is a little bit out of the box, is trying to make sure that different parties in the company know a little bit more about what we are speaking about, and that specific level was we put together 150 managers and directors across the different companies coming from the different areas from design, sales, operations, logistics, and so on, and we spent a couple of days with them doing a full project, well, a quite small project. It was a mobile app, as a matter of fact, on different areas, and we made them do the requirements, focusing on the requirements, and making sure that they were working on an MVP, and they were coding the application themselves and getting out of the session 1 day later with a solution made by them on their mobile phone. So that allows them to be much more aligned to what are the information and the requirements and the way that the IT teams work. So by doing this, you create empathy with the different peers in the company. So they feel a little bit more about your concerns and about what you really want to do. Then we need to make sure that we place the customer or the user in the center. So we must make sure that everything that we do is focused on the consumer, on the user, and if we think this way, I mean, that we are able to empower our teams to take decisions because the question will be, okay. Just put yourself on the customer’s shoes and think what he would be thinking and say what he would be saying and act accordingly to that. So if we are able to have all our teams focusing on this, on making sure that we have a better and we offer a better user and customer experience, this will be great, and this is not only on the consumer, not only on the customer, but for all the users that use our solutions, that use our infrastructure, our computers, our systems, and so on. So, if we think this way, we’ll be able to offer a better experience to our consumers, and it might be a supplier. It might be an operator on the store. It might be an operator on the warehouse. It might be a buyer. It might be any function on the team. So on top of that, you need to make sure that you celebrate improvements. So if you delegate these, you must be able to say, you accomplished these. So you as a team, as a cross-functional team, were able to deliver this, and when they are able to deliver the projects, the result, the fixes, they will be improving their recognition with the company because they feel much more aligned to the company than before. So I think that working together with the company, with your team so that they focus on the company, they think of multifunctional teams in order to deliver. They are transparent with others. So the accomplishments are celebrated. The failures are analyzed, are shared so that, you know, we are human. No one is perfect. Our company is not perfect. Our team is not perfect. Other teams are not perfect either. So we are all humans, and we must be able to live as humans and to recognize failure, but also to celebrate success and to make sure that each and every one of us plays an important role to the company. Despite being a help desk operator or being a developer or being an architect or being a DBA, we all play a major role, and we all must be working as a team to be able to deliver. So I think that, globally, we need to improve our performance as leaders, not as task assigners and controllers, but move inside both business teams and make sure that they could recognize us, IT teams, as allies to solve problems, improve, and innovate.

Sanjog Aul [00:50:19]:

Once again, thank you so much, Nuno, for sharing insights about how to solve problems before they happen.

Nuno Miller [00:50:27]:

Thank you, Sanjog Aul.

Sanjog Aul [00:50:29]:

Once again, thank you so much, Nuno, for sharing your thoughts and insights about how organizations can build the right structure, the culture, and leaders can adopt the right style so that they can solve problems before they happen. Thank you so much again.