When I find myself putting a new team or department together, one of the first areas I pay attention to is identity as, in my experience, it can be one of the most powerful motivators for any group of people.
As we start to build our our technical team here in InvoiceFair, team identity has come to the forefront of my mind.
Before I continue, a quick caveat, I’m no psychologist, much of what follows is based on experience rather than academic research on the topic. In short, you might read this and find something useful, or equally you could read this and conclude that it’s just more rubbish from the nether regions of Dave’s head. You have been warned!
The Nature of Identity
Before we get to team identity, lets consider briefly identity as a human trait. Generally there are a couple of key elements that comprise the concept of identity:
- Self Concept is simply what do we think of ourselves. How do we evaluate our own behaviours. We have opinions on other people based on how we perceive them, and equally we have similar opinions and beliefs about ourselves and our values.
- Self Image is how we see ourselves, and is closely related to self concept. Self image is the internal mental picture you have of yourself both as a physical being and as an individual.
- Self Esteem is how we feel about our characteristics, our qualities and our strengths and weaknesses. It brings the to preceding concepts into stark focus; if they reflect on how you feel about yourself and your behaviours, self esteem is the judgement on those reflections. When your self concept and self image are taken in total, do you feel good (high self esteem) or bad (low self esteem)?
- Selfhood or Individuality is the concept of uniqueness. It is a reflection on our own specific needs, goals, aspirations and responsibilities that distinguishes us from all others.
Ignoring the decades of research, investigation, experimentation and theorising, these are the mental bits that make you ‘you’. Feel free to send your payments for your psychology degree to me and enjoy the many years of your life saved.
Team Identity
With our advanced understanding of human psychology now fully developed, the process of translating these elements to a team should be trivial.
A team identity takes the concept of individuality and applies it to a distinct group. For a person to identify with a team, they must effectively choose to be loyal to their team over other organisational structures.
For example, many organisations have adopted the ‘Spotify’ matrix style for organising teams and many continue to do so, even though it has emerged that Spotify themselves never fully implemented the model. For all that this revelation caused many an agile consultant to modify their web sites and presentations (no discounts or refunds were issued), the concepts behind the model actually provide us with a useful framework for discussing team identity.
In the model, there are:
Squads – the basic unit, a cross functional team of 6-12 members
Tribes – a collection of squads similar to a department that are related by their focus on a feature area
Chapters – a collection of individuals based on their specialism. If you visualise squads as a column in a matrix organisation, then chapters are the rows, gathering people under an owner / manager / leader based on skills and development goals
Guilds – a loose collection of like minded souls. Occasionally, in my rarer unkind moments, I think of chapters as the collection of guitarists from all of my favourite bands and guilds as the groupies they attract. I get it, it’s unfair, but it’s a mental shortcut…
Ok, so we can ignore Tribes, which for our purposes are just big squads, and to a lesser extent Guilds, which we can think of as Chapters who brought their +1, for the moment.
This leaves Squads and Chapters.
Mission and Purpose
Mission, purpose, the ‘why’ of the team’s existence is closely bound to the team’s identity. A team without a purpose cannot form an identity; it’s part of the glue that binds them together. But which mission?
Let me clarify, a Squad is brought together, typically, to meet a specific business challenge. They are aligned to a particular capability, functional area or business domain, leading to the cross functional nature of the squad. A Squad should be able to deliver on their mission independent of other Squads in the organisation.
A Chapter, in contrast, is brought together based on a set of related skills. The Chapter recognises the benefits in a shared approach to a particular technical problem domain. Technical here refers to specific specialist skills, not merely technology skills. The Chapter sets out best practices, standards and so on that each member of the Chapter applies to their daily work within a Squad. A Chapter should be able to maintain its standards, and its shared understanding of its particular skills domain irrespective of which Squad they are operating with.
This leads to problem one, which mission takes precedence, that of the Squad or that of the Chapter? Bear in mind, whichever you choose is the one that defines the team that the member will identify with. Am I a database developer working in a Squad or a Shopping Basket E-commerce Squad member who implements the database layer?
Authority
Squads, like any team, require clear lines of authority. They must be able to define ‘who’s in charge’ or risk not knowing which lead to follow. If authority is left ambiguous, human nature steps in to fill the gap, and that can become a significant issue. In this type of vacuum, cliques can form that are neither aligned to the squad nor to the chapter. In effect its a disintegration of the structure.
Back to the Squad / Chapter scenario. Taking our oh so briefly alluded to Shopping Basket Squad building, well… , a shopping basket on an e-commerce site. One or two of those Squad members are also members of the database Chapter.
I’m picking on the database teams because good database teams, or Chapters, tend to have pretty strong standards on naming conventions, structure, technologies, optimisation and so on.
What if the Squad determines that they can deliver some aspect of the shopping basket functionality more effectively by adopting their own standards? Standards that run contrary to those established by the Chapter?
This leads to problem two, who has the authority to make these types of decision, the Squad lead or the Chapter lead? When primacy is established, so too is team identity.
Procedures and Division of Labour
Teams are often defined by their internal procedures and by how they disseminate work amongst their members. The Squad / Chapter model is a strength here, and may provide something of an answer to the preceding questions.
A chapter may have standardised on specific standards and protocols, and for the most part these are internal to the operation of that function. You shouldn’t have a database developer, for example, telling a user interface developer how they should do their work.
No really, you shouldn’t.
The overall procedures that a team / Squad implements are aligned to delivering the outcome, and internal communication for the most part, not the details on how the specific elements of the work should be completed. In my experience, there tends not to be conflict here.
Similarly for division of labour, which in the Squad / Chapter model is usually pretty clear. Don’t give the database work to the UI Developer.
Again, seriously, even if they say they’re a full stack developer, you should avoid this.
This may indicate a solution though which I’ll discuss next.
Building An Identity
An individual on a team or Squad, can actually hold multiple identities without descending into the realms of rampant schizophrenia. The real challenge when structuring teams is the strength attributed to each identity.
The order, in my mind, should be as follows:
- Squad or Team – Individuals strongest binding should be to their team. From a business perspective the outcome is what is being paid for. Whilst the team may take a hit to productivity from deviating from an established Chapter standard, that is for them to resolve, and they should have the authority to do so to an extent.
A radical departure from standards should not be supported without a wider discussion – that’s not a team that’s anarchy. - Chapter or Technical Department – Chapters are born out of hard won experience and that should not be ignored, but organisations are not paying, for example, for beautiful database architectures, they are paying for strong capabilities that may be supported by beautiful architectures.
Yes some technical architectures are beautiful and elegant – that’s not just me being geeky. - Tribe, Division or Higher Level Organisation – Identity gets lost when the community becomes too large. When we think about the organisation we work for, whether it’s a division in a global multi-national, or an entire SME, we don’t have a direct connection with that construct. When people describe themselves, its in the context of their Role, then Squad, then perhaps Chapter before higher level organisations. Think back to the last person who introduced themselves to you, in a work context, not a nightclub. Was it ‘Hi, my name is x and I’m a database developer (or whatever the role was) in company y’ or was it ‘Hi, I’m from company y and I’m a database developer’. For the most part, its the former, not the latter.
As the person putting the structures together, you will need to establish mechanisms to allow feedback between the various identities. Squads should have a means to update the standards in Chapters, for example, otherwise there is a risk of creating dissonance. Similarly Chapters need to be able to maintain standards across Squads, lest they fall into a multi-vendor, multi-platform, multi-method quagmire of unsustainable skills which will also cause dissonance. People who start to experience a contradiction in the identities they are balancing in their mind often start by complaining, or maybe acting out, but often choose option (c) which is to leave.
Conclusions
Identity is, in my mind, a crucial foundational element to establishing many of the facets of a high performance team, which I have discussed in my The High Performance Team post and the much much earlier Building High Performance Development Teams. Without it, people cannot be anchored, and people like to be anchored – it makes them feel safe and stable.
Hopefully you’ll find this to be somewhat helpful.
Support Ukraine
The invasion of Ukraine is an act of aggression that we should all oppose and speak out against. I will continue to Stand with Ukraine and its people until peace is restored.
Bows and Arrows 
Leave a Reply