The Human Element of Technical Projects
When I graduated with my Bachelor’s Degree in Mechanical Engineering, I moved to Silicon Valley to work closely with our clients. During that year, I was the project and engineering lead on a product that was approaching its launch date. I worked closely with Eric, my counterpart in Taiwan, who was the tooling and manufacturing lead. Through the early phases of design and into the engineering design phase, things on the project went pretty smoothly. Near the end of the engineering design phase, however -- as more and more resources were dedicated to tooling and manufacturing -- Eric proposed a new concept for a critical component of the product. Unfortunately, it quickly became a matter of Chris’ design versus Eric’s design – at least that was how my mind viewed it.
As the engineering lead, I did a deep analysis of the two designs. They were both made of the same materials and used the same general manufacturing process. Any difference in cost between the two designs was negligible. The lead times for tooling were comparable. When I analyzed the mechanical performance of the two designs, however, I could see that mine was clearly superior. I could prove this mathematically, and I did. Just to be sure, though, I hired an engineering professor to do the analysis independently.
As I struggled with how to handle the disagreement on my team, I discussed my thoughts with my boss. I told him it was pretty clear to me – my design was best. I could sense his hesitancy, but I didn’t understand why he had any hesitancy at all. I even tried to convince him by making an ill-fated analogy about the stock market, and that clearly he would always want to invest in stocks with the highest rate of return. While he could see where I was going, he was wiser, more mature, and capable of seeing more than just the engineering numbers.
As a good mentor, he taught me a lesson that has affected my career ever since. He said simply this: if Eric wants this product to succeed, it will. If he doesn't want it to succeed, it won’t.
In my pride, I had missed two critical points about this collaboration:
1- The notion of sufficiency versus superiority
Eric’s design was mechanically inferior to mine; I had all the math and experts to show it. But… Eric’s design did indeed satisfy all the requirements, a detail I ignored. My design was not going to fail, and neither was his.
2. The human element of technical projects
I had lived with the design through the requirements definition phase, the conceptual design phase, and nearly all of the engineering design phase. My intense interaction with the product was about to end, while Eric’s was just ramping up. The fact was that Eric would handle all of the future bugs and problems with this product as it was mass produced. This is where my boss’s lesson rang true; if Eric wanted it to succeed, it would.
As the project lead, I had to choose. Chris’ design, or Eric’s? It is surprising to me now how obvious the answer is, though at the time it was very difficult to know what to do. As you have already guessed, I chose Eric’s design, and I am really glad I did. The project moved forward smoothly, the product went to market and the company made a lot of money from that product.
Would Eric have really sunk the project if his concept wasn’t chosen? No, I don’t think so. But I do believe the important lesson my boss taught me. By choosing Eric’s design, I became a better team player – seeing more viewpoints than just my own. I’m sure Eric felt a greater sense of ownership, having his voice heard and valued. While I have not asked Eric about this, I do believe that the ownership Eric felt made it easier for him to be more committed to the project and the company and possibly more capable and willing to make the project succeed as well as it did.
