Can Software Teams learn from Sporting Teams?

In this new episode of Le Podcast, I had the pleasure to have Chris Foley joining. Chris is a Principal Systems Design Engineer at Red Hat and a sports coach. Together we explored what software teams could learn from sporting teams.

Here are some of the things we discussed in the episode:

What makes a team a good team,
Learning from your defeats,
The importance of the clarity of the roles, especially with the evolution of software teams to cross-functional teams that not only deliver software but run a service,
The importance of momentum (I should write that much bigger seriously, the criticality of momentum!),
What triggers the momentum, positive or negative in sports or software,
How to build on positive momentum, or address a negative one,
The importance of team (team win games, not the individuals),
Fostering leadership across the board,
Contribution to the goal of the team is more important than the number on your shirt,
How to keep the score and track your progress in the software world,
The practice of positive reinforcement,
The use of specific challenges to foster changes and improvements,
Training and performing does not happen at the same pace in sports and software, what can we learn from that,
Positivity in a group is a massive benefit,
Focusing the training on very specific aspects the team needs,
Ownership of the results, the processes, the tools,
Communication at the appropriate level to the different stakeholders,
Understand your strengths, and play to your strengths, as a team,
Cross-pollination of ideas from different domains,

Drop a comment or an email with your feedback or just to say hello! And until next time to find better ways of Changing Your Team!

You can listen to this episode on your favorite platform: Anchor, Spotify, Breaker, Google, Apple…

Here is the transcript of the conversation:

Alexis:

Hey Chris, can you tell us a little bit more about you and your background?

Chris:

Hi, Alexis. Thanks for having me. Yes, of course. So my name is Chris Foley, principal engineer at Red Hat in software for about approximately 23 years now, I was with Erickson initially out of college, worked under 3G. I have a management system, developing for about five or six years, moved into telecoms research after us for about six years and worked on kind of FP7, so Framework Seven European Research Projects. Then went back to industry and went into the financial domain and into the Airlie lifecycle software life cycle around gathering requirements, kind of done some business system analyst role there, and then went back to telecoms with a company called Oracle and worked as a senior engineer team lead in distributed antenna systems. So basically that’s networks and then to Red Hat and was involved with the mobile product in Red Hat, and fulfilling kind of engineering improvements role inside Red Hat in the child services department.

Alexis:

Very interesting and diverse background, Chris. We are here today because we had a chat about sporting teams and software teams, and I’m really deep into what makes a team a team. What makes a team, a group of people that will really increase their impact and satisfaction? What’s make a team a great team? You told me there’s probably things we can learn from sporting teams about that. And I’m curious about what it is and how it works for you.

Chris:

So maybe a little background on my sporting life. So I started playing sports right from a very early age of nearly four or five, was heavily involved in the Gaelic games here in Ireland, hurling and football played soccer. A lot of my forte is predominantly team sports, even though I played individual sports. So I feel the role as a player as a senior player on the group, as a captain, on to coach for juvenile and adults, and then even to manage juvenile and adult teams. So that’s a little bit flavor of my sporting background and I continued to be involved as a coach. My playing career is over now, but I’ve been looking up to be involved with successful teams. But also have took many of these things on sports teams. So as you know, sometimes you learn more from your defeats than your victories.

Chris:

There’re many aspects I think that makes a good team. A lot of the best teams have a lot of clarity in their role, in what they’re trying to do. I think that clarity of role is something that in a group that’s successful. There’s an awareness across the group. That’s an awareness individually of what your role is. And in turn, I think there’s an awareness across the group of what each individual brings to the group. That’s something that’s very evident in success for sporting teams. If we looked across at the software team and looked at that same kind of artifact currently in software, now we are actually creating very cross-functional multi-purpose teams, which is a very good thing. So they don’t just develop software. Now they actually deliver software, they develop, they write the docs, they test the architects. They have all of the components.

Chris:

We are trying to share that responsibility, which is very positive, but I think ensuring that we keep clarity within the group is also, we shouldn’t forget that because with clarity of where our role becomes, there’s a responsibility and there’s an ownership. And once you have that within the group, I think that makes it very strong. I think one aspect is clarity of your role and responsibilities is a fundamental piece that with a successful sporting team, they’re very clear and evident and in turn with software, especially now as we transition across to the multi-purpose cross-functional teams that we have, so we don’t just write the code and throw it over the fence, the testing team that doesn’t happen anymore. So we’re very intertwined and ensuring we keep clarity is key. That’s one aspect, I would say.

Alexis:

It’s a very important one. And as you said, that as we evolve to more cross-functional teams, we don’t have the traditional roles of division by functions. So your role is not the color of your chart. That’s probably something more septal. So we need to clarify the roles, make sure that the expectations are clear. We can have a real team working. What else do you think are things that are connecting what happens in sporting teams and software teams?

Chris:

So there’s one piece that I think that is very evident on the sporting side, but maybe yeah, I think it’s happening on the software side, but maybe people that does not as, it’s not as clear and evident. So the whole concept of momentum in sport is a very big thing. So what do I mean by momentum? Like if you look at a sporting game, one team score the goal. Once that happens, what you’ll see is that team that scores, their confidence increases, as they play the game. Even their aggression levels, all of them go upwards what’s happened is momentum has been triggered the team that are starting to harness that confidence and positivity and that momentum. And then what you’ll often see is that they’ll actually score a second goal. So they are actually build on it and they used that to their benefit.

Chris:

So that’s an example of positive momentum. You must also consider there’s negative moment. And on the negative side, it’s the team that’s actually conceived that goal. So they’ve taken a hit or a blow, conceded a goal. It’s their reaction to that. It will define them if that builds, that negative momentum builds and they concede that second, then potentially the game is over. So it’s how they react to negative momentum and how the team that scored, who reacts to positive. And the other thing there is to know what triggers that. In this example, the goal is very simple trigger. Now, what does that look like on the software side?

Alexis:

Yeah. I’m already curious how we can apply that, how we can benefit or how we can realize what are the triggers, how to build on the positive momentum or the opposite. How to make sure that we are not engaged in a downward spiral.

Chris:

Yes, the potential triggers, they’re there in every day software kind of live sector, right? So like if you do a release after a sprint, that’s a positive impact on the team. They have achieved. And if you do a sprint demo and it does go as well, and your product owner or your stakeholders are giving you a big thumbs up and they’re delighted with the work, that is a trigger positive momentum. If your manage a big PR, it even could put it on to that level. If you look at your burn-down chart for the team and it’s on track, or maybe it’s ahead of your schedule delivery days, all of that are potential positive triggers for the group. How do you actually build on that then?

Chris:

You’ve done your sprint demo went really well. And your team lead maybe there was an area that they wanted to investigate for the last couple of weeks but didn’t get an opportunity. You talk to your manager and say, “Look, this went really well. First, could we, could we do a spike into this specific area?” And your manager says, “Of course, yeah.” Your harness and the momentum at that point, the goodwill that’s around us and the team got this opportunity maybe to do a spike in an area that they’d love to investigate. So that’s a potential parallel missing the positivity and momentum.

Chris:

On the other side or negativity, so severity one bulb comes in on yourself for like, if you don’t get on top of that quickly, if you don’t stand the tide there potentially, that goes on for hours and maybe some days to negativity builds around the team that there’s severity one bulb in there. So really getting the group to put their shoulder to the wheel there and try and stop it in its tracks is very key, because of the rolling stone and it gets bigger and bigger. In software, it’s having the awareness of these things to happen and being able to pick up on that and either harness it or address it as quickly as possible.

Alexis:

Can you give me an example of one thing that really is building negativity and how you choose to address it? How you raised the awareness and the team to address it.

Chris:

That big bug coming in, right? So it’s not like we all look bugs in software. It happens. But if there’s not some resolution to that reasonably quickly, then the manager hears about it, the product owner hears, or most of the stakeholders, it just gets bigger. And have no, it’s not the team’s fault, but it’s the team’s responsibility to try and address that. Try and put some resolution in place such that can assess the underlying problem, if that goes on over time and it’s not addressed that increases the whole negativity increases around it. And that’s the same as conceding the score and maybe conceding the second score and another one. And then once it picks up that, as I said negative momentum, it can be very hard to stop. It’s the team lead or the manager or the engineers the group, and the team awareness. Let’s try and put a resolution in place as quickly as possible.

Alexis:

You mentioned in your background, in your sporting background, there were roles, like player, captain, coach, or manager, how does that relate to the roles in the software team? It’s probably very different, but maybe there are some similarities.

Chris:

Yeah. So I think that the player is your team member, right? So on the software side could be your software engineer, your QE, your docs person could be any of them team member. And I think the captain maps fairly clearly to the team lead. And then the coach manager side is kind of the engineering manager on the outside in a one sense or what I would say, I know from the sports side, we would have a term like teams win games, right? So it’s not really the management it’s the group, it’s the players and captain and in software, it’s that software team like it’s the engineers. They do the work, they release the software, they test the software, they ensure it’s of high quality. So I think that’s why the focus on the team is so strong, in sporting terms.

Chris:

And I think it’s heading that way as well on the software side. And the other thing is just to call out the captain concept there. In the sports side, yes there is a captain boss, successful sporting teams encourage leadership across the board. So they foster leadership. And how do they do that? They give ownership of, to a young player coming in and say, “You take the corners for the soccer team.” So they give them that ownership. So they foster leadership. It’s not just the captain leads. It’s everybody, if at all possible. And I think in the software side, it’s the team lead, or tech lead for the group, saying to an engineer, “Could you investigate this area and come back and talk to the group?” You’re fostering leadership there in the sense that you’re given the opportunity to investigate a new area.

Chris:

And then you’re asking them to come back and articulate the group. So you’re doing knowledge sharing as well. So I think a very clear overlap between what’s happening on the sporting side and on what’s happening on the software side. But I think again, really good team. It’s not about which hat you wear, are you a team member or your team captain? It’s about contributing to the goal of the team and what’s right for the group. And I think on the outside the manager, they are really like, they’re just facilitators. They’re ensuring that there’s no blockers in the way of the team. They have what they need to do their job and do it well. And that’s what you’ll find again, in the sporting side, the manager or coach really facilitates the team, once the team start to, once they really start to mature and become strong, they will drive a lot of it themselves.

Alexis:

You said, teams win games. I love it. But I feel that for a soccer team, it’s fairly easy to know when you win or when you lose, it’s fairly easy to identify your progress. The score is really clear for everybody. At least the results will be already clear for everybody. And you can measure the progress during the game. What happens for software team? How do you keep the score and how to make sure that we all agree what it means, what winning means?

Chris:

I think software is changing a lot. At least when I started working in software a good while ago, when I was that’s nearly more than 20 years ago, we were very much in that waterfall model. We started and we drawn a big plan as to what the project would achieve. And then we may be developed for months, months on end. Maybe even a year and then we’d go and try and test it all. And maybe at the end we find, “Oh, maybe this is not where we want it to be.” It was very difficult I think, to keep the score when the methodology was like that. Now I think it’s improving. I think we’re starting to deliver more frequently. I think that has helped certain teams now are starting to move towards more and more agile approach.

Chris:

They attempt to deliver maybe quarterly in a year or even some of them down to every sprint, which would be every two, three weeks. You will get checkpoints more frequently there. You can track them whether the team is, let’s say, winning or producing what the stakeholders are looking for with regard to, if you were in the waterfall approach, you might hit that issue until maybe six months or maybe 12 months on. So I think keeping the score on that was easier and software is in a sense, a young science towards other sciences. So I think it’s really made massive strides over the last decade, I would say. So that has helped a lot keeping the score now because there’re checkpoints, which are customer, or your stakeholders very frequently. So that’s a big help.

Alexis:

There’s one aspect that I don’t find exactly in the same way when I was thinking about the parallel between sporting teams and software teams. When we deliver more frequently in a software team, we have the opportunity to get feedback from our users and to know if what we are working on is the right thing. That feedback loop is interesting. In sporting teams, I’m not sure where is the feedback loop. Are the public or the fans the user of the game? Or how does it, how would you make the parallel between the two?

Chris:

The feedback loop on the sporting side actually happens very frequently and I would even leave the fans out of it to a degree. Yes, there’s feedback from the fans. Of course, if you’re successful or not. The feedback you’d want in the sporting world. Like if they play on say the weekend, when they train Tuesday, Thursday. After every training session, and I speak from experience here because I’m currently coaching. At the end of every training session, we would take 10 minutes talk to the players and say, “You done this well. I was impressed with…” You’re giving them very positive feedback there. Very frequently. You’re at least giving them Tuesday, Thursday feedback. On the negative side there if you want to, there was an issue often I would add in a challenge for them.

Chris:

Like if they can see the 10-3s I would say, “Can we reduce that? Can we get that down to six or under?” So sporting side, the feedback loop is very frequent actually. And when you’re in that environment, you’ll see that. It’s good on the software side that we get feedback from our stakeholders may be every three weeks. Maybe we could even do more within the team, within the group. What you’ll see the benefits of the feedback on with, from sporting side, you’ll see the player, reacting, the team reacting, reducing that number of threes. So maybe I think there’s a learning there in software that within the team itself, that’s okay. Maybe you don’t do it on your daily standup, but maybe your facilitation in another way in your say, three weeks sprint there’s feedback and saying this done, this was really good. That positivity is so important to the group. And I think we could harness that.

Alexis:

You introduced a lot of interesting concepts there. First of all yes, of course the sporting team are not performing every day. Even if they perform every weekend or every week, they will train more often than they perform. So that was the first thing that is an interesting learning probably for all teams. So let’s come back to that in a minute, but I noticed that when you speak about feedback after the training sessions, you nearly only spoke about positive reinforcement. And do you see that as the best way to provide feedback and do you see that happening in the software world?

Chris:

Early in my sporting career, if you went back, I think sports has changed to be honest, all you think that it was more negative feedback when I was younger in my career. I think it has changed massively. I’m not sure what exactly influenced that change, but it’s quite clear that reinforcing the positives, there’s more value. You’re dealing with human beings here. If you keep praising them, you don’t get anything back. If you try and highlight the benefits in what they’re good at and trow in the challenge, then I think that it’s to have that balance that you highlight the positives and also notice the improvements. That’s so important for any of the leading, either leading players, captain, coach noticing improvements and calling them out, and then adding in your challenge to bring them to the next level. We would always talk in the sports world about having smaller wins. It’s not about going out to win the championship. It’s about maybe improving a skill or being able to execute a skill more frequently. Positive reinforcement there brings value to the whole group. So I would say, definitely think that’s very important.

Alexis:

And if we look at what the software team is doing is the role of providing that positive reinforcement, providing that feedback that, “Oh, you done that really well.” Is it something that is the sole responsibility of the coach or the manager, or is it something that the team members the players could do themselves?

Chris:

Yeah, I think this is what the mature team that are successful and performing really well. You will see that it’s not just a manager. You have this shared awareness among the group. As I said, it doesn’t matter what hat you’re wearing in the group. You can say, “Alexis, that’s a really good job there, that’s very beneficial to the group what you’ve done.” So I think absolutely the very good team that’s performing well have a shared responsibility, not just for the work they do, but for being aware of the benefits others bring to the group and sharing that and calling that out. The responsibility lies with everybody. And it might just be that maybe you created some pipeline to test the software or something. And if I got a lot of benefit over that, just as a team member. Calling that out is really good, just that positivity within the group is massive I think.

Alexis:

Let’s come back to the train and perform part. I feel that the train and perform balance for sporting teams, they are performing from time to time and training a lot. And I feel that for software teams, they are performing all the time and not training at all. Do you have a different experience of that? And then how can we introduce more balance?

Chris:

When I originally started to kind of think through this whole thing, the angle was can software teams learn from sporting teams? I think in this scenario, I think the learning maybe go some way or the other way. And the example I gave here is that in sporting world, you could train for two weeks and maybe your game is coming in three weeks’ time. Sometimes you would go and play a challenge game. We played a game and you’d often hear the coacher or mentor saying after, “Hey guys, this has worked for your training session.” What the methods that’s common true there is that there’s more value to be got by playing rather than training. So I think the sporting world has some way some learnings there. The question then is have the software world, are they like they’re probably 95% performing while 5% training.

Chris:

One thing I would say is the learning that you could take from sport here is once the sporting team plays, and I know I’ve done this myself as a coach, you will see things in the game that you’ll say to yourself, actually, we need to improve somewhat there. Or I might see that player is very strong in certain skill or certain area or certain position. So my reaction would be the week after the training, I would organize the training such that I might try and improve maybe weakness that I saw, or I might say that, “Oh, this player’s really good in this position.” So I would restructure the training to see what that work again. So the training is very focused on the previous game. Now, how could software do that? Like I think the training that we do in software is, “Go do a course on NodeJS or Java or OpenShift.

Chris:

So it’s probably generic, but maybe we could focus our training better in smaller pieces to say that maybe the charts that we produce from the data that we gather in the system, maybe they could be better. Something very focused and small. Maybe there was a comment in a sprint review, maybe pulling the team together and focus in on how could we improve that the charting? Such that we get more value from the data we gather? So I think that there’re learnings both ways there that training on the software side could be a lot more focused for that team where as I said, I think there’re learnings on the sporting side too, that they need to play more and train less.

Alexis:

Yeah, it’s interesting. So we can learn from a formal training sessions and we can learn from the game we play. So what that means in the software world, even if the balance between training and performing is different we should intentionally learn from when we are performing. That’s what you say, in a way?

Chris:

Yes, exactly. Yeah. That’s where you learn more. And that’s where the comment that you’ll get in this. As I said, in that sporting analogy of the challenge game, the code saying this has worked five training sessions. And what they’re really saying, is the learnings that we’ve got here are so important that we wouldn’t maybe have seen in the training environment. So I think the software side, because they play so frequently, there’s continual learnings there and there’s checkpoints like our sprint review, et cetera, demos to stakeholders, there’s all the learnings there. And not even on the stakeholder side, even within the team dynamic that maybe some of the pipelines maybe not as automated as we would like. Smaller tweaks there could bring a big improvement and more automation could give us time to do other things. So there’s lots of opportunity to pieces out that with a small bit of focus training could reap our rewards.

Alexis:

So it’s interesting, you mentioned two different kinds of improvement, there’s improvement we can make on the product itself, on the results of what we are working on. An improvement we can make on our wealth working, on our tuning. So it’s even three aspects of it. Being intentional of seizing the opportunities to improve is something really important. How do you get to that mindset of having all the team that is really interested in working on those things? Interested in learning on improving?

Chris:

Like, I think the key is identifying clear value. We’re not doing something just for the sake of, “Oh, look, we’re trying to improve this.” It’s identifying clear areas where we can extract the value. So if we invest time, there’s value to be gone. If team members see that, then they’re a lot more inclined or a lot more motivated to put that effort in for improvement. That trying to identify value is of the product value that’s clear and the team are not the only people need to do that. Your product owner stakeholders, et cetera. So clear value is on the product side, clear value on the tooling, clear value in our process.

Chris:

So we don’t introduce process just for the sake of it. If we introduce some process that we get some value back, then the team will invest in general. But don’t just do things just because we’re seen to be trying to improve. Identifying the value, getting the team in that mindset. If you think there’s value there, let’s discuss it. Let’s have the discussion to see. So I think that’s what you’re trying to get their mindset thinking that way is to say where’s the value to be out here.

Alexis:

So in reality, they own improving the value on all the different aspects. So they own the process. They own the tooling. They own the product as a result. They can really work on the value on improving the value because they own those benefits too.

Chris:

Yes. I know at the start I mentioned ownership and responsibility. Successful teams feel responsible for the group or for what they’re trying to achieve or in the software world for the product they’re trying to build, for the process that they go through that helps them build that product or helps and release that software. That sense of ownership is absolutely key. And if you don’t have that, if you’re trying to impose teams on the team and they don’t feel that they’re responsible and own, then it’ll be different. But if they take up the mantle and seize the ownership, then again, I go back and say on the sports side, you’ll hear that the best teams are what our player driven. So the team drive them what that is, is responsibility and ownership. And they’re taking the lead. It’s the same with software. If you have that taking the lead on the product, helping steer the direction with the stakeholders, ensuring the process facilitates them well. If you have that in place, that team would be successful.

Alexis:

When clearly the team is not in short of some aspects and that’s outside of the team that maybe decisions are made or whatever. And you mentioned the stakeholders and working with the stakeholders to do it. So it means, yes you can earn your future in a way that you will, of course, work within your team to do something, but you will also work outside of your team to influence the decisions that are made outside of the team.

Chris:

Yes. I think it’s massive in the software side, because you do have the engineers working at the coal phase. So they understand the products or the subsystem really well. So I would envisage them as key contributors or key stakeholders to the direction of that subsystem or product. Obviously, they need to work with the more business stakeholders, with the architects so it’s a bigger group. But they have a big say. And I think another aspect here comes to the fore is the team need to be able to communicate that at the right level. So sometimes you’ll find engineers will talk technical. So it’s another skill set of a very good team that they can abstract that value kind of away from the technical details, if necessary, and to pitch it to the other stakeholders, to say, “Here’s an avenue or here’s a direction that could be worth considering,” Such that the stakeholders can grasp that.

Chris:

That it’s not entangled in technical details, that they can see the value. So that’s another part the team can, should be able to play that they communicate and articulate at the correct level, such that their view is taken into consideration at the direction of the product.

Alexis:

This is really an important one. I remember working with several teams and there was teams I realized in my personal reflection that I didn’t really want to work with them. I didn’t really want to talk with them. And there was also teams that I was really happy to work with them, to engage with them, to try to listen to what they were doing to try to help them. And I was thinking why it’s happening. So I was thinking maybe it’s the people, maybe there are some seeing that. And I realized, no, it was not that. There was teams when I was discussing with them, I was unable to understand what they were discussing. Everything sounded so complicated that I was unable to understand what they were trying to achieve. So I felt excluded and I was not able to contribute to help them. And there were teams, I had that impression that when they were explaining something, I was really smart.

Alexis:

I was able to understand everything. And I realized that it was not the technology. They were working on the same product that was just pieces of the same product. So it’s not the complexity of the technology. It was the ability to explain to outsiders what they were trying to achieve and to put it in simple words enough. So I could understand where I could play a part. And that was really incredible. And that was just a few people that were able to do that, who will care about doing that in a way. So I bet they understood that if they want to reach to external help, that was already good way to do it.

Alexis:

It took me some time to realize what was going on there at the beginning. I was looking ready for personal relationship. When you have a good fit with someone. And I realized it was not that it was exactly that ability to communicate at the right level. They were in a way, probably communicating with me at a more easy level. They were, their technology for them is just for me. So I would be able to help them. That was an interesting realization at some point.

Chris:

I think it’s very important for the software team to have that skill set. It may not be all the members of the team have that. They definitely need one, two members that can understand the business schools and be able to meet in the middle to say, “Technically, we can do this, and I know your business ask is this.” And to kind of talk in that medium, in the middle of such that we have full engagement with the business side of the house. The technical side is portrayed in an understandable way. And often I think, because I played the role as a business systems analyst and product owner, I feel the role is more play them. But I think that’s absolutely key that if the communication’s lost there, because they talk different languages. If you go down and sit in your daily stand up with the engineering team, or if you sit in maybe product roadmap discussions with the business unit, they could be talking about the same product, but are very different. Even terminology, language, everything. So being able to bridge the gap between both is I can really big scale for the team itself.

Alexis:

Yeah. You mentioned that you worked in the Telco world. And my first encounter with some people in Telco. I think after the five, the five first minute there was, there were so many acronyms they mentioned that I was totally lost. And I said that “Okay, I have a problem that I’m totally foreign to your world. I am not able to even think I will be able to engage with you.” And one of them said, “Oh yeah, that’s not a problem. In reality, it’s really simple. Let me draw a simple picture to you so you will understand the basic concept of all that.” And he drew a simple, he made a simple drawing about where you have an antenna or how it’s called. And then you realize that you are able to understand, you can see your mobile phone is there, that’s your internet at home is there. And that’s how it works. And then that’s how it goes back in the network. And that’s all those things.

Alexis:

And then he put all the acronym on it and I said, “Oh yeah, okay. I understand how it works.” And now when there was an acronym mentioned, I was able to connect that with the big picture he drew on the white board. And that was so much easier. And he did that in five minutes. And I asked him about that. And he said, “You are not the first one that is trying to come into our world. So I’m really good now at doing the drawing because I did it probably hundreds of times.” That’s absolutely not a problem. And I totally understand that you need it. Yeah. We need those kinds of people that really care about being inclusive of other people in teams. That was really an amazing experience for me too, to have that opportunity.

Chris:

Teams that don’t want to say controlled or destiny, or at least to kind of bring their team and their product in the right direction. We actually realize that they need to be able to do this. They need to be able to communicate and articulate at the right level with other stakeholders. So you’ll get the very good teams need and become aware of that very quickly. And then speak the language that allows that to happen. That their voice now is heard and understood. For another aspect there, I think that’s worth calling out is in the sporting world there’s a term like play to your strengths. Sometimes maybe in the software world. Sometimes we focus a little bit on where we hear a weak there. Like if you do your retro after your sprint or after your release, you’ll say like, you do look and say, look, this went well. But it often drifts towards, this didn’t go that well, this needs an improvement, which is perfectly fine.

Chris:

What you would find in the sporting world is they will, they’re constantly saying “We’re good at this. We have speed in our attack. Let’s try and play that game. So let’s try and use the strengths we have.” That’s maybe another learning that software could take is that understand the strengths of the team really harness them by all means improve weaknesses. A lot of the time, the strengths of the group, if somebody is really good. Maybe developer, Java developer, no, Java developer, should you have them kind of maybe architecting, maybe not. That their strength is in development. And normally what you’ll see is that their strength is there because they enjoy use, I think software could definitely look at that side somewhat more that really harness your strengths and even build on them.

Chris:

If you’re good at something, why not, you can get better. So I think what you’ll see is sport do that a lot. Sport and teams, they would even use the term like, they want to play the game on their own rules. And what they’re really saying there is, “we want to play a real physical game, or we want to play a really fast game.” Because that’s what they’re good at. Once a problem arises in a sporting team like that. One of our defenders is struggling because their opposition are too physical. What will happen is the coach will go and find one of their physical player to bring them across, to kind of address the issue, playing to your strengths, making them all of them and building on them is something maybe that software can incorporate maybe more.

Alexis:

Yeah, this is a very good one. And you think that we can really play off strengths and overcome or weaknesses playing our strands.

Chris:

I think there’s more to be got. There’s more value to be extracted. Those are strengths. Don’t get me wrong. You should always try and address your weaknesses by all means. But I think sometimes we don’t have that balance that the weaknesses get more attention. And we try and improve that, which is all well and good. But maybe there’s a different solution. Maybe we have other strengths in the team that we could solve that wish for the group as a whole to try and understand that. Do we have the strengths in this group to address whatever problems there, or to enhance some things? So I think that keeping that in mind is important and there’s more value to be extracted from your strengths than maybe we are doing currently.

Alexis:

It’s not an individual realization. It’s a realization as a team. So you are several strengths in the team and maybe you are missing some. And so you will maybe try to find that outside of the team, external support, or in your next hiring session, you will focus on specific strengths that you are looking at, that you miss in the team. So it’s not just looking at the individual and hoping that you will have perfect player that have all the strengths possible in the world. That’s looking at as a result, how the team is composed and what do you have in the team? What kind of strengths do you have already?

Chris:

Yes, exactly. And that’s the awareness of the group. The leaders in the group, at least the senior members should have a really good feel for the skill sets. And it’s not just the technical skill sets. One other thing we have noticed, in the software side actually, sometimes a team with a member who has a kind of teaching acumen or a knowledge sharing skill, some team members might be very kind of focused on getting their job done, where others might have a great skill to share knowledge. That’s a great skill set in the team, because if you bring in somebody in a new member having that kind of teacher/coach-like skill in your group, you can pair them up. So bringing somebody up to speed very quickly. So there’s lots of skills you can harness, but the awareness that they’re there is the first step.

Alexis:

Thank you very much, Chris, for sharing all that today. Maybe one additional last word?

Chris:

Yeah, I think it’s kind of a cross-pollination of ideas from different domains can often be very rewarding. And I think, I suppose I should maybe do the reverse and say what sports can learn from software. The team is the fundamental piece and the fundamental building block. And I do think software has absolutely realized that and are investing in that. And it’s great to see, and I think that’s a harness thing that positivity and momentum is beneficial for everybody. And if you get that team functioning well, everything else falls out of that. I think investment in the team culture team dynamics awareness is so fundamental for all enterprises, not just software. People are really now at this time, fully aware of the impact of good, strong, healthy, functional teams. So it’s great that we’re even having this conversation I think Alexis, and I appreciate the time for us to have this chat.

Alexis:

Thank you very much, Chris. I learned a lot today. I really enjoyed your parallel between sporting teams and software teams and yes, you’re right. Probably all teams. I really love that level of awareness is there. And I hope it will reach more people in the world. Thank you very much, Chris.

Chris:

Thank you.

Alexis:

Thank you for listening to this episode of Le Podcast. Go to alexis.monville.com for the references mentioned in the episode, and to find more help to increase your impact and satisfaction at work. Drop a comment or an email with your feedback, or just to say hello. And until next time, to find better ways of changing your team.

The music is Funkorama by Kevin MacLeod (Creative Commons CC BY 4.0)

The picture is by Danylo Suprun.

Here is the transcript of the conversation:

Le Podcast – Season Two

Le Podcast – Season One