Back in the 19th century, work was extremely straightforward. You enter the factory at an assigned time, then you’d spend the next 18 hours pushing a lever or putting in corkscrews or doing something mindnumbingly boring. And that was about it. If you were born in 1840 and died in 1890, you’d probably think that this was all there was to work, and to life.

In the beginning of the 20th century, after many advancements in the understanding of the psychology of work, things began to change. Psychologically speaking, is it really productive to exhaust your workers to death? And as a job creator, how can I get the best workers to actually *want* to work for me? It was then that employers started to notice a pattern: treating your collaborators well tends to be much, much profitable than exhaust them until they can no longer feel like an individual, but more like a machine, disposable and replaceable. As fellow humans, they are much more than that.

And why the long history class introduction? Because it is pretty important to know history, so it won’t repeat itself.  It seems like many tech companies, under the orientation of poorly-applied HR principles, are misunderstanding what causes a programmer to like or hate their job. Here are some things that I have noticed many tech companies do which, as a programmer, might actually steer me away from them.

A) Faux-benefits

Under risk of burning some employment bridges, I’ll give you a real-world example of this.

There is a certain fintech – which is huge in Brazil and known for its usage of the color purple – who is known for having a ball pool in their office headquarters. Yes, a ball pool – the one you find in kindergartens or children’s birthday parties.

Very well. I am an adult who absolutely loves ball pools and ain’t afraid to say it. But there’s a catch here: I have in really good account that this ball pool is hardly enjoyed by developers. They are normally busy with pushing as much code as they can, even forcing you to work on weekends and late into night – people who are that burned out don’t have the time or the energy to go chill at the (ball) pool. But said fintech gets pretty nice photographs to post in social media and advertises itself as a “modern” workplace.

If you are Brazilian (or South American in general) you probably know which fintech company I am referring to. The lesson to learn here: don’t get lulled into non-sense benefits, as that normally hides very bad working conditions.

B) Viewing people as machines

Workers are not machines that you can crank up speed and extract more productivity from them. Actually, it is the exact opposite. As fellow humans, they are strong allies in helping a company be profitable exactly because they are in the day-to-day of producing whatever it is that your company does; this allows them an insight into how processes can be better managed or optimized, notice points of failure and a lot of super-important stuff that higher management might not be looking at – and that’s not criticism, considering that as a CEO or any high-level management role, you need to have your eyes at a million places at the same time.

C) Low worker retention

Low worker retention can be a symptom of many things. And none of them are good. Bosses – not leaders – usually repeat the following mantra as a justification of this: “no one is irreplaceable”.

Okay then.

Here’s what I have to say on the matter:

No one is irreplaceable, but hiring processes have a steep opportunity cost for everyone involved – and not just the HR team.
No one is irreplaceable, but seeing coworkers quit is usually bad for team morale. And trust me – people will talk about that.
No one is irreplaceable, but training a new team member to replace an experienced one who quit is very, very, very expensive.

The corollary of “no one is irreplaceable” is “everyone is replaceable”. So take in consideration that yes, workers can be eventually replaced, but they are not cogs in a machine where you can simply replace one with another and call it a day. Especially with very small developer teams (like 3-5 people), each individual has something unique they bring to the table, and someone quitting means redistributing that work load across the team. What is usually done by good HR is work on employees weakness and leverage their strengths in favor of the company, and align the organization goals with the collaborator’s own goals – it is not good HR to simply not care.
Note: this is in no way a defense of keeping productive-but-ill-behaved people in your team. I’ll get to that soon.

So, what do I really want?

In no specific order of priority, here are the 3 main things which lead me to decide if I will join or leave a company:

• Flexibility. I believe that the strict 40 hours work week as we know it is on its last breath. But I also understand that certain companies operate on a pay-by-the-hour schedule with their clients, so working hours essentially define the company’s incoming stream of revenue. No problem in that – if the contract tells me I need to work 40 hours a week, then I will honor it. But demanding me to share my desktop screen 8 hours a day is too much. If you don’t trust me, why did you hire me?
• Good working conditions. As a programmer which already has a good amount of experience with WordPress, I expect a pretty good cash payment if there aren’t many benefits (like it is the case with contractor roles), or an average salary but with interesting and real, tangible benefits: healthcare, dental care, a good amount of paid vacation days, etc.
  • That’s on the purely economical side of the equation; a good, psychologically healthy working environment is also absolutely essential and job listings which claim they are “a non-toxic workplace” actually make me worried. That shouldn’t be listed as a benefit – that should be basic human decency. You can negotiate wages and benefits, but you absolutely can not negotiate psychological health.
• Communication. I know that programmers maybe aren’t the most extroverted bunch there is, but we are not cogs in a faceless machine and don’t want to feel like so; we want to know things and know if we can contribute in other ways that aren’t just code. And we also want to know what square we are in the board game; for example, what are the criteria used to evaluate our work quality? And what is the impact in that on our wages, benefits and potential promotions?
  • If a job creator or HR promises a new benefit (e.g you want to introduce health benefits), they should honor that. If due to unforeseen situations this promise turns out to be impossible, they should not let workers in the dark – tell them that plans have changed. If communication isn’t clear it will seem like the company is cheating or making false promises, and this greatly raises the risk of a good collaborator to go look for fresh pastures.

In Conclusion

I like what I do for a living. Seriously. I am (currently) a web developer with aspirations in C++ and game development, which should tell you that I enjoy the programming logic, software engineering and all of its implications. But while passion for your professional occupation is essential for living a decent life (you spend 8 hours a day doing it!), it doesn’t put food in the table. We have family members to feed, bills and taxes to be paid, personal needs and leisure to attend to and so on. I don’t want or need work to feel like a kindergarten, I don’t need any ball pools in the office – what I need is fair compensation, a work environment that is healthy in all possible meanings of that word, and to understand where I am, what I’m doing and what I need to do.

This should be pretty basic for any employment relationship, so it should not be different for programmers, no matter how disruptive the tech sector is.