116: Chris Smith

Listen to full episode:

Joe Krebs speaks with Chris Smith about what dynamic re-teaming did to performance, growth and the leadership team at his company. Chris is sharing real world experiences from the trenches.

Transcript:

Joe Krebs 0:10

Agile FM radio for the Agile community, www.agile.fm. Thank you for tuning in to another episode of Agile.FM. Today I'm here with Chris Smith, who is the head of product delivery at Red Gate. And we have him actually explain a little bit what Red Gate does, but he's also posting information about the topic we're talking about here today on leadingagileteams.com. Our topic today is kind of a companion kind of podcast with something we have done just recently with Heidi Helfand and about dynamic reteaming. So this is the practical implementation on reteaming dynamic reteaming on the team at Red Gate. Welcome to the podcast.

Chris Smith 0:59

Thanks. Thanks, Joe, thank you very much for having me on.

Joe Krebs 1:02

That's awesome thing. So thank you for taking some time and spending some time with the listeners to talk about dynamic reteaming, we could say one more time. But last time I spoke with Heidi about the book, and some stuff that is important for people that are implementing this, but you're the person that actually implemented that at your company. Redgate.

Chris Smith 1:21

Right, yeah, that's right. So, so already talked about a continuum of freedom for reteaming. So where maybe one end managers, organized teams and tell people where they're gonna go, and then at the other end, everyone has gets to choose where they work. And we're moving closer to that second stage where we give people much more influence over where they work, and which teams they're part of. And we do that every year.

Joe Krebs 1:21

Right? Can you just give listeners maybe who are not familiar with Redgate, a little overview of just on a very high level? What is this company? What's the background? What's the size, geographical distribution, etc?

Chris Smith 2:01

Yeah, sure. So. So Redgate are a small medium size software company, we are based in Cambridge, our development hub is in Cambridge in the UK, but we have sales offices around the world. And we create software for database professionals. So that database administrators, database developers, and our tools, help them do their really important jobs of creating, maintaining and operating the databases that support all our systems, corporate and consumer, there's a database in there somewhere, and our tools help the people that make those and look after them. In the last, in the last five years, we've been really focused on helping those database professionals bring the database into an agile and DevOps environment. So you know, agile delivery of application code has been around for years and years, often the database gets left behind, it's scary to change it, it's scary to integrate it in like an agile continuous delivery process. So it gets a kind of a waterfall back backdoor process that gets the changes out, and we want to bring that in there and get the database delivered agile-ly alongside application code. So that's been a part of our mission for the last five years. And, and, and yeah, we've got a whole range of of database products that we really hope will help help people develop databases in a really agile way.

Joe Krebs 3:20

Yeah, that's actually a very good point is like, based on my experience working with teams with Agile teams. That is that is often a bottleneck if they are, you know, with a database administration, right, schema changes, etc. Right? So it's interesting to have like a product. So this is interesting for this podcast, right? Because we're dealing with a product that solvesor tackles a problem in the Agile community, but also Redgate itself is embracing agility. And obviously embraces some things that are about dynamic reteaming. Right. And that's our topic here for today. So tell me a little bit about how you came across this. Obviously, there is a book out there we I spoke with Heidi about but this is really about you taking some of those ideas into your organization. Now. How can how many times did you do reteaming? And how did you start with this?

Chris Smith 4:16

So reteaming something is always happens. It always happened at every company I've been at, and where people join teams, people leave teams, teams, split teams have to end. And that's re-team and that's the creation of, of new teams. And but what we've been doing for the last three years is deliberately reteaming all of our teams or making an opportunity for everyone for me team off the back of our strategy, review process. So for the last three years, we've asked everybody in our product development teams, where they'd like to work in the coming year. Would they like to stick in the team they're in at the moment, or would they like to go and do something interesting they can see across the range of things that we have, we have 11, software development teams at the moment, they're all covering different kinds of products at different stages of their lifecycle, which means very different work. You know, if you're in a, you're working on a product that is very early stage, maybe creating iterating, quickly creating code that might not be super maintainable in the long term you're trying to learn, the whole point there is to learn fast. And you might find actually that you stopped doing the work you're doing because that product hasn't found its market and you go do something else. So it can be quite ephemeral. And then you've got other products that really well established me when I grow and scale their addressable market. And they have a different kind of work. They're about maintainability, and scalability and new features. And that works very different. So reteam to let people choose which of those kinds of work they'd like to invest their work life in for the next 12 years and beyond. So, we've done that for three years now. And it's gone, it's gone surprisingly, well, it's gone, it's gone really well. And people have been really happy with it from both the kind of team members that are involved in it, and the governance that the leadership of the organization.

Joe Krebs 6:03

Right. So you have some metric points out there. So first of all, if you're doing this three times, while it tells me that it's kind of a success, because you would have stopped after one. You have success, right? And it's going very well. But you have some data points behind this too, right. And so I don't know if you know them from the top of your head, but there is some high percentage on satisfaction with this process among the employees, if not so much you but the employees that are impacted by this, can you share any? It doesn't have to be exact right? So but if you have anything that is like somewhere in the in the criteria, where you would say we're like in roughly high, I think I saw something on a blog post of north of 80% of satisfaction with the team that they picked, I think was even higher than ever.

Chris Smith 6:51

Yeah, so in terms of what happened, certainly, the first time we did it, so we asked people, we made it very clear what was out there, what what possible pieces of work were possible teams are out there, what their mission would be, what they were trying to achieve, what their impacts were we were going to have. So they had all these choices about where they might want to work. And we asked them for their preferences. So what was your first preference? Where would you like to ideally go? What was your second preference? What was your third preference? Why was that? Why were you saying this was your first preference? Was it because of tech? Was it because of the lifecycle? And, and that was a big leap of faith like well, we'll ask these people will that create an organization that's effective is that fit for purpose for what we're trying to achieve? Like, it felt like he could have gone really safe, we could have had, everyone wants to be on the same team. But instead, we did get this spread of preferences and interest. So we were able to allow, I think it was around 85% of people got their first preference. 80% of people got their first preference in that first year. So we were able to meet their first preference where they wanted to work. And then I think it was 95% or something, they got one of their preferences. And the last few, we had to fit in with an option that kind of fitted their personal development, but wasn't an option they necessarily chose. So in the end, we got a very high level of satisfaction from our team members that they gone to somewhere that really spoke to them. So we ran that again, that the following year, again, very similar numbers. And in this last year, which we did entirely remotely we had 83% of our engineers who were in the team that was their first preference again. And 98%. Again, we're in the first second or third preference, and in the end, we moved 37% of our team members, which seems a lot, right. But it's been absolutely fine. And in the previous two years, again, a third of people move. So this is what I'm saying we're not we're not we're not completely taking all the teams apart. And putting everyone in different team. We're allowing people the freedom to move, right and the freedom to give strong influence of where they spend their working lives. And not all of them want to move but a decent number do and that's entirely supportable, we can cope with that. Absolutely fine. The last three years.

Joe Krebs 9:15

It's awesome. 98% ended up with one two or 3 option, right? It's it's a very high number considering you know, delivery head of delivery like you would be assigning this you would have probably I would assume a lower percentage if you would assign people to teams, they might not like in the way they actually chose.

Chris Smith 9:37

I honestly, when I when we first time we did this I did not know what to expect. It was as you mentioned, Heidi, I mean Heidi was a was a big influence on this, but I think you know, we call down. We'd call that at Red Gate, that we believe that the best way to make software is empowering teams with clear purpose, freedom to act and a drive to learn. We tried to make that principle we choose what we do behind that principle. And yet we'd have retained in the old fashioned way of like managers in a room deciding. And then Heidi kind of I actually saw Heidi, a couple of conferences, talk about her subject on every team. But hang on a minute. We're talking about giving people purpose and freedom to act. And I'm telling them what team to go in, what am I doing? And it was that kind of push it said, don't be a hypocrite. If you say that you want to give people autonomy and purpose and mastery. Ask them where they want to work. Give them that that opportunity to have a say, it was obvious when I'd seen that. Yeah, and but the first time, I didn't know what was going to happen, I thought I hoped it would, it would be a, I suspected that quite a lot of people would like to move, but not everyone would. Some people like the stability, it's the point in their career or the point in their life, or they're really engaged in their mission, and they don't want to move Thank you very much. But other people are looking for that opportunity. And by making it deliberate and making a date in the candidate, where we will talk about this, it is free I think a number of people up to move that wouldn't have wouldn't have otherwise tried something different. And also given them that opportunity to self-select onto a new purpose to self select a new mission. And I feel like a sense of ownership of of what they do in their career. So yeah, it was first time was a leap of faith. But following that, I don't think we'd ever go a different way now, because it works.

Joe Krebs 11:25

Yeah, It's a, again, nerve wracking moment, right? If you're doing this the very first time and you're like, I have no idea how this very big event with so many people, it's gonna go and, you know, and it's big relief on the other side and, and prove that these things work. Once you go through it.

Chris Smith 11:42

Yeah, I think it was definitely the fear, the fears I had before I did it. And maybe that reflects with with folks at home that might have the same fears. If we ask people where they want to work, they're all going to choose the same exciting team, they're all going to choose where there's the new tech, where there's, you know, Kubernetes, and everything else that we've seen exciting, or they're all going to leave a team that is maybe more, maybe one maintainability, or looking after a large, successful product, but maybe it doesn't, doesn't need a lot more features, it's kind of done, but it needs to be looked after, we're going to see all these people move away from the crown jewels and the most important, most important tools to the business. And ultimately, as a delivery manager, I'm gonna get fired, because of all my people. So that fear was definitely something we had to get over. And, and just sort of step into it. But I think we also thought about the fear that might be on the case of the people involved in the process. So you know, people don't love change in general. And so if you're in a team that you're feeling secure and accepted to actually leave is a big deal. And it can cause a certain amount of anxiety, I step away from that, that comfort area and go and do something else. So with the process of Redgate, we've tried to think quite deliberately about how we can make it reteaming without the anxiety, both for leadership in terms of oh my gosh, we're not delivering the things we need to, to the people involved is I've got to change teams, that is frightening. And so our practice isn't just, you know, we go along to one big session for two hours. And by the end of it, we decided what team we're on, we take a bit more of expanded approach, where we will make it very clear what options are available in the teams, then we will let people explore them in their own time, kind of asynchronously now with remote working. And then we will coach everyone individually. We have coaching sessions with everyone to say what have you seen? What are you interested in? Why are you interested in that? Let me understand your preferences. And there is a process where a set of folks have a set of leadership folks get together and look at those preferences that people have and look at the kind of organizational structure and the investments we need in different products. And can we make those work? And sometimes we'll have to ask people to come together for their second preference and not their first because that's really going to help us unlock this. Well, can I move in a couple of months when we've been able to disseminate the knowledge, it's in your heads and to the rest of the team? Because people are involved in this change? Because it's a change with them and not to them? They've been really open about those things. Oh, yeah, I'll go to my second choice. Happy days. I mean, I understand why that works. Or I will delay for three months no problem, because I can see that my unneeded in this thing before I move. Once you include those folks in this re-org some might call it then it becomes a much more collective experience and a much kind of a less anxious project.

Joe Krebs 14:48

Yeah, it's interesting. Why because you might let's say I have a project one, then two and three as listed on my, my preferences right. And I might get assigned, let's say you as a department head without dynamic regime teaming to, let's say, option three. And for me, as a person being assigned to that team, I might have a negative association to it because I was assigned to it. But if I self select, and I pick three, all of a sudden, it's like I picked that I picked this team, and it was just my third option. But then I made this choice or sometimes, you know, human behavior might also deep down psychology always is like, was this somebody told me to be here, or I made the choice to be here. And even though it's the third option, I might still like

Chris Smith 15:37

Yeah, absolutely. I mean, I'm Have you read the book, The Chimp Paradox?

Joe Krebs 15:42

No.

Chris Smith 15:43

It's by a chap called professor, Steve Peters, and he talks about, he introduces a model that helps you understand how the brain works. And it's very abstract, but it kind of helps me understand it. And that kind of, it talks about your kind of inner, inner, inner Chimp, but the kind of the thing that's, that's kind of captured in your amygdala, which is very, it's very reacts, it's very emotional. And effectively, your chimp doesn't like being told what to do. So by a manager telling you that you need to go into one, you will quite naturally quite physically have a real reaction to that. But it's normal for you to think, Well, why are you telling me I should have a say in this, I need to have some self determination. And you're right, like some people could actually choose that team project one themselves, because they've got the choice. And then their experiences that will be totally different from from being told to go in it. Because they're included, and we cared about what they thought and we looked after their, their psychology and their inner chimp. I think another thing that's happened, that I've noticed, having done this for three years that it's completely normal, I think for, for people to look for someone to blame, if there's a difficult time, on a project, like it's on a project, it's getting really gnarly, there's something very difficult to hear that we got some real hard things we got to do. And it's kind of normal to say, well, they've done this to us, you know, that we've been put in this situation. I've been putting this I'm a victim, I've been put in this situation. And it's really hard. Whereas you, we chosen now to be in these teams, we've seen what's coming and the gnarly work that's coming, and we self selected onto that, and we're gonna give it a crack. And we're going to do our best here. So there's much more kind of, as you say, sort of, they understand why they're here. And they have chosen it. So they they're gonna crack on with it. Much less us versus them now that I see the around team mission, and the kind of the difficult stuff that teams have to take on.

Joe Krebs 17:40

I have a question like you've been with Redgate, prior to the time and you started reteaming, right. And so at one point, there was this moment where you said, I'm gonna try this, obviously, there could have been any kind of impulse, we said, you know, I, I need to do something like, I need to experiment with something, and it led to this process. But what was the time before reteaming? What were the challenges you were trying to solve? What was Redgate prior to reteaming? And just as compare now like, what was the business reason or the need to actually say we want to try something right? And then the path took you to that approach, which we now call dynamic reteaming. But just curious to hear, like, what was the trigger? So if somebody is out there and says, Well, you know, what was the problem that we're trying to solve?

Chris Smith 18:28

Well, there was, there was that piece where yet we were talking about these principles for organization and not living them by doing things in a different way. So there's that part, which was, which was important, but I take your point, it wasn't it wasn't the pure business driver. I think we wanted to make a big change. And we wanted to restructure in a way, where, as I said, we were clear about what our product teams were for. So where they were in sort of Kent, Beck's 3x model, were they exploring? Were they expanding, were they sustaining, and the work was very different, we want to be very clear on that. And then when we're clear on inside product x you are in, you're in exploring products, you looked at the folks in that team, and you knew that wasn't the kind of work they wanted to do some of those folks, they wanted to do some of the other work. They wanted to do some of the scalability and the performance work that is in an expand or sustained products. So you can see people were in the wrong place, and being clear about what the products were trying to achieve. So there was a problem of how do we get them in the right place, while not destroying everyone's morale and having this big, crazy real, where people tell everyone else what to do. So there was that but also, I think we were seeing real silos in the organization. So Redgate for a long time has been a product company. We've got product teams, literally. And we built up teams to be autonomous and self sufficient as much as possible. And when they do that, they stop talking to each other completely Naturally, they solve their own problems and a team that's sits next to them literally next to them, you know, when we're allowed in the office, they wouldn't necessarily share what they were doing. And we end up with components that did the same thing across products. So we saw these, these silos. And we also saw, I mean, I used to totally believe in like that kind of stable team that stays together forever. And that's the best kind of team. And this has changed my thinking, because what you see there is not only those silos, but also people that become the expert in a thing and never leave. And they never can leave, because all the knowledge is in their brain. And all the knowledge around the teams becomes tacit, it becomes part of the groupthink of the team, not explicit. So it's not written down anywhere, because the silo know all these things. So we were we were having a less agile organization, as a result of that siloing that ossification, that when it said, right, it's time to create a new team on product X. We weren't used to changing teams, we weren't used to people leaving and we didn't capture the knowledge in a way that could be shared easily when new people joined. So we needed to get good at reteaming, which is kind of the central central premises of Heidi Helfand's book. So with reteaming now, I think what we've seen is breaking down some of those silos. If you think about it, in the last three years, each time about a third of people have moved. You think about that dissemination of skills and relationships across our organization, that it's easy for me now to go and talk to Team X. Because I know, Jeff, because Jeff used to work with me last year, but we reteamed an error in different things. But I had that connection. Now, we're breaking down some of those silos and building up a kind of an organizational network, but quite naturally was going away because of the strong silos.

Joe Krebs 21:47

So innovation is therefore also like, there's a foundation for innovation, right? Because I might walk over to another person. I mean, you know, in your example, I think, Jeff, would walk over and have a conversation with that person and say, hey, you know what, I remember you from the last year's team we worked on together, and you mentioned XYZ, and I'm now seeing this. And that might be a big thing for us as a company. So as a platform for innovation,

Chris Smith 22:11

we also had probably an issue with allowing people to progress, their personal development, their learning and development goals. So not everyone, especially engineers, that don't want to be the manager or the team lead or the or the whatever. Next, they wants to widen their skill set, they want to learn new technologies, they want to get more experience in different areas. Yeah. And you can do that by changing teams by saying, Okay, well, I want to, you know, some of our teams or some of our products or plugins, to Microsoft IDs, but I want to work on a web tool. So actually, I need to widen my web skills. And I can do that by moving to that is that is that is my personal growth. That's my personal development. I feel like I'm learning I'm happy when I'm doing that, can we be needed to enable those because we weren't doing it within the teams.

Joe Krebs 22:59

So you have these events in the last event was a remote event. And so the first two were in person. The third one is remote. What's what's your takeaway from a remote event? And reteaming? Obviously, you might have gone into the same, like in the first one you had fear about this is going to work? Maybe another moment, a few weeks? I guess it's going to work in a remote way.

Chris Smith 23:23

Yeah, it went, it went really well. And I think I was confident as we went into it, because our organization the same as many organizations that have been forced to, forced to work more remotely is to have people away from the office and working from home from from distributed workplaces, is we've picked up tools. And we've learned techniques over that nine months of doing that they've helped us understand, like, we've learned how to collaborate remotely, we're using tools, visual organization tools like mural, and Miro, yeah, things like that, using virtual meeting spaces, so we can have big collaborative sessions, we've learned and with those tools that we're going into, I was quite confident. But actually, if you'd have asked me a year ago, before we got good at remote working, I would have told you it couldn't happen. It's impossible. It's too connected. It's it's a kind of a it's an experiential event, you've got to get everyone in the room, and they all like spark off each other. But actually, it was, it was probably better. Well, remotely. I think a couple of the reasons were, if you put everyone in a big room, and they talk at the same time, you can't hear anything. So our virtual space, using a tool called spatial chat, meant that you could actually move around the room and hear specific people and encrypt everything else that we could actually share some of the collateral to explain to team members what their teams, what the different teams will be doing next year, we could share that upfront. And people could consume that asynchronously in their own time that could really deep dive into what we call team charters, which we're painting A picture of what a team would be like in the coming year, they could really invest in those. And also as, as leaders trying to visualize all these preferences and work out if they fitted a tool that online that captured how things were progressing, and you didn't have to write up the notes from the meeting, because it was there in the tool. And we used to go into a meeting room, and we used to stick post it notes on a wall to help move people around, I'll just gonna go to that team. Julie's gonna go over here, but the post it notes will just fall off the wall. And then you'd be like, what was the team, like the team is I've got to put the team back together, because the adhesive isn't good enough against these walls. So if it was none of that kind of like logistics problems in putting the jigsaw puzzle together, because the remote tools were so good for helping that. So yeah, I actually think when we get back to a hybrid world, probably at Red Gate, where we have people in the office and back at the office, we will probably go home, all of us to do this process remotely on purpose, because it worked out well. And use the kind of time in the office and social time, it's collaborative time, it's kind of connection time. And this can be a process that actually happens remotely, right.

Joe Krebs 26:13

And you can even prepare the remote rooms. But sometimes you walk into a meeting room, and you have to prepare the room right here, I can actually prepare everything and you go in, that's might be a good time saver to.

Chris Smith 26:24

Absolutely, I forgot that about working in an office, when you go into a room like one minute before it starts, it's just a garbage dump. And there's things everywhere and the wall isn't being cleaned down. And then when you're finished at the end, and there's only a minute left of the meeting, and you've got all this stuff on the walls, and the next person is waiting to come in, you've got to take everything off the wall before you say I forgotten and that's what happened. But that's that's gone now, when we're doing these things remotely,

Joe Krebs 26:50

definitely has changed. You just mentioned something in your last comment about the team charter. And I want to explore this a little bit. Because if somebody listens to this right now, and we're talking about dynamic reteaming, and somebody's choosing Team A over B, or preferences, etc. They're not just going to make this out of the blue. Yeah, and this is gonna be this is not like personal favorites, I want to work with a specific person or something like that I like this person, there is a there is something that guides people in their decision making. Right? And that is the team charter. If I if I'm not mistaken, right? Can you just give listeners a little bit of an overview. So it's not like there is something behind it, which allows people to really self select the teams?

Chris Smith 27:30

Exactly, we have to give people the full context, the full idea of what it will be like in these things. It's a big deal to swat team sometimes, and they need to know what they're stepping into. And he's got to visualize what life will be like in that team, I think. So the team charter, which is just a lightweight canvas, filled in by the leadership roles around the team, who are in place, before other folks have in place, they're there to shape what that team will look like before we get people involved in joining as developers and designers. It calls out the mission. So as I said, before, we're getting saying we need to give you clear purpose. So that needs to be there. Why, why is this team here? What's the impact this is going to have for Redgate? Like, what are you doing? And so we're going to call that out, we can say what this team own? What's the scope of your work? Do you own this product? Or these two products? Or this part of this larger product? What's What don't you own? There's a legal understand again, what that kind of thing that we're doing. And also, you know, by then we should know what the product strategy is, how are we going to be trying to make these metrics move? We're going to be trying to do some competitive features, or we're going to be moving into a new database technology, what is what is going to be the strategy behind this work? And we'll also talk about what's life going to be like day to day and that team. So is this a team that really likes mobbing a couple of our teams do a lot of mobbing even remotely. And really heavy on pairing, it's worth knowing that before you go, you don't want to arrive at that team. Being someone that's, that doesn't really enjoy mobbing so much. And that's all they do every day, you need to know what because there is some variety in practices and techniques across our teams. So about those. And also we talk about and this is an important part of it, as well as the constraints. So for this team to be functional and able to do the job, it's therefore we need these things. So we'll need some people with experience with this product before we have to have people that know how these products work. We need people that have this product this skill with this with this technology react C sharp will need these skills and will need a mix of experiments perhaps on senior to junior we can take a few people that we need to mentor but we really have to have a strong senior in there. So we encourage leaders to be very clear about what they think they need in their team. And for that to be open to everyone so they can say oh, I can see how I fit in there. Yes, I'm a junior but they're okay with a junior so that could really be a good fit for me. And they do mobbing which is a great way for me to learn. That's a team I'd like to go to I'm not so bothered maybe About the higher purpose right now for me in my career, it's best that I can learn from experienced person. So that's the team I want to go to. So it's quite a multifaceted view on, on what the team will be like. But and then lightweight canvas, it's not a lot of words, it's a canvas that that people can fill in and absorb quite quickly, I think.

Joe Krebs 30:20

I mean, this is fascinating. I think this is important, right? Because people need to have the foundation for a decision, right? It's like, it's like, what is what is my skill level? Where do I want to go? Maybe there's a bridge between my current skill set and that future skill set. And there was a ton of people, if not the majority of people who like to learn, right? They want to learn some new skills, especially around technology. I mean, you want to just see something else, or you want to explore different product, or you know, what team you want to be associated with. But you mentioned, you had these three events, and they were annual events. So what if I pick the wrong team and made the wrong? Let's say, I pick number one team, and I got one, my first preference, and I got it, and I'm happy and I get started. And then I realize I'm not liking it. It's not my thing. Is there? Is there an opt out somehow? Or is that a static process for a year that I'm locked in into a team? How would that work that somebody like because it's dynamic, right? How do I possibly shift between teams, even after a reteaming event? How does that look like it? at Redgate.

Chris Smith 31:26

Yeah, it looks like people sharing their experience with their line managers, and then as its people moving, I think this process has allowed us to get good at reteaming has allowed us to build up the kind of explicit knowledge, the team building activities that we know how to run, just an acceptance that people will move teams, we're not so surprised when a stable team has to change because they always change. Yeah, so we're, it's not like we'll do we'll change once a year, and then you're locked into next year? Because I think I think an interesting point is, is we always were like that Redgate. We always said, if you didn't like where you were, and you wanted to move, you can ask the moon, that's fine. Like everything that I've been Redgate in 10 years. It was always the case. But nobody ever asked to move. Yeah, it wasn't a thing that you did. But now it is. Because every year we said, look, it's totally fair to move, you're not criticizing your teammates, you're not saying you don't like your team leader, you're just saying you need to move your career or your personal development or because you need a change. That's fine. So it's now a normal thing. So I think it's much more likely people say, actually, I want to move media and providing the can because clearly, we want investment in certain teams, and we don't want to leave teams under invested. So they're quite fragile. We need a certain size of team for it to be for purpose, provided we can do that. We will move people and we have moved people in media, if that's what they would like. And again, people are very open to saying, well, we need to we need to hire somebody to take your spot. So it might be couple of months. It's like fine, as long as I know, you've heard me and you're going to I'm going to go over there. This is fine. I it's not a problem. I will. I'll keep you in this team until until we ready.

Joe Krebs 33:15

Awesome. Yeah. Would you would you recommend anybody listening out there to go with that flow of yearly annual events? Or do you see any need for possibly shorter reteaming kind of experiences every six months or so? What is the pros and cons? And why did you guys settle for a year?

Chris Smith 33:34

So for us, it's it's yearly because we had previously an annual strategy review process. So with all our different products, obviously, we are trying to be agile, we're trying to respond to the market and change and not plan too far ahead and then respond to what happens. But we do have a yearly process where we say where do we want to invest? We can spend this much on teams, we can add this many people do we want to invest in this product or that product to this and changes do happen? We double down on some products, we spend a bit less than others and we need to create a new product. So it is there's an obvious change point, there's an often obvious reflection point for us in our annual calendar. So doing it then makes sense. There is obviously an overhead to reteaming like this. I think I said it wasn't a two hour meeting where you drop in. And then by the end of it it's we prepare these charters on the back of Product Strategy. We get our leaders in place and then we have that prolonged interaction where we show everyone what what is on offer and then we get their preferences and then put them in a place overall this year it took us 15 working days 15 working days from hear the charters to your in your new team go. It wasn't we weren't doing the work during that 15 days, but clearly people's heads were thinking about what can I do next and it's a bit of a distraction. So if you're going Do something like this. It feels like quarterly would probably be a bit too often to be a bit too much overhead. I could sort of see it six months if there was a reason. Yeah. If there was like that driver that change in strategy, that means we're actually now it's reflection point, we should do that. Again, no big project has stopped a big one starting and actually, there's some opportunity see, I can sort of see it's doing that. But firstly, it's working annually. quite nicely. And actually, we've had some people say, I wouldn't want it any more often. Maybe every two years like you asking quite a lot. Asking once a year. It's not that often but I think there's there's there's a comfort people happy changes in the year for us seems to be a sweet spot right now.

Joe Krebs 35:39

Yes. Wow, this is really awesome. Thank you for spending some time here and explaining some of the, you know, the ideas behind dynamic reteaming here, at Redgate. Okay, this is awesome. Thank you so much for for sharing those. And I just want to refer all the listeners also to your I call it the blog, the leadingagileteams.com Where you you know, somehow share your experiences from these events and experiences also throughout the year. So that's a great source for information. There's also some videos people can watch about you in action, so all cool stuff. Well, thank you, Chris, for that and I'm on the show page I'm gonna make all those links available for all the listeners. So thank you for your time.

Chris Smith 36:25

No worries. Thank you very much for having me on. It's been a pleasure.

Joe Krebs 36:27

Thank you for listening to www.Agile.FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.