Who walks away from success? In his decade with Microsoft Research, Sumit Gulwani (opens in new tab)enjoyed a self-described “blissful” tenure, co-authoring more than 100 papers and giving dozens of keynotes and lectures—so why, then, would he leave?
Microsoft research podcast
What’s Your Story: Lex Story
Model maker and fabricator Lex Story helps bring research to life through prototyping. He discusses his take on failure; the encouragement and advice that has supported his pursuit of art and science; and the sabbatical that might inspire his next career move.
“Research alone is not a sustainable growth model,” said Gulwani in a recent interview. “If we want to do more, and receive more funding, then we need a system in which we give back to society in a shorter time-frame by solving real problems, and putting innovation into tangible products.”
Gulwani felt good about his contributions to the field of computer science research, but at the same time, he saw the need for more practical solutions to a host of real world problems (one could say he acquired a taste for the latter with the successful deployment of his brainchild, Flash Fill for Microsoft Excel (opens in new tab)). So, while rhetoric among researchers often places a higher value on foundational work, he prepared to take on the challenges of practical work and joined the Cloud and Enterprise group at Microsoft.
Gulwani knew this wasn’t an either/or proposition. Instead, he wanted to pursue both disciplines at the same time combining foundational work and generalized theories typically found in research with engineering-focused solutions for immediate customer needs. This would create a self-funding, accelerated innovation engine. But, the challenge would lie in how to go about it.
Adapting a structure from Peter Lee, corporate vice president for Microsoft Research, Gulwani drew up four quadrants, halved on the vertical axis by value and process, and again on the x-axis by engineering and research. Typically, the research and engineering sides functioned as parallel but with completely opaque paths. As a researcher, Gulwani would first build a research prototype (right quadrant side) and then search for an engineering group that needed to address a related problem and that was willing to invest in productizing his research (left quadrant side). This workflow carries with it the risk of working on the wrong problems and duplicating the development effort between the research prototyping and then an end quality product. In Gulwani’s research world, after developing prototypes for specific problems (top-right quadrant), he would work towards a generalized framework of related innovations (bottom-right quadrant). However, unfortunately, the utility of such a framework can prove to be mostly theoretical because engineering groups might not find it worthwhile to productize that general framework because of the high startup cost.
(opens in new tab)An approach to accelerated innovation that funds itself: The flow is inverted (from dotted red lines to solid green lines) and the same team balances time between all four quadrants.
Gulwani looked at the quadrants and thought: “What if we just introduce some transparency and shared intention to the product group, and invert the typical flow? Or even create a team with functionality across all the quadrants?
Thus, Gulwani began construction of a new kind of team. His vision had program managers focusing on customer needs (top left quadrant) and channeling the team’s innovation capacity towards those needs. Researchers would invest in creating a generalized framework (bottom-right quadrant) that would facilitate construction of specific technologies (top-right quadrant). Engineers would set up the correct engineering processes (bottom-left quadrant) so that researchers could develop product quality code. User Experience researchers would create user interface designs for specific technologies. Those designs would then be implemented by the engineers.
Today, Gulwani says the structure is working fairly well. “The team knows we’re all working towards the same vision. We want to advance the state-of-the-art in the nascent field of programming-by-examples – and apply it to concrete tactical problems, bringing the technology out in the real world through different products.”
It takes a deliberately cultivated growth mindset to make this kind of collaboration work, and accepting that one is operating outside one’s comfort zone. “The fact that these researchers are working together and are willing to learn engineering, and the fact that the senior engineers on the team are willing to guide the researchers, and appreciate each other’s point of view? That is a big thing,” according to Gulwani. “Quite different from the individual-contributor and prototype-focused value system that typically exits in academia or field research labs.”
(opens in new tab)Sumit Gulwani’s research and engineering group at Microsoft Redmond
From daily scrum meetings to six-week dedicated customer engagement exercises, the team is always engaged in making their own process better. Not all of it is intuitive, though. For researchers, spending a large percent of their time up front on engineering processes was hard to justify at first. But the realization soon followed that, as Gulwani says, “This is actually going to speed up our pace of innovation, because we can experiment with new ideas much faster, and it is going to make us more agile in the future.”
So, what happens when you put researchers and engineers in a room? If you’re watching Gulwani’s team, the answer is: They start innovating on innovation itself.
Learn more
Programming languages and software engineering