Very well said. We actually saw a lot of the exact problems you outline. Largely because of this, as we matured as a company we moved towards the approach you suggest.

You could always ask the engineering team if it was feasible (assuming you can do that without guilt tripping them).

I see your point, it can put added pressure on developers, but don't you think (in a healthy company) that "shifts responsibility for fuck-ups" is a bit overstated?

Certainly transparency in sales is preferable, but is promising a (unexpectedly important to that customer) feature to close a major deal a "fuck-up"? There are some potential issues to steer clear of - team burn-out, feature bloat, etc. - but I would just consider it a sales expense/opportunity. If executed/communicated appropriately it could potentially create more trust rather than less.

Yes. Absolutely. I work for a company where deadlines are continually mismanaged for features because it really isn't predictable when a feature gets done or not. And the problem is at the top - but the top doesn't ever blame themselves. And so the blame shifts backward onto the engineers who didn't make the unreasonable deadline. The worst part is that the founders are non-technical so they really have no business making estimates about dea. We try to give the best estimate we can but it really is just an estimate, and it should be multipled by two and then have 10 days added to it just as a baseline. But the incentive is to overpromise, and so we're run into time compression again and again.

To me this just sounds like poor company/project management and passing the buck. I guess I'm envisioning a more healthy/well-managed environment, but maybe those are in the minority.

Almost all of the time the project we are doing for the client is so valuable that they eventually become quite pleased when we deliver what they wanted. But the mere imposition of a hard deadline on a feature that the deal-maker imagined because the client requested it is something we should change. I just think better/more flexible deadlines would be a good idea, in general, and overpromising to a client prevents that.

My experience in my office has been good otherwise, so perhaps I was being too negative above.

It is not overstated. What happens there is that development will end up in loose loose situation: fail the deadline or take significant shortcuts (ship buggy software). No matter what choice they take, most often second one, the development will be blamed.