Limiting Labels

05 September 2010

Categorising things is normal and necessary, but does it limit people?

Lately, I’ve noticed a trend in some of the writing and blogging about the software industry[1], which seems to advocate purposely limiting personal learning and development based on professional categorisation[2].

For example: If your professional categorisation (or label) is ‘tester’, then you should not be expected to study or learn anything outside some preconceived notion of a ‘tester’s responsibility’.

Perhaps these people missed the memo on T-shaped people, or are scared that the industry is changing and leaving them behind.

Categorisation and labels in software teams seem to be a subtle kind of silo. So, is that a bad thing? Should we care?

Labels can be limiting

Why are labels a bad thing for people on software teams? What’s the problem with having a defined role and responsibilities? Why not categorise people?

People have been categorising (and labelling, once language came along) things forever. Categorisation is inseparable from cognition. In other words, humans can’t process information without applying some categorisation strategy to every single thing they can see, smell, touch, taste or hear. Categorising (and labelling) things helps us to communicate what we want, what we need and what we want other people to do for us.

So it would seem only natural to categorise ourselves in our professional lives. If you have a tooth-ache, you go to see a person who is categorised as a ‘dentist’. Need someone to help you out of a sticky legal situation, better find an expert in the law; a ‘lawyer’. Nice and easy.

Of course, your ‘dentist’ and ‘lawyer’ don’t only fit into a single category. When they leave the office, they also become a ‘motorist’ or ‘commuter’ on their way home. When they get home, they become ‘Mum’ or ‘Dad’ and at the same time they become ‘sweetheart’, ‘best friend’, ‘companion’, ‘competitor’ and simultaneously a bunch of other things, depending on who they’re dealing with and what they’re trying to achieve.

If our dentist or lawyer were only interested in learning about the things that allowed them to fulfil their professional obligations, then they’d find it difficult to integrate with the rest of the world. I’m sure you can think of at least one person who never really learnt how to interact in social situations and seems awkward and out of place at a party or family gathering.

Conversely, professionals inevitably bring knowledge and expertise from their other categorisations into their work. For example, our dentist might have children and know how to speak and act in order to gain the trust of a frightened toddler who is required to sit still while having their teeth examined.

Our lawyer may be an avid amateur mechanic who rebuilds classic cars in their spare time and uses some of that knowledge to help prove (beyond reasonable doubt) that you didn’t tamper with the brakes on your bosses car, when he dumped that surprise weekend overtime on you and made you miss that fishing trip.

Sticking to the boundaries of an understood professional category can be limiting; for ourselves and for our customers.

A little knowledge goes a long way

Why shouldn’t a ‘system-programmer’ know about the science behind user experience?

Would it be a bad thing for a ‘tester’ to know why violating the Liskov Substitution Principle will probably cause maintainability problems for a codebase in the future and likely causes understandability problems in the codebase right now?!

Being able to communicate effectively with people playing different roles on a software project, means studying and learning some of the things that make them an expert in their role.

Putting yourself in their shoes and understanding some of the problems they face, the constraints they work within and the heuristics they use to solve problems, makes you more able to help them do their job. It will probably help them to help you do your job.

Can you know too much? I think it’s unlikely that studying something outside of your role’s commonly understood sphere of knowledge will ever be completely useless to you.

Learning to love learning

We’ll never be an expert in everything (sorry about that). You’ll probably not even be very good at most things.

So if learning about something outside of our professional categorisation is a good thing, and we can never be very good at most things, then what should we study?

Start with your passions:

Like the idea of data visualisation? Have at it!

Social science and psychology is your thing? Go forth, consume that subject (you may be surprised how relevant your passion is to software projects)!

The idea is that learning itself becomes the passion. If you awaken your appetite for information, regardless of its relevance to your professional situation, then you’ll find it easier to learn things that actually do help you in your work.

Be gentle with categorisation

Nowadays I think we’re mostly agreed that effective face-to-face communication is important for software teams. We’re also agreed that placing people into silos (read ‘applying labels’) reduces communication and can lead to unwillingness to take responsibility for things because they don’t fall specifically into the definition of their role.

It comes down to personal choice. Refusing to be bound by the limits of a category doesn’t have to be something encouraged by management, or fostered as a cultural change initiative.

As individuals, please don’t limit yourself, or each other, with labels.

fn1. It’s probably been the case for a long time, but I only just noticed it. And yes, someone is wrong on the Internet! I was surprised, too.

fn2. Don’t worry, naming names isn’t necessary for the remainder of this post to make sense and it’s more than likely to distract from the message.