© 2003 Dwayne Phillips, home.att.net/~dwayne.phillips
I spend most of my professional life attempting to solve problems.
I face some of these problems privately,
but I face the rest with other people.
Sometimes people working a problem will ask me for suggestions.
Sometimes someone above me at work will assign me to assist
people in solving a problem.
Other times I notice people facing problems and I volunteer my services.
The last two cases are the toughest because I am inflicting
help on others who may not want it.
In my experience, a big part of solving problems with others is convincing them to try my suggestions. I have learned to allow people time when I suggest something to them.
Without allowing time, I usually hear,
“No, I don’t want to do that.”
When I allow time, I often hear, "At first I didn’t like this idea, but on second thought I can live with it."
I have learned a couple of ways to use time depending on the situation. The first situation I’ll describe is with a group of people I manage day to day. The second situation is with an outsourcing contract.
Ten years ago I managed a group of 20 programmers in a signal processing lab. The programmers sat side by side with the users and adapted software to their desires on a daily basis. The situation worked well for the users, but was inefficient for the programming team. We usually had several programmers working redundantly on the same problem because a user would run the halls and spout his desires to any programmer he saw. The programmers were eager to please the user, so they would drop what they were doing and dive into the problem. There are advantages and disadvantages to different people working independently on a single problem. In this case, the disadvantages outweighed the advantages.
The problem we were having was how the users requested services from the programmers. I knew a way to request services that would be more effective and efficient. I called a meeting of all the programmers and proclaimed that henceforth all requests for services would go through me. I would assign the request to the right person and eliminate the redundant and wasteful efforts. This request system also had its advantages and disadvantages, but for this case the advantages outweighed the disadvantages.
Regardless of the benefits, no one implemented my suggestion. Everyone rolled their eyes, left the meeting, and did things the way they had always done them. I knew a better request system, but I failed at moving us from the current to the suggested system.
Several months later I tried again, but this time I allowed time. I prepared a short paper explaining how I wanted to change the way we accepted tasks and priorities from the users. I spoke to each programmer alone for 30 minutes and left them with a copy of the paper. Each conversation was an exchange of ideas. The suggestion evolved, changed, improved, and gained momentum through these exchanges. It took a month to speak to everyone one-on-one. I waited another month for the programmers to chat with each other about this. They did so because they noticed a copy of my paper on each other’s desks.
After these two months had passed, I spoke to the managers of the users about this idea. I explained the problems we were having and how my suggestion could provide the users what they needed more efficiently. The managers liked the idea enough to try it for a while. They too had heard about it several times in the preceding weeks from programmers and users. The word had spread slowly through the lab’s grapevine.
At the next programmer’s meeting, I announced that we would try my suggestion. No one jumped for joy, but everyone was willing to try the suggestion. They had the time to discuss this among their peers and the users, and decided that it was worth trying.
Now the outsourcing case. About five years ago I worked on several outsourcing projects. On each project, I would fly to the west coast to visit with our contractor once a month and learn of their progress. During these one-day visits I would usually make suggestions about how the contractor reported their progress. The contractor was always polite, but almost always rejected my suggestion. They felt that my suggestions had merit, but they would be too difficult and expensive to implement.
One contract had more than the usual amount of problems. We did not have good insight into the software portion of the contract. Therefore, my boss tasked me with gaining the insight we needed. I knew what I wanted from the contractor, but didn’t have much hope of having them follow my suggestions. I tried a variation of the time technique.
Instead of visiting them from 9 to 5 on one day, I arranged my trip so that I would visit them from 1 to 3 PM one afternoon, and again from 10 AM to noon the next morning. I made my suggestions to them the first afternoon, and they resisted. I left at 3 PM. That allowed them a couple of hours to discuss the suggestions and research how much time and effort it would require each month to report what I wanted. They also had the evening to let the idea swirl around in their minds. The next morning they did a little more research before I arrived at 10. Given the time to think about my suggestion and research its implications, they decided that they could provide the status we wanted. In the coming months, this information allowed us to see looming disaster in time to avoid it.
I have since used variations on this in other outsourcing contracts. Sometimes I make suggestions during a series of phone calls before visiting the contractor. Sometimes I send several faxes to different people at the contractor before visiting. If possible, I discuss my suggestion with the contractor over the course of several months before asking for a decision. Each of these techniques provides the contractor with time to consider the suggestion and increases the chances of the contractor trying the suggestion.
There are several possible explanations why time increases the chances that people will try suggestions. One explanation is that with time comes repetition. People have several occasions to hear the suggestion. Another explanation is that most people in technical fields are introverts. We introverts prefer time to process a suggestion internally before accepting it. Finally, time changes the emotional dynamic of the situation. Fear often comes with a suggested change. Fear is an immediate and strong emotion. The passage of time reduces the fear and allows other emotions and thoughts to come to the forefront. Whatever the reason, a second thought seems to work.