4 ms·

I think that this blog post is hiding the fact that a team of engineers had their evening robbed from them, at no fault of their own, for something that was ult

I think that this blog post is hiding the fact that a team of engineers had their evening robbed from them, at no fault of their own, for something that was ultimately kind of trivial. There are numerous reasons why it's a bad idea to make engineers burn the midnight oil to rush the finishing of a product -- the first among them being Hofstader's law. If your team actually needed an additional day of work, and you didn't already have your product in the bag, you had no good reason to be courting the press in the first place. Mistakes happen in the news cycle. This is usually why you do an unadvertised soft launch shortly before a press release's publication date. This was a lack of due diligence, and not on the part of the engineering staff. I think that there's this misconception in the startup world that the shipping of a stable product and its actual introduction in the market are efforts that are in parallel, in real time. In actuality, it makes a lot more sense to implement a lag of roughly one week between finishing a stable product and putting it out to the public. Many shops refer to this as "staging" or "vetting a release candidate". This doesn't seem like something that the folks at Cue considered before diving head-first into a hurried hackathon. The last thing a responsible organization should do is punish the people responsible for making a stable and useful product by making them rush the last 10% of their efforts. I don't doubt that this kind of hurried time to market will result in another all-nighter down the road. I'll bet you dollars to doughnuts that after the 20th time hearing "Y Sin Embargo", the team was fatigued, annoyed, and ready to take shortcuts. So there, we have technical debt that could have been avoided if everyone just agreed to stick to their guns with the original release date. But most likely, the best solution would have been a soft launch preceding the any publication by at least a couple of days. Let's be honest: if the immediate traffic from a little pre-arranged press is what makes or breaks your product, you're doing it wrong. As an engineer, if I see you have to put your entire organization into crisis mode over something like this, then I'm going to start taking recruiter calls more seriously.

kevinclark 14y ago
Engineer at Cue here. This was a team decision. There was no mandate from on high - we're not abused. It was time to ship, so we made it happen.
- asarazan 14y ago
  What he said. Furthermore it's worth pointing out when trying to execute a coordinated media push (especially with traditional media), you have no choice but to give a lead time and put an embargo in place. This is standard practice when dealing with publications. 9 times out of 10 it goes off without a hitch. We were the 10%, so to speak.
RoboTeddy 14y ago
The team at Cue is extremely talented and prideful of their product, and such teams are happy to crunch now and then in order to make things happen.
- MatthewPhillips 14y ago
  > such teams are happy to crunch now and then No one should ever be happy about working for free. Being a good team player means sometimes doing it anyways, but the situation that caused it should be rectified first.
  - dllthomas 14y ago
    > No one should ever be happy about working for free. I don't know if I agree with that statement.
    - MatthewPhillips 14y ago
      Fair enough, in the context of an employer/employee relationship then.
      - dllthomas 14y ago
        Yeah, I think "you should never expect someone to be happy about unpaid work" might be closer.
    - mthreat 14y ago
      Assuming they hold options or shares, it's not likely to be "for free". (edit: I meant to reply to the parent comment)
  - natrius 14y ago
    Unless the employees are being paid hourly, they're not working for free. That's how salaries work.
    - 14y ago
drusenko 14y ago
It's negativity through and through here, and it's impossible to get away from it. Consider the following: - You have a team that has been working incredibly hard pursuing a dream: that they can build a product, from scratch, that is truly useful to millions and millions of people. This is not an EA requiring engineers to pull insane hours -- this is a labor of love and everyone has considerable equity. - It's a small team and that means each person has a lot of responsibility. Don't like ever having to pull an all-nighter? Never want to work a minute past 5? That's OK, but it means you have no real responsibility, and you will be compensated accordingly. Others choose more responsibility, and they man up when the shit occasionally hits the fan. - Have you ever coordinated a massive press push with the top print publications? Then you have no business telling them how it should be done. It's extremely difficult, it requires dates locked down months ahead of time, and with that kind of advanced commitment, planning 100% accurately is beyond difficult. - After this ordeal, the team posts an honest story from the trenches. Go to any successful startup and you will hear many war stories like this. Nothing is ever perfectly planned, unexpected shit happens. It's frankly awesome that they shared it and gave some insight into what goes on behind the scenes that you don't normally hear about. - What is your reaction? You shit all over them. Tell them that they're horrible people and that they did it all wrong. Exclaim that you could have done it all right and they have no idea what assholes they are. I have no idea what drives this extreme negativity on HN, but it's gotten completely out of hand.
- languagehacker 14y ago
  One of the intended uses of this site is to exchange best practices and learn from the mistakes of other startups. I think that this blog post falls in the second category. And I don't think that there's anything wrong with me pointing it out. I'm glad it worked out for the folks at Cue, but I think they could have avoided a lot of headaches with some better planning. I'm not suggesting some radical technique I just made up; I'm pointing out that there exist practices that would have prevented a needless scramble. The circumstances of this story should not serve as an example to other startups, but rather a cautionary tale of what can happen to a shop without the proper release cycle and adequate project management in place. My tone may have been a little rough, sure. I probably wouldn't have even commented if the post had addressed what went wrong and what they learned from it. I guess heroic last-minute efforts amount to a more entertaining story than adequate planning, but I think we can all agree on which method is a more reliable way to run a successful software shop.

kevinclark 14y ago

Engineer at Cue here. This was a team decision. There was no mandate from on high - we're not abused. It was time to ship, so we made it happen.

asarazan 14y ago
What he said. Furthermore it's worth pointing out when trying to execute a coordinated media push (especially with traditional media), you have no choice but to give a lead time and put an embargo in place. This is standard practice when dealing with publications. 9 times out of 10 it goes off without a hitch. We were the 10%, so to speak.

RoboTeddy 14y ago

The team at Cue is extremely talented and prideful of their product, and such teams are happy to crunch now and then in order to make things happen.

MatthewPhillips 14y ago
> such teams are happy to crunch now and then No one should ever be happy about working for free. Being a good team player means sometimes doing it anyways, but the situation that caused it should be rectified first.
- dllthomas 14y ago
  > No one should ever be happy about working for free. I don't know if I agree with that statement.
  - MatthewPhillips 14y ago
    Fair enough, in the context of an employer/employee relationship then.
    - dllthomas 14y ago
      Yeah, I think "you should never expect someone to be happy about unpaid work" might be closer.
  - mthreat 14y ago
    Assuming they hold options or shares, it's not likely to be "for free". (edit: I meant to reply to the parent comment)
- natrius 14y ago
  Unless the employees are being paid hourly, they're not working for free. That's how salaries work.
  - 14y ago

drusenko 14y ago

It's negativity through and through here, and it's impossible to get away from it. Consider the following: - You have a team that has been working incredibly hard pursuing a dream: that they can build a product, from scratch, that is truly useful to millions and millions of people. This is not an EA requiring engineers to pull insane hours -- this is a labor of love and everyone has considerable equity. - It's a small team and that means each person has a lot of responsibility. Don't like ever having to pull an all-nighter? Never want to work a minute past 5? That's OK, but it means you have no real responsibility, and you will be compensated accordingly. Others choose more responsibility, and they man up when the shit occasionally hits the fan. - Have you ever coordinated a massive press push with the top print publications? Then you have no business telling them how it should be done. It's extremely difficult, it requires dates locked down months ahead of time, and with that kind of advanced commitment, planning 100% accurately is beyond difficult. - After this ordeal, the team posts an honest story from the trenches. Go to any successful startup and you will hear many war stories like this. Nothing is ever perfectly planned, unexpected shit happens. It's frankly awesome that they shared it and gave some insight into what goes on behind the scenes that you don't normally hear about. - What is your reaction? You shit all over them. Tell them that they're horrible people and that they did it all wrong. Exclaim that you could have done it all right and they have no idea what assholes they are. I have no idea what drives this extreme negativity on HN, but it's gotten completely out of hand.

languagehacker 14y ago
One of the intended uses of this site is to exchange best practices and learn from the mistakes of other startups. I think that this blog post falls in the second category. And I don't think that there's anything wrong with me pointing it out. I'm glad it worked out for the folks at Cue, but I think they could have avoided a lot of headaches with some better planning. I'm not suggesting some radical technique I just made up; I'm pointing out that there exist practices that would have prevented a needless scramble. The circumstances of this story should not serve as an example to other startups, but rather a cautionary tale of what can happen to a shop without the proper release cycle and adequate project management in place. My tone may have been a little rough, sure. I probably wouldn't have even commented if the post had addressed what went wrong and what they learned from it. I guess heroic last-minute efforts amount to a more entertaining story than adequate planning, but I think we can all agree on which method is a more reliable way to run a successful software shop.