Scoble is baiting me to talk about what it's like to work in MSR. What follows started two hours ago as a short thing; then I got on a roll and it all started pouring out of me, so I just went with it. Apologies in advance for the length and the somewhat train-of-thought path through it all.
This is by far the best job I've ever had. I love coming to work every day. When I was working in MS product groups, I loved the fact that everyone I worked with was smart. In MSR, everyone I work with is scary smart.
There are many stories of research labs that publish lots of papers but never actually get any of their work into real products. There are also the opposite: labs that become extensions of lines of business, but never actually publish anything (and there are two flavors; those that never do real research, and those that do research but aren't allowed to publish; Google Labs is a great example of the latter). We try to do both, and I think we've been very, very successful.
To be a truly world-class research lab, you need to do four things:
1. Hire great researchers
2. Empower them to do great research that advances the state of the art
3. Publish it in peer-revewed journals and proceedings, thus getting the validation from the larger research comunity of the quality of your work
4. Get it into products.
We work super hard at all four.
It turns out that the secret to #1 is actually doing a good job at 2,3, and 4, so let me talk about them first.
There are three main kinds of funding for a corporate research lab: central corporate funding, funding from lines of business, and outside (usually government) grants. Each has its plus and minus. Central funding means that researchers don't have to waste time scrounging for money and can focus on doing great research, but you need to find other incentives for tech transfer;. Funding from lines of business gives them "skin in the game" and increases the likelihood of tech transfer, but creates a slippery slope where a line of business will often declare the things that dropped off of the feature list for their next release as "research" so that the research team becomes work for hire. Outside grants are a huge time-suck (though line-of-business funding can be too) and it's very easy to lose control of the intellectual property.
Microsoft Research is entirely centrally funded. In fact, most research groups don't have their own budget that they have to manage; the senior management of MSR tries to give people what they need but let them stay really focused on just doing great research.
Part of my team is responsible for making sure that we do a good job of tech transfer in spite of the lack of internal financial incentives, and we take a unique approach to doing it. I've spent a lot of time looking at successes and failures of tech transfer our of research labs, and I came to the conclusion that most people think of technology transfer as some sort of Rube Goldberg machine -- technology goes in one side, weird things happen in the middle, and if all goes well it pops out on the other side. And people wonder why the landscape is littered with failed attempts... Tech transfer, when successful, is not a mechanical, logistical process; it's a social process. It's all about people, communication, trust, and relationships. When I built my tech transfer team, I decided that we would embrace this philosophy, so I hired in the best relationship managers I could find and told them that it was their job to build communication and trust between people in MSR and people in our product groups. I told them that I didn't want them devising forms, and processes, and procedures; I wanted them building relationships. I told them that we were going to do this as an act of faith that if we could build communication, trust and relationships, then the tech transfer would take care of itself. And it's been stunningly successful. Today, every single Microsoft product uses technology that came from Microsoft Research. Given the number of Microsoft products, this is no small feat.
But it's not enough to do that; we have to advance the state of the art, and publish those advances. It's very easy to hide from the rest of the world and tell yourself that you're doing great research; the only way you know for sure is by vetting it in the open research community. We encourage all of our researchers to submit papers for publication. In fact, we don't have a policy of mandatory legal review before publication, meaning that there is no lawyer censoring or editing your paper before you submit it for publication. (as an aside, this turns out to be a key factor in being able to attract the best and brightest researchers). So what are the results? Well, MSR groups have an impressive track record of publication in key journals and proceedings, including SIGGRAPH, CHI, PLDI, POPL, MOBICOMM, ICASSP, OOPSLA, and a whole litany of other top-rate publications.
Beyond just publications, we also give back to the research community. Many of us volunteer with professional associations; I personally have been volunteering with SIGCHI since 1989. We see this a super important, and MSR management recognizes this as an important work activity.
So how do you hire the best and brightest researchers? Establish the credibility of the lab. Give them the resources they need, without burying them in bureaucracy. Give them the freedom to publish. Make it easy for them to get their inventions into real customers' hands, and reward them when they do.
We actually have a lot of people who moved from Microsoft Research into product groups -- often when one of their inventions moved over, but equally often as a recognition of their ability and a chance for them to try their hand on the business side. When researchers move over, we give them an open invitation to come back to MSR when they feel like they have contributed fully and want to come back. That's a nice validation that there is strong encouragement to try different things and to take risks.
One of the biggest misconceptions about research labs are that they are supposed to be the place where "big breakthroughs" happen. Research is almost never about big breakthroughs. The mission of research is to advance the state of the art, and 99% of that is incremental, in the grandest and truest tradition of the open research community. Researchers look at the great body of work that has come before them, and extend it to the next logical step; they share that advance with the rest of the community, which validates it, replicates it, learns from it, and then extends it even further. Big breakthroughs are in fact very rare, and usually either accidental or serendipitous.
Microsoft Research has groups working on around 55 different areas of computer science. It's my job to try to keep up on all of them. Some days I surprise myself about how much I really know about most of them. Other days I discover that I've been out of the loop on one that had made tremendous progress, and I have some catching up to do. But overall I feel like I'm going to school every day and taking seminars on new topics all of the time.
Why do they let me do this? Because I'm not a specialist; I'm a synthesist. In an organization (and a company for that matter) full of people who drill down deeply in specific areas, I look across all of them and find the ways to fit them together. I just have a knack for it, that most people don't have. This is a dream job for a lot of people, and I get a lot of them showing up at my door wanting to find out if I'm hiring. Of the ones I talk to, most of them just don't pass the bar; they either have some one particular technology that they've fallen in love with, that they think will drive the entire future of computing, or they don't have the critical thinking or lateral thinking skills you need to maneuver through a landscape where the technologies are constantly changing.
That said, I do have a short list of "dominant variables" that based upon today's state of the art (and the future vector) I believe will shape the future of computing. Part of my job is to communicate that both inside and outside MSR, and to drive consensus on what we should do based upon that consensus view. That list includes, but is not limited to:
- large displays;
- machine learning and data mining algorithms;
- large-scale storage;
- a new generation of software development tools;
- e-sciences;
- miniaturization of computing hardware.
Each of those is an essay in and of itself; suffice it to say, though, that I try very hard to make sure that we are building our efforts to critical mass around these areas.
Every once in a while we get complaints from people who think that nothing has ever come out of MSR, or that we don't compare favorably to something like AlphaWorks -- meaning, we don't put enough research prototypes out directly on the Web. We do occasionally release things onto the Microsoft Research web site , and perhaps we should do more, but our experience is that it benefits our customers more if we can focus on publishing our work and getting it into MS products faster. Support for research prototypes can be a ton of overhead, and we try to think carefully about whether our customers will have a good experience with the prototype vs. the amount of support we need to put in place for it. You could certainly argue that we're erring on the conservative side there, and you may be right. I'm not sure that's a bad thing, though.
We get compared to IBM Research a lot. We have a lot of respect for IBM Research. Worldwide, they are about 5 times the sze of Microsoft Research. They have a long and higly respected reputation for hardware and materials research. Honestly, they have much less of a reputation for software research. I know lots of people who work at IBM Research facilities, and I have many concerns about what I see going on there. First, they ask their researchers to get 50% of their funding from IBM product groups; and in an environment where IBM is shedding business and driving down expenses in the rest, what I'm hearing is that it has become extremely difficult to get lines of business within IBM to fund research; so the researchers are spending more and more of their time begging for funding, and less and less actually doing research. What actually concerns me more is their "consulting researcher" model of the last few years, where researchers become part of IBM's services business. I have spoken to a few researchers who have actually enjoyed this opportunity to get out of the ivory tower and spend some time in customer sites; many others are just scratching their heads at the increasingly complex reward system they are faced with as IBM researchers. What I think is more worrisome, though, is the "rent-a-researcher" philosophy and the opportunity to re-label consultants as "researchers" in order to increase their perceived stature and charge a higher per-hour fee. I hope that isn't happening; it must be a great temptation for them, and I truly hope that they resist it because it would hurt their reputation and the reputation of all computing research labs by association. I guess the bottom line for me is that I would rather be us than them; I think our mission is a lot more straightforward, and our incentive system encourages the right outcomes a lot more clearly than theirs. But still, you gotta respect IBM Research.
Working in MSR is my dream job. I have to go home every day and stick my brain in the freezer to get it to cool off, because it overheats almost every day. But I gladly get up the next day and do it again.
11:16:51 PM  ; ;
|
