Okay. Hello everyone. My name is Khali Dewa. I am director of engineering at Proofpoint, and I'll be talking about developer productivity and the common pitfalls with this presentation. Now, developers, the most important asset for any company delivering software as product. Making sure that they're set up for success is the key to ensuring overall success. Now, we can't lean into this discussion without knowing that what is it that the developers really value? Studies after studies have revealed that developers crave meaningful impact. They like to understand big picture and how their contributions help drive long-term outcomes. Now with that context in mind, let's lean into the most common pitfalls of driving their productivity. Let's start with the ones we stumble on as managers on this front. Now, some of the managers like to dig deep and want to be involved in every detail. Various studies have proven that this is a massive anti-pattern for that productivity. In addition to that, obsessing our metrics has been the trend of our times, but like all trends, it has some pros and cons to it. Looking at the metrics such as prs, commits, deploys, lines of code velocity, all of these numbers without context can drive a lot of unintended behavior. Next, let's look at things from tooling point of view. Given how the role of developer has evolved over the years. With the DevOps DevSecOps observability movement, it has left a lot on an average developer's plate. Now, all of this means that devs have to do a lot of context switching throughout the day while dealing with a lot of tools. This can be the biggest drain. On an asset for dev productivity, depending on how the tooling is set up and if the culture and tooling is set up with empathy and respect for developer workflow. Next is prioritization related related pitfalls. Now setting a processes and automation to shift left security concerns is critical. Otherwise, developers are always playing catch up. Now, given the range of tooling, types of vulnerabilities, threats, surface area, if this is not set up correctly, this can significantly drag down dev productivity. In addition to that, this is well known that tech debt, if not addressed in time, can snowball and become a major roadblock, severely impacting the depth productivity. Huh. After all, we all know that it takes a lot longer to make any changes to those legacy apps. Okay, next one touches on things from arcs at a point of view. Now, with the kind of speed tech landscape evolves, it is very natural for learning gaps and organizational silos to show up now to deal with that. It is important to proactively set up processes and forums that can help drive collaboration and help devs keep up with evolving tooling. A more recent example on this front is AI based code gen tools. The tools in this space are evolving and getting better every day, leaving depths to play catch up almost all the time. Now, while we are busy breaking silos. In catching up, it is also critical to make sure that the teams and organizations are set up with the developer wellbeing in mind. All right, now that we have examined the pitfalls, let's discuss the four pillars of sustainable dev productivity activity. Now, metrics are still the key, but here we need to make sure that. We are tying up activity based metrics with the outcomes. In addition to that, developer is a creative endeavor. Autonomy and trust are at the heart of development. Now, none of that will work unless the goals and the respective business outcomes that the company is trying to chase are spelled out. Clarity. While we have clarity, trust, and context-based measures, we still need to keep up with the trends of the time with continuous learning. Okay? Easier said than done. What's needed to execute sustainable productivity? Now, for practical execution, we need to make sure that we have context based picture. Of the productivity metrics. Now we can ensure that by collecting qualitative metrics with quantitative metrics. In addition to that, we study the variety of reasons across organization that lead to context switching, and that rather trigger triggers, context switching and then take action or diagnose appropriately at the same time. We set a platform, tooling and automation in a way that it creates minimal cognitive load on the devs trying to deliver customer features. Now, to build a sustainable flow with the four pillars at the beginning, we need clarity of goals, then autonomy of execution, next, measurable outcomes to track the progress. And while all of that's going on, we need to continuously invest in the growth of our depths. All right, we are at the tail end of the presentation. So finally, I'd like to conclude by saying that for any engineering organization to be successful, empathy and respect for developers and developer workflow should be front and center of the culture or planning and customer value delivery. Thank you everyone.