Hacker News new | past | comments | ask | show | jobs | submit login

> Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.

I disagree - if you have overworked people, that is usually a red flag that you need more personnel and planning failed. It doesn’t necessarily mean you should be hiring right at the moment, but it is a significant alarm bell that you should seriously consider starting to hire or you’re going to chase away engineers.




>> Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.

> I disagree - if you have overworked people, that is usually a red flag.

Overworked people is a red flag indeed, but it is usually a symptom of a deeper problem that is unlikely to be solved with more hires. I think the author hits the nail on the head here -- first and foremost hire for future opportunities.


Agreed. At a previous (small) job the IT department was VERY overworked. They tried to hire to fix it and it didn’t work. Because it wasn’t the problem.

The problem was unsustainable methods of doing everything. Every job was unique for no good reason. It was all managed by hand, monitoring monitored the wrong things.

Each existing thing generated a ton of work due to how it was setup and required constant tweaking. Any new thing just piled additional work on, often causing issues with what already existed.

Because of the lack of any kind of system or useful documentation new employees only made things worse as they tried to understand what existed, had to ask constant questions, or failed to take into account hidden gotchas that they had no way to watch out for.

Until they started standardizing and stabalizing the base things couldn’t be improved.

Yes there are times you have 10 developers worth of work and 5 developers. But there are times you have 4 developers worth of work and 6 developers worth of mess they have to tip-toe around, but only 5 people.


"Overworked" does not need to mean your engineers are pulling 14 hour days. Even just having a massive backlog that never gets knocked down is, to me, a form of "overwork".

Even if the work life balance is fine, it's very difficult to stay motivated when you are constantly chasing bugs and never getting to actually build anything, or your manager is having to defend your team against second guessing from the outside. Having too many things to do and not enough people to do it can really kill morale.


> Overworked people is a red flag indeed, but it is usually a symptom of a deeper problem that is unlikely to be solved with more hires.

Not necessarily. Accepting a new project or extra responsibilities in exchange for a generous sum may increase your company's workload unexpectedly, which leads to overworked people while the company struggles with the hiring process. Another example is losing a team member right before crunch time.


Sure, there are exceptions. For example, I do not see a team flying out for a 2 60+ hour week test campaign as a red flag as long as the participation is mostly voluntary and the team gets an ample opportunity to detox after the fact.

The exceptions, for me, have three key properties: (1) they are temporary, (2) overworked people know that it is temporary and have a clear (maybe not 100% realistic) date for return to normalcy and (3) this state of affairs is seen by most of the team as acceptable at the moment: not pleasant, but bearable and probably least bad of all options.

If (1) and (2) hold, (3) is usually easy to achieve with sweeteners: $x bonus, T extra vacation, etc. But break either of the three and you have a clear red flag. Just my 2c.


Perhaps the deeper problem is the lead who committed to the deliverables isn't doing a good job and should be removed.


I think what he was going for was that you shouldn't solve the overworked problem with hiring. It indicates you need more manpower, yes, but it's also indicative of planning and resource allocation problems that need to be solved first. Adding more people before you solve those problems will probably make things worse. Things need to be properly divided and conquered, some things may need to be put on the back burner. It often indicates that you haven't split up the workload into manageable pieces, and are instead trying to get it all done at one time.

Someone might now jump and say 'sometimes crunch time is necessary!', and I would reply that if you're in crunch time you've just demonstrated the exact issue I'm describing.

I think he's essentially restating 'the mythical man month' for a modern environment.


But similarly, quickly coming to the conclusion to not hire is just as fallacious.

If someone burns out as a result of the bungled planning, then the project can potentially be doomed without hiring (or even doomed anyway) - one should almost immediately reevaluate when one comes into this situation unless there was some sort of agreement beforehand.


Alternatively, feeling pressure to hire because of workload means that you failed to hire quickly enough upfront, and now you are manpower strapped because you were trying to make your burn rate look better for this month.


You either need more people or less work. And having too much work may be because the organization has lost focus on what really matters, and is trying to do everything. You cannot hire enough people to solve that problem, because as you add people, management says "great, now we can do even more..."


Almost every military metaphor in this piece fell flat for me, but this one might have been the worst of the bunch. Not only is it a forced metaphor that barely fits the point being made, it's not even a particularly good point.


That's about where I stopped reading.


"18. Don’t shy away from leading without doing, it is unavoidable, so just do it. Then do some work to stay pertinent.

19. If you are not able to hire and fire people, leave. Or stay for the retirement fund if you can stomach it."

the way the author discusses people and pretty much everything in the "Yourself" category makes me think this unnamed multinational is a sweatshop overseas. I've worked (temporarily) with people who try to bring this thinking to Silicon Valley


I got the same sense as you, but without the "overseas" bit. We have sweatshop software shops in the US (look in just about any AAA game company, for example).


I took #18 as ‘don’t be afraid to delegate, you don’t have to have your finger in everything.

#19 makes sense me to too. If you can’t hire/fire then you’re not really in charge. How can you manage your team if other people have the ultimate veto on your strongest management options?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: