Monday 30 August 2010

It's a Team Game

Walking home the other night I happened to take a detour through Pencoedtre playing fields, which was home to the Barry Wolves football (soccer) team that I played for as a kid and it got me thinking about the team's ethos and how it could apply to teams in general.

Whereas pretty much every other team in the league had strict rules about passing trials in order to be able to join them, identified their stars who would play no matter what and would leave other kids on the bench on match day, Barry Wolves were different.  Their ethos was:

  • No trials
  • You turn up for training, you play on match day
  • You don't train, you don't play on match day - no matter how good you are
  • You don't always have to be goalie if you fancy trying centre forward
  • No stars, no blame - you win as a team, you lose as a team
We weren't the best team in the league, but the inclusive nature of the team meant that everyone felt involved, there was a real team spirit and we enjoyed being part of the team.

How could this apply to teams in general?

Give People a Chance
You don't necessarily have to make someone prove themselves before letting them join a team.  If they're enthusiastic then let them prove themselves as part of that team.

You Don't Learn from Being on the Sidelines
If someone is putting the effort in to learn and practice skills in their own time or outside of an official project then give them the opportunity of working on an official project as they will learn far more on a real project and "being in the game".

It's a 2-way Street 
Everyone should be working on developing and improving their skills and if someone isn't doing that then they have no right to complain about not being given a role on a project.

Mix it Up
Just because someone has been a developer it doesn't mean they can't have a go at being a system administrator or a UI designer if they want to.  You can learn a lot from trying different roles and giving system administration a go for a while can make you a better developer.

Never Point the Finger
If a project fails it's because the team failed and not because of any one person.  Sure someone may have dropped the ball on something, but a team will help that person pick it up to keep the project on track.  If you start pointing fingers you fragment the team and increase the risk of failure on the next project.

What I'm trying to say is being involved in team sports as a kid can teach you a lot, but having experience of teams that like to do things differently teaches you even more.

3 comments:

Dave Hay said...

Andrew, good points all, lessons learnt whilst young are longest remembered, regards, Dave

christian said...

Nice read, Andrew.

Chris "Tony" McCarthy
(Cowbridge U-14s).

Andrew Frayling said...

Thanks for the comments. It was very nostalgic walking through the old "battle ground" :-)