Words matter; we put labels on things, we put labels on each other. Those labels lead to judgements. The ways we judge what capability someone has or hasn’t in something technical only tend to lead to harm, I’ve found. It’s a way to limit before you even know someone, and that’s one way to block ourselves rapidly from a potentially beneficial experience.
This tweet inspired this post:
https://twitter.com/joshsimmons/status/1417694331532570624
I’m a designer who can code, hardly a rare creature. However, I’ve seen so many times throughout my career where labels of non-technical were attached to me and boundaries were drawn with verbal chalk where I shouldn’t go. Anyone around any time in the software industry might have more than one discipline: designer/writer, design/development, business/systems. There are so many potential variations because you gather exciting knowledge. That is what makes everyone more valuable as they travel their career.
The most significant impact of labelling wasn’t just limiting my worth because it did limit my value in my role. What it did was also end up me mirroring that behaviour. That’s a part of human nature; this type of role dividing is infectious. You are limiting resources, so someone will clutch to the little they have because we are human. I was feeling threatened and devalued, so I responded from that place and mental state. It’s a cycle that you learn and then take to the next role – it goes around and around. It’s a cycle we, a product making industry, have to stop.
By using that label, you impact that moment but also future moments. There is, for example, psychological proof this happens when using the term bully to someone or labelling someone’s mental diagnosis. It’s why incredible care is taken before confirming the diagnosis, which can be a relief to many but, when wrong, a dangerous situation. Limiting someone in this way is potentially dangerous because if you say to someone they aren’t technical, they might assume that is always the case and never reach their potential. Historically, people were told you could be artistic or scientific, left or right brain; women can’t code. As someone that grew up in an age where that happened (it’s not that distant), experiencing that, anything we can do not to repeat that I welcome. Collectively moving beyond this isn’t always easy as it’s ingrained, but it’s gratifying to do so.
Another part of this cycle that’s also just toxic is the resume and background boasting. Nobody should have to prove what they have done to be heard. It means you end up falling into the trap of proclaiming your ‘technical’ or proving. This limits just to the role of development, ruling out other technical backgrounds, and that’s a massive part of this. Technical isn’t and never was just about code. This myth of the divide, the gatekeeping, the ‘us’, and ‘them’ isn’t your product because every person goes into it.
I’ve seen this the other way around, too; I worked a long time ago in development roles and was told ‘just technical’, so I couldn’t comment on the experience. That discounted my background – again, words matter, and it wasn’t using my total value. No matter which angle you come at this from, it hurts. Most of the reactions you see are from hurt people who have learnt that hurt because words matter.
Often you see in a space where this happens; walls go up around the disciplines. You will see increased gatekeeping, process creation can often escalate, and people frequently across the company will be on high alert to prove themselves. The reaction you see is a symptom of people hurt; they are wounded, not united. It just took language – language is that powerful. This space is ripe for other us v them behaviours. All they need is that one fertile ground of divide, suspicion of the other, and you instantly have combative thoughts in your team, and inclusion is more brutal to nurture from that point.
If you take it from a business perspective, it makes no sense to have every skill someone can use. You hire someone for being the incredible person they are, not to use a small percentage. Similarly, more robust products come from allowing more disciplines equal input. I’ve seen remarkable changes come every time this opening; this welcoming approach to creation is at heart. Amazing things happen when nobody feels they have to prove themselves or each decision is a round of combative discussion where proof has to be seen of validity to join in. You don’t want to block any possible revenue stream as a business, so why stop creation streams inside your production process?
Perhaps the next time you go to use the word ‘non-technical’ to describe someone or ‘non-coder’ and even ‘non-developer’, pause. Do you even need to label? What is that doing to them? Does it help move that conversation on? Are you doing it because you’ve learnt it? Am I saying it because someone once told me that? Perhaps leave the label to the side no matter what role you might be labelling and see what a difference it makes to how you feel – I know I’m going to try that for a while to see how it fits. None of us is perfect, and we all do this, so we need to change our mental models collectively.
Leave a Reply