I received a comment from a colleague, who thought it foolish for an expert to think they know everything since almost by definition experts have a narrow focus. Perhaps my use of the term expert diverts attention from the phenomena. The following may help clarify the point I was making.

It is not a matter of people thinking boastfully “I know it all - I am the expert.” It is a failure to dismiss the subconscious false comfort that comes from having used or integrated an existing product or system for an extended period. One story told to me by a Sr. stress analyst touches on the subject. I don’t know how factual the specifics are but the phenomenon fits.

A large corporation designed and manufactured a four prop military aircraft. The plane had been in service for decades and was derived from a civilian model designed and manufactured by the same corporation. It was a good design as decades in service would testify. But all good things must come to an end and the government requested a replacement. According to the analyst the corporation was sure their new design would win. After all they have been making the original aircraft for a long time. They did not win. Designing something and manufacturing something are very different. Few would argue when stated so bluntly but often the bluntness is not provided.

The original designers were long retired or dead. The “what” was documented on the drawings, but often the “why” is lost. The company was proficient at making the parts as documented. But the thousands of minor decisions that result in a final design are often lost in time. We take for granted the complicated devices we use every day. The details that went into the original design of a kitchen can opener, let alone an iPhone, would shock most people.

Another example of the blurring of capabilities which I have experienced many times was among CAD users. It is similar if not the same phenomena. First a little drafting room history is required; some of which even predates me.

Decades ago one of the entry level drafting positions was called Tracer. As the title implies, if parts were to be reused in a new assembly they would be traced onto a new velum. Here too a Jr. Drafter would have to think ahead and avoid running out of room. Even at this entry level there was an awareness of the skills needed to avoid a time consuming mistake. Yet the tracer was the Jr. guy in the room. With the advent of CAD, drawings can be reused and views re-positioned with a much lower level of skill. Think typewriter with a professional typist before the advent of MS Word on everyone’s desk. How many of us can type that fast with so few errors – all day – everyday – for years?
​
Now back to my point. A good portion of the drafting effort then and now are minor changes to drawings. Modifications are much easier with CAD than during the days of velum and this is a source for false confidence. I have interviewed people who really believe they have been designing in CAD for decades when in reality they have been revising and reusing existing designs. 

After a few post hiring surprises we implemented a simple test during the interview. It was a real eye opener to witness “veteran” users having no clue how to start from a blank screen or set up dimension styles. We allowed plenty of time for unfamiliar workstations and for those who used Command Line/Shortcut Keys vs. Window commands. This was not just a case of resume padding – they really believed they met the skill requirements. They were told in advance there would be a CAD test. They had no doubt they had been doing design work for years and never stopped to think if there was something they should look into before the interview.

Over the years I have witnessed a particular mistake repeated. It is usually with an old product that has a problem, or the old product requiring a change or a feature added. The mistake manifests itself with everyone believing they carry the true operation and understanding in their heads. Aside from Scotty aboard the USS Enterprise, most should assume there is something they may not know.

When a new product is being developed the team usually follows some development process with defined tools. Oversight is likely in place with design reviews and gatekeepers of some kind. But humans grow complacent and subconsciously assume these systems must be as they believe it to be. After all we have been making it or using it for years.

If you get involved with Value Stream Mapping you will come to realize everyone has their own reality of how things work. This could almost be a money making parlor tick. Do a demonstration of some process with 15-20 steps to an audience of 20 people. If two in the audience come up with the same detailed step by step process after watching the demonstration, I would be surprised. Usually 2 or 3 people are asked and I have never witnessed two agreeing or any of them being correct on the first pass. The tasking of writing it down will identify to others what was missed. With repeated passes a complete process can be documented.

Having been a manager of experts in a variety of specialties I have often been the dumbest guy in the room. I know what I don’t know and I am less likely to develop a mental understanding good enough to convince myself I understand.
One example in particular comes to mind. I sat in a meeting to develop a system consisting of electronic devices. This was an add-on or a fix – not new product development where checks and balances are in place. I can’t recall the specifics but the experts were discussing this with great confidence. I was lost and asked that the oral conversation to be turned into a block diagram on the white board.

Just as with Value Stream Mapping the first attempt at the block diagram received corrections from people who a few minutes ago were in oral agreement. I believe it took seven iterations of the block diagram before all the experts agreed.
 
This is not an attempt to discredit experts. Without them the job would not get done. This illustrates that experts, except Scotty of course, can easily get over confident. When a team is involved it is seldom the case that everyone knows everything. Add the element of time for aged products/systems and it is almost a certainty.

If you are part of a meeting where everyone is in oral agreement it would be prudent to ask for a flow chart or block diagram. The dumbest guy in the room may save the day. 

Nearly Forty years ago, a fellow engineer told me a story that must now be 70 years old.

This engineer was born and educated in Egypt. His first job was a large civil engineering project with massive amounts of earth moving. Having a formal education but no local real world experience, he started to plan how many steam shovels and trucks were required for the job. A Sr. engineer asked, what he planned do with all the equipment once the project was done, and what about the 99 local laborers left idle for each machine that does the work of 100 men and requiring only one operator?

The Sr. engineer told the young engineer to base his calculations on the required number of donkeys, basket weavers, strong men, little boys, and laborers that would be required. I was puzzled as was my colleague that many years ago.

The Sr. engineer explained that picks and shovels would be the main tools and the local laborers the muscle. The laborers loosen the soil and then fill the woven baskets with the soil. The strong men would lift the baskets onto the donkeys. The young boys would ride the animal off site and dump the soil. This kept the local population employed and able to feed their families. Manual labor as it was may not have been a great way to make a living but it was far better than starvation.

The situation in ancient Rome was similar. The Romans build magnificent structures but the preferred method was brute force. There was no push for efficiency as we think of it today. Even then, there were labor issues. Better to keep everyone working and fed, if only at subsistence levels, than to have massive unemployment and the making of a revolt.
If the laborers were in a position to request higher and higher wages mechanization may have advanced faster.

It will be interesting to see how many jobs robots and computers will replace as the minimum wage increases to $15/hour regardless of the local economies.

Often we live with a problem until we can implement what we perceive is the full solution – No Half Measures Allowed! If you examine the problem closer, half measures may be all that is required. The following half measure eliminated a problem that plagued a company for years.
 
My department created applications for automating machines. These machines could be 25-50 years old and made productive with our automated control system. We created applications on continuous bases. Some shipped every year and others could be a onetime deal. Some repeat orders were years apart. There was no way to tell if we would ever have a repeat order until it arrived.
 
We never built prototypes except for new designs (vs. applications). The applications were created primarily from field surveys. Obtaining accurate measurements during machine downtime was a difficult task. The field engineers often had to make modification on site during installation.
 
We ran a lean shop and the design engineers released one application after another. Engineers either were in the field doing a survey or at their CAD station creating a new application.  There were always orders for new applications and management did not want the field fixes incorporated at the expense of new work. "We may never get another order."
 
We had a system for filing modifications made in the field but no method to retrieve them when a repeat order arrived. As you may have guessed, 1 to 5 years later the same stuff would go out with the same problems.
 
Orders for new applications automatically came to Engineering. Repeat orders were placed into the MRP system by Operations who knew with amazing accuracy, which was the correct product. The problem was the product was not always correct. Though, I had no role in Operations all eyes turned to me when field modifications were required - so I made myself responsible.
 
When a design experienced problems instead of filing the markups as was done for years, I would review the field reports and create a set of detailed notes that described the problem and the preferred Engineering solution vs. the field fix. My written directions were filed with notes from the field engineers. How to remember to make the corrections the next time the application was ordered was still an open question. I was not familiar with the MRP system but others were. I told them what I wanted to accomplish and they found a method for flagging existing applications that required modification.
 
When an application experienced an installation problem Engineering notified Operations. Within the MRP system, Operations would set an attribute, which prevented the application from being placed into the production schedule. No one had to rely on memory. When an order arrived for a flagged application, Operations would inform Engineering. The new order provided justification for work added to the Engineering schedule. Until Engineering released the revised drawings, the application was not loaded into the MRP schedule.
 
Creating the notes and directions when the problem was fresh was simple and fast. The notes and directions were clear instructions the design engineer could follow. The work proceeded faster because the design engineer no longer had to play detective trying to interpret 3-year-old drawing markups from the field engineers. Management was satisfied. Resources used efficiently and repeat errors eliminated.
 
This relatively simple and nearly zero-cost half-measure (closer to 1/20 measure) appears so obvious in retrospect but alluded the company for several years. Management only thought of the time to do the entire incorporation real time. Rethinking the situation allowed a very small expenditure of resources to avoid repeating very costly field modifications.
 
 
 

I recall on a few occasions hearing statements similar to the title. The comment often came from CAD engineers still called drafters 25 years ago. I never heard that statement when I entered industry in the late ‘70s when board drafting was in its final days. There were drafters, designers, Sr. designers, checkers, and engineers. The roles were very clear. If any animosity existed, it needed a subject other than pay to fester. With the advent of CAD eliminating the drafting board, those clear lines no longer exist. On a superficial level, a drafter and engineer sitting side by side at CAD stations can appear to be doing the same work. This has caused delusions at all levels in companies.

Job applicants have told me they have many years experience designing using CAD brand X. After a few bad hires, we started to test applicants. We asked the prospect to start a drawing from scratch and they could not. The delusion that they are doing the same work really struck home. What they did during those years was copy and modified other people’s work. They could never have originated much of what they worked on and had little appreciation for what it took to do so, but they had the title of design engineer. I believe the following article by Matthew Loew, Chief Engineer Daxcon Engineering Inc. explains the problem and defines what a design engineer is.

The task of formal drawing check is no longer required according to PLM and 3D CAD vendors. I think it will make a comeback after one big disaster, but I digress. Whether checking a drawing or document a similar danger of blindness exists.

In my last corporate job, I did a rough estimate and determined I had checked over 10,000 drawings. The following observations and recommendations are based on that experience not a scientific study. Your mileage may vary.

I still use Red, Yellow, Green/Blue color code for checking. I have explained this process to drafters/designers/engineers. Whether they have employed the method or not, becomes apparent very quickly when reviewing their work.

When a document is plagued with many errors, some errors will obscure other problems in the document. In addition, the correction of one error may render other portions of the document in error. In a situation as this, it is impossible to correct, everything in one pass and multiple passes diminishes the objectivity of the checker. With repeated reviews, the checker begins to see in their mind’s eye what should be there vs. what is. If the checker believes they are doing other’s work apathy also takes its toll.

When a document has many errors, it is best to stop the check and sit down with the author. Are they being lazy? Are they lacking in self-checking tools such as Red, Yellow, Green/Blue mentioned above? I have heard some say “let the checker find it.” That mindset results in documents coming back from check looking like a drop cloth at a barn painting.

A properly done drawing should require one check and then one back-check to verify the corrections. A second back-check for minor issues can be expected perhaps 25% of the time. If multiple check cycles are required with each iteration revealing additional errors, the checker is likely to become as blind as the author to the remaining problems.

If right out of the box, you find error after error return the document and review self-checking methods with the author. “Letting the checker find it” can cause blindness.

In my last article Applications vs. Design, I ended by introducing Fermi estimations. As a young engineer, I would struggle searching for exact mathematical models that represented analysis problems. Years ago a Research Engineer gave me three words of advice approximate, approximate, approximate. That same advice is what Fermi estimation i...s about. Fermi may not be a good tool for a detailed proposal but it is an excellent tool to help decide if you wish to submit a proposal especially when you have little data. If you are trying to decide which product to develop or market to pursue from among a few possible choices the process is also useful.
Two observations I made during my years working as an engineer and manager are: 1) At first glance most people under estimate an effort, 2) If you ask a person for an estimate they often freeze. Keeping these two human traits in mind will make Fermi an easier tool to use. Instead of asking how long it will take, it is better two ask “will it take 2 weeks” - you will get a faster response, yes, no, 1 week, three weeks etc. Now you have something to work with. Keep observation 1 in mind. With a hard number offered by a coworker, ask why. They will reveal what hard points they used to make the assessment. This is all happening real time. This could reveal issues you were not aware of or self-imposed requirements your coworker used in his estimate.

For a family story about observation #2 see below*

To address observation number one above, just break down the task into smaller pieces. If there are teams break it down along the team functions, mechanical engineering, electrical, purchasing etc. Within each group break it down further. How far you need to go will vary from project to project and how exact an answer you require. Breaking it down is a key step. It allows people to focus on a small aspect. Another phenomenon is that some estimates will be high and others low so many smaller pieces will have an averaging effect.

You can do a good job of estimating unfamiliar things by comparing it to things the team members know and have hard data for. Project X took Y hours of lab time and we had previous experience with X type projects. The proposed project has a few areas we have no experience with, there will likely be areas that we discover that we are not familiar with. This tells you it will likely take longer and more money that project X.

Ask simple questions - is this effort more difficult than X? Once you get an answer then ask, is it twice as much or half etc. You will find it much easier to get someone to say yes or no to a hard suggestion than to get him or her to offer the number straight away. If the design looks twice as complex as projects you know multiple the known by the complexity factor. If it took 100 hours for a similar project and the new project is twice as complex, estimate 200 hours.

Who to involve will depend on the situation. For example, If your detailed schedules indicate that in 6 months you will have a large quantity of engineering resources idle, you may want to use Fermi to decide among several design concepts which to develop into a new product. This may need to involve just engineering. If you narrow the selection to two or more you may need to do a similar exercise which includes manufacturing or all departments.

Fermi may sound like wild guessing to you. Think about it this way. If you were guided blindfolded into a room that contained a dartboard on one wall, you would have no idea which wall the target was on or what direction you were facing. Since you have hard data to apply complexity factors to it would be like putting the blindfold on after seeing the location of the target. You may miss the target but you will likely hit the correct wall. Fermi gets you into the ballpark.

Remember that the Fermi estimation is just that an estimate. If your results indicate the project would take 3 times the resources that you have and another project will take 75% you can make a decision. Even if the 3x turns out in the end to be 2.25X and the 0.75X is 1.25X you still picked the lower risk project going with 0.75X – all else being the same. If your estimates for two competing projects are 1.0X vs. 1.1X you may need to dig a little deeper. If you applied the same method to estimate profit and the riskier project (3X of resources) had a profit 10X over the safer project, there is a decision point. Do you borrow money and ramp up staffing?

This process can be used in countless ways. If you have questions don’t hesitate to contact me. [email protected],

If you found this information helpful, there are other articles at www.jagengrg.com/blog

*Now for the family story. When I moved from home for my first engineering job I wanted to continue with the traditional Easter cakes my late mom baked. Many of mom’s written receipts made the German enigma code appear easy to crack. Some would call out items quite clear, 6 eggs for example. For other quantities, all that was listed was “enough” - I kid you not. I asked my sister what was enough - flour in this case. She could not, would not, provide a number after repeated requests. She said use your judgment. I thought I would seek up on the correct amount by the tablespoon. After the first disaster I told my sister, that I used 5 tablespoons. (bakers stop laughing). She instantly said (think Brooklyn NY) “what! you need at least 5 cups.” The psychology here I think is a self-imposed requirement on accuracy. When I asked how much she was thinking 5.1 vs. 5.2 cups. I was the guy who walked into the room blindfolded. An estimate on her part of 4 to 6 cups would have gotten me a lot closer. Once I suggested a number a good estimate came without delay.

Donald Rumsfeld raised many eyebrows when he spoke about unknown unknowns. If you are a design engineer, you have a better appreciation for that comment than most people do. What may not be appreciated is the gap between application engineering and design engineering – here lurks the unknown unknowns.

Many of the unknowns discovered during the development phase will drive the final design. But are the reasons for the final configuration documented and parameter boundaries fully understood? During testing, are we unknowingly approaching the parameter envelopes that minor modifications in the future will allow expected use of the product to exceed the envelopes? To avoid being too abstract I will use an example where I nearly headed down the application path when a design program was required.

A web printing press uses a continuous length of paper (the web) guided through the machine by rollers. Our product used dead shafts to support rollers. Dead shafts are easily aligned in the field. This greatly reduces the precision required for manufacturing the support frames and the skills and equipment required during installation. The dead shafts are steel shafts with diameters ranging from one to two inches. A dead shaft does not rotate. The shaft is attached at each end to vertical frames that are parallel to each other. The roller body has ball bearings at each end with the inner race fixed to the dead shaft with setscrews. Our equipment, which we configured for a great variety of machines used rollers of various diameter and length combinations. Though the two parameters, diameter and length, had many combinations we remained within the parameter envelope and did not realize when we were approaching the limits. This often happens when a design is inherited (transferred from the design group to the application group) and an incomplete data trail exists to explain why the design is as it is.

The initial design accepted a web width of 40”. Later variations ranged from 26” to 80” wide. There was one parameter we did check each time and we were OK. There was another that we did not consider. We were always well inside the envelope at 40” and just pushing the envelope at 80” length but did not know it.

The parameter we were familiar with but never addressed for these applications was the axial alignment of the inner and outer races. The load on the roller induced by the web tension is surprising high. This is very much the case with a 180 degree web wrap which doubles the load. Our concern was always with the bending of the roller body not the shaft that supported it. Though the roller was a thin wall cylinder with end plugs for mounting the bearing’s outer race it had a diameter of 4 to 12” vs. the dead shaft of 1 or 2”. The moment of inertial of the roller body was magnitudes greater than the shaft. Loading on the roller body was evenly distributed by the web. The loading on the dead shaft was a point load at the bearings.

We were a fast turnaround shop. Often fire-ready-aim but good at it most of the time. When management wanted to go to 120” length rollers their expectation was just another two to three week application project vs. a design and development project which will take considerably more time. Design engineering and application engineering may look similar especially to the sales department but there is a difference. The difference can range from a fine line to a wide and deep canyon. When orders are coming in hand over fist, it is easy skip the assessment and in short time find your team as the bottom of that canyon.

Recalling the pain caused by those fire-ready-aim projects that went bad, I was able to insist on a proper study. One of the unknowns that became a known was the length limit for which dead shaft rollers are used. Too long and the bowing of the dead shaft creates too large of an angular misalignment of the bearing races. You can increase the shaft diameter but the shaft’s own weight causes it to bow with gravity. In short, at some point rollers needs to go to live shafts and at 120 inches we were way past that point.

Live shafts require bearings mounted in the support frames that required machining accuracies that would have turned the entire product line on its ear. Someone likely picked the dead shaft approach early on and so much of the design and installation became depended on it. That simple fact of inner race to outer race angular alignment had a major ripple effect on the entire design and alignment process during installation.

My study was fast and dirty. How close I was to a true budget and schedule will never be clear. The study clearly indicated the effort we faced was not just another application. Had we proceeded we would have quoted prices and schedules that would have proved impossible to meet. The resources to develop the design were too great and the project dropped with minimal resources expended.

I was able to do the study very quickly using a method I watched an old sage use to put together a multimillion-dollar budget estimate in less than two hours. I later come to learn I was using the Fermi estimation method. Fermi estimation is a powerful tool and would make a good article for the future.

Is possible to make a part “too good”? The answer was yes in the following case and I suspect there are many other examples out there. Often the requirements placed on engineering drawings are copied from previous designs. When done with little or no understanding of why the original design had such a callout, unexpected results will likely take place. The situation most often experienced is too tight of a tolerance that results in unnecessary cost to manufacture and additional cost due to scrap or rework but not poor performance.

Why would engineers and designers use specifications they do not understand?  There is always the pressing schedule and time to market.   Not reinventing the wheel is also very popular. If it was good enough for design 1 why not for design 2? If design number 1 had been truly understood, carrying the requirement to the next design could be valid. 

The case at hand had to do with synchronized manual transaxles. The synchronizer consists of a few parts that allow the gears to mesh without grinding when shifting from one gear to another.  Without going into the theory of synchronizers suffice to say there are surfaces with teeth and others smooth. The smooth surfaces had a surface finish callout that had been successfully used for years perhaps decades.  So again, why reinvent the wheel?

A new and similar design was created and the callout for surface finish was copied. It had worked for millions of parts so why look any deeper. The new design was expected to be in high demand so it was decided to have the parts made both in-house and at a Japanese company. Parts coming from this Japanese supplier were always dead nuts nominal with little variation. When the transaxles containing the subject parts were tested, the manual shifting did not feel right. The shifter seemed to stick and shifting was very poor.

As I described in previous post the first item checked is the drawing callouts. This of course was OK. Next check the “offending” parts and they too were to specification. Someone then decided to check the in-house parts made to the same specification that worked successfully for years.

Feature callouts such as holes or linear dimensions have upper and lower limits. Surface finish is often specified as a maximum with less roughness than specified expected to be a benefit. As we learned this was not the case for this design.

When the in-house parts were inspected in the lab vs. the production QC the parts were not to specification. They likely never where to specification. They were rougher than the surface callout on the drawings. The parts that were not to specification worked and the parts out of specification did not. How can that be possible?

If you have ever experience rubbing Jo Blocks together you know how they stick together as if magnetic. The reality of the attraction is the elimination of air between the two surfaces. The supplier had made the parts to specification for the first time, which resulted in the Jo Block effect - squeezing out air and much of the lubricant. When it was time to shift gears the parts on the synchronizers that were to separate required an unacceptable amount of force to get them apart. The solution was an additive to the lubricant that altered the surface tension. That addressed the transaxles in the field. Going forward the surface callout was relaxed to provide sufficient roughness to maintain a film of oil and not result in a Jo Block effect.

The case here points to a lack of QC at that time. Had the parts been made correctly or inspected correctly a better understanding of the effect of surface callout would have resulted. To rely on CQ is not a good approach to design.

There is a deeper lesson to learn here about the nature of design. There are the things we know; the unknowns, and the bugaboo - the unknown unknowns.  I plan to post some thoughts on this aspect of design in the next few weeks.