Prevent “tool fatigue” with a balanced approach

Once upon a time, I emailed a co-worker asking for help. A few days later, nothing had been done. When I asked “what’s up,” the co-worker replied:

“Our department uses a ticketing system. The way to request help is to go to [long address on the company intranet] and file a ticket using [software system I was unfamiliar with.]

“Tool fatigue” is real: a department head discovers a way to improve how their department works, and suddenly team members are required to learn it. Or a vendor requires you to send files using the next big file-sharing system. Suddenly you feel as if you’re spending your entire day learning the tools. It’s like trying to assemble a new vacuum cleaner and never getting the floor clean.

This post shares three questions to ask yourself when setting up a tool for group use.

Will one person on your team manage the use of the tool, or will everyone be asked to become a power user?

For example, if you are using Microsoft Teams, you have probably discovered it’s a pretty powerful collaboration tool – and it can also go awry very quickly. Instead of requiring every team member to be familiar with all the features of each collaboration workspace you set up on Teams, why not assign one or two team owners? They can be responsible for managing the workspace, curating content, and helping group members use it effectively.

To get even more specific:

  • Make it clear to group members that they can dump files into an “Incoming” folder, and the workspace managers will commit to moving those files to the right place.
  • Instead of requiring everyone to become Sharepoint experts, ask the team managers to create and maintain a team Wiki. The Wiki can contain instructions for using the workspace; it should also contain contact information for people who can help answer questions.

Whose life are you trying to make easier?

If your team regularly uses any productivity tool, it’s been designed to make your team’s life easier. However, your company’s goals are probably not “Make Team X’s life easier.” It’s in the gaps between teams that most mistakes are made. Instead of requiring other teams to participate in your productivity tool, following these three principles can help:

  • Your team is open to any communication from other teams via any channel.
  • Your team takes the responsibility of managing the use of their own productivity tools, tracking software, etc.
  • As your team manages their own system, a sense of ownership grows, and they can constantly improve their practices.

Even if your team at first perceives this as “extra work,” it will quickly become apparent to them that the company’s overall productivity and morale is improving. This will make everyone’s life easier.

Does your tool result in your putting metrics before performance?

It’s important to measure your team’s performance, but not if it interferes with them getting their job done. For example, an IT manager who measures employee performance only by the number of requests they complete will cause the following problems for the organization:

  • Difficult or time-consuming projects are tackled last, even though they have the potential to be more transformative;
  • The organization engage in a lot of busy-work filing tickets for tiny requests;
  • Morale will suffer as your team struggles to “make the numbers,” which do not really measure whether the team is helping the organization succeed.

Writing a purpose statement for the tool is a way to prevent this catastrophe. For example: “Our ticketing system will enable us to collect the right feedback about each user request, triage the requests so they’re completed in the order that serves our company’s goals, and track them so that we can refer to previous solutions.”