Credit

This post was written by John Clapham.

—

Often during a DevOps or agile transformation, we demonstrate the potential of fresh ways of working with a single, pioneering team. Generally these teams produce solid results and there is a strong desire to scale the approach to more teams. This moment is something of a tipping point for the department, successful scaling leads to successful teams, leading to successful projects. How people are picked for those teams is crucial. A team’s make up is just as important as the practices it adopts; personalities, skills, experience and enthusiasm will all determine the drive, output and diligence of the team.

So how are teams created in your organisation? The easy way is to ‘do what we always do’: gather people finishing a project, or copy the template from the last team created, or maybe teams don’t change at all! Slightly more adventurous is to replicate the list of job titles in the pioneering team. These cookie cutter approaches may be successful, but only if the department is already populated by talented flexible individuals. However a little consideration will often yield better results, not just for the business but for the individuals in the team.

People are wonderfully complex, so chances are the job specification used to attract them talked about various responsibilities and a range of skills. Habitually those are forgotten by both parties within a few months and people conveniently get attached to corridor labels: ‘Java developer’, ‘junior DBA’, ‘Docker guru’. These labels are used to shape how we think about what those people offer. They also shape self-perception – the attitude that I am an X, therefore I can’t to Y. Not only that but titles encourage a certain amount of creatively “throwing the hot potato” – “I don’t need to think about that, it’s her job”. In fact everyone has a lot more to offer, and teams are frequently more successful if those other strengths are considered. The range of talents people bring beyond their job titles may be thought of as their capabilities.

So rather than factoring a team on titles and job roles, consider capabilities, and consider them in some depth. There are two angles for consideration:

1. what capabilities do people bring?
2. what capabilities does the project need to succeed?

In DevOps we see this put into practice, rolling up the capabilities of ‘being good at building application software’ and ‘being good at operating software’. his is a bold leap in the right direction, but still a fairly coarse grained breakdown. Some might say we’re merely looking at two titles instead of one, but still not much more effective.

Cross functional teams are relevant here too. The popular interpretation appears to be ‘a team populated with roles sourced from across functions’. This is opposed to the more desirable: ‘a team populated by individuals with multiple capabilities allowing them to play multiple roles in the team’. Football teams provide a great example of this, players have specialised positions where they often play, and the capability to play in different positions.

A person’s capabilities aren’t always obvious, particularly if previous projects or team personalities haven’t provided space for them to be revealed. Previous experience is an obvious place to look, even better is considering personal development needs, or development trajectory. Development trajectory is the direction someone is heading in their career, and it is not a crude ‘up’ or ‘down’. Their current capability is the role they are performing most of the time, generally closely aligned to their job title. A person’s career trajectory is where they want, or could, head to. It may mean developing extra skills in the same area, transitioning from journeyman to expert or changing track from engineer to architect, or product owner to user researcher. These developing capabilities are well worth considering when assembling teams. One person’s routine task may well be someone else’s development need, and pairing an experienced person with an apprentice often enables both to push into new areas. Playing to someone’s interests frequently enables teams to harness their enthusiasm, their willingness to invest time in learning. This highly likely to offset any perceived slowdown from mentoring and pairing, and it occurs without losing valuable input from the original role.

To conclude, consider a concrete example from product development. An agile team often consists of a product owner, an agile team lead, a user experience person, three developers, two testers and an operations specialist. That’s eight people committed before building even the smallest slice of the product. What the product really needs though is at least one person who understands and represents each of those specialisms, each of those capabilities. As long as they are competent it doesn’t matter if the test sensibility is delivered by a ‘Java Engineer’, or if a sysadmin contributes to product decisions. Of course, to make these decisions leaders need a good understanding of their teams. If they don’t hold that understanding, it would be prudent to ask why. To mitigate, these decisions should be made openly and collaboratively with involvement of the individuals concerned. By breaking the one-to-one mapping between title, person and capability we have more options, more flexibility. We also produce a culture where personal development needs are considered and cultivated, increasing motivation and the likelihood that talent remains within the organisation.