Kris Gale recently wrote an attention grabbing article: The one cost engineers and product managers don't consider. The article is long, dips into a few different topics but can generally be summed up as:
Engineering needs to have substancial influence over business decisions. This is because engineers understand a system's overall costs [complexity] better than the business.
*update: Kris summarizes his post as: "My summary: Build only what matters (using economic measures) in order to keep velocity up so you don't miss big opportunities."
An organization should have balance and respect for everyone's expertise and personal motivations. This means that just as the business trusts engineering to do their job well, engineering needs trust that the business is doing their job well. To be clear, this does not mean command and control; there needs to be effective communication between everyone. When a designer argues that a particular design decision may have negative repercussions, everyone should listen - the same applies for every other role.
Yet, Kris' argument puts the emphasis that engineering should have particular influence (because they understand 'cost' more) when business decisions are made.
Ma'am, I got there first with the most men
Consider a real world context: Yipit. How Yipit (a personal shopping service) started is a great story. The summary is that in order to offer a great personal shopper experience, the founders did not write any software which analyzed a customer's tastes and then suggested items for them. Instead, the founders did all the personal shopping by hand.
Even better, as the company took off and competition started popping up (which eventually couldn't compete) - they still didn't write any software; software which would have reduced their costs. Instead, the company just hired more and more employees who would do all the data entry by hand. According to the founder, Yipit didn't build a software implementation until 9 months after the product was released.
The costs of having such a large staff are huge (hiring, firing, training, paying... ) which only grow exponentially. Yet, those costs didn't matter because it was all trumped by a cost which engineers generally don't consider: the opportunity cost of not being first.
A particular design decision may incur substantial costs in the short term (building it) and long term (maintaining it), yet, it's one of many costs which must be evaluated. How an organization evaluates, balances and mitigates these costs depends on the organization and makes it hard to give a straight answer. What straight answer that can be given is simply:
Don't tell engineers how to write a program.
Don't tell designers how to make design.
Don't tell product how to evaluate costs.