Overtime and Capacity
Something is screwed up when there is constant overtime and you have to work on weekends to catch up. It is never normal working practice. Spikes do happen in any industry such as end of financial year, the release date of a software project or unforeseen emergencies. Not being in constant overtime, allows us this spare capacity to deal with them. If you're constantly working overtime, it means there is no capacity left to deal with spikes.
What happens then?
People start to get sick. Mistakes start to creep in due to lack of sleep or fatigue and procedures are worked around ending up in an organizational mess.
Capacity and efficiency issues such as this require a bit more thought and planning, as it's a difficult problem to find solutions for.
An opinion was given to me, that for an IT related project, where you don't have capacity, the solution was simple, just hire a bunch of contractors. Sounds simple? This is a packer statement. It assumes that in an IT project, you can just slot in blocks and stuff will be churned out. When one of these contractors quit, you simply replace them and new hires will continue churning out stuff. Doesn't work that way, as it assumes that individual capacity such as subject matter knowledge is the same, and application for this knowledge is the same.
So a 3 year experienced person = 3 year experienced person, but both are worth more than a fresh grad. Never works that way in my experience. This same line of thinking also gives small value to the training that a fresh grad or intern gets. Oh, the value of a trainee lost is not that much, since their pay scale is still that of a fresh grad or trainee.
I hope this kind of thinking continues to be pervasive throughout the IT industry, as then I know that Inigo will continue to have a competitive advantage.
It's also why I've been slow to take up new interns or hires. I believe that adding 1 doesn't mean capacity goes up by one. In fact the team should jell so that:
capacity = y^x.
Where y is the number of employees, and x is the jell factor and ability of the team to automate and innovate by working together. Capacity is roughly equal to the output of one IT staff at a local IT company. Currently Inigo is I believe where x=2.5 and I'd like to keep it this way. In a small team, adding the wrong person can cause a reduction in this x factor, which can be painful.

totally!
You've touched on the point that education != capable. Where this is quite a common thinking when you have a degree, you are capable, but chances are, you aren't.
Moreover, the jell factor is a very important factor for any organisation/company. How that individual fits into the company can determine its success. Problem is, most HR departments don't realise this factor and only look at your so-called 'achievements'.