[brador]

Failure point: You waited too long to hire a new developer.

You thought you could handle it, but couldn't, and you should have seen this coming. The team leader failed here and let a severe issue (overwork of staff) cover his ass on costs.

We always have an extra developer on every team, no one does crazy overtime. It's worth the extra $0-$30k for the intern/half-timer. The kid gets experience and we get a backup.

Should we lose a live dev, we prop the intern/half up to full and we're back up to speed. We also track overwork/hours.

Once again, the team leader failed. You SHOULD hire more developers, and you should hire them sooner, specifically because a training period is involved.

This is something anyone who's spent time in a growing organization could advise you on, and a good reason to have mentors if you're inexperienced in business.

[matwood]

Failure point: You waited too long to hire a new developer.

This is what I was coming to say. Of course Alice is going to take some handholding because she's new. She could be an A+ developer and will still require team time to help her get up to speed. The problem is that the team in the article waited too long to bring Alice on. They were already far too behind the 8 ball to have any time to get her up to speed. If they had brought her on sooner then they might not have ever been in the situation to start.

[roc]

But the corollary is that the longer they wait to hire Alice, the worse the situation gets.

That is: they should have hired her yesterday and hiring her today won't help the current cycle, but you have to hire her today to have any hope for the future. [1]

[1] Unless you have incredibly isolated projects, in which case you can arguably put off hiring Alice until after the release, but you'll still need to bring her on well before the next one gets under way.

[matwood]

Yeah, I should have been more clear. I agree with you that hiring Alice then was the right thing to do even if late. Worst case is she can start learning the code base on her own until the current cycle finishes and the team has more time to spend with her.

[ohyes]

In fact, if everyone is working a 60 hour week, they should have hired an extra 2 1/2 developers.

If you aren't making enough money to cover the extra 100 hours of development, perhaps you need to change your pricing strategy or have lower expectations for margins.

[MetalMASK]

Couldn't agree more. Also, why not let the new developer work on new features? What's even better, you can hire someone who specialize in that new feature that your client want (geocoding, mobile dev), instead of having existing developers to "learn" it (which by the way, is always the preferred but wrong way by the existing developer). The new developer doesn't have to know the details of the backup, just the interface or API of existing services. Existing developer works on bugfixing on what they are familiar with.

[alttag]

Yes. This is a theme in Tom DeMarco's book _Slack_.

It applies not just to developers, but office furniture, conference rooms, processes, and most other employee types too.

[pinaceae]

you are absolutely right, but there is a factual counterpoint: availability of those intern/half-timers in the region.

we are located near SF, so far we had a hard time finding interns - cause the young kids are busy building start-ups themselves...

[patrickyeon]

How much are you offering to pay them? When you say 'availability', do you really mean 'availability for less than market rates'?

[randomdata]

This is actually a pretty good question.

Everyone has to weigh the benefits of starting a startup over having a regular job. If all the kids are starting startups, that indicates that the benefits of having a job are so low that it is always worth the risk of startupdom.

Money may not be the only consideration, but I'm sure it is a big one. Would these kids be all starting startups if the programming jobs paid, for instance, $500K per year?