On developer happiness and where to find it.
"Success is getting what you want, happiness is wanting what you get" - W.P. Kinsella
A trend that started in companies for a few years now has been for managers to concern themselves with developer happiness. Today we will explore this topic and try to find out an answer to the following questions:
- Why the hell would companies care about developer happiness?
- What would actually make a developer happy?
As you read, keep in mind that this is not supposed to be an absolute truth that everyone should obey. I will just share some ideas based on several discussions with people in the industry mixed in with some of my own ideas and, on purpose, I will leave a blurred line between the two.
The ideas expressed will probably be biased towards the western society, since that is where I live. People in different geographical areas with different cultures may have a complete opposite perception on the topic at hand.
If anyone wants to express some insights from different perspectives I encourage you to do so in the comments.
With this small disclaimer in place lets see what we have here.
Why developer happiness?
First question you may have is: why am I talking about developer happiness and not employees happiness in general? Two main reasons are outlined bellow.
First of all, development is my profession right now, so I know most about this specific niche of employee happiness.
Secondly, the thing is that in general companies do not care that much about employee happiness(of course there are exceptions), unless they can directly correlate it with an increase of profits.
The reason why developers are these days in the privileged position of companies starting to care about their work happiness is due to the fact that there is a high demand for their skills in the market and a limited supply that still does not match that demand, although in the future things may change with more and more people going into the computer science curriculum.
This status quo means that developers have a lot more opportunities in moving across companies if they are not happy in their current one, a situation that can quickly turn into a high turnover rate for a company that does not try to have some prevention policies in place.
The costs of a high turnover rate
So why would a company care if it has a high turnover rate, cant they just replace a leaving employee with a new one? Well there some costs associated with this process, both real costs(i.e. direct costs) and opportunity costs(i.e. indirect costs). I list some bellow, but if I miss anything please let me know in the comments.
- Recruiter fees - when using external recruiters their fee is usually between 15 and 30 percent of the new hires first year salary.
- Advertising the open position on different channels like job websites, linkedin or other social media.
- In some cases external training for the new employee.
- Travel expenses if the candidate is brought in from a foreign country for the interview.
- Loss of productivity caused by the team having one less member.
- Loss of productivity caused by team members interviewing candidates.
- Even after a good candidate is found, there will be extra loss of productivity while the new hire gets accustomed to the project, company processes and tools. If the old employee has been working for quite a while in the company, the gap of knowledge he leaves will take a lot more time to fill in.
- A high turnover rate also impacts the morale of the other employees which can result in a further decrease of productivity.
- A place with a high turnover rate may become infamous in the job market as an unhappy workplace and could make it even more difficult to replace someone, driving up both the direct and indirect costs.
What can companies do about it?
Numbers and data
Some companies may still not look seriously at the problem of employee retention since the indirect costs will most probably not appear on the balance sheets that end up on the desk of the upper management at the end of the year, and these hidden costs may far outweigh the direct costs, but are harder to quantify into a concrete number. So the first step to take would be to try to make rough estimates of the total costs of replacing an employee. With a concrete number in hand to raise the alarm, upper management will be more incentivized to take action.
The exit interview
Secondly they should have in place the so called exit interviews: a talk with an employee who decided to leave in which he can be asked about what determined him to take the decision of moving on to a different place.
This activity should be carefully planned since it is easy to gather false data from it. For example some employees may want to leave on a good relationship with the company so will not express all of his complaints or he may leave because they do not like the manager and if the manager is the one handling the exit interview of course that will lead to a situation with no benefits for either party.
The exit interview is useful not only to find causes of dissatisfaction, but to also avoid false positives: it could turn out that a spike in turnover rate over a period may have nothing to do with the happiness of the employees, but it just happened that by coincidence multiple persons had personal reasons for leaving, not workplace related(e.g. moving back to their native country, moving to an office closer to their home to shorten the commute time, starting their own business or moving on to a freelancer career path etc).
Of course another action point would be to have a pulse of all employees feelings about their work status by continuously gathering this kind of data. This can be done either through 1 on 1 meetings between employees and managers, on-line surveys or office gatherings of the teams in which they can express themselves.
What brings developer hapiness?
Lets first get rid of the elephant in the room. Usually when companies come up with initiatives to raise developer happiness, what they mean is doing that without increasing monetary compensation. Some of them do this because they do not have the money, some just because they want to save costs in order to increase profits and others because they do not consider that to be an effective retention strategy.
There are a couple of points to be made here. First is that some people will always seek as much as an increase possible in their compensation and truly not care about anything else. Others, which I think is the majority, once they reach a level that can sustain the lifestyle they desire, will not care as much about an increase in compensation as they care about other factors which I will list later. Of course this satisfactory compensation level can vary greatly from person to person so few assumptions can be made here. Usually people who are in their first couple of years in their careers will not be at the level they desire so they are the most likely to look for significant salary increases.
It is known that the best method to increase your salary significantly is to leave for another company, since internal increases are usually 2 or 3 times smaller than by the ones gained through job switching. This is somewhat a weird situation considering the high cost of replacing someone as I explainer earlier. Taking the previous 2 facts into account we can infer that this is one of the reasons which contributes to higher turnover rate in younger developers rather than in more senior ones.
Of course there are companies who just cant afford to pay as much money as some of the bigger corporations can. Their main option is to compensate the difference in some other ways: startups give a decent part of equity of the company as an incentive, others give a lot more free days, shorter working hours or complete flexibility to the employee in term of his working schedule.
Another aspect worth mentioning is that even if an employee is satisfied with his current level of compensation, if he constantly hears from friends in the industry and on-line sources how much more money is being offered for a similar position as his in another company, then he will start thinking about jumping the boat, so companies should at least be careful to match the average compensation for the sector in whatever geographical area they are based.
One last point regarding this topic is that an increase in salary is like an instant gratification pill of happiness. It feels great, but the feeling wears off quickly. If the increase happens only once a year, the happiness caused by the increase will for sure disappear well before the next one. As a consequence, many advocate for multiple smaller increases spread out throughout the year. This would also coincide with a policy of continuous performance reviews instead of the classical end of year review.
I guess there is more to say about this aspect so let me know in the comments of what you think.
In the end probably most of the other subjects can be tied to this one, but here I am specifically targeting managers as individuals and their behavior.
For a developer there are two aspects to this topic
- his direct manager - the one to whom he directly reports
- upper management - the ones that control the company and its finances.
This relationship is very important since, for a developer, his direct manager is basically the interface between him and the company.
Because of this, when talking about loyalty, the developer will most of the time be loyal to his manager and not to the company. Managers that cannot foster that sense of loyalty towards them will have a higher turnover rate in their teams.
An employee wants to feel appreciated, trusted and cared for by the company and that is his managers responsibility to convey to him. Most of the time that would translate in making time for frequent 1 on 1 meetings, fighting with upper management to satisfy the desires of the team, advising him on the path to career growth and creating a relaxed working environment.
In a lot of cases, what the employee wants will go against the desires of the company and that is why being a good manager is a difficult job, you have to reconcile these two different agendas.
In Daniel Pinks book Drive it is argued that the best thing to do to motivate someone is to create and amplify his intrinsic drive via 3 axis:
- Autonomy - Everyone wants to express himself and have a degree of freedom in his actions. Some examples that would satisfy this need are: official free time for the developer to work on whatever he wants or learn something new that is not directly tied to his day to day job, flexible working hours, contributing to the design of the features and products, not only implementing them.
- Mastery - developers want to get better at what they do and need their managers guidance in order to achieve this growth. One proven way to do this is using Goldilocks assignments: assignments that are not very easy since that would lead to boredom and lack of motivation, but also not too hard since that would lead to high anxiety and probably poor results. On this axis the developer also wants to feel that focus is also put on quality not only on number of features since that would allow him to show off is increasing mastery of the domain.
- Purpose - Everyone needs a purpose for what they are doing. If in a team the only reason why developers come to work is money, then that company will probably not have the most engaged people and will also have to provide salaries higher than average to attract people. The purpose can be a company wide one, but managers can create a purpose specifically for their team which will further motivate and engage the team members. Once this purpose is clearly identified it should be ubiquitous(start every meeting with it, have some poster with it in the team working place) in order to always remind everyone of the importance of their work. The purpose has to be a believable one otherwise it can backfire and everyone will just think its some corporate bs.
No matter how hard the direct manager tries, if the people in control of the company and its finances will see the development offices as a cost center instead of a profit center, then the developers will fully feel the consequences of that attitude: there wont be any budget for trainings, conferences, tools or team events. Most often this attitude is present in industries that do not have technology as their core product that is being sold to customers, with a simple example being the banking industry, although these days things are starting to change.
One of the most cited problems from developers perspective about big companies management is a lack of transparency regarding decisions made and lack of accountability for those decisions. There are numerous cases of tools or technology stacks being chosen for different projects in companies without a clear explanation of why they were chosen, they are just imposed on the developers. And when further down the line those tools and stacks clearly provide a big impedance to productivity, the persons actually responsible for those decisions are either already promoted to another project or nobody dares to touch them. Involving developers in the decisions that will affect their day to day job seems almost like a no-brainer, but few of the bigger companies do that in a transparent and meaningful way.
Benefits are an excellent way to provide extra value to employees in a cheaper and more efficient way than higher pay. For one thing benefits are not taxed the way an increase in salary is taxed so the employee will get a lot more than if the money would be invested towards their compensation. So allocating a budget for an employee to attend conferences, trainings or to cover his commute travel expenses could end up being a win win situation for both the employee and employer. The list of which benefits are taxed and which not varies per country so check it out with your local tax authority.
Another thing is that some benefits scale better than salary increases: having fresh fruits every day in the office or installing a relaxation zone with different games can have the same effect that a small increase in pay to all employees would bring, but at a fraction of the cost.
The list of developer happiness generators
Since this article became longer than I wanted I will leave you with a compiled list of stuff that can improve developer happiness and which I did not discuss in a lot of detail:
- Team events, not only company events - team events are usually more personal and bonding than company events.
- Minimal bureaucracy - No need for 5 committees approval for each small request.
- Communication and interaction with customers - it brings a lot of joy to know your customers and to hear from them how are they using what you built. It also brings motivation to do better for them once you have concrete face behind the abstract concept of users.
- Flexible schedule - no hard enforced scheduled working hours, allow working from home sometimes
- Good tools - The easier it is to use the tools required to do the job the happier and eager will the developer be to start working on a task. If possible the best is to let him use the tools he desires(or the team desires)..
- Office where you can focus when you work. That is why a lot of developers are opposed to open office plans.
- Properly equipped office: 2 monitors(or 1 big one), a nice chair, a good laptop etc.
- Good work life balance - when developers start having families this becomes even more important.
- Management transparency - clear communications on why certain decisions are made. As mentioned if developers could also have their voice heard for aspects that affects their job, it would be even better.
- Clear responsibilities of persons in the company and clear examples that good decisions and behaviors are rewarded while bad ones are punished.
- Investment in human resources