Effective Engineering Manager

The episode delivers solid, actionable frameworks for cross-functional collaboration - particularly the four-pillar prioritization model (customer, business, team, self) and the orchestra conductor metaphor - but relies heavily on restating general principles rather than packing novel insights per minute. Much of the conversation covers well-established territory (PM-EM friction, alignment, communication) without surprising depth, though the escalation advice and tech-debt reframing offer practical value.

“EM should think about what are the unique engineering insights that only they can bring to the table”

“My suggestion is to always do what is good for the customers...second priority is what's good for the business...third priority is what is good for your team and your excellent partner...then finally the fourth one is yourself”

While the orchestra conductor analogy and the customer-first prioritization framework are reasonably compelling, the core ideas about EM-PM collaboration, proactive communication, and balanced roadmaps are well-worn in engineering leadership discourse. The AI-era observation about engineering as platform providers is forward-looking but underdeveloped and somewhat speculative rather than grounded in novel evidence.

“I visualize this as an orchestra...you as a EM are the conductor”

“EMS will transition to building more of the product platforms than actually building the products directly”

Ani Mishra is an engineering manager at DoorDash heading logistics engineering, giving him direct operating experience at a scaled company with real cross-functional complexity. However, the transcript reveals limited reference to specific, high-scale challenges or learnings unique to his tenure, and he speaks in relatively generalized terms rather than as a deeply specialized practitioner of a particular domain.

“Ani is an engineering manager at Doordash. Ani joined Doordash during its early stages in San Francisco. He currently heads the new verticals, logistics engineering at Doordash.”

“as an em, your job is to deliver high quality software to millions of customers”

The episode offers minimal concrete examples, named companies (beyond DoorDash), specific metrics, or real scenarios. The guest references generic use cases - 'reduce 5% of defects rate' or 'improve the conversion rate for checkout' - without naming actual initiatives, timelines, or measurable outcomes. The framework advice is abstract and principle-based rather than grounded in specific war stories or data.

“reduce 5% of defects rate uh, for a logistics system or it could be like improve the conversion rate uh, for the checkout”

“we are going to have lesser reliability for this XYZ service that will reduce the checkout rate for 1% of customers that are located in this part of the world”

The host (Slava) asks reasonable follow-up questions and affirms the guest's points, but rarely pushes back, challenges assumptions, or drill into contradictions. The conversation is collaborative and warm but lacks the sharp interrogation or productive disagreement that would test the guest's claims. The host mostly validates and extends rather than probe or probe further into edge cases.

“So tell me more, what does it take to collaborate, cross function and what does it take to deliver when you have so many tight important dependencies?”

“How do we handle, how do we as engineering managers handle day to day work which is not always perfect?”