Leading research and innovation

Tags: MSR, IEEE SIGNAL PROCESSING MAGAZINE, curriculum reform, Reflections, Microsoft Research, J.H. Winters, IEEE Signal, pointing system, Peter Chu, G.A. Moore, signal processing, research team, digital signal processing, undergraduate research projects, Harper Collins, DSP research group, PictureTel, C.M. Christensen, team members, members, leadership concepts, electrical engineering department, effective leadership, Harvard Business School Press, source localization, Arye Nehorai, automatic camera, Living on the Fault Line, H. Wang, IEEE ICASSP
Content: [ ] leadership REFLECTIONS
Henrique S. Malvar
Leading Research and Innovation
My first reaction when Prof. Arye Nehorai invited me to write this article was to feel honored: I would be in great company. I've enjoyed reading the "Leadership Reflections" column, from the first excellent article by Max Nikias [1] to the many great articles that followed. My second reaction was a reality check: I'm 49 and relatively young to contribute to this column, a similar reaction to John Cioffi's [2]. On the other hand, I've been managing groups in academia and industry for more than 25 years, so maybe there are a few ideas about leadership that I can share. I'll start with some Historical Perspectives of my career, so you can understand my mindset, with emphasis on things I've learned about leadership. Then I'll review some of the approaches towards leading innovation at Microsoft Research (MSR), because some of the ideas could be applied to other research labs. Finally, I will highlight key characteristics in a good leader through guidelines that I strive to follow. LEARNING TO LEAD My first job experience in management was similar to learning to swim by being thrown in deep water. Even if people are nice to you and say, "go ahead, you can do it," it's probably not the best approach. Back in 1980, I was only 23 and an assistant professor at the electrical engineering department at University of Brasнlia (UnB), Brazil. To my surprise, I was elected associate head of the department, in spite of being the youngest faculty member. My first naпve reaction was, "I must be very good, they picked me!" Soon enough I learned that I was just the
one without specific political agendas and ties, and there were enough people yearning for renewal. As associate head I did not have as much power as the head, butI did have some power and significant influence. I was tasked to lead several efforts (such as a curriculum reform), so I had to learn what leadership meant very quickly. Like many in similar situations, I immediately recognized and experienced the main dangers of leadership, which are well summarized by Heifetz and Linsky [3]: marginalization (being pushed aside, e.g., by not being invited to key meetings), diversion (being dragged to new activities to distract you from your main goals), attack (usually via excessive criticism towards your ideas and comments), EDITOR'S INTRODUCTION The author of this article has made many contributions to academic and industrial research in SIGNAL PROCESSING, especially in multirate systems and signal compression. Henrique (Rico) Malvar is a director of the Microsoft Research (MSR) main lab in Redmond, Washington. His management career started very early, as he says, by "learning to swim by being thrown in deep water." He shares with us some of his experience, with emphasis on Leadership Lessons he learned. He also shares some of the culture at MSR and how leadership concepts are applied to his management of many research groups at the MSR Lab. Rico closes with some additional tidbits for effective leadership, which we hope will inspire our readers. --Arye Nehorai "Leadership Reflections" Column Editor
and seduction (e.g., using tactics such as flattery and exploiting your own desire to do the right things to make you change your focus, to the point where it breaks loyalty from your initial supporters). I was lucky to not run into too many of these dangers, so that things worked reasonably well; we were able to complete the curriculum reform and other projects in the two years of my term. My main contributions were organizing the processes and guiding the meetings towards consensus. The two factors that helped me the most were the support of many senior professors and my admission that I really didn't know anything about management and leadership; I would do my best and work hard, but the faculty would have to be patient with my mistakes along the way. I took a five-year leave from 1982 to 1987, four years for a Ph.D. program at the Massachusetts Institute of Technology (MIT) and one year to work as a Research Scientist at PictureTel Corp., a videoconferencing company. I learned a lot about leadership from my MIT advisor, Prof. David Staelin, in particular, how to motivate people to pursue their ideas and how to carefully bring in some new viewpoints so that people can learn on their own to change gears. He never told me that any of my ideas were bad, but of course some were. His motivation techniques were at time humorous but still efficient: we would have a brief progress review meeting every Friday afternoon; the following Monday morning, he would hear my footsteps going to my office and would greet me with "Good morning, Rico; any new results?" Dave also set many great examples on fostering independence. When I talked to him about ideas for modulated lapped transforms,
which followed my thesis work on lapped orthogonal transforms, he told me: "Rico, from now on your continued research on lapped transforms is your own; I'll be very glad to discuss new ideas with you, but I won't be a coauthor of any new papers." His easiness in giving away credit to help push others forward is an great example that I always try to follow. In 1987, I was back at my faculty position at UnB. What I learned from Dave and others at MIT helped me create a new research group on digital signal processing (DSP) [4]. The main challenge was how to motivate the best students in to join our newly formed group. Toward that goal, we created a graduate program in signal processing, obtained funding for several undergraduate research projects, and, perhaps most importantly, taught many undergraduate courses: from basic electronics to elective courses, including a new one on basic DSP. Many years later, in 1993, I was contacted by my friends Jeff Bernstein and Brian Hinman at PictureTel in Andover, Massachussettes (PictureTel was later acquired by Polycom). The director of research position was open, and they encouraged me to apply. After extensive but enjoyable interviews, I was pleasantly surprised that they offered me the job. At PictureTel, I had my first opportunity to lead a very bright team of researchers in the United States, including folks like Gary Sullivan and Peter Chu. I learned tremendously from them, especially from the team's first criticism after a few months: "Rico, you're running our group as if we were in academia; go raise our visibility inside the company and get more funding!" I took the advice seriously and worked hard to develop strong connections with the leaders of the engineering divisions, from key engineers to vice presidents. I quickly learned how to sell our ideas. At PictureTel, our research team took on some high-risk projects; not all of them panned out, but two of our successes are noteworthy. First, our expertise in wideband speech coding led us to win the ITU-T competition for the 24 kb/s wideband speech standard G.722.1, the only modern speech coding standard whose Intellectual Property is entirely owned by
a single company. Second, in 1996, we shipped the world's first videoconferencing camera that could automatically pan, tilt, and zoom to the person or persons speaking in a teleconference, using sophisticated three-dimensional sound source localization algorithms from the signals captured by a four-element microphone array mounted at the base of the camera, thanks to the great work by Hong Wang and Peter Chu [5]. In 1997, I moved to MSR as a senior researcher, with the goal of forming a new DSP research group. I was very fortunate to have two senior researchers join the group within a few months: Phil Chou and John Platt. In 2002, the group had grown to more than 20 people (large by MSR standards), and in 2004, it split into two new groups led by Phil and John. At that time, I became one of the directors of the MSR Redmond Lab, where I now oversee 11 research groups with about 150 people; roughly two-thirds are researchers, including several IEEE and ACM fellows, and over half have Ph.D. degrees. Our teams cover a wide variety of areas, including communications systems, vision and image processing, text and data mining, databases, search, speech and natural language processing, adaptive systems, and machine learning. MSR AND TECHNOLOGY TRANSFER MSR was founded in 1991, so it's a relatively young corporate research lab. There I've been learning a lot about leading corporate research and what it takes to develop truly innovative technologies and bring them to market for the benefit of many millions of users. Although MSR has a relatively unique culture, it is useful to look into its mission and some of our practices, because they provide insights that can be useful for the management of other research organizations. The two main tenets of MSR's mission are advance the state of the art in each MSR research areas rapidly transfer innovative technologies into Microsoft products. It is important to emphasize that advancing the state of the art comes first; product contributions come second. To advance the state of the art, it is funda-
mental to foster unconstrained research and significant collaboration with academia. Publishing and providing academic service (editing journals; coorganizing conferences; hosting postdocs, visitors, and interns) are not just desired from our researchers, they are required. How can MSR be successful in the second goal, rapidly transferring technologies into products, if researchers can work on whatever they want? History tells us that in a corporate research lab, lots of freedom may lead to lots of results that can't be used in products [6]. A hint toward the answer is a trick I usually play with Young Job candidates; I tell them during the interview, "here at MSR you can work on anything you want," which brings a smile to their faces, but then I continue with "as long as you work on the right things." That changes the smile to a frown, and they'll ask, "ok, that means you or my direct manager will tell me what the right things are, right?" Then I smile and say "of course not!" Then they continue frowning for a few seconds but ultimately realize the simple message: with freedom comes responsibility. That means we motivate our researchers to be bold, creative, and think first about the long term: in five to ten years, what technologies will bring greater productivity or enjoyment to people's lives? Once you determine the main goals, then figure out how can you choose the path toward them so that as you make progress you'll be able to create intermediate results that can be used in products in the near to medium term. The above is easy to say but hard to do. Researchers should learn how to affect products and how to sell their ideas to product teams, especially young ones fresh out of graduate school. However, they need help to be effective at that. Ultimately, the most effective researchers do a lot of selling of their ideas to product teams. Another simple trick can go a long way in helping the process: researchers should contact key developers or managers in product teams and offer help with advanced development projects, maybe an evaluation of Alternative technologies or the definition of proper performance
[ ] leadership REFLECTIONS continued
metrics. Those are not truly research projects and may not lead to any publications. But by providing such help, researchers will earn the trust of those teams, so they're more likely to listen when researchers come back and say, "remember that thing I was trying to help you make work more efficiently? What if we take it away and use instead this new thing I invented?" That works more often than not. Do I mean that in leading an industrial research team, we should always seek to invest in projects for which the path to product adoption is well defined in advance? Of course not! Even a small research group should have a portfolio of open-ended projects, driven by the goal of long-term of TECHNOLOGICAL INNOVATION. Without enough freedom in research, we can't be disruptive [7], [8] and introduce significantly new products in the future. IDEAS FOR EFFECTIVE LEADERSHIP Let me share with you some guidelines that I believe leaders should follow. These guidelines come from my own experience and mistakes, advice from friends and colleagues, and reading and formal training. Never stop learning. Be enthusiastic and motivated to broaden your understanding and learn new things. You can't lead if you don't have a fair understanding of your team's work. Always revise and challenge your assumptions. Resist the temptation to apply your wisdom to new situations where it doesn't apply. Throwing away assumptions is a big step toward invention. Do not compete with your own team! This is really important, as well stressed in Larry Rabiner's contribution [9]. For example, do not add your name to the author list of a paper just because you gave the team many ideas for the project. Communicate clearly. Write short e-mails; be direct and specific. Listen a lot and speak a little. Listen first and speak last. Be very clear and consistent about mission and goals. Be close to your team. Don't just meet with your direct reports; try
to meet with every member of your team as much as possible. I have a "lunch with the director" program, in which every week I take a member of one of my groups to lunch. I can then hear first hand about their work and the issues they consider important. Motivate bottom-up thinking. Don't tell your team what to do; instead, ask questions that motivate them to develop new ideas. Drive new projects based on their ideas, not yours. Even if you had an idea first, don't tell them; let them figure it out. Kill your own projects and initiatives. In other words avoid inertia, be adaptive. What works today may not work tomorrow. That's so easy, so obvious, that we forget to do it! Become less important over time. Don't just try to make the right decisions; teach your team to make them. Empower people to grow into management and to eventually replace you. More likely you'll grow into a new job where you'll get to repeat the cycle: learn, teach, and move on. Reward failure. It's especially true for research. If a project fails, reward the team for having taken the bet and trying hard to make it work. Else you'll foster evolution, not innovation. Guide by example. For instance, if you believe that members of your team should be good at writing software code, then write good code every now and then and don't be afraid to open your code to their criticism. Be consistent with your values. Motivate behavior that achieves your goals, and reward the accomplishments. At MSR we are successful at product contributions in part because team members are rewarded for technology transfers. Don't avoid politics. Understand it, find partners, and keep the opposition close [3]. Hedge your bets. Do not spend too much on the technology du jour. You don't know where your next breakthrough will come from. Lose arguments. Let your team members prove you wrong; invest in
their doing so. Besides fostering innovation, they'll get a kick out of it. Learn from your mistakes. That's well known, but do we really pay enough attention? Remember that first you have to admit your mistakes.
AUTHOR Henrique S. Malvar ([email protected] com) is a distinguished engineer at Microsoft and a director of the MSR Laboratory in Redmond. He holds a Ph.D. from MIT in Electrical Engineering. Before joining Microsoft in 1997, he was a vice president of Research and Advanced Development at PictureTel Corp., and prior to that he was with the faculty of University of Brasilia for 14 years. As a director at MSR, he oversees the activities of several research groups, from image and speech processing to databases, machine learning, and search. His technical interests include multimedia signal compression and enhancement, fast algorithms, multirate filter banks, and wavelet transforms; he has more than 120 publications and 40 patents in those areas. He is a Fellow of the IEEE. He received the 1981 Marconi International FellowshipYoung Scientist Award as well as the Best Paper Award in Image Processing in 1992 and the 2002 Technical Achievement Award, both from the IEEE Signal Processing Society.
[1] C.L.M. Nikias, "Elevating a school," IEEE Signal
Processing Mag., vol. 20, pp. 12­14, Mar. 2003.
[2] J.M. Cioffi, "Ask me again in ten years!," IEEE
Signal Processing Mag., vol. 21, pp. 8­11, Nov. 2004.
[3] R.A. Heifetz and M. Linksy, Leadership on the Line.
Boston, MA: Harvard Business School Press, 2002.
[4] University of Brasнlia Digital Signal Processing
group page [Online]. Available: http://www.ene.
[5] H. Wang and P. Chu, "Voice source localization
for automatic camera pointing system in videocon-
ferencing," in Proc. IEEE ICASSP, Munich, 1997,
pp. 187­190.
[6] J.H. Winters, "Reflections on industrial
research," IEEE Signal Processing Mag., vol. 22,
pp. 6­8, July 2005.
[7] C.M. Christensen and M.E. Raynor, The
Innovator's Solution. Boston, MA: Harvard Business
School Press, 2003.
[8] G.A. Moore, Living on the Fault Line. New York:
Harper Collins, 2000.
[9] L. Rabiner, "Leadership--Some random
thoughts," IEEE Signal Processing Mag., vol. 21,
pp. 16­20, Jan. 2004.

File: leading-research-and-innovation.pdf
Title: Title
Author: Author
Subject: Subject
Keywords: Keywords
Published: Tue Aug 29 10:57:45 2000
Pages: 3
File size: 0.15 Mb


Punished by rewards, 6 pages, 0.08 Mb
Copyright © 2018 doc.uments.com