27 ms·

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 oversta

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.

Aqueous 12y ago
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.
- maxbrown 12y ago
  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.
  - Aqueous 12y ago
    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.
- deleted 12y ago
  [deleted]
watwut 12y ago
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.

Aqueous 12y ago

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.

maxbrown 12y ago
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.
- Aqueous 12y ago
  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.
deleted 12y ago
[deleted]

watwut 12y ago

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.