Language Matters: Terminology in tech and its influence on behaviour
Does language follow behaviour or influence behaviour? My life experience leads me to believe it works both ways. Why is this relevant for technology leaders? Read on.
Hi everyone,
Thank you for reading Great CTOs Focus on Outcomes. I publish weekly and have an archive of over 150 posts, each packed with valuable insights on various topics relevant to CTOs and the issues they face, distilled from my career experience.
I strive to make each post a helpful resource on the topic it focuses on so that when a CTO has a need, they can reference an atomic nugget of insight. To this end, I regularly revisit and refine my posts, ensuring you always receive the best and most up-to-date information with maximum clarity.
If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.There are many reasons why we become stuck with less-than-ideal situations in our workplaces. As a leader with the responsibility to support positive change you look for every edge you can get to helping change come about.
As I’ve shared in a previous post, I believe:
Could the language we use be one of these soft incentives that shape thought and resulting behaviour?
Language and its relationship with behaviour
It has long been debated whether the language we use influences our thoughts and, by extension, our actions.
There’s some evidence to say it runs both ways: https://www.scientificamerican.com/article/how-language-shapes-thought/
This leads to some interesting questions:
Could changing our language alone lead to positive change?
When is changing language an ineffective strategy?
Could changing our language alone lead to positive change?
It’s likely not enough on its own. Still, I’ve witnessed enough to strongly suspect that it can grease the wheels of change by reinforcing healthier ways of thinking about things that better express the nature of issues, as I will demonstrate with a few examples in this post.
It’s also an adjustment that doesn’t work as a decree. It works better when you lead by example and share your rationale for your choices. You might start by discussing the choices and options with your leadership team.
When I’ve had these discussions, I’ve found that the others in my team were supportive, but only if material change was also taking place.
When is changing language an ineffective strategy?
When language is changed without any other supporting efforts to bring about the desired change, it can lead to an impedance mismatch. We are now using a new language, but the system and all our behaviour remain the same as before. The new language assumes a sinister form of Newspeak, inspiring cynicism as leaders modify their language to conceal issues rather than effect genuine change.
If you aren’t making more meaningful changes, I suggest holding off on any suggested adjustments to the language used.
Examples of influential terminology and alternatives
Here are a few examples to demonstrate what I mean:
Requirements
Non-functional Requirements
Resources
Example 1: Requirements
The idea behind requirements has a long history within software development. There have long been detailed descriptions of the intent behind requirements gathering and what requirements are intended to be described.
These days, the understanding of the intent behind requirements seems to be very shallow, leaving people to operate more on a first-principles basis with the term. For instance, the use of the stem ‘require’ infers the idea must be implemented, which was not the intent of formalised requirements approaches.
This may be prevalent in the modern era due to a range of reasons:
The rich diversity of approaches—lean, agile, Prince2, PMM, etc.
The numerous informally trained project management professionals (not a bad thing, just a thing),
The erroneous polemic of agile versus waterfall,
Or possibly a loss of clarity in project management approaches, where the meaning of requirements has been steadily diluted as they have become more detailed and complicated.
Whatever the reason, it’s hard to argue the misinterpretation is not widespread. Organisations are often locked into delivering requirements, a majority of which are not needed.
With the use of the word requirements, I noticed a common assumption that requirements must be implemented. You can combat this by sharing with the team the MoSCoW approach, which Considers which requirements Must, Should, Could, and Will not be done. Even better, you can popularise these ideas and avoid creating this assumption in the first place. Most importantly, regardless of whether the work being project managed is approached in an agile, lean, or other manner, it is also critical to demonstrate that teams regularly reassess and are supported in reassessing what must be implemented to achieve the goal.
The confusion of people assuming requirements are static/must be implemented, combined with the availability of alternative methods and terminology for addressing needs and specifications, has led me to prefer not to use the term' requirements’. A common strategy is to focus on the more specific elements, such as needs, issues, problems, defects, capabilities, and outcomes, as relevant. I’ve never had to decree against using the term ‘requirements,’ but rather advocate for alternative approaches and be open to and encourage more specific terminology.
If you are working in an environment where the intended meaning of the word requirements is well understood, then you may have no issue at all and can ignore this example altogether.
Example 2: Non-functional Requirements
Immediately connected to the previous example is the term Non-functional Requirements. In addition to the limitations associated with the term ’Requirements’, the term ‘Non-functional Requirements’ carries additional baggage. Non-functional Requirements are, in many cases, as necessary or more critical than functional requirements. They describe the qualities of the software required to satisfy its users, such as the performance essential for making the software practical to use and the quality level necessary for the software to be trusted, etc.
There is a bias between effort towards functionality and the broader range of other qualitative aspects of software. There are many reasons for this, many covered elsewhere on this blog - from cognitive biases to the easy concreteness of functionality compared with sometimes more subtle or complicated qualitative aspects of software. This entire range of critical qualitative aspects is obscured behind a term defined by what they are not, i.e. ‘not functional’, and this further diminishes these qualities behind a single, vapid term.
Again, it can help by not using it and being more specific and defining the quality based on what it means to the users and why it matters. For instance, we need the page to start rendering within a fraction of a second; otherwise, users will begin to feel frustrated with the software and describe it as sluggish.
Example 3: Referring to People as Resources
An example often cited is the tendency for people to be grouped under the collective, ‘Resources’. This seems to make sense when considering a project, as people are just one of a range of resources that help bring a project to fruition, along with factors such as funding, materials, and the like. Furthermore, funds could be used to provide additional support to more people, suggesting further parallels.
Of course, people are not the same as inanimate objects. They aren’t mined from the ground, stored in a bank, or moved about at a whim without consequence. And there’s the fact that most people hate being referred to as being resources precisely because they do not possess these qualities.
And worse, I find that the people who refer to others as resources tend to believe that people can be treated like objects. The language has a permissive effect where people start to be treated like things. I can divide the paper supply between these two projects, allowing me to allocate the paper accordingly. I can also divide this person’s time between each project. And sometimes that’s fine; sometimes there’s no significant consequence to rapidly moving someone from one thing to another or splitting them across several things. But more often, there is.
I prefer people to be referred to as people or talent or anything else that denotes their humanity and helps others consider their needs when it comes to change. The actual change you are interested in is more thoughtful treatment of people and the language adjustment is another nudge to help reinforce and remind people of that change in attitude.
Conclusion
I am sure there are many other examples. Changing the language used won’t solve any problem alone. It’s more like putting a thumb lightly on the scale to help tip behaviour in the right direction. It can help people remember the intent behind other changes and the change in posture or position that may have been done differently before.
Don’t make a change like this without real underlying change to address the real issue. However, if you do make genuine efforts for positive change, adjusting your language to reflect that change may help shift behaviours in line with it a little quicker.
Do you have an example where you or the leadership team chose to adjust the terminology commonly used? Was it effective at supporting change, or did it lead to a cynical response? Please share your experience in the comments
If you enjoyed this publication, please help others find us and benefit from the insights.