 All right, so we all heard just today, right? I think in his keynote he was clear about Continuous delivery is possible, right? It is It is hard work. It is struggle. It's a struggle, but it is possible and a key part of continuous delivery, you know is Infrastructure and infrasubes agility, right? Software doesn't make sense until it gets deployed into production and customers use it, right? and it when it's in production it needs to run well, it needs to be responsive, it needs to be available and And when something wrong happens you should be able to troubleshoot it faster, fix it faster, right? Without that ability, you know, no matter what quality practices you put into software and doesn't, you know, serve any purpose, right? So I'm gonna talk about infrasubes agility, right? So software is getting built assuming that quality practices are being followed, then how does it How can it be put into production and run well, right? And how can you, if something goes wrong, how can you troubleshoot faster and fix faster, learn from it, learn from production infrastructure using the right metrics and keep on improving your services. So So and I'm gonna probably end the talk with three key ingredients that which enables that, right? Which enables teams to continuously learn and adapt from running things in production, right? So let's get started. A quick show of hands. How many of you are business leaders, you know, our technology leaders, product management, okay, how many of you are operations engineers, all right. Cool. Any tech leadership, operations or developers, engineering? Great. Cool. So I hope you all connect with some of the things that I speak about today. This is my journey. I started as a sassad man late in 1999, 2000s, I, you know, grew, I learned a lot from my peers and the internet, whatever happened in various timelines and things like that. And then from there, I was able to manage teams both in terms of operations and engineering and things like that. So I'll come to that a little bit later. But first I wanted to show you guys this, right? This is a timeline of various events that happened in the last 20 years, right? So it's grouped into five years, like, you know, 2000s, 2005, 2010 and 2000 till now, 2015 and till 2018. What do you guys infer from this? Any takers? Sorry. Okay. Any other perspectives? Cool. So, I mean, if you look at this, right, the change is fast, right, specifically in the last 10 years. In the last, say, 2008 onwards, you know, ever since DevOps as a philosophy and movement came along, then if you see the explosion of technology, both in terms of your infrastructure, which is virtualization and containers and things like that, and then the tooling around it to manage that infrastructure, plus, you know, tooling around observability, like monitoring metrics and things like that. And cultural aspects in, like, you know, a lot of these companies opened up their culture, like how Netflix operates, how it see operates, how Valve operates, things like that, right? So there's a lot to learn, right? So a lot has happened in the last 10 years, but have we adapted ourselves to that quickly, right? So this is just the technology piece, the same timeline, but only the technology aspects. As you're saying, you know, in the early 2000s, we had VMware was the only virtualization technology that was available, mostly everybody was running bare metals, mostly all of them were handcrafted, you know, servers used to get deployed using CDs and then racked into data centers and then somebody would log in and change configuration files and things like that, right? And then, you know, things evolved a little bit, came along around 2004, which helped us automate some of that work. There were other technologies available at that point in time, like automatic voice deployments where DHCP would be and things like that, but and then, you know, Zen and virtualization came along, people started adopting it to use better capacity, use the capacity of the hardware fully. And then 2008 onwards again, you know, you see process virtualization kicking off, AWS, you know, coming up with cloud and other toolings around those things started evolving, right? And lately, in the last, say, 10 years, you see so much of services that have come and tools that have come that makes our job very, very easy, right? And it's just that, you know, have we evolved with it? Have we, you know, have we implemented that in our work? Have we, as organizations, helped evolve? The teams evolved, right? Our priorities, right? Our structures, right? We have the right leadership, things like that, right? So, and when we say people, we are moving to cloud, we're doing that, we're doing this, are we really doing cloud, right? One of the things that Jess was also talking about today was if you just take bare metals and then, you know, you start moving applications into VMs on the cloud, doesn't really mean cloud, no? Doesn't, right? So touching on the culture a little bit, so, you know, we had this waterfall method, right? Everything was, you know, you have project, product managers, business leaders come up with an idea, product managers, things about how it should look and then developers will do the functional requirements, test it and then they give it to operation teams to, you know, deploy it and manage it, right? And that cycle broke with Agile coming and then, you know, and it took a while for everybody to adopt it and then other things like, so exactly what Agile came up with was increased complexity on the operation side because in waterfall it was step by step by step, so operations had enough time to probably prepare, but in Agile world things started happening much more rapidly and operations kept up because things kept thrown at them, right? So with the advance of DevOps philosophy and, you know, all the other, you know, learning opportunities that we had, the books that come along, came along and the culture of various other large organizations which have done this very successfully. Again, you know, we had the profession has evolved, right? So since admin now they are called DevOps and whatever not, right? But these key skills required for people, engineers, operations engineers at that time and even now are the same, you know, the requirement is still to, you know, manage infrastructure well, automate your work and, you know, use your, the time that you save to do, you know, better value added activities, right? So, but still organizations achieve, struggle to achieve this velocity and agility, right? Particularly when it comes to operations because most often the focus is on functional delivery of software, right? There is a customer requirement, somebody writes a spec, the engineer writes the code, tests it, a QA or somebody might test it, it goes into production in whatever way it goes and then, you know, people forget about it, right? And when they scale, when they, you know, when the engineering team scale when a lot of customers start using that services, you run into a problem where operations are not able to keep up with it, you have infrastructure failing, there is a lot of manual work, you know, you cannot do things quickly and, you know, troubleshooting becomes hard and things like that. There are multiple reasons for it. One is that there is, from an engineering standpoint, there is, the focus is too much on the, just the functional delivery of the code and not on how it is being done and how it is being run in production and things like that, right? So, about me, as I said, you know, I started as a sysadmin, I still prefer being called as a sysadmin even though I moved on to a lot of other things like leading teams and, you know, engineering teams and things like that and I've worked with, you know, companies with the startup culture, like DirectI, I was there for about 12 years and then I, you know, as part of an acquisition, I started working in a public company so I've, you know, been with them for five years and, you know, understand how these enterprises work and now I concerned, I partnered with XNCO earlier called Agile FQs and I work with Nareesh too on helping companies on the infrastructure side of things, right? My wife still calls me a mechanic, you know, because I keep fixing broken things around everything that I see because, you know, that's just my nature of things, right? So, I try to also keep this as buzzword-free as possible so that these are practical things that you can probably go back and apply in your workplace in whatever role you are in. So, defining infrastructure agility, right? So, you know, what does it mean when we say that we need agility on the infrastructure side, right? It requires these four things. One is infrastructure as code, which means that, you know, you can, instead of going and clicking some button to deploy, you know, or create a virtual instance, you can actually write code to do that and spawn it, right? So, there are a lot of tools available these days which lets you do that and what it gives you is you get, you know, speed, you know, because you don't have to go and manually do it. It becomes repeatable and it's reliable. It will not fail. Once you write the code and test it, it will not fail unless, you know, the infrastructure itself, like if you're using AWS, unless AWS has some problems, you know, it won't fail, right? And it provides you the right abstractions. You can, if you write code, if you use the right tool and use code to create your resources, infrastructure resources, it can be, you know, used to create the same resources in any other core infrastructure, right? You could probably do it in the same thing in Azure or your own open stack environments, hybrid environments and things like that. And it forces you to adopt best practices, right? And resilient architectures. The next one is like, you know, have we thought about, you know, high availability, load balancing, how will it scale up? How will it scale down, you know? Have you thought about disaster recovery, you know, BCPs? Do we test our backups? Backups are useless until you, you know, test it and it can be used in production, right? And then when things do go wrong, you know, production operations, how do we, when things go wrong, the observability, right? How do we troubleshoot? What, you know, logs we have? What metrics do we have? What monitoring do we have, right? To go and quickly see what is failing and, you know, and the ability to fix it faster and learn from it, right? And production operations is basically, you know, it consists of how is software being pushed into, you know, infrastructure? How are they rolled out? How do you manage change? And how do you manage incidents when something fails, right? I mean, is it usually it's a chaotic thing, right? If something fails in production and like everybody's on call, you don't know who to call sometimes and, you know, it's getting right people together itself will take over 15 to 30 minutes. And once they come on board, like how do they know what, where to see what, you know, what to see how to fix, right? And these are all things that can be pre-planned, right? These are all capabilities that needs to be built in the teams and in the organization over a period of time. And it takes effort. It takes learning, iteration, we make mistakes and then we, you know, we keep on improving that, right? It often takes, it's a multi-year journey, right? But you've got to get started somewhere, right? So we'll talk about how you can probably get started on some of these aspects. Another key thing, you know, is in, you know, microservices kind of an environment. If you have many microservices running on a cloud environment and if you have multiple teams who are owning those microservices, one team changing something and deploying it would have a cascading effect on everybody else, right? Because they are all interconnected, it's a mesh. So in that kind of a scenario, it's always, the software is always evolving. Each of these microservices are evolving. So how do you control? How do you know, you know, whether they will function well in production or not, right? So chaos engineering is a process, is a method where you can learn these things in production itself by inducing faults, right? So you have the services that are running. You will go and, you know, create, induce a fault, take down a service or kill a VM and things like that. And then you learn from it, right? And see the impact cascade. And it's a controlled test. And then you improve your monitoring, observability and all of that and your change practices or development practices, et cetera. So if this is what we have to achieve as an organization or a team or an engineering team, right? This is an engineering goal. This is an organization goal. I'm not saying that this is just an upstream goal. And if you just look at this as an operations team goal, it doesn't work that well, right? So what makes it harder, you know, why cannot we achieve this, right? Why do organizations struggle to achieve this? So that comes the now struggle. We are always stuck in the now, right? So if you look at a business, you know, there is a need, which is a customer's need, and then the business, which is complex, needs to deliver on outcomes, right? A simple solution for a customer. And for that to work, you have all these units in that business which need to work really well together, right? The reason why there are no arrows in that is that I'm assuming that, okay, for this slide, that they are supposed to be in ideal environment, they are supposed to work together really well to deliver on the right outcomes, right? But it often doesn't work like that. It's often a spaghetti of stuff, right? It's like people, you know, there's no collaboration. Everybody's a silo. Everybody's at the need. People, you know, things get thrown out of from one unit to another unit, and then it keeps going back and forth and things like that, right? So let's look at the, why does that happens, right? Again, if you look at the business as a whole, what does it mean? You know, what do we need to do to run the business? You have features, bugs, incidents, compliance activities, there are finance controls like cost governance and things like that. You have people leaving your team, attrition, and you have recruitment efforts ongoing on the side, and it all depends on engineers to be able to contribute to all these activities, right? And there are activities that I call building capability. So running the business, it works. It's imperfect. Things fail. We recover. We learn something from it, and there's a significant amount of waste because there are a lot of manual efforts, there's a lot of collaboration waste, and things like that, right? And, you know, often we don't focus on building capabilities at all. Organizations don't focus on building capabilities. But when I say capabilities, if you are in an internet company or deploying services that are being used by millions of users there, so you need to build those capabilities. You need to be able to manage that code that you're writing in production well. And that requires you to nurture your teams, you know, give them the right priorities, give them the right technology vision and, you know, and help them and achieve those things, right? And that's not often the focus. So the focus is always on the top bucket, running the business, functioning, essentially delivering whatever, you know, the customer seeks. And most often we, you know, organizations tend to create things that the customer doesn't even need. I mean, how often have we seen that we get, you know, things that, you know, buy this, buy that, you know, we don't need that, right? You know, organizations push us to do something that we don't even really need to do. So a lot of features that the customers might not even want. So we might be building a lot of waste as well, right? So the, when it comes to the operations team, we spoke about this as a organization as a whole. This is a, this is the list of activities that regularly happen to run the business and building capabilities never get focused on. And when it comes to operations team in particular, right? And if they are central in nature, if they are not structured, right? You know, you have all these conflicting priorities that are coming to you. So management comes and tells you, hey, I need this capability. I need this capability. While PM will be saying, okay, I need this feature, right? That needs to get rolled out. Support will come up with escalations that customers have. This is not working. That is slow, et cetera, et cetera, right? Their teams have their own requirements. Compliance teams comes with you with auditory requirements and all of that, right? And then there you have HR, talent acquisition and attrition and other activities as well and cost control, governance and things like that. So operations are always in a struggle, right? You know, it's, it's, we say that we have adopted agile methods. We do sprint and things like that. But whenever the work reaches the operations teams, it's always the last minute, right? It's always a surprise to them. And it, then operations engineers feels like, and feel like they end up being a support role. They feel like they are in a support role where they are constantly serving the needs of a developer or somebody else instead of adding value and creating more automation aspects. So the manual work, kiosk, all of that continues. And it's, you know, there's a lot of sense of helplessness and stress, right? And so again, the building capabilities turns out to be an implicit goal that nobody, you know, cares about. And, you know, you get stuck in, you know, doing the same thing every day, right? And so, and that's one of the key reasons is again, there is a, you know, lack of focus from an organization standpoint, you know, to change that and build that capability, right? So let's look at how we, you know, how we did this. And I mean, I was part of DirectEye, you know, we had thousands of servers spread out across many data centers, right? This is some years old, right? And we were in this situation, you know, we were a small team. We were constantly, you know, interrupted on all these activities. And we had to get out of it, right? It was, you know, the only way we could get out of it was by saying that, hey, you know, we took a pause and said, you know, we're not gonna handcraft, we're not gonna do anything manually anymore, right? So we introduced Puppet for configuration management. We just, you know, we got all the servers loaded up with that and then started with, you know, managing the basic operating system configuration files that way. And then we moved all the application configuration files to Puppet repositories. That way, at least, you know, you have all the configuration files version, so we could, you know, see the change. And then we could use the same code for other servers that go in, right, for that particular role. And then over a period of time, we improved it to use the right templates and, you know, and make the process faster, you know, configure our monitoring systems. Whenever we add a new server, it would automatically go into our monitoring systems, collect metrics and things like that. And a lot of our interruptions were also coming from changes, right? That go in without proper testing or without proper notifications to customers and, you know, things like that. So we had to say that for a change, we will have a very clearly defined process. It's not a bureaucratic process, but at least, you know, the engineer, the focus is on the engineer. You say, you clearly write down what the steps are, right? What are you going to do on the systems? What change are you pushing? What is your role back? You know, and what testing have you done? And that way, you know, we were able to control the, you know, the impact of changes. Customers were kept aware of whatever changes were happening. We didn't get too many support requests. So all of that, you know, reduced over a period of time. And our incident management was also bad, where, you know, people would be called at random times. There were no runbooks, you know, developers would, you know, push stuff. We don't know which developers to contact and things like that. So over a period of time, by improving these processes, we had, you know, a clear way of working together, right? With our development partners, engineers, PMs and things like that. So what happened is your, whenever things go fail in production, you have the right people at the right time. You fix the problem, learn from it. It feeds into your automation and then that's a cyclic process that keeps going on, right? So, and another thing was inventory. Nobody knew with how many servers we have, where we have, you know, how are they connected? Which rack are they on, you know, and which cables are connected to what and things like that. So in a data center environment, when something fails, you don't know where the server is. You cannot look at the server. You cannot keep going and searching, right? So we then, you know, we had to work on fixing that and then, you know, automate the operating system deployment practices itself. So when we rack servers, we used to rack one rack at a time. Bar code everything, including the cables, where the ports are connected to and that will go into our inventory system and then the inventory system will, somebody will assign a role to each of the hardware and then when they put it on the private network and boot it up, you know, it will get whatever it had to, applications it had to be installed, right? And then, you know, so once that was done, you know, it's a multi-year journey. I'm simplifying it, but it was at least, you know, six months to do the first thing, three to six months to do the first thing. And then we constantly improved using the same practices, the SLAs and, you know, then we got in things like orchestration where we could do things across the fleet of servers if we wanted to do something quickly. And we moved from a central silo team to product-focused teams to work closely with our development partners and product managers and things like that to be more, you know, outcome-driven, right? And we did a lot of automation and things like that to push responsibility to the edges. So every request that would come into us would, you know, get translated into some kind of an automated tool that the support teams can use themselves or engineers can use themselves and things like that. So over a period of time, we became much more operable. We became resilient in terms of having processes for HA, you know, failover, failback processes. We had disaster recovery for some of our critical applications on the cloud, you know, and backups, restores, all of that were tested and implemented and things like that. And so the entire goal was to, you know, improve predictability of operations, right? I mean, you need to change every incident, everything, you know, you just need to know who the right people are. You might not know the cause, but you can at least figure out, you know, process if I or, you know, make every other action of yours much more predictable. And then once the teams were set up this way, they had the autonomy, they had the outcome, you know, the goal of improving the product and had their only job was to work with the development teams and product management teams to continue to improve the services that we are offering to our customer. They started adopting new technologies wherever required, right? They never, they never, we never had to tell them, right? Okay, implement this, implement that, right? So things started moving into containers, you know, we started using the cloud infrastructure better and the security as a practice doing our compliance effects, compliance efforts went into, became part of the integrated development process, right? Integrated into the development process instead of it being an add-on activity and things like that. And so the lessons that we learned from this was, you know, continuous learning and improvement mentality is a prerequisite, right? And it needs to be there and everybody in the team including the leaders, management, everybody, right? And infrastructure as what is the software projects? What happened once we got configuration management in and started doing a lot of things, you know, puppet, everything was automated using our configuration management tool over a period of time, you know, it became so huge that people would fear touching something in it because if any change would cause issues across entire fleet and things like that, right? So it needs to be executed as a software project with the right set of practices and people will not reuse code. There might be a class to install and configure Apache, but they may not use that because it's already being used at multiple different projects and they fear that changing that would cause impact on every other project. So they will build their own class and use that, right? And that way it became a little unwieldy and over a period of time we had to again bring back best practices into it and clean it up and things like that. And people need autonomy and consistent autonomy and consistent feedback and encouragement to pursue their ideas, right? You know, you don't need to do a lot more, you know? If you give teams enough time and opportunity and guidance they can implement whatever is the right thing for the software project, for the projects. And you need to have implicit trust, right? You know, if there is no trust and if there is access versus them and developers don't trust ops and ops don't trust devs and PMs and leaders, it's very difficult to achieve anything, right? So you need to build an environment where there is implicit trust between each other and we all are aligned on the shared priorities, right? On the shared outcomes. So I wanted to share a simple message to, you know, leaders and, you know, operations leaders generally struggle, like, you know, when I work with, you know, various leaders in organizations, they say, you know, they don't listen to us, you know, our voice doesn't get heard, you know, we don't, our priorities are not very important and things like that, right? But, you know, building alignment with stakeholders or management, it's a skill in itself, right? It's a, you need to understand the business side of it, yeah. We'll come to that. I think, you know, so it's an organizational journey, right? This is not just a, you know, so I think, but you can make an impact if you are in a leadership role, if you are leading a team or if you are a change agent in your organization, right? You know, understand the business nuances, like, what is the business outcome? So if you don't have information, you have to seek information. I hope the organization allows you to do that and you need to invest time and you need to back up with facts. You need to, you know, go back to your stakeholders and say, okay, these are the problems that we see and this is what we can do to solve it and this is the time that we need and this is the resources we need, right? Unless you are able to push, unless you are able to show that, nobody knows about it, right? We as people, product managers don't know about what it takes, you know, on the infrastructure to run the product well. Even management sometimes, if they're not technically inclined, they don't know about it, unless somebody tells them and shows them very clearly from a business standpoint what is lacking and why and how it is affecting us, right? And building that alignment is a key skill that people need to build, right? And, you know, when you do that, you will get up, most of 95, 90, 100% of the time, you will get support, right? They might take, they might ask you certain questions which will improve your plan, but you will get support because you are thinking about the organization in the end, right? It's not for your own benefit. And when you get that approvals and things like that, when somebody says, okay, why don't you go and do it, you know, you have to be able to execute fast and that builds trust, right? Once you have a successful outcome, once you solve a major problem and say, you know, improved efficiency or whatever it might be and that builds trust and when you keep repeating that, you, over a period of time, your entire, you know, this thing, your operations improves and the leaders trust you more with your decisions and things like that, right? Similarly, you know, how you would do that on, say, if you have, you know, a lot of these microservices on the cloud, right? And the most of the practices are, you know, similar, right? You have to start with first, if you are, this is say, if you have already, you know, hundreds of microservices running on the cloud, right? In various fashions, whether VMs or containers and things like that. And if you are in a situation where it is stressful and things are failing every day and you are, you know, managing incidents, you also have to improve infrastructure, there's a lot of manual work, work is piling up, people are not happy, they're saying ops are not delivering what they want and things like that. If you are in that kind of a situation, right, then some things are wrong, right? The way it's been, as an organization, as an engineering team, the way it got built and put into production and how it runs today, there is something wrong. And it's often the cause, the cause is often, I mean, there are multiple causes and it all can be boiled down to not focusing enough on building that capability, right, as I was saying before. So you have to stop somewhere, review all the production operations practices that you have, you see what all manual work you have, what resiliency do you have, where are the bottlenecks, what are the single point of failures and what are the manual work, right, that your team currently does, where are we wasting time, right? And then slowly start, you know, prioritizing those. I would prioritize by first, you know, stabilizing the production operations, right? You know, that means that knowing what applications are running in production, having the right monitoring in place, you know, and having the right change management, incident management practices in place, which, you know, lets you deal with those interruptions and incidents in a much more structural and defined way, right? Instead of running around in a chaotic fashion trying to find out the right people, if you have all those identified and documented and, you know, you can, there are a lot of tools available today which can translate from alerts into escalations to relevant people and everybody can come together and solve the problem together, right? And that becomes a learning process and that will, these things will feed into your automation, right? And if you have people focused on automating the work using, again, you know, all the tools that we have available today like Ansible, Salt, Terraform and things like that, things become easier and easier to do. Your workload reduces and you can focus more on seeing all these metrics of infrastructure, seeing how they are investing time and finding better ways to do it following our peers in the industry, learning from them and, you know, continuing to iterate and improve, right? And that's being, you know, not ahead of the curve but at least following the curve, right? We often are lagging the curve but, you know, we should be at least somewhere where we are, you know, always following the curve, right? So, the thing about this, again, in this kind of environment is like the context is key and there are so many people, so many siloed teams who are, as I was saying, you know, engineering and deploying these micro-services in production, often nobody has full visibility of what's happening, right? And every team has its own siloed information and when things fail it all caskets down to everybody, right? And that's where I was saying Kiosk Engineering helps where you can induce faults and as a group you can learn how that can be, say, bring down a service and then see how it fails in production what all the impact it has and then learn from it and improve your monitoring and things like that, right? And, you know, and also what the leaders need to do is, at least with the operations leaders side, they need to seek information, they need to understand the business development and the operations side of problems, right? If you see the problems on each of these, business cares about delivering features to the customers, right? But that's what makes money. So feature velocity is important. Development teams care about bringing their changes to the code faster into production, right? And we look at the operations teams, they care about avoiding risks, they care about safety, they care about how it runs in production, availability and all of those things. So how do you take all of these things and then still make progress, right? So that requires that requires a lot of, you know, collaboration. You need to be talking to your other NPRs and managers and then ensuring that the priorities are aligned, right? So the message, again, I want to leave here is with the infrastructure agility in a microservices world is a must-required skill capability that the organization needs to build, right? It cannot be an afterthought, right? Okay, we built this software, we built this microservices, let's put it into production and run it. It cannot be like that, right? And it needs the right skills, it needs the right, you know, structures and organizations and leaders should not just optimize for feature velocity but also ability to manage that evolving complexity because every change, every new microservices that goes into that kind of environment increases the complexity, right? And you need to be able to manage that complexity well. You cannot say that I don't want complexity because it's complex in nature, right? So what are the three key ingredients, right, to get there? I would say the first one, the most important one according to me is culture, right? And these are the ones that I've come to value the most in all my, you know, years of experience is, one, you need to have a very implicit trust with everybody, you know, not just within your teams but with your peers and business managers and everybody. You need to understand them well, you need to understand what they need and how you can support them, right? And you need to be transparent, you need to have I mean, you know, this is an organization culture, right? It needs to be, you know, practiced by everybody in the organization. It cannot be just done by one person, right? So it needs to have zero politics. It needs to embrace vulnerability, right? We all have our fears, right? And we often don't speak about that very openly, right? We fear about failing, we fear about making a mistake, we fear about, you know, so many things, right? And if the organization doesn't make it easy or doesn't embrace that vulnerability that each one of us have, it just becomes tougher for people. They worry about too many things instead of doing, you know, what they think is the best and learning from failure, right? And you cannot learn from failure unless an organization embraces that, you know, concept and embraces that vulnerability that we have. And, you know, emotional safety, right? And one which notures people, right? You know, it needs to have how often do you all get feedback from your managers? Once in three months? Sorry? Very good. How many get once in a year during appraisals? Okay. All right, so that's, you know, once in a year, that's bad, right? You're in the dark for an year and then, you know, suddenly somebody during appraisal times, they say, you know, you didn't do this well, you didn't do that well. So you didn't have enough chance to do anything about it, right? So it needs to happen as frequently as possible and then it needs to be, you know, you don't want to hear bullshit, right? You want to hear the right things. What are you doing well? What are you not doing well? And what support do you need? Those are the questions that you would want, you know, your manager to ask. And, you know, coaching in terms of, you know, how to do better in whatever you are doing and, you know, one which promotes learning and, you know, improve the work that you are doing and, you know, gives the right ownership and outcomes. And I think that this builds lifelong friendships, right? And, you know, and that, you know, a lot of my, the people that I work with, a lot of the friends that I have, you know, I have, you know, I'm from work, right? You know, it is because of all the multiple years that we have worked together doing various different challenges and things like that. Next is structures, right? You know, what structures help in an engineering team to achieve the right outcomes? So, if you look at what is engineering leadership, you have two sides of it. One is the technology aspect of it and one is the product aspect of it, right? And and then you have these second in line managers, you have development operations and again product, right? There might be product leads in each of these things. So the reason why they are co-joined in all of this is that they really need to be aligned. Well, it could be just one person if they have the right skills, right? If they don't have one person, if it is three different person, they need to be really sharing their priorities. They need to come up with shared goals, shared priorities and things like that, even if they are three different people with independent outcomes or independent work streams, they need to, you know, at least agree on what needs to be done, right? If they have conflicting priorities work will not get them, right? Everybody needs to be going in different directions. And then you have these outcome-driven teams which are driven teams which have your developers, operations, UX and whatever other skills that you might need in as one team, right? They call it squads, you can call it anything, right? I mean, but you know, it needs to be a self-sufficient team which knows the outcomes. The outcomes might be like example would be you know, your shopping cart, right? Giving a great shopping cart experience for our service. If that is the outcome of that team, they will continue to iterate, learn and manage that shopping cart service that everybody else consumes, right? And they need to have that shared goal. So your development, operations and product managers need to really have that shared goal. If they don't have it then each of these people will work in very different ways and you don't meet the right outcomes. And what skills do you need, right? Sorry, priorities. Sorry, skills was an extra. How do you manage priorities? As I was saying, if these guys, just one person, it makes it easy because you would have one goal and you can direct the teams towards those goals. If it is three different people, they need to align on those shared priorities. What do you want to do? And then you need to manage all this work, right? You have ad hoc and incidents. You have feature bugs. You have other manual work that is there. You need to do one-on-ones. You need to focus on recruitment, you know, and you also have compliance and financial activities. So all these things need to get factored in, you know. If these don't get factored in, then these won't get done. If you don't do one-on-ones, you're going to lose people, right? People are not going to build the capabilities. If you don't do recruitment, you're not going to scale. If you don't do one-on-ones, you're going to lose people. Similarly, you know, any of this cannot be compromised on it all. It's all important work for a team, right? And only way to do that is to come up with, you know, shared goals and, you know, making all these activities inclusive in your work. And whatever ad hoc and incidents and that, whatever operations and, you know, manual work that it generates can feed back into your automation, right? These managers and the outcome-oriented teams need to be able to self-prioritize, right? This is causing us, you know, a lot of headache. This is causing us stress. This is causing us frustration. Let's fix that. Then, you know, then you are in a much better mode to do better value work, right? If you are constantly under the stress, if you don't have time for your families, if you are constantly working for 12 hours every day, you get burnt out, right? How long will you do that? So, and things should move from more than ad hoc manual type of work and stressful to more planned with clear focus on what is the outcome and the long-term vision, right? For each of the things that we have. What skills helps, right? And what skills are required at this level? We often don't focus on the this, right? In terms of, if you say engineering leadership, right? For the technology side of the leader, they, I would say that, you know, it doesn't matter that much if it is just a software engineering expert, right? He needs to have the operational skills as well, right? He needs to know how it is deployed in production. How is it operated in production? What makes it work well in production and what doesn't, right? And a technology leader needs to be aware of those things, right? He might not be an expert at it, but, you know, he needs to know, right? And how tough it is. It's not easy, right? It's not magic. Just because you're using cloud doesn't mean that, you know, you will get all of that automatically. You have to plumb a lot of things need to be done by operations engineers to achieve that level of agility, right? And he needs to have a product-thinking trade. He needs to understand what product it is, why we are building what features so that, you know, we can direct the teams appropriately. He or she, they need to be good and emergent technologies. They need to understand what is emerging, how they can adopt it, how they can, how it will simplify our stack. The great people and leadership skills, right? They need to be able to set a vision. They need to be able to guide their teams, to coach, provide feedback and never compromise on the people management aspects of things, right? And also the quality delivery, right? How do you maintain quality with whatever velocity you want and create the right engineering culture, you know, iterative learning, all of those aspects. On the product side, similarly, you would need good product thinking, UI, UX, they need to also understand software development aspects. If a product team doesn't understand what it takes to build software in, you know, then they're losing something, right? They need to really know what it takes to build a software and how they can, you know, make an impact. Similarly, great, you know, all of this requires great people in leadership skills, right? And then these, similarly in operations manager, they need to be experts in their relevant areas. Development manager would need to be a good software developer. Similarly, other people and they need to focus more on people, priority and outcomes. And they will have all these teams will have, you know, inputs into the vision, the technology vision or the product vision and things like that, but they, and you know, at the engineers level, they all need to be specialists in each areas. And they need to be effective engineers. So the effective engineers are what do you want from an engineer, right? You need to be able, the engineer should be able to tell, you know, his stakeholders, what it takes to build it, what the requirements are. You should be able to communicate things very clearly. He needs to be able to work with his peers and get that outcome delivered, right? Instead of waiting for instructions and things like that. So an effective engineer would do that without being told and, you know, with coaching, he could do that, right? He would not worry about just his piece of work. He will worry about the entire process that it takes to get work done, right? By building the right relationships and things like that. And he will highlight it and he will tell you to a phase if something is wrong or it's not the way that it should be done, right? So overall, as I said in summary, you need culture, you need, you know skills and you need the right priorities to be able to change all of this in any of the organization that you are in. And it is not just a one-man or one ops leaders or a development leaders or, you know, an operation engineers goal. It is, it should be an organization goal. And, you know, building that infrastructure operations agility and this is a must-required capability in this world and it cannot be done by, you know, focusing too much on the just on the functional delivery of things. But, you know, it also requires how it's runs into production and things like that. You have to care about all of that as well. That's it. Thanks. Questions? Yeah, we can hang out. I mean, I'm here already. So, you know thank you.