Why Don't They Trust Us?

Hmm,

The article conjures up an idea of blind "trust" that I would claim you only have when you're making a decision of fairly small consequence to yourself. Sure, I'd guess a wealthy person is OK just sending their car, that probably doesn't many miles on it or problems to it, to a high priced mechanic and assuming everything will be OK. It probably will be and in the off-chance it isn't, the extra money you've been feeding the mechanic gives them an incentive to make things up to you.

Personally, I have one mechanic I trust to repair my car at the lowest price and another mechanic I trust to know all of the weird problems of this vehicle (and to charge a higher price as well as to have a multi-week wait time). But that's because auto repairs are a big part of my budget (sure, you can buy a car for $20K and spend nothing for a while or you spend $2K on your car and $1K/year for some period, TCO isn't clear).

Even more, if you are getting improvements on your house, you only dole out money to someone you "trust completely" if your income stream is secure enough you don't mind the risk of a significant amount being tacked by a contractor who's gotten up to the level of "best reputation". If you're trying to improve your house on the cheap, you look carefully at all the options, not "trusting" anyone explicitly.

And that's why it's unlike a software team is likely to get this sort of trust. Nearly everyone paying to have a significant piece of software built is making the kind of decision you have to supervise. Supervise doesn't mean micro-manage but it is significant and quite different from any "pay and forget" type relationship.

the problem (as I said in my other comment) is that "development" is incredibly vague, software development or product development are hugely different fields, almost always those roles won't be covered by the same person, unless we're talking about a very small startup. In the article the author makes several statements that apply e.g. to SW dev but not product dev or vice-versa. I find the article confusing for this reason.

I can dig this.

That said, if a mechanic says “if you don’t get this repair your tailpipe is gonna fall off” and you say “nah let’s risk it”, you’re not gonna go back to him when it falls off and say “wow I can’t believe you let me drive my car until the tailpipe fell off, you should’ve done better!”

If, however, a dev team says “hey guys, if we don’t fix this tech debt we’re gonna run into some perf issues and the site may crash” it’s a lot more likely they’ll come back and still find a way to blame the dev team when the product inevitably does crash or really struggle to deliver results.

Again, like my other comments say, this could be completely anecdotal on my part and totally greener grass thinking on my part, but it definitely does feel like this is the way the product teams I’ve worked with behave toward development teams.

The article suggests multiple times that it's "software product development"... so product development. The author has tagged himself as "product development nut".