Don’t Call Your Programs “Tools”
I understand why it happens. A lot of time and money is spent on development and now you have a “thingamajig” to use. Of course, you can’t call it a “thingamajig” when you propose its use-cases and you can’t very well list all creations by name. So you call it a tool, add it to the toolbox and carry it around.
Honestly, it kind of reminds me of Batman and the utility belt he used to have in the old days. He would run into a building, but the Joker would have a trap. Bam! The door slams behind him and the room fills with water. Luckily, he has a device that serves as a mini oxygen tank on one side. And on the other side? A high energy focused laser to cut through the walls. Whaaaat? How cool is that?
Don’t get me wrong. If you always have the exact tool for the exact way to do exactly what you need (like Batman always did), you’re set! The problem is that it’s just not realistic. Instead of having the exact tool you need, you end up with a bunch of tools that kind of do what you need. It’s hard to sell something that kind of fixes a problem, so the tools get placed back on the shelf for that scenario where they can be used one day.
The word “tool” creates a perception both in the minds of the people proposing its uses and the person trying to actually use it.
Here’s why you shouldn’t call it a tool.
Tools have very specific applications.
A hammer isn’t a screwdriver. It just isn’t and people very fundamentally understand that. However, technology isn’t as clear cut because people don’t have the same experience level with it. What happens instead is a scenario where a tool gets part way to a goal, but doesn’t meet it and there’s that familiar problem where the user didn’t get what they wanted in the first place.
People tend to care more about goals than about the details.
I do a lot of web design and development for individuals with little or no technological experience. Originally, I’d propose different means to their ends. Sometimes I would explain the advantages and disadvantages of frameworks like WordPress over hard coded web pages. Without fail, I got the same responses. “What do you recommend?” or, “Whatever you think,” or my favorite, “Look, I don’t care. I just want it to work.”
At that point, I began to take a different approach. Instead of asking how they wanted it done, I’d ask what they wanted done. What were their end goals and what do they need to be able to do? I would then build a basic proposal of the “tools” I would be using, charge accordingly, and then explain each item upon request. It was sort of a realization for me that I was selling a path and not a tool.
Tools end up lost or forgotten.
A lot of people have a spectacular collection of tools in their garage and they’re usually very proud of it. I know that the guys in my family collect tools as a standard present each Christmas and/or birthday. The problem? There were all those times where they actually did need a specific tool they had, but they forgot they had it. Instead, it became an interesting collaboration of other tools to accomplish the goal and took a lot more work than was necessary.
Recently, I was approached by someone that wanted a tool to record a specific type of interaction on a web page. It was explained to me that they tried to discourage the use of it because it was going to be hard to develop and was sort of a specific use-case. The client simply explained that’s just what they needed so we couldn’t say no any longer.
At first, I was a little intimidated, but then I went and found some old code because it kind of rang a bell. It turned out that I had already written this particular tool three years ago and we had been delaying for no reason other than no one knew it was something we already had.
People have specific objectives they want you to reach and you have the privilege of understanding how to help them get there. Take advantage of what you know by helping them to get there. Independent contract work can be difficult and often times you get lost in the details. Don’t give them some things they could do. Instead, give them a way to do what they need done. It’s worth it for them and, in the end, it’s worth it for you too.