Microsoft CoreAI tracks engineering focus time via internal quantitative dashboards
Jay Parikh · The most expensive mistake in outsourcing your tech stack | Jay Parikh (EVP CoreAI, Microsoft) · Aug 27, 2026 · at 14:00
Jay Parikh, EVP of CoreAI at Microsoft, explains how leadership quantitatively tracked engineering focus time to identify operational headwinds and increase pace.
0:00 / 1:04exact quote · 65.0s
▶ Watch the full episode on YouTube → 720p mp4 · rendered on demand · StarZero watermark
“I'd say there's like a set of data that needs to be collected, and it's what we did when I joined and we created this core AI team, right? Which is, first of all, get both qualitative and quantitative data in terms of what is going on in terms of like that pace. What are in many ways the detractors? What are the headwinds? So we did a number of things to basically get that in subjective, almost like anecdotes or anecdata around this. And then we also had a bunch of quantitative data in terms of how product folks, builders, engineers were spending their time, and we broke it up into what we call kind of like, either you call it productive time, or we called it focus time, and that was like, we wanted more and more focus time, and then come, you know, what we do with that focus time was like another thing we had to go do, but we wanted to get more of your time spent into focus time, but we could measure this, right? And then we could actually have dashboards, we could have all of the engineering leaders see kind of where their teams were on this focus time.”
quote is from the automated transcript, cleaned for reading: filler sounds and stutters are removed, nothing is rephrased. names can be misheard (the analysis reads context, assessments check outside sources). how →
More from Jay Parikh
AI makes code an output and dramatically shortens software development lifecycles
“Writing code is not the long pole in the tent anymore, and code is an output now. It's not an input, and the half-life of the, as I will talk about, the typical software development life cycle or the product Development life cycle. The half-life of that is dra…”
AI prototyping velocity makes multi-year software engineering bets completely obsolete
“I think it is hard these days to take a bet that is multi-year at this point. Maybe not on the, I would say, Adams-level infrastructure, because those do still take a while, but if it's in, you know, in, in product, in software, because I don't know that it ne…”
Running competing technical bets in parallel resolves uncertainty and accelerates learning
“If I can do both and learn faster, versus do one, fail at it, and then do something else after that, and that takes me four months to figure that out, versus doing two in parallel, and I learn in two months what I would have done in four, that is like a trade …”
Parikh: Infrastructure teams must share fate and accountability with product teams
“If our part worked, and the product piece didn't work, then, like, we still failed. So, those teams had to be fused together, and it was sort of a shared fate. I had no tolerance for this, like, hey, just because you're in infra, you don't need to care about, …”
Steep technology inflections demand IC-led cultures rather than managerial hierarchies
“If you want to be able to really, like, accelerate through one of those steep technology inflections, The people who generally know the best about the technology are actually the ICs. So you have to, like, elevate them, you have to, like, protect them, you hav…”
Hyper-scale technology companies fundamentally cannot rely on third-party infrastructure vendors
“When you take some layer of your kind of core stack, and it's like outsourced to this vendor, and vendor, you know, could be great, but when I was at these companies that were, you know, Kind of N of one in terms of what they were doing scale wise. They weren'…”