Cross-Functional People

This piece was originally published at: meheleventyone.com

Cross-functional people AKA T-shaped people or Generalizing-Specialists. The idea that as well as a deep understanding of one subject you want someone with a more general understanding of many others as well. The concept is not new but its quite hard for people to take on board as we live in a culture that raises us to value specialization. Even in education people are pushed further and further into their own little box until a fresh faced person pops out who has “this is my specialty” emblazoned into their mind. The problem with this approach is that it sets up boxes that people are put into based on their label. Even if a team is cross-functional with a mix of the specializations required to build a product people are often trapped in their ‘specialization box’ and this can manifest all sorts of problems:

Slack Time - You have a workflow defined by specializations: The designer will design the stories you have in this iteration, the engineer will build them and then the result will be tested for correctness by a QA person and the defects found fixed. The problem here is that the poor QA person will only get a couple of days to do all of the testing for any artifacts created in an iteration and will have spent the rest of his time not working on the things the team will be doing. Likewise the designer will have to be done early in an iteration in order for there to be development and testing time. The engineer is an even worse position as they will be twiddling their thumbs at the start and end with an unknown amount of work to cram in right at the end to fix any defects. The team is not really working as a team but as an assembly line. In fact it’s just the old-school silo by specialization approach in miniature. Working in time-boxed iterations and being co-located have lots of advantages but now people have to scramble about for things to do to fit into the awkward gaps. Worse still planning each iteration is a nightmare of trying to fit together tasks given the variable length of time design, development and testing may take. This leads to a tendency for each iteration to bleed into the next as estimation goes awry. We could just make the iterations longer but that makes us less able to respond to changes and increases slack time. Often this leads to a naive fix:

Working Off Cadence - Brilliant! We know we’re a waterfall production line in reality so we’ll get the designer to make a design in an iteration. Then the engineer can build it in the next. Finally the QA person can test the end result and the engineer can fix any defects in the final iteration. Now we can all work in parallel at different points in the cycle! Only now we’re even less of a team than we were before! Plus each of us will have to context switch all the time to deal with team members in earlier and later iterations. We’re also now taking three iterations to make anything so after the first three iterations we will be constantly delivering things at the old rate but there will be three times as long between starting something and receiving any feedback on it. In that time we may have designed new systems that take advantage of things in mid-flow only to have to rework both things when feedback comes in. Clearly this system is better at delivering a constant stream of things provided we don’t make any mistakes. However the cost of mistakes, people going on holiday or getting ill just increased a lot! We’re also setting ourselves up to make mistakes by dividing the attention of everyone between several different things in flow. This doesn’t sound good at all!

The answer to this problem is to let people break out of their box and collaborate to make things. Specialists become facilitators and mentors to the team in their area of expertise and the team actually works together to design, build and test the product. The risk of mistakes are lowered as the team is bringing their expertise to bear on each stage of development, the team is more resilient to everyday problems like illness and ultimately the team will be able to self-organize better to account for members strengths and weaknesses.

A few days ago I posted a quote from the Hearthstone developer Eric Dodds about how great it is to work with cross-functional people on a team because everyone is involved and that leads to a better game. But why is that so? I think several things come into it:

Shared Vision – The team builds and truly owns the vision for their work, rather than a few team members doing it in isolation. This means everyone is on the same page building something they feel ownership of. It’s a massive boon to motivation and team building. The team has a purpose and work becomes more enjoyable. It also cuts out a lot of the communication problems caused in trying to articulate ideas namely that it’s very easy to miss important things out when translating ideas to text and the text is easily misinterpreted. Chinese-whispers on paper.

Autonomy – Individuals are no longer locked in a box and are allowed to grow as their talents allow. There has been a lot written on the power of autonomy as an intrinsic motivator.

Increased Development Velocity – Many hands make light work, when free of their box people will do what needs to be done to finish their vision rather than making work to fill their time. The more work on the actual product that will fit into the time and budget requirements the better it will be. Particularly if people are invested in making it great. Increased velocity also brings with it an sense of accomplishment.

The other place to look for the success of this approach is with Indie games. Necessity drives people to be generalists. You can’t really be an Indie game designer unless you can actually make something. Likewise just being able to program a kick ass piece of software or make awesome art doesn’t get you very far unless you are willing to work on a contract basis. These days awesome tools mean generalists can get 90% of the way to making some very complex products and only need to bring specialists in for certain tasks.

The take-away from this is that you are hurting the agility of your company or project if you have an over-reliance on the concept specialization and aren’t encouraging teams to work collaboratively to spread knowledge and skills.