WisBiz People: UW Engineering Dean Says Tech Transfer is a Contact Sport
This is a new edition of WisBiz People, a column from WisBusiness Editor Brian Clark. If you know someone with a good business story to tell, write to email@example.com with your idea.
Paul S. Peercy, dean of the UW-Madison College of Engineering for the past five years, likes to call technology transfer a “contact sport.”
He doesn’t mean bruises and broken teeth, though, as in hockey or football. Peercy is talking about interdisciplinary research with scientists and engineers talking to each other at the earliest stages of product development.
WisBusiness.com editor Brian E. Clark recently interviewed Peercy, who guides a highly ranked engineering college with more than 3,600 undergraduates, 1,600 graduate students and an annual operating budget of approximately $150 million. Under his leadership, the college has set annual records for both research funding and patent disclosures by engineering faculty and staff.
Prior to joining the college, Peercy was president of SEMI/SEMATECH, a non-profit R&D consortium of the nation's leading semiconductor industry suppliers. Prior to that position, he was director of microeletronics and photonics at Sandia National Laboratories in Albuquerque, New Mexico. He received his masters degree in 1963 and PhD in 1966 from the UW-Madison Department of Physics.
His research spans several areas of solid-state and materials physics and engineering, and he is the author or co-author of more than 180 technical papers, co-editor of several books, and holds two patents.
Brian Clark: How is technology transfer a “contact sport?”
Paul Peercy: When a researcher develops a new technology or invention, there are not only the things that are written down in a patent application that are important for applying that invention, there are also other things that aren’t recorded in the patent itself.
They include what you might call the “art” of research, such as a knowledge about how things work and what sort of changes you should or shouldn’t make in the way something works as you are trying to advance from a research concept to a usable process technology or a product.
It is very difficult to move from research concept to a new technology or a new product without hands-on, face-to-face interaction by the researcher with the real-world process or product he or she is trying to improve. That’s what I mean by a contact sport.
Clark: Contact in sports sometimes implies roughness and blood.
Peercy: There can be some of that too. (chuckle). Especially when your ideas, ones that you think are just fabulous don’t really work. It might not be actual blood spilled, but there can be a lot of healthy give-and-take back and forth between the parties involved.
One of the observations I have about research scientists and research engineers is that they tend to be quite optimistic about easy it is going to be move something from a concept and demonstration into a prototype than is actually manufactured.
There is often a huge underestimation on the amount of time something requires. And that time and effort is even greater if an activity is being performed by a group that did not do the research and does not have that background as the original researcher.
Clark: Is that because scientists have trouble working with business people?
Peercy: No, I was thinking of the actual product development, not so much the business side of the world or marketing.
Here’s the difference: I have spent time as a research scientist, as well as on the engineering side and as a manager where we were responsible for delivering products at Sandia Labs and also as president of SEMI/SEMATECH. I had a good deal of experience for delivering products.
The situation is that a research scientist or engineer has an idea, they pursue it and if it turns out to be very difficult, they are free to rethink and change directions. And they might have an even bigger breakthrough than if they had followed their initial idea. Or they might discover something tangential to it that is even more promising.
If you are developing a product, however, and you have promised a customer you are going to deliver that product by a certain date and somewhere along the way you get a good idea for a different product, the tendency for the researcher is to pursue this different product. But that is not what you committed to deliver to your customer.
Researchers need freedom to follow their creativity and best ideas to the end point. It is much more difficult to refine a product until it is easily manufacturable and highly reliable and something you are willing to put your company’s name on warranty and provide service -- than it is to do the first prototype from concept. It’s not that you don’t want to develop that prototype, it’s just that it takes a very different discipline to get from the concept and prototype to the finished product in the marketplace.
Clark: Were you frustrated when you were in private industry when you worked with researchers?
Peercy: Oh no. This doesn’t frustrate me at all. You just needed to understand what the strength of the different groups are.
Clark: Did you ever have to rein the researchers in?
Peercy: No, that is the wrong way to look at it. The right answer is you need to put the right team together. For tech transfer to work well, you might have a “post-doc” researcher move between the research group and the development group, back and forth, carrying information and bringing new knowledge. But also helping develop the manufacturable prototype.
You put the team together that wants to develop a prototype that will satisfy the customer and make a contribution to the company, the economy or society. Then the research scientists know that they will advance technologies and be there for the next generations.
Clark: What if the research scientist wants to go off on a tangent? Who would rein him or her back in?
Peercy: I don’t think that is the right question. The right question is who put that person in charge of the development team. You might want a development engineer in charge of the development team. And let the research scientist generate the new knowledge and be available to answer questions.
Clark: What worked or did not work well in your experience?
Peercy: I won’t name any lab names, but one approach that doesn't work very well is to have central research labs where scientists come up with lots of great inventions and then “toss them over the wall” to the development side of the house. Then those folks would eventually develop products and make money.
That system of technology transfer did not work very well. It was almost dysfunctional because there was no contact. Researchers thought their job was to develop ideas and the others thought they were supposed to develop products.
You really need an interdisciplinary team with cross-disciplinary interaction and multiple contacts. But you also need to let different members of the team function in the areas of their strength and unique contribution.
There is an art to what author Peter Drucker called managing “knowledge workers.”
Clark: How do you define knowledge worker?
Peercy: A knowledge worker is someone who by definition knows more about what he or she is doing than their supervisor. If that is not true, then the supervisor has hired the wrong person. So you need to let these people know which hill you are going to take, and let these people develop how you will take that hill. They are the ones with that knowledge.
There are some who will come up with that knowledge and others who are better suited to developing those ideas into hardware or software or usable products that are robust enough to generate the revenue to support what the knowledge workers are creating.
Clark: Is that common practice?
Peercy: Historically, it was uncommon and it used to be that the physics community was separated from the engineering community and separated from the medical community and separated from the chemistry community and so on.
If you look back over past 100 years, we had broken science and engineering into focused areas and they did not work across the areas. We did that because we did not have adequate understanding and breadth to handle it all at once. So we handled small vertical parts of it.
Then we drilled down to the scientific bedrock of understanding and came to the same common bedrock whether you were in chemistry or engineering or physics. Now we are putting it all back together. Starting late in the 20th century, we began to recognize the value of interdisciplinary research. If you look at the College of Engineering today, it is the administrative home of 40 interdisciplinary research centers and 15 industrial consortia. Recently, we had a two-day review of the annual work of the Engine Research Center with all of our corporate sponsors. They had their scientists and engineers here interacting with our scientists and engineers so they could learn as much as possible and apply it back in their work. It is people talking to people, conveying all the hidden knowledge that goes into developing advances.
Clark: Who makes the best manager for technology transfer?
Peercy: I don’t know.
Clark: Obviously, that person has to have technical skills, but is it personal skills that comes next?
Peercy: I think knowledge of the technology is absolutely essential. In fact, it is very hard for me to think that someone could manage a high-tech company today without some appreciation and understanding of the technology.
They also need a pretty good breadth of experience and training, so it helps to have been moved around in sub-disciplines in their careers so they are conversant with other disciplines. The most important thing in managing an operation is to recognize what other disciplines can bring to help you and when you need to engage them and at what level.
Clark: For example?
Peercy: If you had a mechanical engineer designing a product 30 years ago, the first thing that mechanical engineer would have done was look up the mechanical properties of different materials to pick out the best one. Today, he or she should talk to a materials scientist and say, “I’m going to design this product and I would like you to design a material with these properties.”
But very quickly, that mechanical engineer should ask, "What kind of information technology, sensors, networks, microprocessors and embedded computers do I need in this product? Does it need to be adaptable and reconfigurable as the environment around it changes? Does it need to be smart?" That was not in the traditional mechanical engineering way of thinking, and that is why you need an interdisciplinary team.
Clark: Have you been successful in breaking down the walls?
Peercy: At UW-Madison, yes. Collaborations across campus are very easy. We reward interaction and we reward joint appointments with other colleges and vice versa. It is counted high in one’s performance. We have been very successful at the graduate school level and research level. Now, we are working to extend that down to undergrad education and research level. A BS degree is a professional level engineering degree and the students that we educate will need to have the same appreciation of information technology, sensors, material science… and know when to engage people from those disciplines. Today, even more, you are going to have to have a global awareness and a cultural awareness because efforts often require a large design team that will not only have not only engineers, but business people and customers and even marketing folks. You’ll want to design a product that will reach to the global market place and span multiple cultures.
Clark: Are there many cases where research scientists go on to successfully run companies?
Peercy: I have a doctorate in physics and I was president of a company for five years. If you look at the semi-conductor industry, all of the start-up companies that moved from that phase to mainstream companies such as Intel were led by people with science or engineering degrees. Now as they mature, things like handling exposure to global currency fluctuations and management of knowledge pieces become more important so you see the normal maturation of a company and its management.
Clark: Is Wisconsin a good place for technology transfer?
Peercy: It is. We’ve done a better job in the biotech and bio-medical related areas in Wisconsin than perhaps we’ve done in information technology. I’d look to see us do more with information technology.
Clark: Why has there been less success with IT?
Peercy: I think UW-Madison is unique in that it has not only physics, chemistry, mathematics and computer science, plus a full suite engineering disciplines. But it also has a lot of bio-related activities in agriculture, life science, medicine, nursing, veterinary medicine, pharmacy, letters and science as well as engineering. So if you had to pick a real strength that is recognized around the world, it would have to be bio-related. That is a large amount of science, engineering and technology you can build on to start a company.
There also has not been an existing base of high-tech companies, and by that I mean the semi-conductor industry or computer industry, here in Wisconsin that built up a large infrastructure in that area, which helps start-up companies. If you want to start an IT-related company in the Silicon Valley, for example, or Austin, you can focus totally on where you add value and get all the products and services need from the infrastructure companies in the area. That makes it mechanically easier to get up and running.
Clark: Is IT part of the engineering school?
Peercy: It is a very strong program in engineering, but it is big in computer science, too.
Clark: What role will engineering play in the proposed Institute for Discovery?
Peercy: Engineering will be a key component. The dean of the medical school said to me early on in my tenure here that we need to have engineers involved in stem cell work or we’ll never get breakthroughs out into the hands of physicians and health care providers. The Institute for Discovery will advance the horizons of human biology. It will build on stem cell research and build on other areas such as genomics (the study of genes and their functions) and proteomics (understanding total protein expression), but it will engage information technology and engineers and computer scientists in engineering solutions.