I'm lazy today, so I just grabbed this article which describes office space in the bay area for startups [0]. Their talking all the way up to about $70 per square foot. Peopleware says 100 sq ft per person, so that's up to about $700 per month per employee (or $8400).
I honestly don't think that's crazy money, but you also have to plan for growth. This makes things a lot harder. If you think you are going to grow from 4 developers to 20 in the next couple of years, then you need to make sure you have access to space. Moving offices is usually traumatic, so it's a cost you need to balance.
TBH, I've only ever experienced that much space once in my career. Normally I've had about 60 sq ft and I've had much less in some jobs. My experience is that the extra space is definitely worth it. There shouldn't even be a question about it.
I think the problem is more that it is hard for the people-with-purchasing-power to understand that productivity in knowledge workers can very dramatically. Spending $10K per year on working conditions can easily save you $100K in salary (given current SV salaries) -- you can go with a lower head count and achieve the same amount of work.
But it's not just that. I'm a big proponent of small head count. The communication overhead for large teams can be crippling. When you look at trying to increase production by improving code quality -- it's practically impossible with large teams. If you never speak to half your team mates, there is no way to reach consensus on design approaches. There are ways to mitigate these kinds of problems, but I have to stress that I have never seen successful mitigation strategies in non-open source projects. In fact I've never even seen them attempted because the overwhelming bias is that more programmers == more productivity (amongst people-with-purchasing-power).
But even as I type this, I can see how it is scary to spend money on working conditions. Let's say you are bleeding cash (like most startups), or you are eeking out low single digit percent profit (like most establish companies). You've got some cash to invest and so you think, "We need to raise revenue. To do that, we need the product to have more capability". It's a pretty gigantic leap of faith to conclude "Instead of growing the dev staff by 10%, I'm going to spend that money on improving working conditions". And even if you do, you have to repress the very next thought, "Hmmm... dev staff comprises 10% of my workforce. WTF am I going to do when the sales people demand the same working conditions? If I refuse, all the best ones are likely to quit in a huff".
> Their [sic] talking all the way up to about $70 per square foot. Peopleware says 100 sq ft per person, so that's up to about $700 per month per employee (or $8400).
I honestly don't think that's crazy money, but you also have to plan for growth. This makes things a lot harder. If you think you are going to grow from 4 developers to 20 in the next couple of years, then you need to make sure you have access to space. Moving offices is usually traumatic, so it's a cost you need to balance.
TBH, I've only ever experienced that much space once in my career. Normally I've had about 60 sq ft and I've had much less in some jobs. My experience is that the extra space is definitely worth it. There shouldn't even be a question about it.
I think the problem is more that it is hard for the people-with-purchasing-power to understand that productivity in knowledge workers can very dramatically. Spending $10K per year on working conditions can easily save you $100K in salary (given current SV salaries) -- you can go with a lower head count and achieve the same amount of work.
But it's not just that. I'm a big proponent of small head count. The communication overhead for large teams can be crippling. When you look at trying to increase production by improving code quality -- it's practically impossible with large teams. If you never speak to half your team mates, there is no way to reach consensus on design approaches. There are ways to mitigate these kinds of problems, but I have to stress that I have never seen successful mitigation strategies in non-open source projects. In fact I've never even seen them attempted because the overwhelming bias is that more programmers == more productivity (amongst people-with-purchasing-power).
But even as I type this, I can see how it is scary to spend money on working conditions. Let's say you are bleeding cash (like most startups), or you are eeking out low single digit percent profit (like most establish companies). You've got some cash to invest and so you think, "We need to raise revenue. To do that, we need the product to have more capability". It's a pretty gigantic leap of faith to conclude "Instead of growing the dev staff by 10%, I'm going to spend that money on improving working conditions". And even if you do, you have to repress the very next thought, "Hmmm... dev staff comprises 10% of my workforce. WTF am I going to do when the sales people demand the same working conditions? If I refuse, all the best ones are likely to quit in a huff".
[0] - https://medium.com/initialized-capital/the-outlook-for-bay-a...