According to popular fiction, “playing hard to get” is a strategy sometimes used by women to snare a man. It makes the assumption that men want something more when they can’t have it, so if a woman acts like she’s not interested in a man, it makes the man more interested in her.
I have no personal opinion about whether or not this works for women, or whether the strategy is even used in real life. But I do know that this approach works for corporate IT.
Small companies have IT organizations, and large companies often have multiple IT organizations: some that are decentralized to support the various divisions, factories or offices, and another centralized “Corporate IT” organization which performs various IT duties for the overall corporation. I’ve worked in corporate IT organizations, I’ve talked to people who have worked in corporate IT organizations in other companies, and I know that most corporate IT organizations all over the world share one particular problem: corporate IT is regarded by everyone outside of the corporate headquarters as a huge pain in the neck.
Many years ago, when I worked in corporate IT for Boston-area based Digital Equipment Corporation (DEC), the people in the various manufacturing plants had a name for people from corporate IT. They called us “seagulls” because we would fly in from the coast, eat their food, poop on them, and then fly away. Seagulls were unwanted creatures; corporate IT just got in the way of things that were going on locally, and the corporate people always wanted the local people to do something that they didn’t want to do.
So here I was in this corporate IT organization, working at the mandate of corporate executives to develop a Material Requirements Planning (MRP) system to be used by the 29 DEC plants. How, I wondered, do I sell such a system to these plants? How can a seagull be successful?
The answer, as you may have guessed from the title of the article, is to play hard to get. We could not be successful if we forced the manufacturing plants to use a corporate system. They would go along begrudgingly, but they wouldn’t commit to success, and in fact they would probably try their hardest to prove that the corporate system was no good. We had to take a different approach.
A few of the manufacturing plants were seriously interested in getting an MRP system, so we started with them. We worked directly with those plants to develop something that would meet their needs, but we tried our best to generalize the solution so that it would be usable in other plants as well. We didn’t force these initial plants to use our solution; instead, we volunteered our expertise to build and implement their solution.
We told the managers in the initial manufacturing plants that there are four keys to MRP success:
- Changing their processes to include the use of the new system. The system has to be built into their day-to-day activities.
- An emphasis on data integrity. You can’t make critical decisions using a system that you don’t trust, so it’s paramount that the data in the system be trustworthy.
- A new approach to measuring people. Employees have to be rewarded or punished based on their use of the system. For example, a stockroom clerk cannot be considered successful if he does things the old way and doesn’t use the system. The measurement criteria for each job have to be revised to include some sort of measurement related to the use of the system and the importance of data quality. Failure to use the new system correctly has to be grounds for termination.
- The software. When we listed this item, we deliberately listed it last, and we would usually say “oh, by the way” when we described the item. Software wasn’t the key to MRP success – it was an “oh by the way.” The software doesn’t do the work – the people do. That message absolutely has to get across: giving someone a tool doesn’t do anything for the business unless the tool is incorporated into daily life.
The first couple of plants were a success, and the manufacturing managers in those plants saw benefits: lower inventory, fewer out-of-stock situations, and smoother production. We could have immediately started blasting the software out to the other plants, but we didn’t. We played hard to get, and we waited until other plants came to us, asking for the software. But even then, we didn’t just give the software to them. We continued to play hard to get, telling the new plants about the four keys to MRP success. We told them that we would only give them the software if the plant managers signed a pledge that they would commit to all four keys. Once they signed the pledge, then we would do training in the new plant, explain the processes that are required by the software, and help the plant people change their processes and measurements. Software would be installed only after the people in the plant were ready, and by then they were eager to start using it.
More DEC plants signed the pledge and implemented the software. Not every plant did, but all of the plants were measured by corporate executives in the same way, so the ones using MRP typically came out ahead on most measurements. That motivated the remaining plants to either implement the software or to come up with a alternate way to achieve the goals.
What a difference – the corporate IT organization went from being a flock of seagulls to being a respected consultant and vendor. And all because we played hard to get.
Is your corporate IT organization treated like seagulls? It’s usually because you act like you work for some sort of bureaucratic government agency where you can force people to do things your way, instead of acting as a partner to your customers. When you play hard to get, you have to create a demand for your services and then graciously satisfy that demand. It’s quite a change from the way most corporate organizations operate, but it’s a whole lot more successful.