Subscribe
Share
Share
Embed
Become an Epic Product Engineer is Kent C. Dodds's interview podcast about skills that stay valuable as AI takes on more implementation: product engineering - blending technical depth with product judgment, user empathy, and problem clarity.
Each episode is a long-form conversation with a guest who has shipped real software and cares about building the right thing before making it right. You get full audio, transcripts, structured show notes, homework (one concrete action to try), and links from the conversation.
Canonical home for the show and every episode page: https://www.epicproduct.engineer/become-an-epic-product-engineer-podcast
New episodes publish on Wednesdays (America/Denver). Video is added on Transistor for supported podcast apps when available.
Complements Better with Kent - Kent's solo series on durable skills for people who ship software.
Kent C. Dodds (00:01.000)
Hey, everybody, it's Kent C. Dodds, and I'm joined by my new friend, Jay Parikh. How are you doing, Jay? I'm just like stumbling over my words.
Jay Parikh (00:08.440)
That's awesome. It's great to be here, thanks, Kent.
Kent C. Dodds (00:10.680)
I haven't done this like a million times, so yeah.
Jay Parikh (00:13.320)
First time for everything.
Kent C. Dodds (00:14.360)
Yeah, so Jay, let's just get a quick intro to you. You work at Microsoft. You are over the CoreAI and a variety of other things. Can you tell us a little bit about what it is that you do at Microsoft?
Jay Parikh (00:27.600)
Yeah, absolutely. So the CoreAI team that I support today is focused on everything that the AI powered, AI native developer and you think about it from like a tools perspective, from a systems perspective, from an infrastructure perspective, a primitives perspective, a platform perspective, ecosystem, but really when we think about how we build software is just fundamentally changing these days with AI, and it's a systems thing. It's not just a, hey, here's one model or here's one tool. It is like a entire system of like the applications that we're building for the future, look and operate and need to be built and deployed and governed very differently, secured very differently. And as you know, the technology is also changing really quickly. So we've got to adapt.
Kent C. Dodds (01:16.480)
Yeah, absolutely. And like talking about security, we've had some pretty exciting couple weeks with the better the agents get, the better they are able to secure our applications, but also the more need we have to have them be secure. So yeah, there's so many elements in there. I love that you mentioned primitives as well. That's like just key to creating a system in which agents can be efficient. And I think that's one of the things that at least today, maybe in the future, agents get better. But today, one of the things that product engineers can do is to focus on the primitives that the agents piece together to build the product or whatever, and get to the outcome that we're going for. So things changed at the beginning of this year considerably with the way that software is built. And I had two existential crises myself as a software implementer, and that's when I made the shift to product engineering and thinking that knowing what to build is the real key here. This is something that you recently sent an email to your team about. Can you talk to us a little bit about where your head is at, at the way that we think about building products and where the traditional software engineer fits in that future of how we build software?
Jay Parikh (02:38.320)
So one, I absolutely think things are changing and they're evolving quickly. And I would say that the world that is focused on building products also is a very dynamic range today, right? Because you have enterprises that are still working one way and then you have maybe certain, you know, maybe it's just a one person company that's working a completely different way, right? And so we see a very big range of how developers and builders or product engineers want to work today. And in CoreAI, but really in GitHub, we have to make sure that the platform, the surfaces, the offerings really do encompass or offer enough to everybody to move forward and get that work done. Now, for us, I would also say that it's important to think through the outcomes, right? And in some ways, we have to be more and more focused and we can because we don't have to spend as much time typing lines of code by hand and doing different things by hand. Now, if you are savvy with these technologies, a lot of that, I would say, toil work, you know, being able to go and do this type of data analysis or gather these things or go integrate these various things that were manual and maybe kind of clunky. These are things that you're like, hey, I just don't want to have to do this. I want to focus my time on going and talking to end users. Like instead of spending three hours doing some of this other stuff that now I can set up as we talked about today and automation for and have that be running and be like, hey, I'm going to go and talk to customers today, right? So, kind of in many ways, that time that you gain back in the implementation and verification, you put into ideation, creation, collaboration, and picking right, right? And then also the ability to kind of see if your whatever feature, your improvements are actually driving your business forward, right? And there's lots of different ways to measure this. And you've got to get super dialed in because ultimately that coming up with an idea or having an intent or a plan, whatever you want to call it, and then connecting it to an outcome, that time now has like gotten and can be much shorter if you're doing it well. Agentically, yeah.
Kent C. Dodds (05:11.120)
Yeah, exactly.
Jay Parikh (05:12.080)
So, this is the kind of where we always end up with like, okay, well, now you have time free to
Kent C. Dodds (05:19.440)
go do these other things. There are a lot of software developers who are like, but I don't want to do those other things. Like, I liked the coding. Or it almost feels like they're becoming product managers. And like, those are the tasks that the product manager typically does. So, where in your mind is the line between what a software engineer does or a product engineer and a product manager? Is there a line? Or are these kind of becoming the same thing?
Jay Parikh (05:44.560)
I think it really depends on the product. It depends on the industry. It depends on the company, right? And I think that there is no reason right now to, I would say, maybe be draconian about it. Because I think it is situational. It's very fluid, right? Because there are places where maybe those more prescribed kind of specific roles make a lot of sense, right? Because there are places in enterprise and certain industries where having those handoffs, having those expertise from like pricing, packaging, marketing perspective versus like scale and architecture and security and observability and, you know, whatever it might be, infrastructure. Those are also, and those don't like blur together overnight, right? Because those are different set of shared experiences and intuition and understanding in the world. Now, the key is whatever expertise you have in as many is the, you know, team that you need to. And I think, obviously, this isn't new, but we feel it and see it a lot more where the slow, I mean, the sort of the small teams that, you know, can move fast, actually, what I call, will drive a much faster learning loop. Yes.
Kent C. Dodds (07:02.080)
And that learning loop, the faster you can make it, the, you know, smaller you can make it
Jay Parikh (07:07.120)
and the faster you can traverse it. You just learn faster than your competitors and your velocity and you compound like that learning, because I talked about that in today's keynote, right? Which is this velocity, intelligence, and quality are the kind of these three dimensions that we think about in this agentic software delivery system that then allows you to get this completed work done, right? But you got to measure the outcomes too. This isn't just, hey, here's how many PRs I, you know, I submitted or whatever. What are those outcomes? And like, and every business is going to have that. But the only thing I would say here also is that for, if you're in software engineering, I think it is a great opportunity to be curious about these things that are historically separate boxes in the org chart.
Kent C. Dodds (07:58.000)
Yeah. Right.
Jay Parikh (07:58.720)
And getting closer to the customer, if you haven't been close to the customer as an engineer, personally, I think that is all upside for your understanding of how to build better things and drive, you know, better value to your, you know, like your, your customers will just like your thing better if you know what they're experiencing. Right. And so that to me is like an opportunity to go learn. Mm hmm.
Kent C. Dodds (08:25.440)
Yeah. I don't think that you can build a good system without understanding who the system is for. Absolutely.
Jay Parikh (08:30.800)
Now, there are so many things that you mentioned that I want to pull more threads on,
Kent C. Dodds (08:34.800)
but one of them in particular is about scale. And this opportunity that GitHub has with just the ridiculous amount of contributions that are happening at GitHub scale. You saw the graphs. Yeah. I saw the graphs and, and my goodness, I can't even imagine HugOps and all of that. Right.
Jay Parikh (08:56.000)
So there are product decisions that are going behind the way that you're addressing this scale problem.
Kent C. Dodds (09:02.400)
You certainly don't want to just lie down and hope that it works like that, or that it continues to operate. And so how do you go about addressing those types of problems where the, the scale problem isn't that there are, certainly there are more people contributing to GitHub, but it's, the bigger problem I think is that the volume per person is increasing. And so it kind of requires a bit of a rethink of how you traditionally would allocate, you know, infrastructure per user. Right now it requires a lot more. So how do you go about determining what the needs are, not only today, but projecting that into the future, so that you're prepared for the next wave of whatever comes next? Yeah.
Jay Parikh (09:46.880)
So one is, I would just say, given that the technology is rapidly changing, it is like imprecise, because you don't know what is coming that may inflect the curves, you know, more or less, whatever it might be. So any capacity planning I would just say is like, you know, give me all the capacity.
Kent C. Dodds (10:06.800)
Yeah, yeah, yeah, because there's infinite capacity, right?
Jay Parikh (10:09.680)
Right. Right. There is, there's such a thing, no.
Kent C. Dodds (10:11.360)
Yeah.
Jay Parikh (10:11.680)
And, but it is one where there's lots of signals in the system, right? And with a, such a broad and amazing and powerful community on GitHub, we see many different, you know, behaviors. You see kind of what maybe a new technology, a new model, a new something. You can see it in the cohorts in terms of what's happening. So you have early warning signals at times. And then there is just like, you know, hey, there's lots of sophisticated ways that we do forecasting for capacity planning, right? And you watch these trends, you see things. We also do a ton of work on efficiency. Yeah, I was going to ask about that.
Kent C. Dodds (10:49.040)
So when we go and we squash down something and prompt caching in the gateway, or we do something
Jay Parikh (10:54.960)
that reduces CPU usage and actions, then that's, you know, capacity that then you can use and like add more features or handle more load or whatever it is. So it is a, you know, it's always a given take in terms of the system. You're always trying to make it, make it more efficient. You're trying to add capacity. And then you're trying to like optimize for how that's delivered to, to end users now. And also over time, you'll, you'll see us, Kent, which is there are going to be different tiers, right? I mean, you have like, you can do certain things if you're free or basic usage. And then there's folks in the enterprise that need a lot more or organizations that need a lot more. So we'll have different offerings so you can size whatever you need that fits your needs.
Kent C. Dodds (11:39.920)
Yeah. Yeah, that makes sense. And along with this, as you're building out this system to match the scale, one of the other things that you talked about in your keynote was the quality aspect of this. And you talked about like having those small teams with this really fast feedback loop so that you can have inputs in and outcomes out. We're not talking about output. Like we don't really, that output matters, code matters, like all that. But it's the outcome that we're really after. It's not the number of PRs, whatever. It's, it's that outcome. So what, what are the processes that you are encouraging in your team to make sure that we get quality outcomes and that they can move at the velocity that you're trying to move at? Yeah.
Jay Parikh (12:26.720)
So work in progress. And I think every team is some bit experimenting, but also being able to take kind of these primitives in that agentic software delivery system. A couple of things that we talk about internally and some externally. And these are, I would say a lot of this is basics, but think about in the past, you know, maybe always wrong, but people would measure lines of code or PRs and all of these. And we talk about those and define those and kind of put them in a box that we call activity metrics.
Kent C. Dodds (12:57.680)
Yeah.
Jay Parikh (12:58.000)
It's, it's a quantity or like something that's quantifiable and comparable. And they're useful, I think, for example, when we were really trying to get people comfortable using the new tools and new systems, you did actually want to see activity.
Kent C. Dodds (13:12.320)
Yeah.
Jay Parikh (13:12.800)
And you wanted to see broad-based activity just to make sure people were using the new tools and the technology.
Kent C. Dodds (13:20.640)
Mm-hmm. To gain experience. Yeah. It's kind of that in some ways that, you know, getting past static friction, right?
Jay Parikh (13:26.320)
Mm-hmm. And sort of that bootstrapping phase, you're, you're getting-
Kent C. Dodds (13:29.200)
Just get them moving and then we'll point them in the right direction.
Jay Parikh (13:31.440)
Right. And then we'll figure out and get feedback and then point them in the right direction and start to like measure more and quantify what the ROI is. Now, when it comes to quality, for example, one of the very basic things that we do is we watch kind of PR velocity, but we also divide that by incident rate, right?
Kent C. Dodds (13:49.760)
Yeah. Yeah.
Jay Parikh (13:50.160)
So then it's like-
Kent C. Dodds (13:50.960)
And maybe cost as well?
Jay Parikh (13:52.480)
Cost is also something that we track very closely as well. And are we optimizing and using things like, you know, Fusion and these things that help us optimize the outcome based on the intent or the task or the idea that needs to be implemented. And then, you know, there is that time, right, which is like, hey, this, this idea came in, this bug report came in, this signal from production came in, and now instead of it taking weeks or months, now it can take hours or days. And now we can measure that, right?
Kent C. Dodds (14:24.160)
Yeah. And then there is, over time you do this enough, you can start to understand what is moving the
Jay Parikh (14:30.000)
business forward, either helping us save money or driving some top line metric that we care about. But we do want to care, we do care about the quality metrics, right? So another thing we track very, very carefully is metrics around how much time would be spent by developers and what we would call kind of unfocused time or toil. Oh, okay. And we actually track this, right? Friction, things that are hard and it might be with AI now we can automate stuff, right? And some of this is basic stuff that doesn't require AI and other things are using AI to be like, hey, now I can have agentic workflow that does these set of things for me that I would have to do, basically click a lot of buttons, talk to a lot of different teams and you lose time, right? And these are repetitive kind of tedious things and now I can have agentic workflows for that. Now that frees me up to go do something else, right?
Kent C. Dodds (15:26.720)
Think about the products, yeah.
Jay Parikh (15:28.080)
Yeah. So, but we do manage and monitor this like what we call focus time and unfocused time. And we do like review that very carefully for all teams in CoreAI. And then when we get more and more focus time back, how do we apply that?
Kent C. Dodds (15:43.520)
Hmm. You know, that actually makes me think of some toil that I have had, which this is maybe a bad segue, but one thing I wanted to talk about was Copilot and the Fusion. So I've felt this forever. I don't feel like I should have to choose the model. I think that the computer can absolutely do that.
Jay Parikh (16:06.640)
We agree.
Kent C. Dodds (16:07.120)
And so Copilot and many other agents have always had like an, or for a long time have had an auto mode that'll just kind of pick, you know, the cheapest one or whatever, but, but Fusion is different. So tell me a little bit about the product decisions that went into Fusion and why Fusion solves the problems that your users were facing.
Jay Parikh (16:27.760)
Yeah. So one is just to consider, you know, that Fusion is not a static thing. Like we announced it, we shared a lot of information today, and this is like for us constant work because we're, and people are using it, give feedback, the models are changing. We will find ways to optimize the harness and Fusion and other subsystems together, right? Because it's not this by itself. It's this part of the whole system, the harness, the product, other things that you may do. And we have three patterns today to get out the gate between single and cascade and critique. But there may be other patterns that emerge based on what's happening in the ecosystem. Models are not standing still either. It's very exciting. But in any ways, like your pain point, which is like, I don't want to have to decide. I don't think I should have to deal with this.
Kent C. Dodds (17:25.280)
Yeah, I don't want to keep up.
Jay Parikh (17:26.320)
I don't want to keep up. I've got a product to worry about. I have an idea. I want to get that done. I will tell you if I like have a budget, you know, hey, I only want to spend X dollars on this thing and like figure it out. Or I really want the highest, highest, highest quality, and I'm willing to spend a bit more, right? And so these are the types of things that you can, you can express to the system and the system should be able to then orchestrate the right sequence of decisions and models to get that done. And so that's like what I think is like the magic happens, right? Because then you could be, as we talked about in the other demo showing Copilot projects, you can just be flowing at the speed of thought into Copilot across like all of these repos and research, and maybe you have to do docs and presentations and demos. And now you're just flowing thought. And this thing is figuring out which repos, what agents, sub-agents to go do. That context is shared across that work, that work output or the outcome that you want. And I think that's like...
Kent C. Dodds (18:32.080)
That's the next level of leverage. And I'm always thinking about what are the things that I'm doing now and how do I get an agent to do that for me instead? And it used to be that I was managing all these different agents and maybe they had sub-agents and that's fine. Yeah. But it's better to say, well, I'm managing this project. How about we just have an agent that manages the project? So I'm very excited to find out what comes next. Like, what is the thing that I'm now doing now that I have projects and that sort of thing? Now, Jay, we only have just a little bit of time left. I need to get some homework from you. So as part of the Become an Epic Product Engineer podcast, the people watching, they can just listen and whatever and move on with their lives, but we want them to change. They need to improve in some way, get better product sense or something. So, Jay, what would be the homework that you give to people listening to improve themselves as product engineers?
Jay Parikh (19:24.800)
So, one thing that we touched on earlier, and I think there's a lot of things that we all can go be curious about, and I'll give two. One is that, you know, I always tell our team customers I meet with, the hundreds of customers I meet with, is whatever level of ambition you have in being a product engineer, engineer, designer, using these tools, these systems, many of what we announced today, but, you know, there's lots of choice out there. So, part one is, like, whatever level of ambition you have, raise it, right? Because that's how we, like, we learn faster. Find the edge. And keep pushing. Whatever, you know, thing you think you're good at today, just like, oh, I need to go bigger, bolder, faster, and let me try something that I, like, just try to be bolder in whatever tasks, ambition, projects that you have. Try different tools, try different ways of doing it. So, that's part one. I think the other part of it is, maybe homework to give, is go and really think about how to measure and quantify the outcome of something you're doing. Do you have the right outcome metrics in your system, on dashboards, wired into your agents, as part of, like, your creation and collaboration with the rest of your team, you know? And, like, be very, very prescriptive and, like, explicit about what those outcome metrics are. And are they leading? Are they lagging? And because I think that is important to making this whole learning loop go super fast.
Kent C. Dodds (21:08.960)
Yeah. No, I absolutely, completely agree with that. And, as you said, bring that into your agent. Because the agent, it's not going to make the decisions for you. You have to be accountable and ownership and all of that is important. But it really is good at helping you make the decisions. And it can keep that context with you as you are coming up with other ideas, you're troubleshooting things, you're trying to make decisions. Yeah, absolutely. Especially if you're using projects.
Jay Parikh (21:34.660)
Absolutely. Absolutely.
Kent C. Dodds (21:35.820)
Hey, Jay, this has been a pleasure. Thank you so much for giving me some of your time. And thanks, everybody, for watching.
Jay Parikh (21:39.600)
Thank you, Kent.