As someone on the implementation side I have a sour taste for Sales and Sales Engineers. Always selling features we do not have or things we cannot do. Then they mock it up and leave and I have to break the news to the customer.
You may wish to consider your sour taste to be less targeted at Sales and SEs and more around (broken) company-wide processes and (lack of) clout the implementation teams wield.
I'm also on the implementation side (sometimes referred to as professional services), and two immediate thoughts jump to mind:
1) Unless you're a practice manager directly responsible for maintaining a targeted book-to-bill ratio or other quota metric (which usually entails account and long-term customer relationship management), your management should not be throwing you under the bus and exposing you to break that news to the customer. Nothing destroys a booking pipeline faster than customers with mismanaged expectations.
2) This type of behaviour from Sales teams is usually indicative of misaligned incentives. A concrete example of this type of situation could be company in an early "hyper-growth" phase where they only comp on new bookings, and don't comp Sales on contract renewals.
Much of the time sales' over-promising comes as a result of some management or client services functionary that's not a technical product manager but thinks they are insisting that $requirement definitely will be possible once $feature is in place, which definitely will be on time, so no need to communicate with the dev team at all on that.
(It's often the same middle management that omits to let the dev team know the system is supposed to work on IE8 until the client complains.)
Sales commmonly direct their sour taste towards the developers...
I had a long response written out but my browser barfed. Short answer is "yes". Longer answer is "it depends" on the size of the budget/deal, the business function that the manager fulfills, and the size of your organization as a whole:
* Business function: If you're customer facing, most [project|practice|field|support]managers should be sticking their nose into day-to-day projects, especially when a bad message needs to be delivered (e.g. the product we sold you will fall short of your expectations). This is not only because the customer will be incensed, but because there may also be commercial repercussions (e.g. SLA penalties) that you may not be aware of in umbrella master [service|support|license] agreements.
* Deal/budget size: Typically, the larger a manager's deal or budget, the more headcount they have. And the more headcount on a project|team|division, the more intermediate managers there will be to layer the manager in question. Hence, if the deal size is rather large, in most cases managers will not get involved on a day-to-day basis, but should be available for escalations (presuming an account management role for larger deal sizes). If the deal size is usually smaller, more than likely the manager will be more involved (e.g. as a project manager).
* Org size: BDC - not usually. Startup - usually yes.
A lot of it is cultural. Is sales job to hit the number, or is it customer success? It has to be the latter if you want to grow a reputation and in turn increase the level of relationship with your customer. This is the difference between selling a $400k one off, a $2m "mail the CDs and run", or a long term relationship that nets you $10m or more and multiples of that in benefits for the customer themself.
Also, some (most) places do not have very good lines of communication between sales and R&D, while others do. I'm lucky to be in a place where I can submit a PR on Github if I need something yesterday, or can file feature requests / fixes that will get looked at within the week.
My view is generally that the relationship with a customer is where you make most of your money over 5+ years, selling them an opportunity once by promising the moon and delivering a paper plate is in no one's interest. Lots of sales people act that way but that's not going generally going to be your leaders.
I'm a Sales Engineer and I work mostly on the post-sale implementation side of things, which is not really a common approach - so I completely understand why people feel this way. One of my main jobs is to keep our Sales team informed of exactly what is and isn't possible, because most of them just don't know better when it comes to deep technical topics. Having somebody on the Sales team who is willing say no is really important.
I've been on break/fix and on the Sales Engineer side and know both - there's never a single side to these things.
Sales Engineers in particular don't want to sell something dishonestly - it opens the company up to risk and it hurts their credibility, particularly if you sell multiple products.
There are a few reasons I can think of:
1. The technical people that run the current implementation didn't put their requirements into the sales process.
2. Some of those features really don't matter to the business and were fodder.
3. The requirements were listed, but not accurately or with enough depth.
4. The Sales team didn't have enough knowledge (or training) to know the difference - or inaccurate documentation.
5. It was roadmapped close enough to implementation and including delays to go ahead anyway.
6. The competitor claims to have this feature but theirs is broken also, so it's a race to who can sell broken stuff faster - because nobody can truly do it.
The people and the companies that support this exist certainly - just not for very long.
I see different incentives within my own organization. Sales and sales engineers makes commission so they want to close the deal no matter what. I deliver a specific product so I just want to get it done and stay under budget. Another consulting group handles the long term customer relationship so they are more inclined to give away free work for future relationship building that I am not incentivized to want to do.
