 Now I'm going to hand over to Jeff Watts. Jeff is a Scrum and leadership coach and his talk is on why great teams are more important than ever. Jeff, over to you. Cool, thanks Alex. So let's share this one. Get that there, is that working okay? I think it thumbs up from someone. That's the kind of thing. Yeah, that's perfect. Great, thank you. So yes, why are great teams needed more than ever? So I've been doing a few talks recently because people have been asking me to talk about my new book which is great and first thing I say to everybody is I feel really guilty talking about a new book that's coming out with everything that's going on in the world. But there is, for me at least, there's this view that right now it's great teams that are going to help companies, first of all, survive in this period because a lot of companies may well not but also thrive and I think it's those great teams that are going to help make those organizations make the difference. Now I think we can probably all agree, although I don't really like it when people start by trying to guess what I'm thinking. But I think we can probably all agree that we're living in interesting times. I think we're very interesting. Something we can probably all agree on. For me, one of the things that I found particularly interesting having worked with organizations that have been toying with various degrees this idea of shall we become more of an agile organization, shall we not? Do we really mean it? Do we not? They've kind of been faced with a really stark choice over the last couple of months. And that choice has been about how much do they truly trust and enable their people? And seeing how different companies have reacted to that choice, they might not have realized it was a choice quite often it's subconscious. But seeing how organizations have reacted has been quite fascinating for me. I think on the whole, generally, most organizations and most national institutions by and large have acted pretty well in the early stages of the crisis. So when there is a crisis, not just talking about a pandemic but a business crisis, the first thing leaders really need to do is they need to make some quick decisions. Undemocratic decisions. And that's the right thing to do. We don't necessarily want a lot of conversation and a lot of people's inputs into something when a really quick decision is needed. And those quick decisions are there to try and stabilize, first of all, the business and the people but also then the immediate future. It's the right thing to do and it's also what people are looking for. And that's important as well because if leadership acts as the people they're leading expect them and want them to act, then that organization and their leadership will avoid what I tend to call motivational debt. If I'm acting as a leader in a very directive, decisive, undemocratic way that the people that I'm acting towards are expecting a democratic approach or autonomy, then they're gonna be incredibly frustrated and dissatisfied by that. But equally, if those people, that team, are expecting me to be decisive and not democratic, but I come in and ask them, yeah, well, what do you think we should do? Then that's gonna cause motivational debt as well, just a different kind of motivational debt. So that's a good thing, okay? So leaders on the whole have acted pretty well in the start of this. Get things safe, simple messages, clear messages, make some decisions. Unfortunately, for some people, the crisis has been an excuse. An excuse to indulge their somewhat controlling nature, shall we say, more than perhaps they should have done. And maybe like me, you've heard some of the stories of employers installed in tracking and monitoring software and policies on their people who've been forced to work from home. And it's very easy to stay in that mode of, okay, we need to make decisions, it's still a crisis, it's still a crisis. But actually, there's a lot of evidence around that would be been well for a long time, but actually, micro-managing past the point of crisis is going to be counterproductive. For other companies, the few that stand out, this has actually been a fantastic opportunity. Now that might sound very callous for me to say, I'm not trying to downplay the bad situation at all, but for some organizations, they've really thrived here. And I'm not talking about the obvious examples of people, Zoom who've had a massive growth in users and licenses and things like this. And as we were talking about beforehand, the companies that are selling all the home-working equipment like microphones and lights and cameras, I'm talking about those organizations whose leadership have for months and years invested in the development of the relationship between them and the people that they work with. They've built up trust, they've built up goodwill through, among other things, enabling autonomous self-organizing teams to solve business-foundable problems. And those organizations, when faced with this situation, have, those teams have actually taken to it like the proverbial Dr. Walter, because this is something that they've been used to, you know, actually being left to their own devices and given some steer and checking in now and again, this is what they've been used to. So that's where those two types of organizations for me and those two types of leadership have really gone in very starkly different paths. I was gonna talk you through a very simple exercise I was introduced to, but I didn't know whether I had time. I'll try and squeeze it in. Years and years ago when I was first introduced to the concept of self-organizing teams. So I was a classically trained project manager in a very bureaucratic hierarchical organization. So I believed as a manager, my job was to tell people what to do. And some people were trying to change my mind about that, trying to change my perspective and make a servant leader out of them. And I was introduced to this exercise called 50 Steps. And in it, you had to pair up. And one person was the boss and one person was the worker. The job of the worker was to produce 50 steps, basically walk 50 paces in the room. The job of the boss was to instruct the worker without touching them, using some simple commands such as forwards, backwards, left, right, faster, slower, that kind of thing. The worker had to obey the boss. And there were some fairly static obstacles in the room, tables and chairs, but there were also some relatively complex variables in the room, other people trying to complete this task at the same time. If you bumped into them or if you bumped into the wall, you bumped into obstacles, there was a penalty. And within the time box, very, very few pairs actually managed to achieve it. And the second part of the exercise was there were no bosses. Everybody had to achieve 50 steps using their own autonomy dealing with the same situation. So as well as achieving the 50 steps within the time box, both employee and boss achieved it, so you more than double the productivity. And it was a very simple over simplistic example of the difference between command and control. But it kind of stuck with me. And this idea of complex environments, having a directed leader and micro management reduces productivity and increases motivation of debt. The person in the employee, the worker role was really not happy about being told to walk forward when they knew they were gonna hit a table. And in this situation here where we have greater complexity and we do have greater complexity. I mean, even if you take aside the pandemic, working in software development, working in product development, that is a complex endeavor. It involves other human beings and other human beings are complex, weird things. So it's complex anyway. And when you add onto the fact that we're all working in a new way, that's in suboptimal conditions. I've got kids that aren't going to school and I've got bandwidth issues and all sorts of different things. I don't get to the same communication shows that I had before. The complexity is increased. So we need rather than to micro manage. And that's understandable because if I was a manager in an organization, my neck was on the line and I can't see what's going on. I'm going to be craving information and progress reports. Even if I know it's counterproductive. So what we really need is great teams. These great teams who have the ability to self-organize not just themselves, but with their colleagues to deal with the complexity as they see it. So that's the kind of context for what I'm talking about and what I've written about. And I've been lucky enough to work with teams from lots of different domains, lots of different industries. So from Sujit's financial services to I think you're working financial services as a member as well. Yeah. To pharmaceuticals, to insurance, to completely outside of software and product development research, marketing, sports teams even as I've done a bit of work with medical teams. And while every team is absolutely unique, they absolutely are, there are a few common patterns that I've noticed. And I'm not saying that I found the secret or anything, but just some things that I found quite useful to notice that these things have in common. Now, I'm not gonna have enough time to go through everything in detail, but a little bit of an overview as to what I'm talking about when I talk about a great team is sort of five characteristics that I notice. Regardless of industry, regardless of domain, regardless of the product that they're working on, the service that they're working on, it could be voluntary teams, school teams, sports teams, whatever. All these great teams that I've seen have a habit of self-improvement. They take getting better seriously. The other thing they take seriously is quality. They attach their name, their personal reputation to what it is that they're doing, building, providing, serving, producing. They have a strong sense of togetherness. The team comes first and that's sort of we are in this together thing. They're brave. They take audacious steps. And I saw in the comment earlier on somebody when Yana asked what's the one thing you'd like to see different in the world and somebody commented about I'd like people to always be able to work outside of their comfort zone. Great teams regularly step outside of their comfort zone. I'm gonna talk about that a little bit more in a minute, but equally, as well as getting better and focusing on quality and feeling like a good team and being brave, all great teams deliver. They all find a way to deliver stuff. I'm gonna very briefly talk you through each of these five and give you a little bit of an example. So self-improvement, all good teams improve, all great teams improve, not because someone tells them to improve, not because they're paid or incentivized to improve but because they want to, because it actually gives them a bit of a kick to get better. They like knowing that they're a little bit better today than they were yesterday and they're the hallmark of Yana's talk there. And one of the big differences that I've seen between good teams and great teams, and actually before I go any further, good teams themselves are really good. A lot of organizations that I've been in and other teams that I've been in wouldn't even classify themselves as good teams. So good teams are already really, really a nice thing to be a part of, significantly better than just groups of people logged together, resources, some organizations call in, said, all right, you're working together, now that's not a team, okay. Good teams are already way above that but great teams are sort of 5% that really, and you might only be a great team for a while, you might come back down from being that but it's the little things that tend to set those apart. So most teams, in fact, all teams I would say, and this is no slight on them, this is not an insult to that team by saying this, but all teams have massive glaring opportunities to get better in the early days, all right. And you all know the journey that we go through, again, Yana had the Tutman curve on there, you know it's going to take time before we get to be a really good team. So during that growth period, there's always these massive opportunities so we can really get better at that, and actually a small amount of effort can yield quite big game changing, headline grabbing changes in that team's effectiveness. And great teams do that as well, but they don't get complacent when they get to that sort of Pareto principle 80-20 zone, they keep pushing. And even when it's small improvements, they're in a habit. In my book, I cite Dave Brailsford, who is a guy who was a coach of the team GB cycling team. And one of the things that he brought in was this concept of tiny gains, improving everything, I mean everything, from the comfort of the seats to the pillows that the cyclists would use when they go to bed at night, to how they wash their hands, everything. His view was that if you could improve everything by 1%, then the compound impact of all of those tiny gains would be massive. And while each of those little changes was very, very marginal, these marginal gains added up to, in their case, record medal halls. And I've seen similar kinds of attitudes towards self-improvement in the great teams that I've worked with, in this sense of the milestones. Today, we improve the little things. That milestone is often a lot more important than a big change that we make in a retrospective, for example, get a little bit better every day, that's even more powerful. Next thing I wanted to talk about quickly was quality. Okay, so all good teams, look at how they can avoid problems. I don't think you could really ethically call yourself or morally call yourself a good team if you weren't working out how you could mitigate the risk of things going wrong, doing a bit of planning, doing a bit of risk mitigation. Now, that's quite normal for good teams, but great teams go even further. Now, great teams know that there are unknown unknowns, but they don't just take that as an opportunity to ignore it. They don't say, well, I can't plan for it because I don't know what's gonna happen. So if you don't know what's gonna happen, you can't do anything about it. Instead, what they tend to do is they look at developing their ability to respond calmly when any kind of unexpected event hits. Yes, they'll prepare for what they can prepare for, but they'll also be working on developing their resilience, their ability to cover each other, their ability to think rationally when chaos is going on around them. And my favorite story in the book is actually in this section because it shocks a few people when they read it, but I'm not gonna give you any spoilers, and I just have to read it to yourselves. Great teams are driven by, well, I said this already, a pride in their work, right? They had this sort of personal sense of attachment to the reputation of what they're building. And they're developing resilience, they're developing redundancy within their ranks so that they can kind of cope with almost anything that gets thrown at them. And this is a slightly dangerous thing for me to say, but again, I've seen it, so I'll report back. A lot of the great teams that I've seen actually see new problems as something cool in a way. Now, what I mean by that is they see it as an opportunity to test themselves against something new. It's like a new achievement that they can unlock because they know they're gonna learn something. They have confidence that somehow they'll find a way around it, or in some cases the view that, well, if we can't find a way around it, there's a good chance that nobody else would have been able to do any better. So what's there to lose? And I find that really, really interesting seeing this thing that comes up out of nowhere, this monster, most people would be scared of it and run away from it. Great team, cool challenge. And that's a big thing that sets them apart. The part of my book that in many ways was, I suppose the easiest to write was about unity, because I think everyone really knows that good teams stick together. They're united, they have a bond, they have a commitment to each other. But on the other hand, I think it was paradoxically also the most difficult to write because despite all that awareness, the Tuckman model's been around for 60 years, and yet there are so many teams out there that haven't gone through that storming phase well and ended up high performing. And I found that fascinating. So a lot of teams have goals, all right? That's a good thing. Goals are important because without a sense of purpose and objective that we're trying to solve or that task that we want to complain, we haven't even got a chance of becoming a good team. Plenty of teams have goals. Okay, you could say that they could do some work, you can make them more personable, inspiring, engaging, meaningful, whatever. And that would increase their effect and I would probably have to agree with you on that one. But they have a goal. What surprises me is that so few teams have a strong identity that binds them. And it surprises me because I haven't seen one great team that doesn't have a strong identity, that doesn't know what they stand for as a team, that doesn't know what they expected each other, that hasn't taken into account their own personal likes, their personal values, their personalities, their skills of the individual team members and crafted them into something bigger and better. Haven't seen one great team without a strong identity. And I think it's important because not just from the team perspective but from the individual perspective, if I'm gonna be a member of a team and if I'm gonna be a useful member of a team, there's no getting past the fact that I'm gonna have to give up or trade off a little part of me. I'm not talking about physical limb or anything but actually a little bit of my own personal selfish objectives because there may well be times when I need to sacrifice what I'm personally interested in because the team needs something else from me. And that's often glossed over, sort of, well, let's just not talk about it because that might put people off wanting to be part of the team. Now, hopefully the trade is mutually beneficial because that's how trades work. I have something, you have something, we trade, we're both better off. And for me, that's where this identity comes in. That's what I'm getting in return for trading off a little bit of my personal selfish objectives. It's just amazing for me that so many of the teams that I've worked with just haven't had that. There you go, that is such is life, audacity. Personally, I like this. For those of you that have read any of my other books, you'll kind of notice a little bit of a theme going on, this sense of bravery. It is, both Suji and Yana talked a lot about taking a step forward, taking steps into the unknown and that always requires a sense of bravery. It's not acting without fear. You don't have to be brave if you're not scared. You kind of should be scared. You have to be scared if you're going to be brave. And what I found fascinating about the teams that were brave, they all challenge processes. They all challenge policies, limits, systems, assumptions, all sorts of things. They take risks, they risk failure. They basically just go for it. It's that they didn't treat audacity as binary. And I think if I was to, when I first came across that as a concept and I thought back to my view of audacity, I think I'd have to admit that I would classify bravery, audacity as a binary concept. You either are brave or you're not. And I think that was a false assumption of mine. And this perhaps even a limiting belief. I think a lot of these great teams have looked at this thing with, well, okay, we're brave enough to try this. One of the great things about doing that is that you're starting to expand your comfort zone and you're also building your bravery or audacity muscle, if you like. So the slogan here says, a good team catches their teammates doing things wrong. A great team catches their teammates doing things right. I was to use a really fantastic English phrase for you, flabbergasted. When I thought catching people doing things right would be so much easier and so much more commonplace than catching people doing things wrong. So for me, having to tell somebody that they're not doing something right, sort of brings me up in a bit of a sweat. I don't like the conflict, how are they gonna react, giving people feedback, that kind of thing. But actually saying, oh, nice job. You did that really, really well. Well done for whatever it was that you were doing. Picking out the good behaviors in action should be a lot easier. But I found the opposite. I found, maybe it's just the fact that I've lived in the UK for so long. We don't like telling people or maybe someone can tell me it's a cultural thing. But we do seem to find it easier to just sort of miss out on those specific appreciations. Specific, not just saying well done, but well done for. I appreciate you for this. Thank you for doing this. But I think it's a really simple place to start for a lot of great teams. And that sense of, if it is difficult, then that is brave for those individuals. That is audacious for that team. Brilliant, start there, build up to something else. And the final thing, I've left this till last because for many organizations, I think this is the big worry about our teams. Sujit mentioned that in a B2B or B2C environment, there's always a date, right? And there's stuff we need to do. And I think speaking to a lot of leaders over the years, this idea of letting go of control and giving teams autonomy scares them. And they worry about, well, what am I gonna get in return? So let me have people come along and say, well, you need to make people happy. This is all about mental health awareness and all the good stuff that we talk about, psychologically safe environments and leaders thinking, yeah, yeah, but I still need my data, I still need my deliveries. Come on, I don't mind indulging this hippy stuff as long as I still get my stuff. And their concern is that they're not gonna get twice the work in half the time, all right? Now, don't get me started on books that encourage that with their titles. But teams will actually, in many ways, take a dip before they become hyper-performing. And, or at least appear to because we're factoring in the whole life cycle now. And that, but team, great teams don't forget about delivery and not just because other people want them to, but just like with self-improvement, it's something that they want to do. These teams enjoy creating things that are used. They enjoy giving people something valuable. Now, good teams will use the agile approach and the built-in, you know, cadences within something like Scrum, for example, the rhythm of the framework to become predictable in a good way, all right? So, and that's great because we can be relied upon to deliver stuff in a, you know, in a time box. That's useful for planning, expectation management, and so on. But great teams don't just find a rhythm. They find flow. That magical, almost magical feeling of, you know, sort of forgetting that time is a concept. You know, stuff gets done really, really quickly, effectively, and it feels great when you're in flow. Now, everyone's experienced that at some point. Maybe not at work, maybe outside of work, but they've experienced it at some point. Now, what I found interesting is great teams get into flow a lot more frequently than other teams, and it's not an accident. They do it consciously. Now, a lot of people when they define flow, so it's very hard to know what it is until you've been in it. So, if you don't know what it is, how can you actually create it? Well, the teams that I've seen, they look for patterns. So, they look for contextual patterns. So, they look for the environment. They look for times of day. They look for situations, problems. They look for anything that will indicate, yeah, this is something that was there when we had flow last time, and they'll keep logging these things, and they will just tweak their environments. They'll tweak their layout, their setup, their conversations, their working patterns, their environment in an effort to try and replicate that and maximize their chances of getting into flow. And when they do that, they do tend to over deliver. And it's not because they've rushed it. It's not because they've cooked quality. It's not because they've worked over time. It's not because they deliberately played those games of under-committing and over-deliver. They just get into flow and smash it. I think that's fascinating. But it's gotta be that way round. If you're going into this with the objective of getting towards the working half the time, you won't get that. I think that's my time box, possibly more. Apologies if I've blown it, Alex. Yes, spot on. Thank you very much. Really great talk from the three of you. And some great questions have been pulled in here. So I'm gonna go straight up. What is your, you came from a project management background. What is your opinion on the hybrid agile PM slash Scrum Master role that we so often see companies advertising for? Is this to me, Alex? That's, sorry, Jeff, that one was to you, yes. Okay. What's my opinion on it? I think it's, my problem with it really is, do the people that are asking for it know what they're getting or know what they're asking for? So you could well have put me in that category. But equally, you could put my boss in that category. And we're two very, very different people. I think we're both good people, but I think we're very, very different. And we could have the same job title, but approach the role and be a very different cultural fit for different organizations. So I think the danger with any kind of role, I mean, even the role Scrum Master, there are different sort of philosophical approaches on what kind of Scrum Master that you wanna be. So I don't think you can really use any role to get that or certainly assure yourself of getting the person or the impact that you're looking for. And I know from my limited exposure to recruitment that that's not the point. It's always going to be part of the puzzle, right? There's always gonna be a conversation. There's always going to be a sort of values alignment and a cultural alignment and so on. My worry is that if it's an early part of the process, then some people might feel they need to change who they're putting themselves out there as in order to get through the door. And one of the things I really liked about Yana's talk was being the best you, you know? And what there's, that's a better version of you. I think people shouldn't be afraid of it saying, you know, I am a Scrum Master. Now I can apply for an agile PM role, will I still get a conversation with somebody about what I think I can do to help them meet their objectives while having a different role? And I think that's my main worry with it. Okay, thank you very much. Two, Swigit, how do you drive innovation at PaySafe? So to Jeff's point, right? I mean, I think innovation's almost got to be organic to a firm, right? So one of the things that we've largely done within PaySafe is that unlike most organizations, what we don't have are guardrails, right? We haven't standardized the tooling within the organization, right? We haven't kind of, so while we've kind of almost built out the standards to say, these are the standards that you need to comply to, as a firm, they're actually not descriptive about solving for business problems, right? So very early in the cycle, we have kind of institutionalized the element of build versus buy, right? Where, I mean, we kind of, so the mantra largely is that, you know, one way to kind of have a build and deliver products fast is actually to write the least amount of code. So early in the cycle, right? Massive emphasis on build versus buy, where we kind of almost incentivize the teams to pull together solutions as innovatively as possible. And within the development life cycle itself, we've kind of gone very heavily into the open source ecosystem, right? So in a sense, there are no guardrails. As long as we comply to the standards, what you've done is regimented our CI-CD pipeline, we regimented our, how we log and monitor, right? But the entire thought process very much is around building that culture, right? So, I mean, so the classic example that we give is that going into production, things are always great, right? You're never gonna be in a scenario where you're gonna write perfect code. But how that culture develops is that if I have an outage, right? And it takes me six hours to recover from that outage, you inherently build an organization that is risk-averse and then they put in all the checks and regimented guardrails that are needed to prevent that as an outcome, right? But if you build out an ecosystem where if there is an outage, we are able to actually recover in under five minutes. A lot of that culture around wanting to build guardrails goes away, right? But the entire, so unlike most organizations, we don't actually have an innovation hub, right? Innovation is very much organic to the teams. And again, no path is perfect, right? So I think the ecosystem that we follow does come at a cost. But as long as the benefits outweigh the costs, it seems to work for us, right? Thank you, CJ. To Yana, what inspires you? That is such a hard but simple question. I think what inspires me the most is meeting that person that gives me a challenge because they challenge me to come up with new options and a different version of myself to learn. Okay, short and sweet, brilliant. So this one is actually to all three of you. Now, what I've found has worked well in the past when the same question has gone to multiple speakers is that we sort of maybe put a time box on your answers. So if we can try and keep your answers to 30 seconds each. The question is, what advice would you give to someone breaking into the world of scrum or agile on a larger scale? Jeff, I'll go to you first. If you could try and keep your answer to 30 seconds, as I say to it, it's all three of you. I hope this isn't going to use up my 30 seconds, but can you just repeat it again? It's something to do with larger scale. Of course. So it's what advice would you give to someone breaking into scrum or agile on a wider scale? Okay, okay. So breaking into it, I mean, first of all, as with anything, and again, I'm going to steal from the other people's talks today. How does it match who you are? I think there's the great thing about an agile approach is there are so many ways for you to fulfill your, or actually increase your fulfillment, but it's got to be something that matches your personal value. So work out what's important to you and then find a role in an organization that allows you to live them. Thank you. And to Sijit. Yeah, very much along what Jeff said, right? And I think at the end of the day, it just comes down to, adapting to the wider ecosystem, right? So I think Jeff spoke about the individual from an enterprise perspective. I think you get a good starting point in terms of betting it, but then how we evolve and scale it totally comes down to the organization culture and what works well. So adapt to the organization's personality. Thank you, Sijit and Yana. I would say check yourself. Before you wreck yourself, I stick to it. If you're about to think about scaling and growing, really draw boundaries for yourself. What do you know that you are comfortable at doing and that you feel confident in it? What areas that do you feel more weak at? And I would say find someone that you can consult or that you can get some advice from to get feedback as you're testing and learning because if I reference back to Jeff, he actually put squads up, you're not the only person starting this journey. Every speaker and a lot of people in this meetup we've all gone on a similar journey and although it's not going to be your journey and it's not going to be the same, scaling and that complexity, it's taking bits from other people's learnings and applying your own to really make it successful. That's my answer. Thanks, Yana. To Jeff, other than your own, can you recommend any books or other literature that can help me on my agile journey? So it's a difficult one because I would want to know more because I think if you're interested in being a product then I could go into different books. If you're interested in being a business analyst maybe with something else. So I suppose with the generic question like that, Mike Cohen's books are great if you wanted to learn about agile stuff. If you wanted to go into sort of more of the philosophical underpinnings, one of my favorite books that I found really, really useful when I was starting out was The Gold by Goldratt. Just the sort of principles of that really underpin what agile is in many ways, even though it's a complete, nothing to do with software development. And it's actually quite a daunting book when you look at it, it's quite thick but it's a really easy read and I think it's a bit of an eye opener for in many different ways. Thanks, Jeff. Chee Shujit, how has COVID-19 impacted PaySafe? So surprisingly not as extensively as we initially thought, right? So I think PESAF in itself is probably not very different from a lot of firms out there, right? We were able to make the transition to an all remote working ecosystem relatively fast, literally no bumps there, right? Probably goes down to the industry that we were in. And from a pure business perspective, like many organizations, I think we went into toxic shock in April. May is kind of, we kind of emerging from that element of shock to realize it's probably wasn't as bad as we thought it would be. Hopefully the story just keeps getting better, right? So as disruptive as COVID was in terms of changing things in my mind irrevocably for the future, the both, you know, the environment as well as the business as a whole continue to be pretty resilient. Thank you, Chee Shujit. To you, Jeff, when you provide your teachers good personality that's played over and received that. Is it just me that didn't get that? Looks like he's frozen up. No. No. Can you repeat that, please, Alec? If it's not, can you try to re-establish? Oliver Bernard, you are out here. Sorry, Jeff. I've got, I'm back in now. I think my internet connection was a little unstable. So it wasn't me, that's good. Yeah, I think it was me. So I'll repeat the question. When providing feedback to a team and being audacious, how should personality types play a role in how we deliver and receive feedback? I think you should always be aware of your audience. I think in general, there are a number of things that human beings have in common. But for me, the first thing with regards to feedback is, well, there are two really important things with regards to feedback. It's more important, it's more useful if it's been asked for. So just like in my coaching work, I really try hard, sometimes I fail, but I really try hard to not go around inflicting my help on people. Equally, I don't wanna go around inflicting feedback on people. If people want my feedback, I'll happily provide it. And that goes two ways as well, because if people give me some advanced warning about the feedback that they're looking for, I can be more mindful about what I'm looking at for and more helpful in what I'm offering. I think the second thing for me is around just knowing the sort of normal processing journey that we go through. We used to teach people about the SARA model, where the first response is shock or surprise. Often, if it hasn't been asked for, why are you saying this? And the next one is often anger. How dare you? Who are you to tell me to give me that kind of feedback before you can rationalize it, which is the R. The other R is rejection. And as a person receiving feedback, and Yana talked a lot about feedback, I've gotta be aware of being able to take that feedback as with the pinch of salt that it deserves, right? It's their perception. It's not true. It's not fact. It's their truth. But it might not be truth to me. And it might not be useful to me. So I don't just take it just because it's been offered. I should consider it and then reject it if it's not useful to me. But if it is useful to me, then I'll accept it. And I'll take it on board. So being aware where those people are on that curve, you heard the whole phrase of sleep on it quite often. You need to let people sleep on things and just process it sometimes subconsciously on their journey home from work or something. I didn't like the whole, we used to have these orange chairs in the office at BT. So there's no orange furniture in our house because they were the feedback chairs. The boss would come along from another office. He'd come in and make his way over to the orange comfy chairs. And one by one, we'd be called over for our feedback session. And it'd just be dreading it, you know, be once every six months or something. And yeah, that sort of formality of it, I don't really like. Thank you. To Yana, what advice would you give to somebody when going through an agile transformation from a waterfall environment if it's just not being accepted? I think for me, this is probably the hardest thing is when you are that first agile person, understand what they know is their base and core knowledge. If it is waterfall, don't be afraid to pick up Prince II or maybe P3O or MSP or some of those core knowledge that they have and try and take them on that journey of transitioning across into agile because usually what I've found is it's either coming from fear, they feel like they're not gonna have a role or they were the best PM or delivery lead or something. And they feel that purpose or how they identify themselves might not be the same if you go into an agile, but really it's not about agile waterfall or how do you bring them. But it's about that outcome. What is that project? What is the purpose of that change in that project and wrapping it around? Don't say, I'm gonna teach you this and it's better, but come in with, we're gonna start problem solving differently. I'm gonna be using techniques from Scrum or other agile techniques and we're just gonna introduce them in as a step by step. And what you wanna do is build the trust of those around you first rather than, I like to say, throw the guide at them. That's kind of my answer. Find that commonality and start with that and build up and you will get that transition and it will be hard because every action has an equal and opposite reaction and you've got to be prepared for that force. And you have to, what I like to say and what I train the product owners is, is learn how to counter the message before it comes back. So agile isn't working, product owner or team. We've solved this problem that we wouldn't have solved in the old way or in the way we were thinking. You've got to have your messages very clear and you've got to always counteract as a team or a unit. So you might join a team that might not be brought in at the start but you've really got to build that trust because they are the advocates for the change. Thank you very much, Yana. And that's the end of the questions for this evening. I'd like to say a really special thanks to Sidriq, Yana and Jeff for your fantastic, engaging and really insightful talks this evening. Thank you very much. We actually hit record numbers for remote agile London tonight. So thank you to everyone for getting involved and joining. It's really appreciated. Just a closing statement from myself. I said this on our product London meetup last night. We're certainly starting to see a bit of a positive change in the world of recruitment. And I'm not saying that we've got vacancies coming out of our ears at the moment but we are slowly starting to see things trickle through and our confidence that will continue. So if you are looking for something new, my name is Alex Scriven. I'm pretty easy to find. I'm linking to me and I will reach out to anyone within my company that will be able to help you for the technology that you cover or area you work in. So thank you very much. The slides will be up and the video will be shared through our community's page which has a link to our Oliver Burnett YouTube page. Again, thank you very much, Jeff, Lana and Sajit for this evening. Really enjoyed those talks. And I will see everyone next week. Thank you very much.