Why lowered salaries and processing employees are ineffective for startups
In this article, an American programmer with twenty years of experience explains why a low salary and a seventy-hour work week are disastrous for any startup.
Did you have a thought like: “I need a job in which I will be paid much, much less than my work costs?” So I never thought so. Nevertheless, there are companies that not only pay less, but also take pride in this fact. Let me explain what I'm talking about.
Recently, I saw a job just from one of these startups. In such cases, I usually annoyedly roll my eyes and move on further, but the text of this ad amazed me so much with its content that if I reacted as usual, my eyes would now look at my head.
Therefore, in order to spare my visual organs, and - more importantly - wanting to help you avoid the potential suffering associated with working for such companies, I decided to share with you the key offer of the ad:
In this post I will reveal the meaning of this paragraph and talk about the possible consequences of the approach described in it. I deliberately refrained from pouring myself some kind of drink while working on the post, since each repeated reading would lead to the fact that the contents of each sip would be on the table and keyboard - so much I was outraged. Speaking shortly, joining a similar company, you will work for people:
Let's start with wages. A standard US work week consists of 40 business hours. Working 70 hours a week, you will spend 75% more time at work than usual. In other words, the company offers to evaluate your working time at 40% less than its market value.
Instead of hiring more engineers, they are trying to make the available specialists work much more for the same money. This is nothing but exploitation and you should have no reason to put up with this order of things.
It's not so difficult to find companies offering you the usual 40-hour work week. All of my last five jobs, from tiny start-ups to a position on Google, were just that. Yes, sometimes you have to put something off until later. Nevertheless, such a schedule is quite real. But even if you are unable to find such a job, there are many other companies offering options with 45 or 50 hour work weeks. And even such an excessive number as 60 hours, which also occurs in practice, will still be better than 70.
There is another point. It is quite possible that you love programming so much that you might think: “I’ll still be coding 70 hours a week. So why not do it at work? ” As I will explain further, I do not think that increasing the number of working hours by another 30 per week can give any tangible benefits, but even if I'm wrong, you still should not spend them on your employer.
Let's imagine that you code 70 hours a week. You could use all this time with your employer, without receiving any wage increase, or you could devote 40 hours to regular work, and in the remaining 30:
And besides, in this case, you will have some relatively free time, which is useful to you in those moments when life gets in the way and you have to devote it to classes that are different from programming.
Yes, the promotion of the 70-hour working weeks is an unheard of exploitation. Sadly, in addition, this approach often demonstrates the folly of practicing its leaders. This problem is summarized in the following statement of the vacancy: "We are working not just rationally, but also hard."
If your starting point is exploitation, and you focus on extracting as much work from your subordinates as possible, then the meaning of doing this or that work eludes you. The point is that the work done as such does not have its own value. What really matters is her results. That is, the solved tasks or the value created with its help - and there are those indicators that need to actually be maximized.
In a more detailed study, it turns out that many studies carried out over the past few decades show that exceeding the weekly rate of 40 working hours leads to a decrease in labor productivity. It is likely that the leaders of this startup do not believe in it or are not trying to put this knowledge into practice. And you, perhaps, also do not believe in such statements. But even if we assume that the 70-hour work week leads to a 75% improvement in the quality and quantity of results compared to 40 hours, then this idea as such is still bad for most companies.
When an organization tries to maximize the amount of resources, not the quality of the final result, the result is one continuous series of erroneous decisions. So, for example, hiring a junior programmer working 70 hours a week for this job will lead to much less valuable results than hiring an experienced programmer working 40 hours each. But a company that wants to achieve maximum exploitation and maximize the amount of work will publish such a vacancy, looking at which an experienced specialist will definitely not want to come for an interview.
In addition to reduced productivity and a stupid recruitment policy, encouraging overtime also indicates a likely lack of project management skills. Overtime in this case is both a cause and a symptom of this particular deficiency.
The seventy-hour weekly schedule can be broken down for 7 days from 9 to 19 hours. Such a schedule does not imply that the employee will have quite a bit of free time for both his personal life and the project. Sooner or later an emergency situation arises in every project. If the production server crashes, then someone will have to return it one way or another. The real need for overtime work may appear in the context of more everyday situations: the client may ask to add more features, or the seemingly simple task may actually turn out to be much more complicated than you initially thought.
Advance planning can help to cope with such situations. Attempting to paint everything by the minute does not help, nor does trying to make everyone work at the limit of their capabilities. After all, in the end, your problem is unplanned work. What will really be useful in this situation is planning for relatively free and unplanned time, available for any inevitable and unexpected problems.
But the manager, who expects 70 hours of work per week from you, is not among those who plan time for unexpected work in advance. No, such a manager solves problems, simply telling you to work harder and more. And when that most unexpected problem or emergency situation appears, such a manager throws up his hands and says: “Well, who could have known that this would happen? ¯ \ _ (ツ) _ / ¯. And so suddenly your 70-hour work week turns into an 80-hour one.
Maybe you can fix it even with this approach, but I doubt it. It is more likely that eventually you will burn out and leave such work, taking with you all the knowledge and experience gained during the work.
The vacancy, which led to the birth of this post, also stated that “a stable readiness to help junior engineers” is not necessarily a requirement, but it will be very useful. In this regard, I have one piece of advice for all junior engineers: avoid companies that want you to be at such an unrealistic amount of time at work, because:
But if it so happens that you have already found yourself in such a company, then it will probably be useful for you to read my book, The Programmer's Guide to a Sane Workweek .
Did you have a thought like: “I need a job in which I will be paid much, much less than my work costs?” So I never thought so. Nevertheless, there are companies that not only pay less, but also take pride in this fact. Let me explain what I'm talking about.
Recently, I saw a job just from one of these startups. In such cases, I usually annoyedly roll my eyes and move on further, but the text of this ad amazed me so much with its content that if I reacted as usual, my eyes would now look at my head.
Therefore, in order to spare my visual organs, and - more importantly - wanting to help you avoid the potential suffering associated with working for such companies, I decided to share with you the key offer of the ad:
“We have quite ordinary situations when some team members stay late in the office. For many of us, it is in order to devote more than 70 hours a week to work and vocational training. ”
In this post I will reveal the meaning of this paragraph and talk about the possible consequences of the approach described in it. I deliberately refrained from pouring myself some kind of drink while working on the post, since each repeated reading would lead to the fact that the contents of each sip would be on the table and keyboard - so much I was outraged. Speaking shortly, joining a similar company, you will work for people:
- Exploiting you by tremendously undervaluing the value of your labor.
- Destroying your productivity.
- Possessing disgusting project management skills.
Cutting wages by 40%
Let's start with wages. A standard US work week consists of 40 business hours. Working 70 hours a week, you will spend 75% more time at work than usual. In other words, the company offers to evaluate your working time at 40% less than its market value.
Instead of hiring more engineers, they are trying to make the available specialists work much more for the same money. This is nothing but exploitation and you should have no reason to put up with this order of things.
It's not so difficult to find companies offering you the usual 40-hour work week. All of my last five jobs, from tiny start-ups to a position on Google, were just that. Yes, sometimes you have to put something off until later. Nevertheless, such a schedule is quite real. But even if you are unable to find such a job, there are many other companies offering options with 45 or 50 hour work weeks. And even such an excessive number as 60 hours, which also occurs in practice, will still be better than 70.
When programming is a hobby
There is another point. It is quite possible that you love programming so much that you might think: “I’ll still be coding 70 hours a week. So why not do it at work? ” As I will explain further, I do not think that increasing the number of working hours by another 30 per week can give any tangible benefits, but even if I'm wrong, you still should not spend them on your employer.
Let's imagine that you code 70 hours a week. You could use all this time with your employer, without receiving any wage increase, or you could devote 40 hours to regular work, and in the remaining 30:
- Work on a personal project just for your own pleasure. So you can acquire new skills - those that will be interesting for you. You can work on a useless from a practical point of view thing of your own fun for the sake of.
- Work on an open source project, thus helping other people.
- Take up consulting activities, getting an additional source of income.
- Create your own startup, which, if successful, will allow you to get substantially greater benefits.
And besides, in this case, you will have some relatively free time, which is useful to you in those moments when life gets in the way and you have to devote it to classes that are different from programming.
“We work not just rationally, but also diligently”
Yes, the promotion of the 70-hour working weeks is an unheard of exploitation. Sadly, in addition, this approach often demonstrates the folly of practicing its leaders. This problem is summarized in the following statement of the vacancy: "We are working not just rationally, but also hard."
If your starting point is exploitation, and you focus on extracting as much work from your subordinates as possible, then the meaning of doing this or that work eludes you. The point is that the work done as such does not have its own value. What really matters is her results. That is, the solved tasks or the value created with its help - and there are those indicators that need to actually be maximized.
In a more detailed study, it turns out that many studies carried out over the past few decades show that exceeding the weekly rate of 40 working hours leads to a decrease in labor productivity. It is likely that the leaders of this startup do not believe in it or are not trying to put this knowledge into practice. And you, perhaps, also do not believe in such statements. But even if we assume that the 70-hour work week leads to a 75% improvement in the quality and quantity of results compared to 40 hours, then this idea as such is still bad for most companies.
When an organization tries to maximize the amount of resources, not the quality of the final result, the result is one continuous series of erroneous decisions. So, for example, hiring a junior programmer working 70 hours a week for this job will lead to much less valuable results than hiring an experienced programmer working 40 hours each. But a company that wants to achieve maximum exploitation and maximize the amount of work will publish such a vacancy, looking at which an experienced specialist will definitely not want to come for an interview.
Emergency unforeseen situations in which an increase in the number of working hours is necessary
In addition to reduced productivity and a stupid recruitment policy, encouraging overtime also indicates a likely lack of project management skills. Overtime in this case is both a cause and a symptom of this particular deficiency.
The seventy-hour weekly schedule can be broken down for 7 days from 9 to 19 hours. Such a schedule does not imply that the employee will have quite a bit of free time for both his personal life and the project. Sooner or later an emergency situation arises in every project. If the production server crashes, then someone will have to return it one way or another. The real need for overtime work may appear in the context of more everyday situations: the client may ask to add more features, or the seemingly simple task may actually turn out to be much more complicated than you initially thought.
Advance planning can help to cope with such situations. Attempting to paint everything by the minute does not help, nor does trying to make everyone work at the limit of their capabilities. After all, in the end, your problem is unplanned work. What will really be useful in this situation is planning for relatively free and unplanned time, available for any inevitable and unexpected problems.
But the manager, who expects 70 hours of work per week from you, is not among those who plan time for unexpected work in advance. No, such a manager solves problems, simply telling you to work harder and more. And when that most unexpected problem or emergency situation appears, such a manager throws up his hands and says: “Well, who could have known that this would happen? ¯ \ _ (ツ) _ / ¯. And so suddenly your 70-hour work week turns into an 80-hour one.
Maybe you can fix it even with this approach, but I doubt it. It is more likely that eventually you will burn out and leave such work, taking with you all the knowledge and experience gained during the work.
“Stable willingness to help junior engineers”
The vacancy, which led to the birth of this post, also stated that “a stable readiness to help junior engineers” is not necessarily a requirement, but it will be very useful. In this regard, I have one piece of advice for all junior engineers: avoid companies that want you to be at such an unrealistic amount of time at work, because:
- This is bad for you.
- This is bad for your company.
- And you hardly want to work with a manager, whose level of competence does not allow to understand what is bad for a company.
But if it so happens that you have already found yourself in such a company, then it will probably be useful for you to read my book, The Programmer's Guide to a Sane Workweek .
All Articles