Build the team. Keep the team.


I was in a meeting yesterday which was actually quite enjoyable as far as meetings go. Lots of important topics were brought up, but one of them I felt more important and resonated harder with me than the others.

This particular topic centred around the notion of product teams; a team that is assembled and hopefully through a life of one or more years builds a series of products. The team structure doesn’t change to a great extent and in lots of circumstances it can actually stay the same. The thing is, there was actually quite a bit of negativity around this idea which I found very confusing. Sure, some views I can understand who’s immediate responsibility isn’t at the coalface, but there were others there who should know better from experience.

You see, in lots of large organisations engineers, product managers, UX designers, DevOps etc are thrown into a thing called a ‘resource pool’. Yes, I know I shudder at the word too. And from this mythical resourceful pool are born robot soldiers from the future. OK, so I’m lying about that bit, but I’m trying to emphasise the fact that by using this outdated ‘resource pool’ concept you’re actually treating the person as a cookie cutter constant. An automaton that given a series of distinct inputs will produce a known set of known outputs. This we all know is very wrong and yet it is still readily supported in so many, many organisations.

The first time I encountered this notion was back in my dot com days as an engineer working in what was termed an e-consultancy. Basically, and e-consultancy was a code word for a large agency that would hire lots of highly skilled people to sit on their ass for weeks on end, just so that the sales guys and gals could have pissing matches with other agencies when tendering for business. “We’ve got 200 engineers all trained in the latest Java blah blah”. You’d turn up on a Monday and find out you’d been assigned to some CRM project sitting next to a clueless Silverstream (remember that damn awful joke of a technology?) consultant who was there just to make up the numbers promised to the client.
Since then, I’ve constantly had a bitter taste in my mouth to the resource pool method of pipelining people. Don’t think though that this is the only reason why I dislike this methodology. We’ve all heard the project manager joke; If it takes 9 months for a woman to make a baby then surely if we have 9 women we could make a baby in 1 month.

The joke isn’t in good taste, but therein lies the rub. We’ve just taken something that is a very human and emotional aspect of peoples lives and turned it into a cold baby making production chain. I’m often asked by people in senior management, usually the founder of a company what is the most challenging technical problem I’ve faced. I’ll often looked back confused. If we’re all honest with ourselves the biggest challenges we faced haven’t been with technology. They’ve been with people. We’re such complex creatures that we’re very hard to figure out. Every day we see new books and articles published describing a new understanding in the human psyche.

Lots of companies take such great care in assembling their teams. “We only hire the best” you’ll often hear. But then once that person in hired, they then put them into a bucket. Like a crab waiting to be made into someones lunch. Randomly picked out to fulfil someones crustacean appetite. Teams are far more complex though. They go through several distinct phases of both learning and social aspects. With a good team being able to successfully build new products or features in less time with better quality than one that was just thrown together yesterday.

So, it’s sad to see great functioning teams disbanded at the end of projects. Dropped into a resource pool and again dropped into another team. Most often those teams they’re dropped into have already been together for several months if not more, leading to feelings of being the outsider in a lot of cases while the rest of the team learns to build trust in this new individual. We all know that when a new team is put together you’re going to see a drop in productivity due to a number of factors:

  • Finding the correct level of social interaction between members
  • Understanding each others strengths and weaknesses
  • Understanding each others personal quirks
  • Understanding the best ways of individuals working with each other
  • Discovering hidden strengths or needs that weren’t originally evident at team inception
  • Understanding the best levels of communication and frequency

When the team overcomes the above we say that the team has a flow. This can sometimes take weeks if not months in some cases and yet we’re constantly doing this to teams again an again. And all this time accepting the associated problems again and again.

Of course there is the argument that not all projects require a person with skills X or Y. If we’re just building an API why do we need someone with front end skills. Now I see two problems with this argument. The first being that each project we work on is a special snow flake with special needs that require a specific set of skills. Ask anyone who’s been in the industry long enough and they’ll tell you that 80% or more of services that get built are most often simple CRUD style applications. Sure, they might have more complex user interaction, security requirements etc. But most teams consisting of full stack or front/back end specialist should be able to get the job done the majority of the time.

The second problem I have with the above argument is the idea that project pipelining should be done at the individual level rather than the problem domain/team level. Teams as they work together gather a huge amount of domain knowledge that quite often gets thrown to the wind at the end of the projects life cycle, but which could easily be re-applied to other areas. By utilising the combine skills and knowledge of a team, we should be able to bootstrap projects faster. Kick off discovery phases with ease and bypass the common pitfalls often found in that projects business area. So you see, when we do pipelining at the granular level of the individual we’re accidentally looking that the problem from that of a resource, the problem we should be actively trying to avoid.

Now, you’re probably wondering what to do about the other 20% where not only do the needs change between projects. Well then that’s where the concept of self organising teams comes in. It’s definitely not a new concept and has been successfully used in lots of companies that value autonomy not just within the individual but also within the team. The idea that it’s the teams responsibility to recruit new members and current members are able to move/be recruited by other teams. I’ve actually implemented similar ideas in a few places and have always tried and push a lot of management back down into the teams themselves in order to keep the hierarchy as flat as possible. I won’t say that at first this idea is always welcomed with open arms. Some people are so used to years of entrenched hierarchy that it’s actually quite hard for them to adapt. Others use hierarchy as a way to disguise their own personal weaknesses so will fight passionately to keep the status quo.

I’m hoping that I’ve put forward a well reasoned enough argument on why more effort should be put into keeping teams life cycles not intertwined so heavily with that of the individual projects they’re building. Other than the productivity aspect, I think we can all agree that long lived teams have less churn. Not just within the team itself, but also the organisation as a whole.

Filed under: company culture, teams, tech
Jonathan Conway

comments powered by Disqus