Everyone is attacking the overall theme of this article, and I agree with many of the points made, but nobody seems to be focused on the actual solutions provided in the article which I think are good. The article isn't about software developers believing in you PRODUCT its about software developers believing in your PROJECT. If I was the author, I would probably try to rephrase this as "Software developers are most effective when they feel a sense of ownership and responsibility for the projects they contribute to." The article suggests 4 items:
Don't withhold newly discovered information about the customer's needs
Avoid the temptation of isolating the team in the name of "just getting* it done"
Avoid discouraging technical team members who express interest in the market or business model
Avoid over-statusing your software development initiatives
All four of these items are ways you can signal to your developers that you trust them to do their job and respect their ability to make use of the information given to them (You can't handle the truth!!). I think its worth at least being aware of this methodology in the case that you have a dev team which is showing interest in "the why" of a particular project, or appear to be struggling to build what the business is asking for. Otherwise, you are better off incentivizing devs with bonuses, pay raises, and equity because they might just not care about "the why" or "the why" might just not be useful for them to do their job.
Don't withhold newly discovered information about the customer's needs
Avoid the temptation of isolating the team in the name of "just getting* it done"
Avoid discouraging technical team members who express interest in the market or business model
Avoid over-statusing your software development initiatives
All four of these items are ways you can signal to your developers that you trust them to do their job and respect their ability to make use of the information given to them (You can't handle the truth!!). I think its worth at least being aware of this methodology in the case that you have a dev team which is showing interest in "the why" of a particular project, or appear to be struggling to build what the business is asking for. Otherwise, you are better off incentivizing devs with bonuses, pay raises, and equity because they might just not care about "the why" or "the why" might just not be useful for them to do their job.