Language shapes reality. Tools shape reality too
“Inuits have 50 different words for snow”. Have you ever heard this statement?
While the actual number may be exaggerated (see this article, for instance), it can be assumed that people who need to survive harsh winter conditions will indeed need more precise language to describe what exactly they are dealing with. According to a related Wikipedia article: “Studies of the Sami languages of Norway, Sweden and Finland, conclude that the languages have anywhere from 180 snow- and ice-related words and as many as 300 different words for types of snow, tracks in the snow, and conditions of the use of snow.”
Why am I thinking about this?
I have discovered, both in my professional and personal life, that in general, it is difficult to solve (or even spot) issues if they have not been correctly named. As a private life example, understanding broken family dynamics can become so much easier when you read about scapegoats and golden children. The same goes for corporate environments. It can be difficult in organizations to understand why a workplace feels unhealthy and people leave, until you learn about the “science” of performance, with components such as individual task performance, citizenship behaviors, and counterproductive behaviors. When you’re equipped with the necessary, precise terms, it becomes so much easier to explain why the grumpy senior dev who talks down to interns is not a good candidate for employee of the month even though he fixes more bugs per hour than anybody else.
Again, why am I thinking about this?
Well. While I have been aware of the significance of recognizing and naming things correctly in terms of language — language does shape reality — it hit me recently that the same is true about the tools we use. Hear me out.
Not so long ago, I had a problem at work. We were doing annual planning (my thoughts about annual planning can easily fill another post), and I knew I would be on vacation during the last two weeks of the process. So I did everything in advance — checked with stakeholders, built the roadmap, worked with the teams on sizing and feasibility. When I came back, I was informed that program people were chasing me, as there was overdue, unestimated work assigned to me and my teams. It turned out that some people just assigned work to us without reaching out and explaining anything… I put up a fight, telling whoever wanted to listen that this was not how product ownership worked.
But it got me thinking. Why were the program managers after me, and not the individuals who filed those tickets? And then I realized that Rally (which is the task/project management tool used in that part of the org) does a very good job of hiding the identity of the creator of a task(the “reporter” field in Jira). Basically, Jira’s “assignee” becomes the “owner”, and Jira’s reporter is hidden deeply in “revision history”. It is so much easier to find, and then reach out to, the instantly visible “owner” than the creator hidden 5 clicks away.
The time it takes to find who actually filed that unit of work is not just a nuisance. It affects the entire process — it introduces a mutation. People will start doing what is easier; what the tool makes easy for them.
I noticed a similar, smaller thing with Google vs Outlook calendars. Google will, by default, show other people’s calendars overlapped with yours, making it easy to see when someone is busy, and where open slots exist. Outlook will first show them separately, and the outcome I notice is more conflicts as people cannot be bothered to check someone’s availability properly.
(Disclaimer: it is possible the features and UX I am describing are configurable — this post is not about proving that one tool is better than the other).
Why is this important?
Every now and then, an organization has to select a tool to serve a given purpose. Different aspects are usually considered (feel free to check my previous post about decision docs btw): pricing, market position, open standards, CTO’s personal preference, many others. What I am trying to do here is advocate to include this important check in the selection process: understand what becomes easier, and what becomes more difficult with the tool. It is not enough that an action you want to complete is possible with the tool. If you want people to do it, and continue doing it, you need to make sure that it is also easy — or at least easier than the things you don’t want them to do. Otherwise, you will not be able to shape the processes for your organization — the tool will do it for you, affecting outcomes and value at the same time.
And ineffective processes really frustrate people, you know.
