Tools make culture.
One of the things that sets humans apart is that we make and use tools. Very few other animals do this, and those that do show only a rudimentary ability to use simple tools, like using a stick to “fish” for termites. The tools used in this way are not valued, rather they are picked up, used, then thrown away.
Early man had a similar relationship to tools. Primitive stone tools were often used then discarded. As our tool-making became more sophisticated, this behaviour changed and we began to build tools that we kept and reused.
Modern humans have developed incredibly sophisticated tools that have become extensions of ourselves — you’re using one now! Not only have we evolved in our ability to create increasingly complex tools, but we’ve also developed an understanding about how the tools we use can shape our behaviour, and in turn the culture we create together.
Most people would agree that computers, devices and the Internet have changed how modern humans relate to each other. When you look at the software tools in use in a modern computer-based work environment, however, you will find few people are thinking about how these tools we use every day in our work affect how we relate to each other.
This seems strange to me. Think of it this way: imagine your mechanic didn’t have the right spanners to efficiently remove the bolts on your car. Firstly, they’d be less efficient when working on it and would probably get frustrated about that. Secondly they’d be more likely to damage your car when trying to fix it, which would lead to angry customers.
You would expect such a situation to create a tense and unhappy working environment. In other words, not having the right spanners would create a bad culture. The same thing applies to the software tools you use.
The tools you use, and the way those tools are designed to work, affect how you feel, and have an effect on how you do your job. If a tool doesn’t behave intuitively, you will find it annoying to use and may choose not to use it at all. If a particular work function, say entering a sales lead, is made difficult by the way your CRM is set up, people may choose not to do it, or may take shortcuts by not entering all the data, or entering it in the wrong place. This would create a compounding problem of low quality data that someone then has to spend time cleaning up.
No-one wants to spend time dealing with tools that do not work well.
But the effect can be more subtle than this. Seemingly fit-for-purpose tools may be designed in ways that encourage certain types of behaviour that are not optimal. An example of this is an issue management system that encourages support staff to get issues out of their queue by “escalating” the problem to someone else. This creates a game of “pass the bomb” where no-one accepts responsibility for actually resolving the issue. People are using the tool as it’s designed to be used, but the outcome is low engagement and poor customer service.
Partly this sort of problem is a consequence of complexity. The tools we use now are so complex in their operation that many people struggle just to learn how to operate them. We are then challenged by updates that purport to make the tool more intuitive than the previous version. How often do we stop to think about whether the fundamentals of the software are delivering the outcome we wanted in the first place?
When working in an Agile environment, there is often a discussion about which tools will best support teams to work in a more Agile way. This is a great discussion to have, and I’d encourage you to think about how well the tools you use today deliver the goals you have for them.
One way to do this is to think about your desired end state first. For example, if you want to deal effectively with customer issues with your systems, forget the tools for a moment and ask yourself: what does success look like?
ITIL states that service desk agents must be accountable for every incident, open-to-close. We all know how annoying it is to be hand-balled from one support person to another, so our ideal end state in this case would be one where support personnel have end-to-end ownership. To achieve this, they need to be able to get support from other teams without losing that sense of ownership.
One way to do this is to use the concept of “participants” from whom the support agent requests help in resolving the issue. Using this model, the agent gets the benefit of escalation without losing responsibility for the ticket.
Now you know that’s the behaviour you want, look for a tool that encourages this way of working. Repeat this process for other outcomes you want to build the complete list of capabilities you want your tools to deliver.
When you know your ideal end state you will be in a better position to make smart choices about the tools that will create the organisational behaviour you want.
Tools that support good work create happier, more effective teams, and happy and effective teams are the surest way to create the kind of positive and constructive culture of which everyone wants to be a part.
