31 May 2009


Alan Tsuda writes a blog post observing team behaviors. Are all groups of people teams? Not unless they have a common goal, and even then, not always.

Somewhere else (It was at JB's practical analyst) recently I read about how project teams are often not really teams as they don't get the chance to establish common values and learn to work together.  Instead each individual contributes in his or her own technical area and hopes the project manager has developed a coherent integrated plan.

Maybe.  Maybe longer projects do form as team.  This has been my experience in most cases.

But Alan's comments are about teams acting as a group to overcome common problems, and I do see groups who are nominaly teams, but where individuals will sit back and watch their
'team mates' struggle and potentially fail at their task.

(In my team we are constantly trying to kill this behaviour, but it's hard.  Those individuls have to want to change.)

Alan's post got me thinking about how to plan for change.  He led me to trust and competency as two key issues.  I put up some ideas below.

In this model you see two dimensions of technical capability and trust as drivers for teamwork.  If you have both, then your job will be to help the team optimsie it's performance.  If the team is lacking on one dimension but has the attributes of the other, you'll work with the team on enhancing those weaker attributes.

If your team has poor technical capability AND a low level of trust, congratualtions: you have problems.  How do you get out of this quadrant as quickly as possible?

If the secret of 'team success' lies in trust and competence then the fastest way out of the bottom left quadrant is to hire in leadership and talent.  Naturally your best hope is to hire leaders who have technical capability.  They don't always come together, and depending on your local labour market and your budget this may be a challenge.

(A funny thing about tough economic conditions is that finally there are penty of great staff avialble and affordable out there, but many organsiations have implemented a hiring freeze, so you still can't get them.)

So we my have to look for other solutions to hiring in help.  One  option put forwad by one of my team members was for everyone to go home one day and have a think about why they have signed on to this team. His question was "If you are not committed to our success, why are you here?" 
Another pathway to better teamwork may be a series of small steps.  You may strike a blow for trust by introducing some team events - pizza for lunch, co-location, drinks, whatever.  Compliment this with things like training or pairing team members on tasks.  Step by step they can build themseleves into a team rather than just a group.
Another pathway may be to build a strong team culture.  I emphasize this at the team level, rather than the organsiational level.  You want the team members to define themselves at work primarily as a member of your projet team.  Their sense of purpose and achievement should be tied to the project's outcomes.

These are just a few ideas thought up on a Sunday afternoon.  Maybe you should hit all these approaches at once. And there are others also.

If you have read this far then this topic probably interests you.  Maybe you have some experience in this area?  What are your thoughts?


  1. Wow, that's a great set of diagrams. I'm going to have to think about them some more.

    My first reaction was that fixing trust has to come first. Maybe that's because I tend to operate in an environment where most people are technically competent and hesitant to trust.

    And then I thought "well no, improving trust without enhancing competence doesn't really make much sense." I guess the ideal approach is the zig-zag, simultaneous improvement path.

    Like I said, I'll have to think about this some more.

  2. Dan

    You are right.

    Trust is the place to start, but it isn't a finite border is it?

    An example is someone who find themseleves out of their technical depth; To be accepted by their eers as a team member they'll need to own up to their shortcomings, but then they'll also have t _visibly_ make an effort to impre that technical shortcoming.

    Like so many things, it is an iterative process.