Privacy programs that live inside legal are privacy programs that react to problems. Privacy programs that live inside engineering are the ones that prevent them. The difference is when in the product cycle the privacy review happens.
The failure mode I have seen most often is a privacy review process that runs after design is complete. By then, the cost of changes is high and the appetite for them is low. Privacy review at that stage is damage control. The ask is always: can you make this change without touching the existing design. The answer is usually: not really, or only with significant rework.
The intervention that works is getting privacy questions into the design review. Not a checkbox, not a form filed after the review. Actual questions in the room: what data does this feature collect, does it need to, where does it go, who can see it, and how does it get deleted. Those questions change designs when they are asked early. They are resented when asked late.
At Intuit, compliance dashboards for TurboTax required clear data lineage: where the data came from, how it was transformed, and what happened to it at the end of its retention window. Building that lineage into the program architecture from the start cost less than auditing it after the fact by a significant margin.
Privacy by design is a program management outcome, not a privacy team outcome. The privacy team sets the standard. The TPM is what makes engineering teams hit it before the audit, not after.