I didn't read the original, but the clarification evokes a reaction in me.<p>I'm very much in agreement with the idea that you shouldn't hire <i>just because</i> you are overworked. However, I would rephrase it in the positive: Hire when you are in a position to incorporate more people. Avoid hiring when you are not, even if you are over worked. Hiring someone because you are doggedly trying to hit a deadline and you think that bringing on more people will help you is one of the classic ways of torpedoing your team. Integrating new people takes time, attention and resources. You will have <i>less</i> capability for a surprisingly long time immediately after you hire someone. Make sure that you hire when you have the capability of dealing with that. If you don't have the capability, then focus your activities until you do.<p>With respect to time synchronisations, logic would have me agreeing, but experience compels me to disagree. I've never had "ship when it's ready" work. That sounds horrible, but it's true. The main problem is that "ready" usually has a very loose definition and without anything to constrain it, it often expands over time. I'm sure there are ways to get it to work (by imposing other constraints), but I have not personally experienced that. Instead, I have had great success with using time to constrain what we deliver. The trick to this is to have <i>very</i> good tracking and to be flexible in <i>reducing</i> scope as you arrive at your arbitrary release date. By having very short releases, you can kind of approximate the "release when ready" approach (to an extreme, you can have "internal only" releases and then have an "external release" when you think it is "good enough" -- but you have to be very careful of the "creeping good enough" even still).<p>The other stuff is hard for me to comment on because I have yet to form firm opinions (after 30 or so years on the job!) I've definitely changed my mind a <i>lot</i> and I suspect most other people will too, given enough time in the industry. Possibly it's hard to make a general statement because it is to sensitive to the context.