I usually don't publish letters in my editorials. But I'd be shortchanging everyone if I didn't make an exception in this one case. It comes from Nathan Jones, founder of Automated Tooling LLC in Los Gatos, Calif.
Enjoyed your column, “A formula for success,” in the February issue. I agree on all fronts. When designing new machines, there's always someone who wants me to “draw up a table,” then put everything on it. My approach is always to start with the heart of the process and work my way back to the ground. When the load path and forces are taken into account, the optimum design of the structure usually becomes apparent.
One thing I would add to your list, though, is “Evaluate project parameters.” When I undertake a project, I'm often given a list of things that are non-negotiable, some of which can cause a lot of extra work and complexity.
In one case, I was designing some clean room machinery for a company and discovered a major inefficiency in its manufacturing process. Its products were loaded onto pallets, carried from machine to machine, then removed at the end. The pallets had a huge amount of precision built into them, and despite much discounting, cost over $1,000 each. Making matters worse, there were several automated production lines in the plant, each requiring 100 pallets to run at capacity. In all, the company was spending over $1 million annually per product just on pallets.
After a lot of research and several presentations, I managed to convince the company to transfer the precision from the pallets to the five machines on each line. The solution added several thousand dollars to the cost of each machine, but helped drive pallet costs down to around $50. Had I stayed with the original design constraints, I wouldn't have been able to spot this cost-saving improvement.
Thanks, Nathan, for enriching all of us with this great story. The moral is never take project parameters for granted. It's quite possible that the person handing them down is stuck in a less than optimum frame of reference or may have an overly narrow view of things.
Nathan's experience also reminds me of something we touched on in the da Vinci series, when we discussed the matter of perspective. As problem solvers, we need to discipline ourselves to explore problem-solution spaces from different angles and perspectives. What's invisible from one vantage point might jump out and hit you in the nose from another.
In Nathan's case, he discovered a better perspective from which he could more effectively leverage overall design intelligence, specifically precision. Even then, however, he faced another challenge, that of convincing someone else to look at things from a different angle. Ultimately, it was Nathan's skills as a communicator, and his persistence, that carried the day.
We can all do these things, by the way, if we work at it. And we can all, like Nathan, contribute to each other's success and raise one another's level of knowledge by sharing our most valuable insights and experiences.
How about some others out there? What can you share that might benefit the rest of us?