3 min read

Soccer as a metaphor for software development teams

Soccer as a metaphor for software development teams

I'm sure I'm not the first person to think of software engineering teams as mini soccer (or 'football' for my readers outside of Canada and the US) teams given some of the dynamics that exist within engineering teams are the same ones that you see playing out on the pitch.

I thought it'd be fun to expand on these dynamics and how certain positions in soccer map to roles within an engineering team.


When a soccer team needs to switch the play or they're coming under some pressure from the opposing team, they can pass it back to the defense so that the ball can be moved across the field and pushed forward when there's an opening.

One example of how defense can change the momentum of a play

In a software development context, this can look like the team is coming under pressure from deadlines and competing priorities. When this happens, some work is usually 'passed back' to managers (engineering and/or product) so that it can be re-prioritized, moved to a different team that has the bandwidth to do the work sooner, or descoped entirely from a project to give the team space to build momentum in the areas they want to make progress in.

If something unexpected manages to sneak by the team (say, unexpected complexity in a project that another team is working on that pushes back the delivery dates of multiple projects that depend on it), then that's where the software engineering equivalent of a 'keeper' comes in.

Keepers are the final line of defense in soccer, and block all the shots that manage to sneak past the defense.

Kailen Sheridan from the Canadian Women's Soccer Team

They have a decent view of plays as they unfold, see where there might be weak spots, and organize the team to cover those spots. When the team is in possession of the ball, they help bring awareness to opportunities in the offensive play.

Managers and senior engineers tend to play this role as they organize not just the team they work in, but coordinate with other teams and managers to ensure that things get delivered on time. They also allow for the exploration of new opportunities within the business by the engineering organization.


Midfielders are play-makers, helping create and build up opportunities, and can provide an anchoring presence for the team.

They may help push the momentum forward and score or provide an assist, or they can track back and help bolster the defence when pressure against the team intensifies.

In a software engineering context, 'scoring' could look like shipping a feature or a hotfix, and while technical leads are an obvious role that translates to what a midfielder does, any engineer who often helps set others up for success or who often has a measure of foresight into what the team will need in the future and starts organizing the team in that direction is a 'midfielder' on their team.


Engineers who are given a particular task or goal, and whose job it is to take it and run with it until they complete it in a tunnel-vision kind of way - these are your forwards.


Forwards in football are set up for the most success by being 'fed the ball' by one of their teammates inside an open space on the opposing teams' side of the pitch that provides them with a scoring opportunity.

In a software engineering team, I see this dynamic in the form of clear requirements and expectations of a project as well as the autonomy to complete their goals as they see fit within the parameters given to them. Engineers in this 'forward' capacity may not have as many responsibilities outside of the project (such as helping conduct interviews) and can give their full focus and attention to the project they've been assigned to.

Ambiguous requirements are similar to being given the ball in a difficult area on the soccer pitch - your forwards might be able to do something with it but it will be more difficult and might require a bit more time to break through.

And that's it! It's not a perfect metaphor by any means as engineers often float between various 'positions' as needed, but it's one that I enjoy using from time to time to help explain some dynamics that I see within teams that I work in.

Enjoy this post? Subscribe to be notified when I publish new content!