 Good morning everyone, my name is Denise Shannon and the Senior Director of Engineering at Rancher by SUSE. I lead the teams that work on Rancher, a multi-cluster management platform, as well as our Kubernetes distributions RKE, RK2, and CNCS K3S. Today I want to get started off and just review a little bit of how far along Kubernetes and Rancher has come. Kubernetes recently released its 27th minor version. Over the last nine years, as learned how to introduce and graduate APIs, deprecate and do the dreaded removal of them as well. Alongside it, Rancher has also evolved, where originally it started off as a platform dedicated to supporting multiple container orchestrations before about five years ago, pivoting and doubling down on Kubernetes where it became dedicated to managing only Kubernetes clusters as well as being built on the Kubernetes API itself. Now over time, both Kubernetes and Rancher have had to adapt to the ever-changing ecosystem. So in Kubernetes, the example I have is around cloud providers, where originally it was embedded in the Kubernetes code base, and then as more and more cloud vendors wanted to contribute to Kubernetes, they realized they needed to refactor in order to be able to support this dependency that they were providing. And so what they did is they created external cloud providers, which now allows any cloud vendor to be able to create and manage their cloud provider without being reliant on a Kubernetes release. Similarly, in Rancher, we wanted to adapt to the ever-growing ecosystem. So we have a Apps and Marketplace feature, which allows not only Rancher to package and manage helm charts from the community, but also allows any user to be able to take their helm chart, put it into any Rancher installation, and manage it without relying anything on Rancher. In our latest release, we added in a feature called UI extensions, which now allows you to take not only that home chart and deploy it through Rancher, but to be able to embed your UI directly into it so it's a seamless interface. Now, as software grows, your teams tend to grow alongside with it. So in Rancher, we started off like everyone else does as a small development team. And as it continues to grow, you're going to get to the point where as the software grows, the community grows, your customer base grows, and then your team sizes grow, so then you have to figure out what are you going to do? And so we realized that we were struggling between the balance of how do we figure out how much time to spend on community found defects, community issues, customer found defects, and what we actually wanted to do for the product ourselves. So what we ended up doing is we decided to split our teams up and we dedicated one team to customer found defects. And then we had several teams doing community issues and enhancements. And then we tried this out for about a year, and then we realized that we got to another tipping point where the software was actually wider and the breadth of it was harder for one single team to actually support. And so we did the next iteration, which was to divide our teams into product area teams. We had teams that were built focused and dedicated to one product area, and this helps now support the career development of our individual engineers. They can now become subject matter experts in that one area and not have to struggle to figure out how to support the whole product. And so this has been our most successful iteration because now it not only empowers our engineers to feel confident in what they're doing, but it also allows them or allows us to be able to onboard and scale out new teams easily by carving out product areas and building new teams around that. Now, while we've been scaling and growing our teams, our processes are constantly reviewed and scrutinized by the new teams. One of the founding principles that I've always felt at Rancher that we had was that efficiency and execution were our main two focus points. And so we never adopted a full agile process. And so instead, we've always had a Kanban style because that allows us to remain flexible with our ever-changing priorities. And as of today, we haven't changed that process even though we've scaled significantly over time. The engineering team hasn't changed, but instead we focus on what is the process that we want to figure out? What are the priorities that we're doing in bringing over to the engineering team? And making sure we document all of that. Now, in summary, everyone should constantly be reviewing what you're working on, who's working on it, and how these teams are working. No one should be afraid of change. Instead, I think you all should expect and embrace it. And in fact, if you can be the one to propose it even better, and never be afraid to iterate and iterate again. Thank you.