What Software Teams Can Learn from Sporting Teams, with Chris Foley

Alexis:

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

Chris:

Hi, Alexis. Thanks for having me. My name is Chris Foley, principal engineer at Red Hat — about 23 years now in software. I started with Ericsson out of college working on 3G management systems for five or six years, then moved into telecoms research for about six years on European Framework 7 projects. I went back to industry in the financial domain doing requirements gathering and business systems analysis, then back to telecoms with a company called Aircom and worked as a senior engineer and team lead in distributed antenna systems. Then to Red Hat, involved with the mobile product, and now in an engineering improvements role inside the Cloud Services department.

Alexis:

Very interesting and diverse background. We're here today because we had a chat about sporting teams and software teams. I'm really deep into what makes a team a team — what makes a group of people really increase their impact and satisfaction. You told me there's probably things we can learn from sporting teams about that. I'm curious about what it is and how it works for you.

Chris:

A little background on my sporting life: I started playing sports from the age of four or five. I was heavily involved in the Gaelic games here in Ireland — hurling and football — and played soccer. My forte is predominantly team sports, even though I played individual sports too. I've played as a senior player, as a captain, coached juvenile and adult teams, and managed teams. I've been lucky to be involved with successful teams — but you also learn more from your defeats than your victories.

There are many aspects that make a good team. The best teams have a lot of clarity in their role and in what they're trying to do. There's an awareness across the group of what each individual brings. That's very evident in successful sporting teams.

If we look at software now, we're creating very cross-functional multi-purpose teams — they don't just develop software, they deliver it, write the docs, test, architect. We're trying to share that responsibility, which is very positive, but ensuring we keep clarity within the group is just as important. With clarity of role comes responsibility and ownership. That's a fundamental piece.

Alexis:

Very important. As we evolve to more cross-functional teams, your role is no longer the colour of your box on the org chart. We need to clarify the roles and make the expectations explicit. What else do you think connects sporting teams and software teams?

Chris:

One piece that's very evident on the sporting side but maybe less so in software is the concept of momentum. In a sporting game, when one team scores a goal, their confidence rises, their energy rises — momentum has been triggered. They often go on and score a second goal. That's positive momentum.

There's also negative momentum: the team that conceded the goal. How they react defines them. If the negative momentum builds and they concede a second, the game is potentially over. The key is knowing what triggers it. In sport the goal is a simple trigger. What does that look like on the software side?

Alexis:

I'm curious how we can apply that — how we can spot the triggers, build on the positive, and avoid a downward spiral.

Chris:

The triggers are there in everyday software life. A successful release after a sprint, a sprint demo where the product owner or stakeholders give a big thumbs up, a big PR landing, a burn-down on track or ahead — these are all positive triggers.

How do you build on it? Maybe there was an area the team wanted to investigate but never got to. You talk to your manager and say 'this went really well — could we do a spike into this area?' You harness the goodwill that's around.

On the negative side, a severity-one bug coming in. If you don't get on top of it quickly, the negativity builds. Getting the group to put their shoulder to the wheel and stop it in its tracks is key — because it gets bigger and bigger. In software, having the awareness of these patterns and being able to harness or address them as quickly as possible is what matters.

Alexis:

You mentioned roles in your sporting background — player, captain, coach, manager. How does that relate to roles in a software team?

Chris:

The player is your team member — software engineer, QE, docs person. The captain maps fairly clearly to the team lead. The coach or manager is closer to the engineering manager. On the sports side we have a term: teams win games. It's not the management — it's the players and the captain. In software it's the same: the engineers do the work, release the software, ensure quality.

On the captain concept — successful sporting teams encourage leadership across the board. They foster leadership by giving ownership: 'You take the corners for the soccer team.' It's not just the captain who leads. In software, the team lead saying to an engineer 'could you investigate this area and come back and talk to the group?' fosters leadership and shares knowledge.

In a really good team it's not about which hat you wear. It's about contributing to the goal of the team. The manager really facilitates — ensuring there are no blockers, that the team has what they need. Once teams mature, they drive a lot of it themselves.

Alexis:

I love 'teams win games'. But for a soccer team, it's easy to know when you win or lose — the score is clear. What happens for a software team? How do you keep the score?

Chris:

Software is changing a lot. When I started, more than 20 years ago, we were very much in the waterfall model — draw a big plan, develop for months, then test at the end and find out 'maybe this is not where we want it to be.' It was very difficult to keep the score then.

Now teams are starting to deliver more frequently — quarterly, or every sprint of two or three weeks. You get checkpoints more frequently. You can track whether the team is producing what stakeholders are looking for. In waterfall you might not hit that issue for six or twelve months. Software is a young science compared to others, and it has made massive strides over the last decade. Frequent checkpoints with customers and stakeholders are a big help.

Alexis:

When we deliver more frequently, we get feedback from our users and know if we're working on the right thing. In sporting teams, where is the feedback loop? Are the fans the users of the game?

Chris:

The feedback loop on the sporting side actually happens very frequently — and I'd leave the fans out of it to a degree. If they play on the weekend, they train Tuesday and Thursday. At the end of every training session — and I speak from experience as a current coach — we take 10 minutes and tell the players 'you did this well, I was impressed with…'. Very positive, very frequent feedback. On the negative side, I'd add a challenge: if they conceded ten threes, can we get that down to six?

It's good that on the software side we get feedback from stakeholders maybe every three weeks. But maybe we could do more within the team itself. The benefit you see in sport is the player reacting and reducing the number of threes. There's a learning there for software: positivity is so important to the group.

Alexis:

When you speak about feedback after training sessions, you nearly only spoke about positive reinforcement. Do you see that as the best way to provide feedback?

Chris:

Earlier in my sporting career it was more negative feedback. Sport has changed massively. Reinforcing the positives has more value — you're dealing with human beings. But it's a balance: highlight the positives and notice the improvements, then add a challenge to bring them to the next level. We always talk in the sports world about smaller wins — not winning the championship, but improving a skill or being able to execute it more frequently. Positive reinforcement brings value to the whole group.

Alexis:

And in a software team — is providing that feedback the sole responsibility of the manager, or something the team members can do themselves?

Chris:

In mature, successful teams it's not just the manager. There's a shared awareness. It doesn't matter what hat you're wearing — you can say 'Alexis, that's a really good job, that's very beneficial to the group.' Maybe somebody created a pipeline that helps everyone — calling that out is really valuable. The responsibility lies with everybody.

Alexis:

Let's come back to train versus perform. Sporting teams perform from time to time and train a lot. Software teams perform all the time and barely train at all. How can we introduce more balance?

Chris:

When I started to think about this, the angle was 'can software teams learn from sporting teams?' In this scenario, I think the learning maybe goes the other way too. In the sporting world, after a challenge game you'll often hear the coach say 'this was worth five training sessions.' There's more value to be got from playing than from training.

The question is: are software teams 95% performing and 5% training? One learning from sport: once a team plays, you see things in the game and reorganize the next training around them. The training is very focused on the previous game.

Now, how could software do that? The training we do tends to be 'go do a course on Node.js or Java or OpenShift' — pretty generic. But maybe the charts we produce from the data we gather could be better. Pull the team together and focus on improving the charting. The training on the software side could be a lot more focused — and on the sporting side maybe they need to play more and train less.

Alexis:

So in software, even if the balance is different, we should intentionally learn from when we are performing.

Chris:

Exactly. That's where you learn more. Sprint reviews, demos to stakeholders — there's continual learning. Even within the team: maybe pipelines are not as automated as we'd like; small tweaks could bring big improvement and free up time. Lots of opportunities, with a small bit of focus, where training could reap rewards.

Alexis:

You mentioned different kinds of improvement — on the product, on the way of working. How do you get a whole team into a mindset of being interested in improving?

Chris:

The key is identifying clear value. We're not doing something just for the sake of 'we're trying to improve this'. If we invest time, there's value to be got — on the product, on the tooling, on the process. Don't introduce process just to be seen to be improving. Get the team in the mindset of asking 'where's the value here?' If you think there's value, let's discuss it.

Chris:

Successful teams feel responsible for what they're trying to achieve — the product, the process, the release. That sense of ownership is absolutely key. On the sports side we say the best teams are player-driven — the players take the lead. It's the same in software: helping steer direction with stakeholders, ensuring the process facilitates them well. If you have that, the team will be successful.

Alexis:

So the team also needs to influence decisions made outside the team.

Chris:

Yes — engineers work at the coal face, so they understand the product really well. They're key stakeholders for the direction of that subsystem. And another aspect comes to the fore: the team needs to communicate at the right level. Sometimes engineers talk technical. A very good team can abstract the value away from technical detail and pitch it to other stakeholders so they can grasp it. That's another part the team should be able to play — communicating and articulating at the correct level so their view is taken into account in product direction.

Alexis:

I remember teams I didn't really want to work with — not because of the people, but because everything sounded so complicated I couldn't understand what they were trying to achieve. And other teams working on the same product who, when they explained, made me feel smart. I could understand and contribute. It wasn't the technology — it was the ability to explain at the right level.

Chris:

It's very important for the software team to have that skill set. Not all members need it, but you need one or two who can bridge the business and the technical worlds. Often, daily standups and product roadmap discussions are about the same product but in completely different languages. Bridging that gap is a really big skill for the team.

Alexis:

You worked in telecoms — my first encounter there was so many acronyms in five minutes I was totally lost. Then someone said 'it's really simple, let me draw a picture' — antenna here, your phone here, internet at home here — and put the acronyms on the drawing. In five minutes I understood. He told me 'I've done this hundreds of times.' We need people who care about being inclusive of others.

Chris:

Teams that want some control of their destiny and product direction realize they need this — to communicate so their voice is heard.

Another aspect worth calling out: in the sporting world there's a term, 'play to your strengths'. In software, retros often drift toward what didn't go well, what needs improving — which is fine. But sporting teams constantly say 'we're good at this — we have speed in our attack — let's play that game.' Understand the strengths of the team and harness them. By all means improve weaknesses, but a lot of the disproportionate value comes from your strengths. If somebody is a really good Java developer, should you have them architecting? Maybe not — their strength is in development, and usually their strength is there because they enjoy it.

Alexis:

So we can play our strengths to overcome our weaknesses.

Chris:

There's more value to be extracted from strengths than maybe we are doing currently. You should always try to address weaknesses, but the balance often tips too far that way. Maybe other strengths in the team can address the issue. Keep that in mind.

Alexis:

So it's a team-level realization. You may have several strengths in the team and miss some — find that outside the team, or focus your next hire on the missing strength. Not just hoping for a perfect player who has every strength.

Chris:

Exactly — and that's the awareness of the group. The leaders should have a really good feel for the skill sets, and not just the technical ones. Sometimes a team member has a teaching or knowledge-sharing skill — that's a great asset. Pair them with new joiners and you bring people up to speed very quickly. Lots of skills to harness — but awareness that they're there is the first step.

Alexis:

Thank you very much, Chris. Maybe one last word?

Chris:

Cross-pollination of ideas from different domains is very rewarding. Maybe I should do the reverse and ask what sport can learn from software. The team is the fundamental building block, and software has absolutely realized that and is investing in it. Harnessing positivity and momentum is beneficial for everybody. If the team is functioning well, everything else falls out of that. People are really now fully aware of the impact of good, strong, healthy, functional teams. Great that we're even having this conversation — I appreciate the time.

Alexis:

Thank you very much, Chris. I learned a lot today. I really enjoyed your parallel between sporting teams and software teams — and probably all teams.

Chris:

Thank you.

Alexis:

Thank you for listening to this episode of Le Podcast. Go to blog-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. Until next time, to find better ways of changing your team.