Don’t Be a Tool – Choose Them Wisely

The cognitive overload of every possible tech tool available to humankind being imposed on one person…

And that’s all she wrote. (Or so you’d hope – nope, we’re in for another long post. Hang tight.)

Periodically, someone notices a problem in the work community. Often, the first proposed solution is a new tool. ‘We just need MORE TECHNOLOGY to fix this HUMAN-CREATED issue,’ the thinking goes, and so a new, expensive tool is added to the already-full toolbox.

During my career I’ve spent a hefty amount of time coaching others on the ‘how,’ whether that be values, tools, or ways of working. A lot of the time people see a new tool as the solution - ‘if only I had visibility, then there’d be no more overlapping work.’ I saw the same with Chat-GPT in 2023. I was evaluating its use for a subset of colleagues and could easily identify many use cases, all of which I recommended (such as overcoming the fear of the blank page, helping with grammar, and in rendering one’s writing more concise). What I could not recommend, however, was outsourcing action-taking to Chat-GPT. Here’s the thing: this kind of an AI can think for you, but it cannot act for you. Yes, it can write something, it can create a step-by-step action plan, but it cannot perform those actions nor force you to do it. In my assessment I said that Chat-GPT (or any other similar tool, for that matter) is great for getting you to the point of action, but it’s often the action itself that causes people to struggle.

Here are some of the reasons why new tools are brought into organizations:

• Duplicate work (no understanding of what other parts of the organization are doing)
• Bad project management (no way to efficiently track different parts of the project)
• Bad communication (no tools to communicate)
• No understanding of priorities (strategy not communicated or followed)
• Existing tools do not serve new needs
• Existing tools cannot be integrated (leads to duplicated manual work)
• Existing tools are not familiar to someone in charge of the tools (they prefer what they know)

I’ve seen all of these many times. I find all of the above (bar the last one) to be good reasons to clarify things. Whether a new piece of tech is the answer, that depends.

Let’s take one of the biggest underlying issues: unclear strategy. What kind of a software can transform a power point slide into action points? Chat-GPT, for one. But can it do that for an organization of hundreds of people? Sure, just ask AI to cascade those goals all the way down to the lowly salariat. But will you ask AI to do that? And if you do, will you take the time to revise and refine, communicate, and follow up on those goals?

In my opinion, many problems that we attack tool-first are actually about legacy ways of working. Most times when either I’ve introduced a new tool to alleviate a set of issues or been at the receiving end of introductions, the biggest issue of lack of communication has still remained. If you want for people in your organization to know where you’re trying to go, what they should do, and how they should do it, you have to keep repeating the same messages over and over again, until everyone lives and breathes in sync.

Here’s a checklist for when you’re considering bringing in a new tool:

• Find out what are the real issues. What are the unwanted outcomes currently slowing down your organization? What individual steps and missteps lead to them?
• If your research shows that a tool would help (for example when the issue is that your employees cannot track something for lack of a database), do an inventory of your organization. Do you have some software that is used for this? Or software that could be used for this? If so, test it out and see if you can use the same tools across the organization, often for a better price, and always for less hassle.
• If you need a new tool, involve stakeholders from all the necessary groups. Don’t pigeon-hole yourself – not every stakeholder involved needs to be an IT wizard! In fact, it’s always good to involve people with different points-of-view and abilities to make sure that the investment is suitable for all, or at least for as many people as possible. Make sure not to over-include, though: choosing a tool for a hundred people and involving 90 people in the vendor calls is just pointless.
• Relating to the previous point, let your organization know that you’re submitting requests for proposal (RFP). This gives the organization a heads up that a change may be coming, creates transparency, and gives people the chance to contribute if needed. While you shouldn’t involve every individual in the nitty-gritty, someone might have experience using one of the proposed tools or an alternative solution. This is valuable insight.
• Obviously, you should communicate throughout. Depending on the tool and its use case(s), your organization may or may not care. If you’re looking for a back office tool for payroll, that’s unlikely to interest your employees (unless the software results in mistakes and delays in salaries, in which case you can be sure that everyone is extremely curious about the situation); if you’re planning on introducing a mandatory work time tracker, it’s crucial to communicate openly and consistently.
• Secure a trial period for the tool. Upon actually using the tool, you may find it doesn’t serve your organization as it should. Don’t commit to an expensive tool that gives you nothing or a negative return of investment.
• Secure trainings for the organization, both technical and best practice.
• One month in, do a survey. How’s the tool working out for your organization? Any particular segments that love or hate it? Unearth the reasons, and make decision on the next steps based on feedback. You can’t always trust the tool’s data (it is likely to tell you that you’ve saved an x amount of money or time, but whether that’s actually true is difficult to decern).
• Finally, a pro tip for Customer Success Managers: be in touch with your customer!

Am I missing some important steps from the above list? Let me know in the comments! And if you’ve got examples of tool implementations that went belly up, share them with us.