# AI shifts engineers toward judgment and EPD leaders toward alignment

Markdown copy of https://realalpha.app/s/ai-shifts-engineers-toward-judgment-and-epd-leaders-toward/ on Real Alpha, the best minutes from long interviews with the people building AI. Cite and link the page, not this copy.

- Speaker: [Ashwin Sreenivas](https://realalpha.app/builders/ashwin-sreenivas/) · Ashwin Sreenivas is cofounder and CTO of Decagon. · Co-founded Decagon, the conversational AI platform valued at $4.5B, after building Helia, which Scale AI acquired.
- Host: [Nakul Mandan](https://realalpha.app/people/nakul-mandan/) · Host, Knuckle Up with Nakul · General partner at Audacious Ventures; his show goes deep with founder CEOs on how they build.
- Show: Knuckle Up with Nakul
- Episode: [The AI founder advice you won’t hear on X | Ashwin Sreenivas (Co-Founder at Decagon)](https://realalpha.app/v/_FmwqPzqkjY/), May 19, 2026
- Moment: 35:05 to 40:04 of the episode (5 min), playing on https://realalpha.app/s/ai-shifts-engineers-toward-judgment-and-epd-leaders-toward/; the episode from there: https://realalpha.app/v/_FmwqPzqkjY/?t=2105

## Quote

> “the job of EPD leadership becomes to very clearly **paint the targets** of where we want to go”
> — [Ashwin Sreenivas](https://realalpha.app/builders/ashwin-sreenivas/) at [36:41](https://realalpha.app/v/_FmwqPzqkjY/?t=2201) · Knuckle Up with Nakul

## Takeaways

1. IC engineers are expected to shape incomplete requirements.
2. EPD leaders define targets, ownership and cross-team interfaces.
3. Teams can try options while keeping the customer solution simple.

## About this segment

Engineers take vague briefs, test options and use judgment to finish product details; EPD leaders set outcomes, owners and interfaces. Faster iteration shifts leaders from specifying solutions to aligning autonomous decisions.

From “The AI founder advice you won’t hear on X | Ashwin Sreenivas (Co-Founder at Decagon)”, May 19, 2026. [Watch the full episode](https://realalpha.app/v/_FmwqPzqkjY/)

## Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

[35:12](https://realalpha.app/v/_FmwqPzqkjY/?t=2112) starting from six months ago when Cloud Code seemed to have made a very step function difference to the next one to two years? So I think the IC engineer's role changes to being able to just iterate really fast. Back in the day when you had a very high cost to trying something, the correct thing to do was say, I'm going to spend a lot of time planning. Because if I do something incorrectly, it's going to take me even more time to fix it.

[35:40](https://realalpha.app/v/_FmwqPzqkjY/?t=2140) now essentially what we're doing is we need to push a lot more of that planning and thinking into one engineer's head because they can autonomously run for a really long period of time so the way that the ic engineers role changes is being able to say okay my job is no longer just taking a well fleshed out prd and just executing against it to getting a much more vague PRD with not all of the pieces filled out and saying, I'm going to be able to try things for each of these things that are unfinished and develop good taste on what the right final thing should be. Because that, again, constrains the development cycle substantially, right? Like, I don't need to wait for PM to come in and review this. I don't need to wait to have three meetings with people to figure out what the right thing is. Now, because of this, I think the VP engineering

[36:35](https://realalpha.app/v/_FmwqPzqkjY/?t=2195) and VP products job change substantially because since you have these small teams that are moving very, very fast without as much time to coordinate between them, the job of EPD leadership becomes to very clearly paint the targets of where we want to go because the moment you do that for a specific week, a hundred micro decisions will be made without you and to ensure that everyone is rowing in the same direction, achieving the same kinds of goals.

[37:07](https://realalpha.app/v/_FmwqPzqkjY/?t=2227) Your job on EPD leadership is to figure out very clearly and articulate very clearly what are the core problems we're trying to solve, who is responsible for solving each of those things, and if there are big kind of cross-team decisions, being able to very clearly point out what those are and what the decisions were. EPD leadership, has this not created a lot of noise or surface area for like too many micro decisions being made?

[37:33](https://realalpha.app/v/_FmwqPzqkjY/?t=2253) I have to pay attention to so much of this. Yeah, no, you're absolutely right. So I think effectively what the job has become is to be able to define these kind of higher level goals without being opinionated on how they're implemented. So for instance, you should be able to say, look, we built agents. So we need a good solution to be able to test agents well. And maybe say two or three sub bullets under that in terms of, hey, here are the kinds of things it should do and not be as opinionated on, oh, exactly how do we accomplish each of these?

[38:07](https://realalpha.app/v/_FmwqPzqkjY/?t=2287) Because if you can say, okay, this piece on how an agent is tested with the three subspecifics is done and you just trust that, okay, this person's going to do it. And now you look at a separate thing, right? Essentially what you're looking for is you have these services and you have contracts between them and you're not as opinionated on how each of those things is built. And as an EPD leader, your job is to be able to draw these clean lines and say, here are the interfaces.

[38:30](https://realalpha.app/v/_FmwqPzqkjY/?t=2310) that this is what each part should do. I'm not opinionated on how it is built because I know all of those decisions will be made very, very quickly without me. And teams should just be able to trust that everything on that side of the house will get done. Actually, as we're having this conversation, I wonder if, you know, Steve Jobs had a great quote, focuses about saying no. And in a prior era where the cost was, hey, if I try 15 different things, it takes time to build it.

[38:55](https://realalpha.app/v/_FmwqPzqkjY/?t=2335) It takes time to fix mistake. Now you're saying, actually, it doesn't take as much time to build it and it doesn't take as much time to fix mistakes, do you actually feel your advice would be to say yes more to EPD leaders? I think it's actually in between, where it would be try a lot of things. Because what you don't want to do is give... The customer, at the end of the day, wants that problem solved, right?

[39:21](https://realalpha.app/v/_FmwqPzqkjY/?t=2361) And ideally, they want that problem solved in the simplest possible way. And we run into this all the time, right? If you go into a customer and say, here is a product. And by the way, here is 500 different things that you could do to make this fit exactly like it. The customer just wants that problem solved. So it is our job to be able to abstract away a lot of this complexity from them. So we try a lot of things.

[39:47](https://realalpha.app/v/_FmwqPzqkjY/?t=2387) We try a lot of different solutions. But we want to go to the customer and say, hey, this is the right one for you. So I think that the adage on simplicity still holds. So let's shift towards FDE or customer success slash FDE.