Training your teams

Welcome to Definitely Maybe Agile, the podcast where Peter Madison and David Shark discuss the complexities of adopting new ways of working at scale. Hello, and welcome to another exciting episode of Definitely Maybe Agile with your hosts Peter Madison and David Shark. So how are you doing today, Dave?

Hey, doing really well. I think we've both had that chance to kind of relax a little bit and get some whatever free air, I think the way it is, isn't it? So just a few thoughts away from whatever's in front of the you in terms of screen time, work time, and client commitments.

How about you? How are you doing? Oh, I'm doing good. I'm doing good. I uh I have greatly enjoyed having that little bit of time to take a breather and uh relax my mind. I think it's absolutely essential to be able to do that to try and uh come back and like be invigorated about all the exciting things we have to talk about.

Which immediately leads us to um being invigorated by the huge number of things that we've somehow managed to commit ourselves to without um heeding our own best advice, right, about working limits and process limits and all the rest of it that come together with these things.

Yep. Uh but that's not what we're gonna talk about in this session, although I think that's gonna be coming in one uh very, very soon. Uh so we had a we had a conversation with uh somebody who reached out who said he was really enjoying the podcast, and uh he had this question, and it went like this. So as roles were evolving from your traditional IT roles to more innovation on products and process re-engineering, how would a leader or manager train their team to learn skills like process mapping? Uh and uh what resources are there available to help learn those skills?

I really like this question just because the implicit piece behind it is that you're going to train up your team and teach them or they're going to learn something. And the reason I pulled that one out just straight away as I'm reading this is so many organizations just expect people to be able to work with the skills they bring to the table, which is great. There are some very, very skilled individuals out there and great teams that work together. But we really have to invest in people. We have to invest in the team. So then the question becomes how do you train people up, right? How do you train um roles, IT roles up when the the the environment they're working in has changed so much?

Yeah, I think it's a very good point. It's that uh this implicit assumption that um we'll be able to say, hey, go read this book, and you'll now know everything there is to know about this, and then you'll be able to go and act on it without providing the the time and the space and the and the training and the learning to be able to actually go and learn how to do some of these things, which are for a lot of people who are coming out of uh or are in very traditional IT roles, these are very new behaviors, these are very different to the things that they have been doing in the past. So coming and asking them to, hey, go and be introspective and look at that process you've been doing for the last 20 years and completely reinvent it. Oh, by the way, read this book, it'll tell you all about the tools you need to know. Uh see you in a month. And then expecting uh miracles to happen.

I I mean I think it it it talks to the fact that learning itself has been undergoing a shift. And I I've got three kids at university, and one of the interesting things there is when I think back to my university days, it was very much, you know, you get you get a lecture, you've got a textbook, or whatever it might be, and you're really there for the most part, is you're absorbing information and it's your job to sort of make make sure you understand that information, you can solve some problems, but it's a skills-based approach uh where the intention is if you if you know, if you come in as a novice, then after a certain number of hours of learning and training, you're going to come out being much more knowledgeable. But the process is very much about transferring information or knowledge from one person to the next. And what I find interesting when you look at things like universities now, they're moving much more to project-based learning. They're moving to to scenario-based learning. And part of the reason for that is reflected in the workspace. The the idea that, you know, if you need a particular skill, you go out and either you get a course that trains somebody up in that skill, or or you you find a person, consultant, resource contractor, whatever it is, a third party in some cases, or you bring them internally who has that skill and you bring them to the table and they go and do things. And I think when you look at things like innovation, when you look at product thinking, when you look at things like um the agile teams and how we're expecting them to work, the skills bit is a small part of what they're going to learn and how that capability builds up. Another piece is the working relationship within the team. And it's not skills-based, it's picked up by learning through experiential learning. And so there's a whole bunch of consequences that come by rethinking how people uh how we upskill our organization.

Yeah, we used to have a uh leader that liked to describe the the resources, which I hate that word as a way of describing people anyway, uh, within the organization as uh being fungible. So like we can just take them out and replace them with somebody else, and it's like going, I think fungible's got something to do with mushrooms. It's like it's it's not a good word to use to describe people. Uh and as we're looking at how you need to work in the much more complex environment that we're working in now, the uh old and I'm gonna throw out things like tailorism, a way of working where we could take the work that we had to do, we could break it down into very specific sets of tasks, which would be the same on every occasion, and then we could build out this entire end-to-end uh stream of work that we could just pass work between each person. That's not how we need to work today to deal with the environment that we're working within. So when when we look at complex knowledge work today, the skills that we need to build and the capabilities we need to build within within teams and within individuals so that they can be looking at how do we work together, how do we understand the flow of work through to our teams, the teams we interact with, the conversations that we're having, those dynamics across the organization. Uh, understanding all of that requires a very different way of encouraging learning in the organization.

What I find interesting is uh, and I always fall back onto sports metaphors, but I'm going to use a slightly different metaphor here. But whenever we're talking about these agile teams, whether you use sports or in this case something like the SAS, right? Specialist um uh uh forces within in the military, those anybody who looks at whether it's the Marines or the SAS or any of these exceptional units that get pulled together, the the skills are given. We we know that people don't get into those teams if they don't have the skills. And this is the thing that when you're talking about fungible resources, what you're really talking about is skill sets and being able to pull skill sets in and out and have them land on their feet and find things. And as long as you're only dealing with skills, then we can argue which skills are truly fungible and which ones maybe aren't, but that that's it's a it's a very sort of process-oriented perspective. But what's interesting is you kind of keep moving up towards high-performing teams. And if I take the SAS as an example, without any like direct experience, but if you take kind of the the books that you read and the stories and the examples that they provide, the the learning curve there is number one, make sure your skills are high. So if you take any learning from it, is you invest in skills learning, you make sure people have the opportunity and the skills learning opportunities. But number two is they then run through scenario after scenario after scenario, problem set after problem set after problem set, to find out how they work together. And in the case of the SAS, they're typically four-person teams, and those four-person teams are continually training over and over again, repeating the problem until they learn, they they learn how to work together and they they the skill that they're learning there is not how to do something in a predictable way, but it's how to respond to the uncertainties, respond to the surprises that we know are going to happen. So now if I take that analogy and go back to an agile team, we definitely need skills. We need to s upskill in terms of the basic how you know what my job is. If I'm a front-end developer or I'm a architect or a database engineer or whatever it is, I need the highest skills possible. But the the sort of magic source that comes in is how that team solves problems. And they need to go through that scenario-based learning, experiential-based learning over and over again. And that raises two very quick questions that come out of that or learnings that come out of it. One is don't break the team up. Like, why would you do that? You lose so much. The moment you break that team up, now all of that experiential learning about how the team can rely on one another is all of a sudden gonna up in smoke. It's disappeared. And then the second part is how do you give them small, safe scenarios to work on repeatedly so that they can learn and figure out how to solve the unknowns, how to solve the surprises that they are going to find.

And we we've seen a number of mechanisms, or at least I have come into organizations uh to try and encourage this type of learning too. Uh uh Brian Finster over at Walnut did a fantastic job with uh with Dojos creating uh these where you can come out of the workplace into a safe environment to completely learn and practice new skills, new ways of learning, new ways of doing things, so that you can then take those and apply them back into your work and the things that you're doing. So the these ideas or concepts of like how do we create these environments where we can safely learn and safely uh and have these experiential learning experiences and learn how to apply uh the these new skills in the context of uh the particular active problems that we have in front of us. So this is a very valuable way of uh of going through and starting to help teams be able to learn and develop these. Uh I I know that there is a there's a second part of uh this which where the um the gentleman was asking this was asking about uh what resources are available to be able to do this. Where can we go find resources that can help teams? And uh I had I had several that came to mind, but uh I would like to hear your thoughts on that.

Well, uh so I I think um as you're looking at something like this, the the two things that come to mind is one is the skills. You do need to understand sort of have a skills audit. You need to whether you use the skills matrix as an exercise with the team or you're looking at the problem that you're trying to solve and figuring out what the skills are that you need to go and learn. So something that that most, you know, any agile team looking at say product delivery or some sort of um process work, they'll they're going to need skills around value stream app, they're going to need skills around process definition and things like this, probably. But context is everything. So understanding that skills audit piece is an important part. But most organizations are actually really well set up for that. They're good at those sorts of things. Either they've put you know senior, experienced individuals who kind of have that in their heads uh into leadership roles who can then oversee these things, or they bring project managers in or something like this, where they've got that expertise. What's more interesting is the experiential learning piece. And you're mentioning there are there are a handful of ways that you can do it sort of off-pieced, off away from where the work is. So the the uh Walmart example that you're mentioning, things like um uh hackathons and dojos, these are all let's let's go to one side and not touch our sort of lifeblood work that we're doing and work in a safe environment. Um a kind of more interesting change or a challenge that we've seen work really, really well when you get it right is creating that safety in the work environment. And so when you look at something like sprinting and agile teams, and I'm not going to get into whether they're whatever the framework is, but short iterations of work where they're making small changes and they're validating those changes and they're learning from them and they're in a process where they can continually get better and better and they're getting rapid feedback, creates if you've got that right organization around it, where there is safety in making mistakes, there is an ability to learn because they chase one particular architecture, and then they suddenly find out that it has some weaknesses that get exposed, so they have to back it out and do something else. And these things are not taken as mistakes or failures or something kind of negative, but are actually taken as this is part of the journey. You're going to run into cul de sacs and go thinking this is definitely the way it's going to work, and then you're going to find something out that means you have to back it out and go somewhere else. Right. And I I think those are really interesting because if you can get that into the the DNA of the organization, and this is what we've certainly seen is teams excel in that, but you also end up with teams that are so far ahead of their of their peers in some ways, because the learning happens when you're not there. The learning happens very, very rapidly, and they can build that up really, really quickly.

Yeah, I 100% agree. I mean, I've seen that in uh in many instances, wherever you can set people up to be able to try these things immediately. It's why from a from a DevOps perspective, we we bring it in and say, okay, so I want you to push something into production. Just saying small. Like, what will that take? Now show me what they do. Uh so by the end of the day, I want you to be able to have something in production. And you can usually tell by the amount of fear in people's eyes just how much of a devastating idea this might possibly be. That can't I've got to get all these approvals to do this, I would need this and this and this and this. But just even understanding what will this take will now give you an awful lot of learning just in, well, okay, so now we have an understanding of where we want to be, but why is it we're so afraid of doing this and what is it that's standing in our way? Now, if we start to look at what is it we would need in order to feel more comfortable with doing this, what are the things that we can do to ensure that this is uh allowable within the organization, what are the safety nets we can put into place, how can we be comfortable with this idea that it's going to be okay, right? And uh helping people uh through that journey for exactly the reason you say, because once you can get that set up within the teams and teams can do that on their own on a continual basis, they will run with it and they will go much faster than you could ever imagine. And uh that in of itself is something that uh is is wonderful to see.

Yeah, so it's it's um when whenever we're having this conversation at some point, this conversation is normally going to come up, and I I use the phrase specifically about capability building, because capability building is different to skills building or or resource upskilling, right? And capability building has these sort of three elements that come in, which I think we've been talking about really well, so this might frame what we're looking at. One of them is there's clearly the skills, and ignoring the skills is a bad move. You we need to build in an understanding of what skills we need and how we can up like raise the bar. But that's typically done by individuals, and it's typically there are courses out there, go get them, or or it's a mentoring piece, or something along those lines, working alongside a senior engineer and you know, seeing how they approach things and asking questions and moving that up from we I think we're pretty familiar with that skills building piece. The working together as a team, whether it's what we call it problem-based learning or project-based learning, or it's it's scenarios or experiential learning, but that working together, that skill set is the soft skills. So, where do you go for the resources around that? Well, there's a ton of books around team building and uh culture code that we've talked about in previous, um you know, uh previous podcasts and things like this. So there's there are many uh books out there that talk about how to create that environment, how to encourage teams to work together. What I find interesting is agile does that really well in a in a just general, when when it's applied well, when it's not uh stripped of any real meaning and there's a stand-up at the beginning of the month and that's it. But I'm not talking about that kind of agile, but when you really get a team working together and they are encouraged to work together as a team, that sort of experiential learning happens really clearly. And then the third thing, and I'll I'll pause in a second, but the third one is just keeping the team together because recognizing the container that has the skills and now has that capability to work together is the team, not the individual. So, as an organization, when we understand that we're building teams, we're not building individuals, that changes a lot of the organizational decisions that we start making.

Yeah, I think the the one thing I would add to all of that is um, and that this comes nicely out of our flow engineering piece, like start with the end in mind, like focus on the outcomes. Why are we doing these practicing? Why are we seeing the need to develop this capability? Um, what is the outcome we're looking for? Um what how are we expecting the world to look differently if I look out three months, six months from now, how will how will it look? What am I trying to achieve? So that I can have this understanding that I'm focusing on things for the right reasons and not just because it's the flavor of the month or the thing that I read in the latest article on LinkedIn or uh or something along those lines, versus hey, no, I I I've got a vision of where I want to be. And so in order to achieve that, here's some experiments I want to run. How can I current start to create those capabilities to do that?

I I love that that that's the ribbon that ties everything together because when you talk about holding those teams together, the best organizations, the ones that I point people at to say, you need to go see how these guys work. Their teams have a purpose, number one. And when that purpose changes, the teams change because you'll need different capabilities, you need different skills, whatever it is. So the the teams are persistent around a given purpose or outcome, and then as those outcomes shift and change, those teams will shift and change, driven by the outcome, not driven by funding, not driven by different resource managers wanting to move things around or whatever it is, but they're driven by the the need, the purpose of that team. It's a brilliant point.

Well, awesome. And with that, I think we're right about at time. So it is wonderful chatting as always, Dave. And uh, if anyone wants to reach out to us, they can at uh feedback at definitymabyagile.com. And uh I'll look forward to next time.

Same. Good to talk again.

You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Madison and David Sharak focus on the art and science of digital, agile, and DevOps at scale.