Do you know someone who irritates you so much that just the mere act of them taking a breath to speak puts you over the edge? No matter what they say, it just rubs you the wrong way. I think most people know someone like that. Unfortunately, for many businesspeople, that person is their IT partner.
Whenever the IT person tries to explain a technical problem or defend a business case, the person on the receiving end hears nails on a chalkboard. Couple that with a blank stare when pressing business issues are being discussed, and you’ve got a recipe for a rumble.
Over the years, I have heard from many business partners--especially franchisees--that they get very frustrated when talking to IT people. There is a significant barrier when it comes to the language. The business partners are frustrated that the IT people don’t understand their language (terms like COGS, theoretical food cost, sales/labor hour, etc.), and they have no idea what the IT person is talking about (terms like Web services, ASP, dynamic IP addresses, etc.). This barrier creates friction that can result in a not-so-subtle “stink-eye” from across the room.
The problem is only getting worse. First, technology vendors are creating new features and functionality much faster than they are retiring them. As a result, the catalog of things that most IT people need to know is constantly growing. Second, as technology advances and becomes more complex, so do the explanations behind it. As a result, IT people often focus on understanding the new technology and fail to learn how to properly translate that knowledge to the layperson.
Here are some helpful hints when it comes to talking about technology to your business partners or franchisees:
Let me give an example. I am in the process of launching a new inventory management package for one of our brands. This new system will replace an existing manual process with technology that greatly improves efficiencies, thereby resulting in dollars to the bottom line. The new system has a bunch of great features like integrated supply chain, theoretical food costs, recipe management, etc., etc. The training course for this system takes two full days to fully learn both the basics and the bells and whistles. I’m sure many of you already have a similar approach in place.
The mistake that many IT people make is trying to explain all of that detailed information right out of the gate. Remember that the goal is to explain what the system does, not how it does it. Here is the business case that I plan on presenting to our franchisees.
Saving You Money
- Reduces food cost, waste and theft
- Offers tighter inventory controls
- Allows you to see all stores’ data on a single screen
- Compares data against your market, DMA or entire system
That is it. It is simple, easy to understand and uses business terms. It does not give unnecessary detail about how the supplier interface works, nor does it talk about the hundreds of reports that can identify variances or the fact that it is a Web-based application. I also don’t go into detail about how not all reports allow you to see all stores on one screen. (Some do, and some don’t.) What is important is the sentiment; details will be provided later.
Many IT people get caught up trying to explain all the particulars right up front. Going into that level of detail at this level of conversation will just create confusion and frustrate your audience. Some businesspeople mistakenly think that IT people are talking about these details using technical terms and acronyms in an attempt to make them feel stupid. Most times, however, that is not the case. The reality is that the summarization rarely conveys the entire point and that the IT person is simply attempting to be complete in his or her statement of a technology’s capabilities.
IT people also tend to talk about what is comfortable for them, which is often technical information. But it is important to make sure that IT people understand, at a detailed level, how the business works. They need to spend time working with businesspeople to understand the company. IT should be closely tied with operations, marketing, supply chain or whatever business units that it supports. If, for example, an IT person is supporting the operations team, that IT person should think and act like an operations person who knows IT, not as an IT person who provides technology solutions to operations. This distinction can be a hard mindset to change, but one that can pay dramatic dividends in the future.
What do you think? Love it or hate it, I’d love to gain some additional perspectives. Leave a comment, or E-mail me: [email protected].