Microsoft Research Podcast - 110 - Engineering research to life with Gavin Jancke

Episode Date: March 11, 2020

If you want an inside look at how a research idea goes from project to prototype to product, you should hang out with Gavin Jancke for a while. He’s the General Manager of Engineering for MSR Redmond where he created – and runs – the Central Engineering Group. Over the past two decades, he’s overseen more than seven hundred software and hardware engineering projects, from internal MSR innovations to Microsoft product group partnerships. Today, Gavin takes us on a guided tour of the research engineering landscape and the engineering pipeline, recounting some of Central Engineering’s greatest hits. He also explains how the lab determines which projects get engineering resources, and reveals how one of his own projects ended up in the Museum of Modern Art. https://www.microsoft.com/research  

So generally we get engineering proposals from the researchers which are highly ambitious. And having done enough of these over the years, we're kind of able to identify which ones have the highest chance of success. And so this is how we determine what we're going to invest in and obviously there's an opportunity of this is really going to be a paradigm shift in terms of affecting a new underserved population, new technology that creates new experiences for humanity, that kind of stuff. You're listening to the Microsoft Research Podcast, a show that brings you closer to the cutting edge of technology research and the scientists behind it. I'm your host, Gretchen Huizinga. If you want an inside look at how a research idea goes from project to prototype to product,

you should hang out with Gavin Janke for a while. He's the general manager of engineering for MSR Redmond, where he created and runs the Central Engineering Group. Over the past two decades, he's overseen more than 700 software and hardware engineering projects, from internal MSR innovations to Microsoft product group partnerships. Today, Gavin takes us on a guided tour of the research engineering landscape and the engineering pipeline, recounting some of central engineering's greatest hits. He also explains how the lab determines which projects get engineering resources, and reveals how one of his own projects ended up in the Museum of Modern Art. That and much more on this episode of

the Microsoft Research Podcast. Gavin Janke, welcome to the podcast. Thanks, Gretchen, for hosting me. You're the general manager and engineering research manager of MSR's Central Engineering. And because this group is so different from the others here at MSR, I want to split the situating into two parts. So first, give us a really short elevator pitch for what you do in central engineering and why your group exists. Right. So MSR's core mission, obviously, is to advance the state of the art in computer science and also deliver cutting edge technology to Microsoft itself. And so our team essentially is a capability for hire within the division

to help researchers transform their ideas into reality. And it's both, you know, very early and also late stage engineering engagement with the research teams. It spans tech transfers, internal research team, engineering from the first napkin conversion of an algorithm into living, breathing software or hardware. So we pretty much cover the spectrum. And the team that I have is fully multidisciplinary with engineers, program managers, designers, quality assurance folks, and hardware engineers. And the challenge today compared to, you know, two decades ago when MSR was first formed, when there was pretty much just the beige box underneath the desk, that was the state of the art of computing at the time. The industry and the landscape has dramatically shifted. And to create software and innovation is dramatically broad. So when researchers want to innovate an army of one or two or three,

sometimes just cannot achieve it. So it requires a deep bench of product disciplines and also working style, you know, diversity too, and being able to create these manifestations. So my team essentially is a central capability for the Redmond Lab itself to tap upon when the research teams don't have enough people to do something ambitious, or they need specific skills that they can't necessarily hire for. And so my team fills those gaps and executes. Well, now that we know what central engineering does, let's zoom in and talk in more detail about the current engagement model. You've sort of alluded to that just now. Maybe you could start by giving us a snapshot of the traditional engineering to product pipeline, and then explain the central engineering model and how it came about and how

it's different by design. So historically, Microsoft Research, when it started 25 years ago, there were researchers and what we call embedded research design engineers. And an RSTE, which is a research software design engineer, it's R plus SDE. And at any moment in time, those embedded R SDEs can be, you know, 100% R, 100% SDE and anything in between. And that slider changes over time. So that's traditionally how MSR was structured up until about 20 years ago. I actually started out as an embedded RST myself. So I kind of got firsthand what being an engineer in MSR was like in that traditional model. So about 20 years ago, Dan Ling, the VP of MSR, he wanted to model a similar setup that MSR Asia had, where they didn't have embedded RSTs, but they had a centralized model, a pool of engineers that their lab could draw upon. And what that kind

of tried to address is the elastic need that research teams have in being able to efficiently assign engineering resources to teams that needed a specific capability for a small amount of time or specific skill sets they couldn't hire for. So Dan Ling and Jack Breeze came to me and said, we'd like to form something here. Can you set something up? We'll give you two heads to start with and come up with an engagement model with the lab and see exactly what happens.

So I did that. I got two slots for engineers. And obviously, I was the third slot as an active engineer at the time, too. And so I came up with this kind of RFP, request for proposal model, where researchers would submit kind of a single sheet of paper saying what they wanted to achieve and what they thought the scope was. And I would take those sheets and essentially do kind of a value proposition analysis of them and kind of a technology fit to see if I had engineers who could work on these things. And this is how the central engineering model started. Let me ask you then, what was your metric for choosing a project?

Yeah, so the proposals would come directly to me and then myself and the office of directors at the time. We would sit down and huddle and look over these proposals. And I would, obviously, I had pre-vetted them and had spoken to the researchers to determine, you know, exactly what was being requested here. And so I would get kind of a gut feel in terms of, yes, this is ambitious. Yes, this is achievable. No, this can't be done without 10 engineers and a whole product team behind it. And I was kind of applying an instinctual gut model approach to these analysis of projects.

And as leadership changed, I kind of respected my insights into these, but they wanted something more formalized. So I tried to reduce what was my instinct into an actual formula. So I try and equally balance the tech transfer value proposition. Is it going to advance the state of the art for the researchers themselves? Do we have a good engineering fit with these kind of projects? Is it achievable? And then I'd kind of have my own chip, which would be these kind of projects? Is it achievable? And then I'd kind of have my own chip, which would be the kind of the fun factor metric. So I broke this equation into kind of five pieces with our new leadership. And we started running the projects using this model. Now today, that has gone through essentially 17 years of evolution, we have a whole new process

now, which is based on the existing models and weightings and that kind of stuff. And it's called Pitch Tank. So Pitch Tank, I came up with the cheesy name based off the show Shark Tank, you know, whereby inventors would come on the show to get VC funding. And so Pitch Tank was formed, whereby we also were trying to address kind of transparency issues because researchers didn't really understand how decisions got made. And so we really opened it up in terms of the researchers would actually do the pitching of their proposals themselves rather than me present to the office of directors or leadership. So very much like the show.

Very much so. So they own the messaging, they own the pitch and the presentation. I also changed who the program committee was in terms of the evaluation and our leader, Donald Kostman, currently wanted to completely democratize and open that up where leadership themselves wasn't involved at all in making these decisions. It was owned by the people of the lab themselves. And so I equally split up the program committee into an equal weighting of four researchers and four engineering folks from my team. So we could bring the engineering perspective to these decisions. The researchers could bring their research perspectives the engineering perspective to these decisions. The researchers

could bring their research perspectives in terms of evaluating these projects. And so we've run PitchTank for about three years now. We've had about five sessions. And it seems to be working really well. How many do you choose per tank? So the PitchTank that we just ran two weeks ago in January 2020, we had 16 pitches on the line, which was our most ever. It was actually a challenge. We had to split this across three days of three and a half hour sessions, which is quite the workload. And there's a lot of due diligence that we do ahead of time. So the researchers still have to write the proposals. And then we also have a pre-pitch session with the researchers to help them hone what their pitches are and what their value proposition requests are going to be.

So I have members of my team help them hone that. And then after the pitch tank, the committee get together and we have a scoring session where we enter these value weights into our scoring model. And we create a color heat map, which actually shows basically the scores on a heat map, how we execute and prioritize which projects we're going to invest in. I am seeing a reality TV show here. Yeah. Well, let's talk about you for a minute, Gavin, and what gets you up in the morning. You've been at Microsoft Research for a long time and at Microsoft for even longer, and you've done a lot in your career here.

In your current role, though, you're both a partner-level leader and what I would call a roll-up-your-sleeves doer, and that's by choice. So tell us how you keep all the plates spinning above your head and why. Yeah, the plate spinning thing is quite the challenge. So what gets me up in the morning is obviously meaningful work, both myself and the engineers in our lab and obviously the researchers too. We find great meaning in the work that we do when we're obviously privileged to work with several hundred PhDs with cutting edge breakthrough technology and ideas. So for me and folks on my team, you know, we get a vast diversity in job content and to be able to come

to that every day and not only work on new projects, but new angles to the problems that we work on every day is just profound. So for me, as an engineer, obviously I lead a team and I provide engineering leadership within the lab to the researchers and beyond. But I also am an individual contributor engineer myself. I'm a trained engineer by profession and I really strive to keep that alive because I feel if I'm not an effective engineer and up-to-date and practiced and versed in the latest technologies and challenges and stuff like that, I don't feel like that I can be an effective engineering leader and be able to steer and help my team steer the research execution in creating real solvable engineering problems. I have a real issue with

overcommitment because when I see these incredible research problems being presented, I have a problem not saying yes. But that overcommitment helps me really focus on delivering and executing on innovation. And that's also a role model for the rest of the team too, because they see that I'm kind of fearless in diving into the hardest firmware engineering problem or whatever it is. So I get the best of both worlds, both in terms of engineering leadership, managing an incredible team of talented people, but also staying a talented engineer myself. How do you keep your creds up? I'm just looking at hours in a day and what you do here. I know because I've had people who work with you talk about you. When do you do this? It's a challenge. Obviously, when I'm at work, I do the least amount of individual contributor engineering. But in my kind of role,

one doesn't have a work week per se. When you find passion in a career, it spills over beyond a 40-hour week. So I do find precious time at the end of the day when everyone, which is pretty horrendous from Seattle over to the east side of... I can't even. So I actually have started to cycle to work, which is half my commute time, and I can basically find an extra half hour, 45 minutes an hour each working day by cycling. Wait, wait. So you get here faster by riding your bike than by driving in a car?

Well, the commute really is bad. Yes, it is. It's an e-bike, so I do fly around. Oh, there you go. It's still a good workout. I thought you were going to say you rode the bus and then did more innovating on the bus, which would be a good little TV show as well. Well, so I would actually get more work done with the bus, but I don't find time to work out. So I kind of get a workout and save time commuting.

So there you go, the productivity hacks going on all the time. Gavin, your central engineering team has worked on more than 700 projects over the 20 years that you've been at this, and over such a large range of topics that it would take less time to list what you haven't done than what you have. So before we talk about some of your more recent work, give us a brief overview of some of your past favorite projects, maybe in the form of central engineering's greatest hits. Yeah, so it's really hard to pick a favorite child. So I'll do my best to pick a good sampling there. So generally the ones that stick out in mind have been kind of the roller coaster rides where there's been intense pressure and also big unknowns. One is the Kinect for Windows. So this was back in the day when

the Xbox released a skeletal tracker device for its gaming console. And so the hacker community managed to hack that for general use outside of the console before Microsoft had a story there. And so the VP of the Entertainment Advices Group and the president of research needed to come up with a solution. So they basically said, well, Gavin, what can you come up with in terms of creating an SDK and runtime for Windows, which kind of fills that gap? And so I picked a few people in my team with incredible skills in signal processing, and basically we took the Xbox skeletal tracking code, and essentially we took those algorithms, filled in some big gaps,

and so we created a full runtime, which included all of the audio stack too, and an SDK, setup program, samples, and that kind of stuff. And the president of research at the time says, well, we need to release it by June. So essentially we had 14 weeks to deliver a company-grade offering for Connect for Windows. So that really stuck out in my mind. It was a fantastic run. There were lots of, you know, hot collared

moments there. Some other ones that come to the top of the list. So Skype Translator was another great one. This involved working with the research team, the machine translation team, and the Skype team in terms of how do we create an experience that links the machine translation backend with the Skype front. And so my team provided the program management, the user interface engineering, and all of the quality assurance testing aspects to that. That was another kind of thrill ride, which involved, I think, five different continents of players. And we worked very closely with the machine translation team. And we shipped that. And it's interesting that the long tail of research takes many years for technology to appear in the mainstream. And I recall seeing in this Christmas 2019 Microsoft commercial,

there was a young girl speaking to a reindeer, and the speech translation aspect of Skype Translator was essentially behind that commercial. So it's incredible to see how long it takes innovations in research to finally get into the forefront. And they have reindeer now in the language selection. That's right. And Klingon as well, I believe. Some other ones that we've done.

So Project Premonition, we worked with a researcher to create the world's most advanced mosquito trap, which was kind of a healthcare research endeavor. And so we created a hotel which had special doors of entry into the hotel rooms whereby we'd do wingbeat frequency analysis of specific mosquito types so that the mosquitoes could be trapped and essentially their DNA be ground up and tested for things like Zika virus and stuff like that. And so this was an incredible engineering effort for the hardware lab to engage upon. And eventually, I think several thousand of these devices were made and deployed. So that was another fun one that comes to mind. Another project, which was of my own creation called Microsoft Tag.

And this came from this color barcode technology that I had. And this was another kind of overcommitment challenge pickle that I got myself into, whereby myself and a marketer from the Xbox team wanted to change the marketing barcode industry for consumer user interaction with magazines and billboards and that kind of stuff. So I had this Calabarco technology, which worked really well with the cell phone camera technology at the time. And we're talking the late 2000s here. And essentially, we made a pitch to the president and we got some brands such as serial manufacturers really excited. And essentially, again, I committed myself,

oh, I'm going to create a product and we'll launch it at Consumer Electronics Show on five different mobile platforms with a cloud backend with marketing tools for publishers to use and leverage and monitor campaigns. And so, again, with an incredible set of committed people who covered my behind with this, we executed and we delivered. And actually, a 30-person product team got created around this. And the product actually lasted for several years. And I'm going to make a bold claim here that this is probably one of the most pervasive pieces of technology that Microsoft might have ever deployed in that 15 billion color barcodes were printed and in circulation. Eventually, the product was sundown as business strategy changed, and it was licensed off to another company. But that was an incredible ride of my own technological

creation with the color barcode and actually creating a workable platform. Well, it doesn't look like the pace of central engineering has slowed down at all or is slowing down. So let's talk about what's happened just in the last year. And again, it will take too long to do the entire list of your year, Gavin. But in the immortal words of Janet Jackson, what have you done for me lately? So the team's been working on, again, some remarkable innovations with the researchers. So one of the projects that come to mind is video AR. So essentially doing augmented reality, but using virtual reality displays.

And this involved creating a new brand of camera device that the hardware engineering team created for us, which was very high resolution in order to not give viewing sickness to people when they're looking in motion sickness, that kind of thing. And so this was a full stack kind of endeavor, both from electrical schematics all the way up to pipeline and software titles. So that was an incredible multi-year project that we've been working on. Another one is the third generation elevator, whereby we're bringing ambient computing into the everyday work environment. We have an elevator control system where you can literally walk up to the elevator and it can determine your intent to actually press the button to go into it. And so we actually do... Oh, wait, it can determine that I'm going to push the

button to go up or down, not which floor I'm going to. Well, we actually have two parts to this. So our first deployment of this was to actually determine intent based on your walking pattern before you got to the elevator. And the second phase, which we rolled out last year, essentially puts an in-car experience whereby using RFID and speech, you can literally say, I'd like to go to floor four. Or based on what's in your calendar, it knows that you have a meeting on floor two. It will automatically press the floor two button. Oh my gosh.

That's also been a fun engagement working with the elevator companies. And so a very talented engineer on my team has been the architect for this and engineer. I'm just shaking my head. And then some other projects I personally overcommitted myself to. So one was the firmware and software for the Project Emma Parkinson's watch. Oh, right. So the research team kind of went into different parts of the company, but we had a second generation piece of hardware. and then also decided to help write the clinician software so that patients can actually use pens, so they can actually do analysis on tremor response to different vibrations in this new prototype watch.

And so we're now engaging with research institutions into furthering this work. Let me interject that Haiyan Zheng was on the show, and she does an entire sort of overview of Project Emma, and how amazing that was for this young woman who was an artist, Emma, and she couldn't draw anymore because her hand shook. It's a fantastic story, so I just want to say listeners can look that one up for more detail on that. It's interesting, I didn't know how much involvement you had with it. Yeah, that was very meaningful work for me because aside from the very fun technical challenge, obviously it's serving an underserved community in terms of improving their lives. And so tying into that, now I'm kind of generating a theme to my kind of underlying passion.

So I was working with the innovations team about a year ago on detecting pollution using inks that change color based on different gas levels in the atmosphere. And I thought, well, perhaps there's also a parallel way of doing this digitally. And so I came up with this harebrained idea of creating an air quality sensing device, which could be cellular connected, doesn't require any infrastructure beyond the cellular signal. So we could do dense air quality measuring. And so this kind of hardware, firmware innovation kind of pulled in the other parts of the research team. And so there's a significant effort around air quality measuring that we're now actually deploying to major U.S.

cities, which give new insights into kind of pollution and climate awareness. So this has been another incredible project. One of the hottest lines of machine learning research across the labs is teaching machines to make decisions under uncertainty. You've said that operating under uncertain conditions is one of central engineering's greatest strengths, and even a machines to make decisions under uncertainty. You've said that operating under uncertain conditions is one of central engineering's greatest strengths, and even a differentiator. So talk about how your ability to work with ambiguity plays out in your world. So generally, we get engineering proposals from the researchers, which are highly ambitious. There's often quite a bit of naivety around

the final mile execution of these things, whereby they have an algorithm that works great on a huge desktop machine under their desk, but then they want it to run on a chip that runs on 3.3 volts with a battery life of 10 months or so. So then we have to refactor the research prototype code into something that's actually deployable. And so having done enough of these over the years, and I guess almost two decades now, we're kind of able to identify how these things turn out and which ones have the highest chance of success. And so based on this gut instinct, you know, this is how we determine what we're going to invest in. And obviously, there's an opportunity of this is really going to be a paradigm shift in terms of affecting a new underserved population,

new technology that creates new experiences for humanity, that kind of stuff. And so we kind of weight all those things and we're able to boil down, you know, where our investments are going to be and what technology is most likely to succeed. You've alluded to a deep bench in the conversation today, and I love sports analogies. So what that means to me is that your researchers can expect great things from your central engineering team. What kinds of people are you working with here in your, what, now 30-person team? How do you get them, scout them, draft them, and bring them on the team? So I've crafted my team over 17 years. So essentially I've cherry-picked many people over almost two decades.

And generally, the people that have the highest chances of success are those that are deeply curious. They have an absolute love of learning. They know how to work in ambiguous situations. They aren't intimidated by what they don't know. And so I've also picked people with a very broad range of backgrounds. They find true craftsmanship in their work and pride in what they do. And many of these people have been since the creation and founding of the team. So not only are these folks that I picked from the very beginning of the team's creation,

but also I've had some fantastic new recruits over the last few years. And these folks are going to be the future of the team. They themselves are younger, they bring new perspectives in terms of how to engage with technology, how to engineer technology. So with the 30 people that I have, many of us having worked together for such a long period of time, you know, we don't have to learn how to work with each other. We have 70 years of knowing how to execute in ambiguity. We have each other's backs, that kind of thing. I'm also very proud that my team is almost 50% women. That's awesome. So you talked about your high-capacity color barcode, and I happen to know that it actually made it all the way to the Museum of Modern Art for some reason. So I want you to talk just a little bit about how that ended up there,

and then what are your thoughts about the importance of beauty and art and design in technology? Because I know this is something a lot of your team members are interested in. So the barcode itself came from a project working with researchers that we were doing on trying to create a counterfeit proof ID. And so we're trying to stuff a cryptographic hash of birth date and all that stuff together with the person's image so that neither could be faked. And in order to achieve that density, a black and white barcode of the day just wasn't achievable.

So we came up with the notion of using colors to store additional bits per symbol. And essentially came up with this color barcode and somehow it ended up being picked up in some trade magazine that we were trying to achieve this. And the Museum of Modern Art was doing a initiative along the lines of design and the elastic mind, which is how momentous changes in technology reflect major adjustments in human behavior. And so it got picked to go in the Museum of Modern Art. It was exhibited there for several months and that's how it ended up there. All right. And so, you know, just in terms of, I've seen a picture of it and it is beautiful. How then do you think and employ or deploy concepts of beautiful design and art and beauty into the work that you do?

So actually, I've always had a love for user interfaces. And when I first started Microsoft, I started as a user interface engineer in the SQL group, creating the first graphical user interfaces for the product. And so I was experimenting with kind of the first 3D looking user interfaces for Windows that Microsoft had released. The buttons and things that kind of beveled locks and stuff like that. So I've always had a kind of interest in design. I'm by no means a designer. I'm just a wannabe designer. But because of that, I've kind of been attracted to projects as an IEC, which have had that aspect to them.

I was involved in the founding of Studio 99, which was basically a design and technology and a technology and design kind of initiative within MSR. And so I also kind of pick projects that have a design element to them. I don't think it can be understated that user experience and user interaction is a very underlooked discipline. And I had an incredible user experience manager working for me over the years who really honed my appreciation for that in kind of design-first engineering and innovation. And so that's continued over the years. We've reached the part of the podcast where I ask all my guests, what could possibly go wrong? And as we've discussed already, as an engineer, I suspect a good portion of your job is telling

researchers what could possibly go wrong. But you're in a research organization, and so inherently you're inclined and maybe even mandated to take more risks. So aside from telling a starry-eyed researcher it'll never work, what kinds of things do you see in the current milieu of high-tech research that concern you and what keeps you up at night? Yeah, so my role, I guess, is to play the bad cop, which is to often point out assumptions that researchers might have in taking a piece of technology to the next level. I'm not so much intimidated by the technical challenges. My biggest concerns are the speed from conception to delivery of an

innovation and the competitive challenges that we as a company face. And so this is both in terms of potential team size to tackle a specific innovation and also the breadth of disciplines and skills that are required that go into these things. So that's the funniest answer because it's basically how can I execute what we got to do? That's the thing that keeps you up at night. In addition to your off hours innovation, which literally keeps you up at night. Yeah, it does, actually. Hard-falling sleep. Well, we've established that the Venn diagram of your personal life, your professional life,

and your leisure life could probably be represented by one circle, and that the three paths kind of form one story. Give us a short history of Gavin Janke. Where did it all begin? What thing led to another? How'd you end up here? So I guess my first experience with computing when I was age 12, and I requested a Sinclair Spectrum, which was a Z80 based actual for one of the first color personal computers. So I was lucky to get that for Christmas. And I started tinkering with typing basic programs from magazines and my first experiences with technology then. From age 7 until 17, I always wanted to be a dentist.

It wasn't until a cruel teacher said, Gavin, you'll never make the grades to be a dentist, that I actually re-evaluated what I wanted to do. And in hindsight, I think I made the right decision, which is I will continue the computing track. And a junior in high school, I was lucky to strong arm my parents into outlaying one of the first IBM clones that were affordable with an EGA display. And I decided to pick Turbo C as my mechanism for creating software on that thing. When I was 17, I went on vacation with my parents and we were waiting to get on a cruise or something like that. And we went into a bookshop. And there's a saying, which is don't judge a book by its cover. I actually judged a book by its cover. And the book was Programming Windows by Charles Petzold. And this is how my intersection with Microsoft

started. And I got the Microsoft compiler and I started developing Windows apps kind of before I got to college. And in England, we have the degrees whereby you can take a sandwich degree whereby the third year in college is actually on an industrial placement. So I wrote to Microsoft in the UK saying, do you know of any companies that are using your Windows development kit? Because I'd like to do my co-op year with them. And they says, well, why don't you pop down and we'll chat to you. So I drove down to Microsoft UK and chatted to their developer support department. And I left loaded up with SDKs and OS2 development SDKs in my arms and basically worked for my third year industrial placement Microsoft product support in the UK. I also created an internal scheduling and phone book directory

app for Windows. And that kind of got me notoriety within the company. And one of my mentors back at the time said, oh, you should apply for an internship in the development groups over in Redmond. So I was all starry-eyed at that and actually managed to secure that. And this is when I was introduced to the SQL team and had an internship there. And essentially upon my exit,

they offered me a full-time position. So I had my hardest year of my life, which was finishing my final year of university, knowing that I'd be working in the USA in the SQL Server team as an engineer. So that's how my start with Microsoft began, and the rest is kind of history. Gavin, tell us something we might not know about you and how perhaps it's impacted your life and career. Yeah, so from about age 10 until 21 years old, I was a sprinter and my speciality, as it were, was 200 meters. So I had some amazing but hard Scottish running coaches where I was a member of the local running club. Essentially, it was a year-long commitment whereby I'd run in driving sideways rain in the north of England.

And over the years, you know, I went to competitions and stuff like that. And by age 17, this culminated in me winning the bronze at the English National School Championships. And sadly, 20 yards from the end, I pulled a hamstring. Who knows how that ending might have happened. Oh, my gosh. But I became part of the English team. Unfortunately, because of that injury, I wasn't able to compete. But by my Microsoft internships, I couldn't offer that kind of dedication to my running.

So I obviously rededicated it to Microsoft. But I think that decade of intense focus and dedication to that gave me the focus skills and ability to manage stress, you know, on the starting pads in a national stadium. So I really think that's helped me manage various aspects of my career. I've got the music to Vangelis running through my head, you know, running on the beach in Scotland in the rain. Well, we're getting to the end of the podcast and I'm disappointed because I want to keep talking to you forever. So maybe we'll go for a pint. Do you do pints here?

I drink a pint. At the end of every podcast, I ask my guests to leave us with some words of wisdom. And you're talking mostly here to an audience of researchers, PhDs, postdocs, emerging researchers, and the people that love them. From your position at the intersection of what I would call blue sky and rubber meets the road, what ought our listeners to be thinking about and working on if they want to follow in your footsteps? And what kind of journey are they in for? So I really feel that if you can find a career where you can combine your passions and your hobbies into it, that's where you're really going to have an incredible journey. I don't think one can confine oneself to a 40-hour week to find incredible success and richness in a career.

So I really feel like for me, risk-taking has been an incredible part of what I've gotten out of my career, where one shouldn't feel intimidated by one's own constraints and fears. And if you can find a way of being able to overcome that, I think you'll really find richness and meaning in your work. But also I feel like engaging outside of one's specific job role is also another important aspect. For me, collaborating with others in hackathons and stuff like that, surprising things have happened in my career whereby I've learned a new aspect of engineering, which has set up subsequent years and joys of future work.

I'm seeing the Venn diagram overlaps again. It's like if you can find what you love, it almost isn't work. Exactly. Gavin Janke, thank you for joining us today. Thanks so much. It's been a pleasure. To learn more about Gavin Janke and how the Central Engineering Team helps turn research into reality, visit Microsoft.com slash research.