Die Neuerfindung des Entwicklerteams im Zeitalter von AI Agents

[00:00] Hello. Hello, people are still coming in, but [00:06] As as towards the end of the day, [00:11] want to make sure that we're thanking a couple of the other people who are in here as well. So, can we get a big cheer for Assan on the sound? [00:16] [Cheering] [00:22] And Dan behind the camera. [00:23] [Cheering] [00:27] And we've got our lovely volunteer in the room. I I didn't catch your name, you have to shout it to me. [00:32] [Name] [00:34] [Cheering] [00:37] All of the tech and volunteers here today have been absolutely fantastic. So, yeah, big cheers for all of them. Right. [00:44] One more big cheer for Hannah, who is going to come onto the stage now. Hannah Foxwell, would you like to join us on the lecture? [00:51] [Applause] [00:53] Am I on? [00:54] Hannah Foxwell is an independent advisor, writer, and creator of founder of creator, founder of AI for the rest of us. [1:01] Creating accessible AI learning experiences for everyone, regardless of their role or background. [1:08] That's right. And And, you're going to be talking about the reinvention [1:13] of AI for the dev team. No, no AI. No AI in this one, sorry. Yes. It's the end of the day, I'm stopping reading now. [1:18] It's It's all good. Hi everyone. Um, thank you [1:24] uh, for coming uh towards the end of the day. Um, I'm going to be talking about [1:30] agentic software development. But I'm not going to be talking [1:33] about the tools or technology. I'm going to be talking about what it means for our teams [1:37] and how we organize ourselves with these new capabilities. [1:42] So, ever since I started working in tech, [1:45] this has been the fixation of every manager [1:49] or engineering leader I have ever worked with. How do we get more velocity [1:55] from the developers in our organization? Uh, we even, we even call it velocity. [2:00] We even track it in story points and [2:04] I feel like right now, today, [2:07] the velocity that we've been yearning for is here. Like, and it changes everything. And for a lot of teams, we don't quite know what to do with it yet. We don't know, um [2:17] we don't know. Like, and I've been through these transformations that have impacted our velocity. Um, I've been through cloud transformation, which meant we didn't have to wait weeks for a server to run our software. [2:29] I've been through DevOps transformation, which means that we automated the path to production, we didn't go through week-long test cycles. Um, [2:38] and like, every one of them brought with it new organizational challenges, new patterns for success. And so what I'm very, very interested in right now is what agentic software development does [2:49] now that we've unlocked that massive next step of velocity. [2:55] We've even, like, we've we've even created words around it. Like, um, [2:59] like, just a couple of years ago, you would have been on a stage and you would have been talking about developer experience, developer productivity. There were whole conferences organized around it. I think that [3:09] that dialogue has kind of, it's it's kind of quietened [3:13] now. It's like, we've got the velocity that we've all been wanting. And now we have to figure out what to do with it. [3:19] Uh, you may have already seen this slide, because Luke Marsden had it in his deck and I stole it from him. Um, [3:26] But this is um this is Steve Yegge's sort of um [3:32] like levels of agentic coding maturity. And we, like, we start at the bottom with like a narrow IDE agent, and we get all the way down to level 8, which is like an agent orchestrator, something like a GasTown, something where, like, it's pure agentic development. And we're all on a journey. And I want to just reassure everyone that if you're still over here [3:53] at like level 2 or 3, [3:55] that's absolutely fine and normal. Like, I don't know many people who are operating at level 8, and I certainly don't know anybody who could say credibly that they're doing it safely. So, um we are all on a journey. But I do think that it is worth keeping an eye on these things because this is what the future could look like for all of us. [4:14] Earlier this year, Cursor, um published their blog post talking about the third era [4:21] of software development. And this is when the uh on their platform, on their coding platform, agentic tasks started to supersede [4:30] um the tab completes and accepts. And so, whether whether your team is doing it or not, this is a clear signal that this is the way that software is being written now. Um, these are these are the metrics that show us that on that platform, um agentic software development is superseding [4:47] um tab completes and other other forms. And so, let's talk about what it means for our teams. And so, when I start to do thought experiments about how and how to reason about this, I try to go back to basics. I try to think about like, what things do I believe will be true [5:02] no matter how good the coding agents get. And so these are my three anchors that I use to navigate this change. [5:11] The first one, we need to build something worth building. [5:16] The second, I believe speed requires safety. [5:21] And the third one, and I hope there's no disagreement on this one, people matter. [5:26] So I'm going to start, I'm going to get straight into it because um like, [5:31] I believe that we always, always must pursue the outcome [5:37] and not the and not the tasks. We always must build something worth building. We must be solving a problem. We must be clear on the problem that we're solving. The code [5:43] is how we solve that problem. It's not the what. And so when you think about organizations [5:50] and the typical organization today, what you have is you have a load of users, and they have a problem. [5:57] And then there's usually a person whose job it is to understand that problem and translate that into requirements, which are then delivered by developers using code. [6:06] The solution to that problem is shipped as a product and the users will benefit from that. Um and if you do a good job, you can turn this into a business. And the way that teams structure themselves is that there are far, far, far too many user problems that any one team can solve. And so you filter them. You filter the noise. And the product manager filters that noise [6:26] um and tries to get the maximum value out of the product that they can. They make decisions about what to build and what not to build, and that doesn't change. But what has changed is the pace at which we can solve problems. And so what I'm seeing is I'm seeing um actually, like, the pace that we can address these problems in the development team creating what I call backpressure [6:52] in product. The speed of decision-making, the speed of analysis is actually not able to keep up with the pace of software development in a typical team. [7:02] And the right answer is not to just build more faster. Like, enshitification is a thing. Um if you say yes to every idea and to every user request, your product will become bloated, you'll impact user experience, and it eventually your product will actually suffer. And so, like, saying yes and building everything isn't the right answer either. [7:28] But one thing is true today and is new [7:34] for us as an industry, is that it is becoming increasingly cheap to test our ideas [7:40] with real prototypes. And previously, because I've sat on both sides of the fence, I've been in product and I've been in engineering. Um and so I've been on both sides of the negotiation of like what do we build next. And as a product person, it was really difficult to justify the investment in building a prototype when you had like a three-year backlog. Like, are we going to test this idea with real code, or am I going to try and figure out how to test my ideas in other ways? But that is no longer true. We can prototype, and we can do it quickly and cheaply. [8:12] So, what does this new world look like? We have to make sure that we make good, informed decisions about how to deliver the maximum value through the software that we're creating. And so what I've seen, um is a few different manifestations of this. [8:27] Um the vibe coding product manager is for sure here. That product manager is building prototypes themselves and they're testing the ideas to make sure that the work that's funneling through to the dev team, am I getting a wave from a vibe coding product manager in the bag? Yes. Yes. [8:46] So yeah, so the work that flows through to the dev team is validated by a real working prototype. And that's a very powerful pattern um that I'm seeing. [8:55] If your product manager isn't comfortable prototyping, then what you can do is you can you can move developers to be more front-facing, to be more explore explorative, um and to partner with your product team on validating that you're building the right thing before it goes to the rest of the dev team that will work on productionizing that feature once it's proven to deliver value. [9:17] Another pattern, um that is becoming very, very widespread is the forward deployed engineer. Now, a forward deployed engineer isn't a sales engineer, they're not a solution architect, they're an empowered engineer that sits side-by-side with the users. [9:33] And if they see a gap in the product, they are empowered to fix the product and deliver that value to that user. So you're actually really, really, really reducing that feedback loop from user to product [9:45] by embedding an engineer side-by-side with your users. Um and it was only just a couple of weeks ago that there was an announcement from Google that they're now they're building a capability of forward-deployed engineers um to go and do this with their AI products. [10:02] Another thing that works particularly well for reducing that feedback loop between users and engineers is the idea of a product engineer. And there's some fantastic writing by incident.io on the role of product engineer. But these are engineers that don't need to ask permission of a product manager to go and improve the product. And this pattern works incredibly well if you're building products for software developers, [10:24] because you have that user empathy already. You're building for yourself, you are the user persona. And so, um teams like incident, they're building products for software engineers, and so they have that empathy, and so they are empowered to go and improve the product. [10:41] So when we talk about team design, like, um, I work with I work with a number of startups, and [10:48] uh one of the startups I work with, they hired your typical engineering team. So they got some pre-seed funding and they hired like six six engineers and what became apparent very, very quickly is that they just ran out of well-qualified work to deliver. And I think we really need to challenge like what we consider a normal um development team, because at the moment, this normal development team of sort of 6 to 8 engineers and a single PM, it feels imbalanced. You end up with bottlenecks, especially around decision-making. [11:21] And so, um what I've seen some folks do is experiment with different ratios. Two developers to every product manager. [11:30] Um and one of the companies that I've seen experimenting with this is called NBIM. So, they're running this experiment at the moment of that different ratio, the one that we're not used to, to see whether or not that can unlock more value, putting more product people per developer on the team. [11:47] Earlier this year, Andrew Ng, um was speaking at Davos Summit, um and proposed that actually the typical dev team might even look something like this. Two product people to a single developer. Because the speed of decision-making is such that a single developer can keep on top of a backlog driven by two product managers. Um who knows? Like, I don't know. I'm not up here advocating for any of these. I'm talking to you about what I'm seeing people experiment with um to unlock the velocity that agentic development gives them. [12:19] I also sat down with the CTO of a consultancy, because I thought that would be, um really interesting, um across a broad spectrum and lots of different um development teams about how AI-driven software development is impacting them. And what was really interesting is actually, they're not reducing team size, but they are expecting far more output. Um [12:45] Only two or three have actually, um intentionally reduced team size because they feel like they had too many people. And you know, this is this is one sample, and we can look at the news and we can see in the news all of these various rounds of layoffs that companies are doing. And everyone is sort of challenging themselves. And I don't think it's necessarily about reducing head count, it's just making sure you have people in the right places doing the right work. And I think the dynamics of our teams have absolutely changed. [13:16] I spent last year working with startups, um and uh this year I was like, I've spent too much time helping other people be successful. I want to have a go at it myself. And so I started to build a product. Um it's called BIMP. It is a base image management platform. Um so it's a platform that manages your container base images. And the hypothesis of this product is that, um zero CVE base images are becoming the new normal and that most organizations at some point in the near future will transition from the container base images they're using today to a zero CVE version. So, while you do that, why not have a platform to automate it for you? So, we are a two-person team. [14:00] A ratio of one developer to one product person. I am wearing the product hat. Um [14:07] and I felt the new pain of this extra velocity in a very, very real way. So we gave ourselves two weeks um to build, uh to build these sort of MVP, the first iteration of this product and on day one, [14:24] we decided what we were going to build that week and on day one, we had finished by lunchtime. [14:31] And so it was like, oh, brilliant. Uh on day two, um I was catching, I was catching a train to London, so I I was I was chatting to Stew and we were like deciding what we should, what we what what what we should build and, um I was on the train platform and I got a text saying, done, 11:00 a.m. 11:00 a.m. And I love to think about that, and I'm like, gosh, what could life look like if work just existed between 9:00 a.m. and 11:00 a.m. and then I got the rest of my day free. Wouldn't that be fantastic? But I think it's a common theme that I've heard, um across a few of the talks here is that actually, um this, this unlocking of this velocity makes us more ambitious and we have to be more ambitious. And so, we had to relearn like I had to completely throw out a lot of my product toolkit about ruthless prioritization, about slicing up features. I, I had to think way, way, way ahead about what the, what the end goal of this product was and how I wanted it all to work. Like, instead of focusing on one thing, I had to think bigger. Um so, so that's what we did. We gave ourselves two weeks to test an idea. [15:40] We tested our idea at KubeCon. The idea seemed to be very well received and so we were able then to make an informed decision about actually, we're going to in we're going to invest more time in this product idea. And so, like, from my own like kind of real lived experience, um I feel so excited about this new era of software development because you can test every idea, and you can you can make more informed decisions. Like, I haven't had to go and knock on the door of a VC and say, please give me money because I've got a good idea. I've actually been able to build a thing and test that it's a good idea. Um and so when I think about team design, and I think about how we make sure that no matter how fast we get we always build something worth building. We always build something that has an impact. Um here are the things that I'm keeping, here are the things that I'm trashing, and here are the things that I'm trying. So I'm keeping empowered product teams. Um no one should have to ask permission to to help their users. [16:32] Um absolutely fast feedback with real users is your superpower. Um you have to really understand the problem that you're solving. [16:45] And I think when everybody is empowered to build and everyone is empowered to build quickly, user experience and usability are going to be your differentiator, so don't, um don't forget about those. I'm absolutely trashing the two pizza team and my six-month roadmap. [17:03] I was at a conference earlier this year and someone suggested that we start calling it a tapas team. Which I really liked. Like, the teedy-tiny tapas team, the small plates, um I I like that a lot. Uh and I'm trying the forward deployed engineer model, the empowered engineer that sits side-by-side with the customer. Love that. Um product engineers, and I think that's a very powerful one if you're building dev tools. Um prototyping and testing your ideas quickly. Fail fast if it's a bad idea. Um and smaller teams for sure. Really thinking about the right ratio, developers to product people to keep that flow of ideas and value moving smoothly through your organization. [17:42] My next anchor [17:46] is that speed requires safety. So we can go very, very quickly and we can break things, [17:53] but your users aren't going to thank you for that. Um and so, I think the second pillar, I is about how we move quickly and do it safely. [18:00] The path to production is so, so important, and I think, um the evolution of how we engineer our pipelines and our paths to production, and the platforms that support them are going to be differentiating, and if you have these capabilities already, you're going to be able to unlock a lot of value from agentic software development. But what I've seen happen in a few places is that actually, what was a kind of smooth process from idea into production becomes a little bit of a car crash somewhere after the code is written, and before that code delivers value to users. And so, if there's any manual steps on that path to production for your software, you're going to end up with a pileup, whether that be code reviews, whether that be your testing suite, you're going to end up with a bottleneck somewhere else. And so, investing in your path to production, your pipelines, your automation is so important to actually, um leveraging AI for software development. [19:07] Um it's a forever truth that like high confidence requires testing, and if you want high confidence quickly, you absolutely have to automate that. [19:20] One of the blog posts that I particularly like and this was actually from last year, so things may have changed, was from AWS about how they had to completely rethink their path to production to be able to get the extra velocity and to get the volume of code that the software developers were delivering safely into production. And I think if your organization hasn't started to think about that, started to map that path to production, look for those bottlenecks, think about investing time in optimizing it, then this is my sort of vice-to-year that I think I that problem might not um might not might not be manifesting today, but I feel like it will eventually. Um and so getting your pipelines in order is super important. [20:02] There's really good news here, is and that is that AI is fantastic at writing tests. [20:10] Um so if you have manual testing, um or slow testing on your path to production, then this is a really fantastic use case for using AI to improve your software development capability. And there's a great case study for from J.P. Morgan that talks about how they are using AI to do continuous component testing. [20:31] Um making it safer to deliver a larger number of changes into production because you have that and enhanced test coverage. So again, when we talk about, we talk about your team of developers today, you might not need all of them working on features right now today. What you might want to do is split that team, and have some folks focused on pipeline, some folks focused on, um test coverage, something that makes it safe to move quickly using automation. And SRE teams that can act as internal consultants, um helping teams, um invest in reliability so that you can deliver with this velocity but you don't do it at the expense of your availability and your performance of the product. [21:24] I don't need to read out that quote, um [21:26] So yeah, like in my experience, uh the cost of day 2 is always greater than day 1, um to scale and maintain an application that has real users, um is going to cost you more in the long run than just getting version 1 of that application into the hands of users. We don't we don't talk about it enough really. [21:27] Uh users also care about this stuff. [21:30] Like, you're never going to get a you a feature request that comes in and says like, don't be shipping any vulnerabilities, but they expect it, like they expect it from you. And reliability issues will make the news, um especially if you're on a popular platform and so, investing in reliability, um is is super important. We must always, always balance velocity with reliability. Because our users may not care about us shipping 100 features every month. What they care about is you actually doing the thing that you said you were going to do, and doing it reliably and safely. [22:07] Again, like, [22:11] very few customers will come knocking on your door and say, make sure you're secure. They expect it of you. Um and so good security tends to be invisible. It's an absence of problems, um and what I have found is that like good security is invisible, bad security is an absolute, uh reputation killer. So, these are areas where we actually want to be investing time. And, like, in the past, having to negotiate the time on the backlog to do that important work, was always a trade-off. Do we build this feature the users are asking for? Do we do this important invisible work? Um now, we don't necessarily have to make those trade-offs. We can do it all or we should at least be trying to do it all. [23:01] Practices like progressive delivery, that make it safe [23:06] uh to deliver a larger number, a larger amount of change into the hands of your users are super important. So I'm talking about like feature flags, so that you decouple feature delivery from the actual deployment of the software. I'm talking about blue-green deployments where you can actually have a new release, um being used by a subset of your users. Progressive delivery will make it much much more safe for you to move quickly and deliver a lot more change to your users. So if you haven't got those capabilities in your platform at the moment, now might be the moment that now might be the time to try it out. [23:42] I said that we always need to balance velocity and stability, and luckily we already have a language to reason about this. So I will advocate for site reliability engineering, um forever, having SLIs, um service level indicators that tell you whether your product is doing the right thing for its users, objectives about how often it it has to work to meet your users' needs, and error budgets, the amount of kind of forgivable failure in in the system. By getting these things in place, by measuring them continuously, you can have a better dialogue, um about whether or not you need to intentionally slow down the amount of change that's getting shipped to your users, so that you can make sure that you're always meeting their expectations on reliability. [24:30] And so when I think about the future of organizational design, and the humans, like, I can see a world where actually, at the moment, I find platform teams, SRE teams, security teams, they are massively outnumbered by the number of developers who are focused on features. [24:50] I can see that balance, um shifting. I can see an increased, um an increased importance for the platform and the SRE capabilities because they are the people who unlock the velocity of the development teams who are serving users, the development teams who are building, uh building features. So platform teams who make it safe to move quickly using automation, and SRE teams that can act as internal consultants, um helping teams, um invest in reliability so that you can deliver with this velocity but you don't do it at the expense of your availability and your performance of the product. [25:10] So I'm going to talk another another little bit about about BIMP and and my experience of my my two-person team, um building our first product. So like I said, we had the first version of the product ready in two weeks. So what did we do after that? [25:25] I can honestly tell you it looked a hell of a lot like platform engineering, reliability engineering, like there was not a lot of feature development. It was about scalability, security, and doing and doing it right. So whilst it was cheap to actually build, like, um a functioning application, what then took the time was making sure that application was ready to scale and that it was safe to do so. So this is my kind of like my own experience of where the time went, um it wasn't in feature delivery at all. It was in making sure that that uh that platform was robust enough to be used by real enterprise customers. [26:05] And so when we talk about our organization design and the humans, like, I can see a world where, actually, at the moment, I find platform teams, SRE teams, security teams, they are massively outnumbered by the number of developers who are focused on features. [26:22] I can see that balance, um shifting. I can see an increased, um an increased importance for the platform and the SRE capabilities because they are the people who unlock the value of those feature-aligned teams. [26:37] So what am I keeping, what am I trashing, and what am I trying? I'm definitely keeping SRE practices, progressive delivery, and internal platforms. These are things that make it safe. [26:48] I am trashing anything manual on my path to production that doesn't mean we can't do manual testing, it just can't be on the critical path, and use things like feature flags to make sure that it is safe to ship something buggy and that your users won't notice. [27:06] Um and I'm absolutely going to be addressing tech debt using AI. I'm going to be trying to improve my test coverage, make it, um make it really easy to, to spot issues, um using AI to, um accelerate my migrations and my refactors. And I'm definitely, uh looking at bringing back the SRE team as internal consultants that can help teams invest in reliability so that you can deliver with this velocity but you don't do it at the expense of your availability and your performance of the product. [27:28] Now, as I wrap up, um my third anchor is is actually probably the most important. Um and it's that people matter. [27:42] And so, as we reinvent our teams, um for this new age of agentic software development, it has to be done with people in mind. We have to create jobs that are worth doing. Um and the first thing that I'm going to controversially say is that reviewing code that was written by AI, thousands of lines of it, it's not fun. It is not a very fun job. [28:02] Um and so I've got a very keen eye on the organizations that are trying new things. Like, instead of having a massive pileup, of of code reviews, what are they doing instead? [28:13] Um there's a couple, there's a couple of organizations that have publicly said that they're not doing mandatory code reviews, that doesn't mean that they don't do code reviews, it just means that they're not doing them, um in a mandatory way on every single, um every single change. [28:29] So, some of these organizations are actually shifting left on the peer review. So, previously, a code review would actually, you know, it would go to a senior engineer who would spot issues, um with it, when now shifting left to maybe at the point where you write the spec for the agent, you're shifting left that decision-making and that oversight and that peer review, to make sure that you're building the right thing. [28:52] I really like this quote, um by Joseph Ruscio, um the mistake would be to treat unread code as a failure of discipline rather than a signal that discipline itself must change. [29:03] And I don't again, I don't have answers here, I just know that asking engineers to review thousands and thousands of lines of AI-authored code is going to create a lot of very unhappy engineers. And so we have to figure out another way that we can build quality and assurance into our process without creating unsustainable work. [29:24] Another thing that I know for sure [29:28] people are not going to want to do is to support a fragile service. An agent cannot hold the pager. [29:35] And so this is one of like the infungible sort of things that, um I believe like engineering teams need to navigate, and it's who is owning the service in production. [29:47] On-call is still a thing and you have to have a sustainable on-call rota. Um you can't have a single engineer being on-call all of the time, that's not fair, that's not right, that's not sustainable. And so when I think about how small we might be able to make our teams, this is the thing that I keep coming back to. It's like, well, what, like, what is the most the smallest team that you can have a sustainable on-call rota? And I think it's four people. Four people capable of supporting that, um that product in production, because you always have a primary, and you always have a secondary, um and you can't be on-call more than 50% of the time. I know a lot of people who wouldn't even want to be on-call 50% of the time. So, like, the minimum viable human, like is going to be dictated by some of these roles. Um [30:34] I think I said at the beginning, like, um when we were building BIMP, we absolutely like we we ran out of work on day one. We ran out of work on day two. I think the thing that I would urge folks to challenge is a lot of the ceremony that we surround our development teams with. Might not be adding value or it might not be adding value anymore and in some cases, it might be slowing us down. Um the sprint planning that only happens every two weeks. Is that the right pace of decision-making that we need? [31:08] Do I have any en- do do I have any managers in the room? Yes, managers. Um, [31:15] It's a tough time to be a manager of software engineering teams, uh because we don't really know what the role of software engineering is evolving into. But one thing that I'm going to urge you all to do is to go and watch a talk by Sophie Weston, um from QCon last year where she talked about the broken comb. Instead of the T-shaped folks, develop people who have a broad understanding, um and a few various A areas of depth. And when you're doing career coaching with folks, think about the skills that they may need, that will that will help them. Think about what I've talked about, it's like, what do you have engineers who are going to lean to more towards product, um or are you going to have engineers who are going to lean more towards platform, and can you help people develop those skills that we really need right now? [32:06] I am almost out of time, but I think, um one of the things that I like to do, I like to I like to I like to imagine the team that I would build in the future, and the one thing that is absolutely critical for me right now is user empathy. Like, if you hire someone and they can't sit down with a user, understand their problem, and design a solution that solves that problem, then that person is going to become a bottleneck. They're going to be need to spoon-feed requirements and that has become normal in our industry, and I think that's a practice that needs to end. [32:40] And so, um you'll be very relieved to hear this is my final slide. I've been trying to be subtle. Oh no. That's right. People matter. Like, I want to make sure that every engineer has a sustainable on-call rota. I want to make sure that we have a language to discuss like, um our error budgets and our availability targets, and invest appropriately, and I want to do realistic career planning for the skills that we need today, not the skills that we needed yesterday. [33:10] I am trashing heavy planning processes, two-week sprints are absolutely too long right now, and mandatory code reviews feel like an unsustainable practice that's going to need to be replaced with some other ways of assuring quality. [33:25] I'm definitely shifting left on peer review, um uh using spec-driven development, and I'm going to encourage all of you in this room, and especially the managers to think about how we create people who are less T-shaped and more of a broken comb, people with a diverse diverse areas of depth, because those are the sort of people who are going to thrive, um in this new age. [33:49] We are all on a journey and we do not know where we're heading, and I find it exciting, but it can also be daunting. And so, as you leave here, hopefully I've given you some ideas, um to experiment with, or to help you address some of the new challenges. I would just urge all of you to experiment with empathy because it is not an easy thing to change like, to change your discipline so fundamentally and at such speed. So, yes, we do need to try new things, we need to share our learning, um but do it with people, don't do it to them. [34:27] And so, here are the things that I'm keeping, no matter what, no matter how good agents, um become. I'm always going to build an organization that focuses on the user. Build build something worth building, solve a real problem. I'm going to be investing in ways that, uh we can move safely with speed and I'm going to always, always focus on the people because people matter, and we need to create teams that are joyful, um to work in, and careers that are worth pursuing. [35:00] So that's me, I'm Hannah. Um come and find me for questions over a beer. I will release you now. Thank you, Hannah. Thank you so much. [35:12] [Music]