For a certain type of engineer everything involving sales, marketing, discussions about perceived value and getting paid tons of money for something that basically equates to "advice giving"... will seem strange and weird.
I've tried to use this same reframing approach when working with people to estimate a software schedule (for complex projects with external promises). Basically, if you can establish that engineering is about tradeoffs -- such as between runtime and memory footprint and code size and small vs large values of N and so on -- then certainly human development time is another resource subject to tradeoffs, where we should identify alternate scenarios and try to aim for the optimal one.
Finding ways to talk to people in terms that resonate is tricky -- and often almost a matter of bridging micro-cultures, where subtle tribal affinity signals are needed to gain trust -- so I was impressed that Patrick could break down salary negotiation in a way that didn't seem skeezy to people who just want to build great things and not worry they are getting shafted.
