Here is a team formation anti-pattern that I have observed recently: Dividing the team along the lines of Skillset.
Grouping teams along skill lines, inherently sets up competition rather than collaboration. This is especially true (in my experience) in software designed, where skills vary by “architectural layer” so subteams form at the layer level. Each subteam develops some ego: my layer/skill is important, our practices are immutable.
The reasons for this are somewhat obvious. People tend to group with their peers, and they perceive their peers as those who share a skillset, some expertise, and a way of thinking. Unfortunately, this tends to set up some us against them dynamics, especially when deciding where in a software stack any meaningful work will get done. There are patterns that have each layer implementing more than their share, and with the skill/layer subteam setup – who can mediate between these? On what basis can they compromise.
Here are some options for defeating this naturally occurring phenomenon:
1) Work through “customer/provider” relationships between layers/skills, and rather than having them focus on how great my layer/skill is, they can focus on how their layer/skill serves or supports other layers or skills in the context of the whole. This approach may be sufficient to defeat the skill clique mentality in a team.
2) Construct and assign skills into “all layer” feature teams, so that your team is divided (for design purposes) in subgroups representing each skill. Let those teams work together to propose and validate design patterns. These same teams can work together to complete features once design is complete.
3) Pair developers across layer boundaries, and let your layer specific experts start to expand their skills into neighboring layers, and so gradually move your organization toward generalists. Reward those who become more generalized by giving them leadership responsibility as they move in this direction.
4) Hire more generalists who have end-to-end expertise, who have skill and expertiese across all layers. This is harder to do, but these individuals can disrupt the logic of the layer/skill clique.
Have you ever experienced this phenomenon interfering with team formation or team cohesion? If so, what did you do? Ideas you haven’t tried?
Please leave a comment!
No Comments