2. The reason engineers tend to hate tactics like this is that it shifts responsibility for fuck-ups from you, the CEO, who should be managing and prioritizing features so you get the best bang for the buck, to them, the engineers, who are now on the hook for a feature that may or may not be able to be built in the time frame you promised. Things go wrong in engineering, and there are unexpected snags and slowdowns, and a well-managed business should be able to absorb them without losing customers. There are very real costs in added stress and loss of personal time for engineers - not to mention decreased trust from customers - that come from this tactic.

As the sibling comment mentioned, just say "The feature is not ready yet but we'll take your request under advisement and let you know as soon as it is." Then prioritize the features that lots of customers want. Maybe you'll lose the sale, or maybe they'll buy anyway because it was non-critical for them. Either way, you should be operating with enough of a financial cushion that one sale won't put you out of business (as PG says, "Deals fall through!"), and being able to aggregate requests lets you build a much better product instead of continually chasing after whatever the latest customer wanted.

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.

2.) Caused a lot of big troubles in companies I worked for. The customer signs. Turns out that developers can not make the feature till the launch. Shortcuts are taken to cover up. We ship broken buggy software just to make the deadline. Whops.

Of course, salesman learned that all went well, because all those bugs are going to be reported/fixed weeks and months after launch. He does not see the connection. Salesman do that again and again, promises conflict with each other, development is permanently without feature plan to stick to more then a month. Work get to be done redone again and again and the code is increasingly crappy and buggy.

Of course, development gets blamed for all those problems. Of course development can do nothing about underlying cause of it.

Feature scheduling by salesman during the meeting is horrible thing. That behavior is the reason why sales have reputation of being liers and why companies tend to produce crap so often.

> 2. I think people can reasonably disagree here. An example: a potential customer asks a sales guy during a demo "...and will we be able to export a list of our users?" Answer: "yes, absolutely". The customer signs. The sales person then runs to dev team and says "we need to build this export functionality before they launch". Did the potential customer think that feature already existed? Probably. Is anyone being hurt? I don't think so, so long as the export functionality can actually be built before the customer launches.

I'm not OP, but you still don't get what's wrong here. You're still lying. Why not say "Not yet, but we have a great dev team and we would gladly add this feature in for you before launch." It's honest, and frankly sounds more impressive to the client.

It's so common that most people think this is how every one works.

I worked with many sales people who got CEOs later, because they made big sales, but most of them, because they sold stuff they didn't had, because they didn't really know the customers.

In extreme cases, this leads to overworked devs and rich sales people, when the devs are good and the features aren't that hard to implement. If the features are too hard, it leads to angry customers and the company losing much money.

" It's honest, and frankly sounds more impressive to the client."

LOL, how much have you sold in your career? Because really, it seems like you've never had a sales meeting at all.

Look, ethically, I totally agree with you.

Practically though, if you've worked in sales, you'll know that what the OP is talking about isn't just something that happens often, but is basically the life-blood of some rather large companies.

Now, I dislike it because it puts the impetus on the developers to deal with it if it goes wrong, and that sort of crunch-time stress is just crazy, but it's also not something that the OP has come up with on his own...

Smarter clients (and I agree that there are plenty of not-so-smart clients), will actually double-check on these things before buying in various ways. They can, for example, request an evaluation version to use, check with the support department exactly what's actually supported, or simply have them demonstrate exactly how the product can meet that requirement.

I'm sure there are more ways of doing that too, though, so these are just my observations. And yeah, don't trust the sales guys :)

Agreed. It is great that he is being open and honest about his morals.

But if I ever learned that a business partner were so dishonest with me, I'd drop them in a heartbeat. Business relations are all about trust and integrity.

He's not being open and honest about anything here. He's a liar. He lied to his partners, he lied to his investors, he lied to his employees, he lied to his customers, he lied to the IRS, and he lied to the press. Every single item on his list here is the result of him stretching the truth and calling it "hacks".

That's fun new word for "lies".

I mean, he's speaking openly about his morals here. Which is undoubtedly a good thing.

Obviously, he's a liar to his business partners, his customers, and his employees. But right now, he isn't a liar to us quite yet.

And it should be noted, that based on the replies here and the feedback, it sounds like he might not be a liar anymore. Hopefully he's seeing the issues that his employees have to put up with when he puts them into this kind of situation.

So he has gained some personal growth from this event. All's well in the long run, but its difficult to make up for broken trust.

Your #2 astounds me. To me, that is obviously, obviously, clearcut, wrong. And the way you justify it is transparently stupid. You say that it's fine because nobody gets hurt as long as the lie can be made good. The whole problem with lying (putting aside for a moment abstract moral ideas that it's wrong in some pure sense) is that it eventually comes crashing down.

Sure, it all works out fine. Sales over-promises, engineering delivers anyway, the customer is happy. Until sales promises something that not only doesn't exist, but can't be done. Then you have a binding agreement to deliver something impossible. You get hurt because you're now revealed as untrustworthy. The customer gets hurt because their plans are built on something that isn't going to happen.

I'm especially impressed that you're unable to see the parallels with your own story. Much of your post boils down to, "don't lie (especially to yourself), because it eventually catches up to you". Yet here you are, saying that it's perfectly fine to lie as long as it doesn't catch up to you. Did you learn nothing of the commonalities that tie your individual points together?

For the record, I haven't the slightest idea who you are or what your company does or did, and am basing this comment purely on your post and this comment, just in case it sounds like I'm reacting to old wounds or anything like that.

Thanks for responding. I actually made the account because I haven't commented on hacker news before though I read it all the time. I just feel strongly about it so I had to write a response.

I stand by my comment.

> absolutely

When a vendor uses superlatives like "absolutely" in answer to a capability question, they are lying. This also applies to politicians.

If the answer is "yes", they will say "yes" or "yes, because/for example ...".

Seth, I'm very impressed with your level-headed response here. As others have said, thank you for writing the post that you did. I've been in similar situations so I know that wasn't easy. People will be upset with you and that is their prerogative--after all, you did make some big mistakes and you know it--but the best thing you can do is make your apology, learn from it, and move on. Good luck!

First, I think xcubed is right about #1. Not paying taxes should be considered a criminal negligence. All companies should operate within specified rules by the law and if one company does not it gets an unfair advantage over others. As a stakeholder in a company one should learn how to run the daily operations or hire some bookkeeper that can.

The other points (2-3) I don't see any problem as that's how all the companies that I know operate. Everybody sells half-ready products. I would even consider stupid not to do that.

Regarding the employees I think that every employee that joins a company is part of the and the team fails as a one. I have been a part of a failing team and I don't hold the company's owners resposible of my future career. I don't think Enron's owners were very much interested in the re-employment of their staff either.

I was once listening to a lecture by Monty Widenius and he said that statistically an enterpreneur succeeds in the third startup he/she gets going. Failures just teach us how to do things better. A culture where a failure is considered as our only lost chance of success does not lead to anybody succeeding.