I take some things for granted at work. That saves me time. Sometimes, however, taking expertise for granted can be costly.

I was between some clients (see footnote) and a developer. My job was to takes the clients' description of the system, convert it to technical requirements, and pass that to the developer. The developer would deliver the system to the clients and me, and we would pass it to the users.

I sat conscientiously with the clients, listened closely to what they said, and took careful notes. I met with the clients several times to be sure that I had faithfully recorded what they wanted. They listened as I told them what I had heard and nodded yes as I spoke.

I felt pretty good about myself and what I had done. I put their desires into the proper format, boarded a plane, and went off to meet with the developer. A little pause here to state what I did not do. I did not build a model or prototype using plastic, cardboard, or paper. I did not draw the system on paper to scale. I did not even make a rough sketch of the system.

I met with the developer - a senior engineer with years of experience building similar systems. He took my requirements on paper and promised to study them. Our meeting time was short, so we agreed to discuss his thoughts during the next monthly visit.

The next month rolled around and the developer's senior engineer calmly showed me that the system I had asked for six inches of connectors to be placed on a three-inch wide little black box. Take a moment to look at the ethernet connector on your laptop computer. It is so big. It is not half as big as it is - it is what it is. You cannot squeeze that connector any smaller. Well, that is what I had asked the developer to do - squeeze some connectors.

I felt stupid. Despite doing everything I was supposed to do (well, almost everything) this had become a small disaster. Several more meetings ensued in which the clients, the developer, and myself decided to try to build a system that was physically realizable.

Excuses? Yes, I had a few excuses. First, we were facing an end-of-year deadline. I had to gather the requirements from the clients and send them to the developer quickly. Second, I was feeling the pressure of the deadline. Instead of working quickly, I was hurrying, i.e. going faster than I could. Finally, I really didn't want to do this job. I was pushed into it at the last moment, and it was interfering with other work that I considered more important. I ended all meetings and conversations sooner than I should have.

Regardless of my excuses, I had made a few mistakes. My biggest mistake was that I assumed the clients knew what they were doing when they told me what they wanted. They had years of experience in this field with systems like this. Surely they knew what they wanted and what was possible.

I hate to admit it, but most people I know often don't know what they are doing. (I include myself at the top of the list of people I know.) This is especially true when it comes to experts. I suppose "expert" had the same root word as "experience." Someone with experience becomes an expert. Regardless of root words, I have concluded that the term "expert" is a prediction not a label. Predictions are often wrong.

On good days, I am able to work with people who don't know what we are doing. I try to check and double check the important points of what people tell me. In the above episode, the clients kept emphasizing that they wanted a three-inch-wide system. I should have double checked the size of all the connectors.

I knew everything that I should have done. A major mistake was that my haste caused me to forget basic concepts. A checklist would have been helpful. Experienced experts like myself don't use chekclists much. Those things are for inexperienced people who know that they don't know what they are doing.

Another practice that would have saved us was a peer review. Surely one of my peers would have made a sketch and discovered our oversight. I didn't need a peer review (so I thought).

Finally, my supervisor didn't check my work. He sat idly by while I met with the clients. I suppose that he assumed I knew what I was doing.

My best advice is to be skeptical of everyone. We are all human and we all make mistakes. I was skeptical of the developer's senior engineer. I asked him to show my why the connectors wouldn't fit in three inches. He showed me that in a blueprint. He showed me hesitantly because he thought I knew what I was doing and he had made a mistake. He had more confidence and less skepticism in my abilities than he did in his own.

Finally, we had enough people look at the facts to prove that we didn't know what we were doing for a long time.

FOOTNOTE: Clients: These are the people who pay for the product. Clients differ from users in that clients don't use the product. Users use the product. The clients in this story were former users who had graduated with age to management positions.