My Job as a Microsoft Researcher

Recently, I spent some time reflecting on my 6 years at Microsoft Research. I have to thank my new management chain – Shan Lu, Ed Nightingale, Desney Tan – for triggering this analysis of how I view my job. My previous management chain certainly spoke about their values and MSR culture, but I had not been at MSR for long enough to think about or understand what they were saying. Certainly, my experience and goals do not encompass all researchers at MSR, that is one of the really great things about MSR, most of us get to write our own job description. This musing is also not meant to speak for others, even the folks named in it; it is simply my own opinion, values and goals.

Overview of My Job

Many folks have asked me in the past: what is being an MSR researcher like? It’s an interesting question because, in some ways, it is much more nebulous than academia, but on the other hand, I report to a manager, who reports to another manager and so on, and is solely responsible for evaluating my performance. However, I can choose what I spend my time on, whether it is writing papers, writing code, interacting with faculty, grad students or software engineers. My job is not as fixed in terms of how I spend my day-to-day time, and success can be evaluated in a number of ways, compared to academia, where I feel the goal posts are more fixed.

As a result, in addition to defining my own research agenda, some days I feel that I also have to figure out what the heck I’m suppose to be doing in the first place. When I arrived at MSR, they gave me an empty office and just said: do your thing! It took me months to figure out exactly what my “thing” was. This statement is not a poor reflection of my org chart, I am so grateful to my manager at the time, Ricardo Bianchini, the rest of my management chain, (Donald Kossmann, Johannes Gehrke) and the fantastic members of the systems group and other groups who provided tons of advice, guidance and inspiration. But I think most researchers find their own journey when they start at MSR, and this does take some time. The great thing is that no one will really expect you to be productive in a research sense for the first year or two out of your PhD, so this time is really fun – but also scary – because there are so many possibilities, much like when first starting your PhD.

Now that I have done this job for a while, I think I have a reasonably good view of what I strive for. My job seems to encompass three roles: innovator, educator and community contributor. I’ll talk about each in more detail, but these are not so different from academic responsibilities in research, teaching and service (Funding is a whole other issue that could occupy its own post.)

The Innovator

This role is my most important and hardest. My role at MSR is first and foremost to produce ideas, which I see as reading trends, predicting the future and finding gaps where I (my research expertise) can provide value. This role is totally the same as faculty, but I do it from within a hyperscalar that runs tons of services and datacenters. Of course, this environment comes with pros and cons: I have access to software engineers and hardware designers that are in the trenches trying to make things work every day, but my research agenda is constrained by things that help make their lives easier and that the company cares about. The cons are not so onerous because, as a systems researcher, I want to build systems that people will use, and a large (possibly largest??) company like Microsoft inevitably cares about almost everything that matters (take with grain of salt). In fact, having some constraints makes deciding what research to do somewhat easier because I don’t have to guess at whether I’m doing useful research or not; someone will tell me in a pretty direct way.

I find interacting with software engineers to be really energizing, so when I can get their time, I really prefer to find out what their pain points are, what they worry about, what keeps them up (or wakes them up) at night. That said, I simply collect these perspectives to construct a picture with future trends that I see and try to predict where problems will pop up in the future. There are pretty much three types of problems that I have found; 1) problems that exist now that we (computer scientists) know how to solve, 2) problems that exist now that we don’t know how to solve, and 3) problems that don’t exist now but will in the future that we don’t know how to solve (I suppose there are also future problems that we know how to solve but those don’t seem too interesting as they are neither novel nor pressing).

I aim to work on the third category. In the first category, the constraint is often time: while we know how to solve many problems, engineers don’t always have time to solve them, so sometimes I can provide value there. Category 2 is what I imagine that the research groups embedded in various product groups aim to solve (while not speaking for them, certainly some of them are working on Category 3 problems). Working on this third category means that I have the most impact, but it also means that it can take a loooong time for my research to become useful. In the meantime, I entertain myself writing papers, building systems and trying to be useful to my product collaborators.

The Educator

This role is the most fun. In contrast to faculty that teach tens or hundreds (or thousands?!?) of students each year, my role as a researcher is to interact with the thousands of software engineers at Microsoft (and beyond). They spend their days keeping everything up and running, while I interrupt them to talk about the BIG SCARY PROBLEM that will show up SOON and the SHINY NEW SYSTEM that will solve their problem that they DO NOT HAVE BUT SHOULD DEFINITELY CARE ABOUT. I recently had a manager tell me to stop distracting the software engineers with shiny new toys. :)

I find these interactions incredibly rewarding. By and large, my experiences with software engineers at Microsoft have been positive, especially as someone that has done their job out of college (or just someone with sympathy and empathy). Sleep-deprived software engineers that are being woken up on call because their service suddenly increased 10x in size due to the pandemic really do not want a random researcher telling them that they are doing everything wrong, everything is broken, and they must immediately fix it. But that is what I do, and incredibly, these folks that have been working on these services for 10+ years actually listen to me.

My current work on kernel-bypass operating systems is at least half hand-holding engineers as we go into a big scary world of nanosecond latencies and weird hardware accelerators with four letter acronyms. They have a lot of experience, but much of what they are doing now is not going to work going forward to terabit networks, so we spend a lot of time explaining new technologies and helping software engineers figure out how to leverage those technologies for their services. I usually call this part of my role “consulting”, which indicates that I get to tell them what to do without taking responsibility for anything that I break.

The Contributor

The last part of my job is giving back to the research community that I grew up in. I spent much of the first few years post-PhD reviewing papers on PCs; by now, I have chaired quite a few PCs. Microsoft supports our communities by paying me to do this work because it benefits from the research output, and I do it because research is fundamentally a collaborative effort that requires a healthy community of researchers exchanging ideas around the world.

I’ve also worked on generally improving our community. I started the 2019 petition to move both SOSP and OSDI to an annual cadence (with the strong support of my management chain). I started and got MSR to fund a survey and project to improve codes of conduct in our communities. Likewise, my management chain supported me in this by providing most of the funding, but Microsoft also crucially provide my collaborators – Demetris Cheatham and Emma Irwin – that had previous experience with harassment in the open-source community and continue to work on making OSS communities safer as their full-time jobs.

I love to advise PhD students. I can often offer another point of view from their advisors, but much like the fun aunt, I don’t have to make them do generals or write a thesis. I have also benefited immensely from the senior faculty that I’ve been able to co-advise with: Scott Shenker, Boon Thau Loo, Lorenzo Alvisi, Phil Levis, Matei Zaharia, Tom Anderson, Ronaldo Alves Ferreira. It’s always inspiring to see how they think about problems, and I have no constraints on collaboration, so I try to work with as many people as possible. It is also just fun to work with friends, like Adam Belay, Simon Peter, Jialin Li. I can always embarrass them by telling their grad students stories from grad school. It was great to work with all of the folks on the Treehouse project where I was able to connect with faculty and students across 4 universities, so thanks to Adam for dragging me into that.

Finally, I am incredibly proud of the high-quality open-source operating system that is now deployed at Microsoft. Microsoft supporting open-source is still a recent novelty to me, but I would not be at MSR if I could not open source my research. I hope Demikernel will be a research platform for universities that do not have the resources to develop and maintain a research OS. Obviously, universities can produce high-quality operating systems, as Mothy Roscoe had demonstrated more than once, but I think it would be hard to build and maintain a research prototype like Demikernel without the resources and support of MSR. I also enjoy working with and mentoring the large number of Demikernel software engineers: Sujay Jayakar, Pedro Henrique Penna, Brian Zill, Anand Bonde.

Conclusion

Wow, this really turned into a thesis acknowledgments section. It is nice to write about the wins and positive experiences of the last 6 years; there were plenty of negative experiences, which I will save for another time (or drinks with my friends that are always there for me, looking at you, Natacha Crooks). But I hope this post helps grad students trying to make a decision, as my first advising batch are graduating this year and next (and if you are hiring, you know how to find me)!