It is not an obvious task to screen for productivity in a recruitment process. Companies often hire developers who have a hard time becoming productive. Even worse, HR best practices in some environments often slow down the promotion and growth of productive developers. As a result, top talent in these companies often finds growth opportunities elsewhere.
If companies took care of their developers in terms of educating them on best practices around productivity, eventually, their teams would perform better. In reality, in most companies, corporate processes, values, and culture often distract their developers from peak performance.
There are three major problems with productivity. Most companies
- hire developers who are not willing to be productive
- have a hard time keeping their most productive developers
- shape their culture and processes so badly that they prevent their developers from becoming productive.
Although these problems sound severe, there is a way out. With just a few simple steps, it is possible to create and maintain a working environment that helps developers reach peak performance.
When do we say that developers are productive?
Productivity is an overused term that is often used in a wrong context. Once you learn what productivity truly means, you will soon realize that productivity is not enough. Once you realize what people mean by productivity, you may realize that you want to widen your definition of being more productive.
The word productive contains product. If you are productive, you are meant to deliver effort that has some results we call products. This is why you are productive. Productivity is measured as the amount of work done over unit time, assuming everything else is constant.
We can agree that productive developers tend to be better than those who lack productivity. I have a surprising confession to make though: I don’t believe in this type of productivity on its own.
For instance, what if you work on a task that makes absolutely no sense? Imagine each product you deliver makes your company lose $10. The more productive you are, the more money your company will lose. Is this concept far from reality? Not at all. What if you were very productive at manually reformatting the code into your own style? If you finished 6 files an hour and your hourly rate was $60, your work would cost your company $10 per file. What benefit would the company gain from your activity? Marginal at best, most likely nothing.
If you keep on being very productive at the useless task of manually formatting files, you would end up doing productive procrastination. You stay in your comfort zone by working hard on something that does not bring value to your company. This is why I don’t believe in productivity alone.
We need a better term.
We often hear that people are efficient. What does this mean? Efficiency is measured as maximizing resource utilization assuming fixed productivity. Efficiency does not address our problems either, because it does not guarantee that we spend resources on meaningful goals.
The correct term to use is effective work. In fact, many people mean effectiveness when talking about productivity. The effectiveness of work maximizes the ability of producing a desired deliverable. Increasing productivity or efficiency on meaningful things increases effectiveness. At the same time, effectiveness includes proper planning, and the willingness to say no to tasks that don’t matter.
In this article, I will use productivity in the context of delivering the most value to the company. In this sense, productivity means that you are productive, efficient, and effective at the same time.
Why do so many developers face productivity issues?
There are various issues why software developers face productivity issues on a regular basis. Some of these issues are:
- Our brain is in conflict with itself,
- Habitual and instinctual interruptions,
- Lack of enough deliberate practice,
- Unconscious defense mechanisms.
Let’s face it. We are all humans. We are not evolved to be productive at work. We are evolved to survive. The rest is our job.
Our brain is in conflict with itself. Similarly to computer networks, the human brain has a layered structure. Each layer acts as a filter, and each layer may influence our behavior.
Information enters our brain in the reptilian complex. We will refer to it as the crocodile brain. This is the most primitive part of our brain, mainly dealing with fight-flee-freeze responses. When someone taps you on your shoulder and you experience fear running through your spine, your crocodile brain sends this signal.
Social skills help our survival. Our social skills are in the second layer of our brain: the limbic system. This is where our emotional awareness lies, this is where we feel empathy, and this is the part of us that monitors social situations.
The third layer provides us with conscious thinking, reasoning capabilities. This part of us can think and plan the future. This part is called the neocortex. Sometimes our conscious brain has no control over what the croc brain and the limbic system wants. Therefore, we end up doing things that logically don’t make sense from the perspective of our productivity.
Habitual and instinctual interruptions. Our neocortex is surprisingly intelligent, but it also consumes a lot of resources. Therefore, we only use the conscious brain when necessary. Most of the information that enters our brain is filtered out by lower layers. This means, many productivity issues are unconscious.
When the croc brain gets bored, it seeks for some novelty, either in the form of some food that increases our chances of survival at tough times, or in the form of social connections. The easiest way to get social connections at work is social media. If we check our social media account, our croc bain feels good. Our limbic system registers that we are connected to other people. After a while, regular emotional spikes form habits.
Every time we submit to the unconscious desires of our crocodile brain, we interrupt our work. Interruptions prevent us from reaching a state when we are deeply immersed in our work to the extent that we stop sensing how time passes. This state is called flow. Check out point 5 titled Learning is Fun in my article on effective learning to learn more about flow experiences.
Lack of enough deliberate practice. While working in flow, our brain helps us master our craft a lot faster. Cal Newport calls this process deep work. Following Malcolm Gladwell, Cal Newport states an estimation of 10.000 hours of deliberate practice as the price of true expertise in a field.
Flow experience, deep work, and deliberate practice help us get better. When our croc brain interrupts us, we get stuck without improving. This is why some developers function as net undoers in some environments, even after collecting ten years of verifiable experience.
Unconscious defense mechanisms. I have seen an excellent developer who almost got fired, because his croc brain continuously defended against information he perceived as attack. When he failed to answer a question, his croc brain froze his system. His self-esteem suffered. He thought he was dumb. In reality, he was a net undoer, because his crock brain kept fighting against non-existing threats, and his limbic system was concerned more on his own social status than the quality of his work.
Have you ever felt that you need to defend yourself at work? Have you ever pretended in a meeting that you understood everything, while another person kept throwing TLAs at you?
If you didn’t ask what a TLA is, the answer to the second question is an obvious yes. I just made TLA up, it stands for Three Letter Abbreviation.
Defending ourselves is not a conscious act. As long as we defend ourselves, our employer makes a loss on employing us.
Considering these the inefficiencies of the human brain, a logical question to ask is, how do some developers become productive? The Pareto-answer, i.e. the 80% that really matters, is
- Emotional intelligence,
- Productivity habits.
Emotional intelligence is based on taking responsibility for our own feelings and actions. It comes with self-awareness or consciousness. By developing our emotional intelligence, we become less dependent on external sources of motivation, and we do our job, whether we feel like it or not. The side-effect of doing our job is that we tend to feel better during the process. Emotional intelligence makes our croc brain and our social brain our ally instead of an obstacle.
The second solution is better productivity habits. We will omit productivity tips in this article. If you want productivity tips for yourself, check out the article Ten Productivity Tips for Software Developers on my tech blog. These are quick wins that help developers become more productive on an individual level.
The rest of this article will discuss some improvements that help companies manage talent, educate developers on being more productive, and create an inspiring environment that supports high productivity.
Common sense dictates that it is easier to hire productive developers than breaking tens of years of unproductive habits. If you add A-players to your team, your colleagues will also be more productive because of the absence of emotional toxicity in your environment. This statement is based on the peer group effect. Studies show that the risk of you becoming more productive increases in a productive peer group than in an unproductive peer group.
Screening for productivity is tricky, because direct methods don’t make sense. We are looking for character traits that result in productivity.
One example is emotional resilience. HR can easily filter out people who get carried away by their emotions to the point that they deny cooperation with the interviewer. Any major soft-skill red flags indicate that the company will later have productivity issues with the candidate.
Back in the days, we recruited frontend developers. A seemingly knowledgeable engineer passed the HR screening round. In the second round, we gave him a task. Instead of focusing the solution, he first focused on why he does not like such tasks. After ten minutes, he started focusing on the solution. He was on the right track when he started talking about a nit-picky detail that had nothing to do with improving the quality of the solution. He was the first developer we had to reject even though he completed the task. We felt it was impossible to cooperate with him, because he refused following clear orders and continued with his explanation multiple times.
I can recall two developers who received an extra interview because they were insecure about whether they wanted to accept our offer or not. They appeared very high maintenance. After receiving a great offer, including some extra flexibility on our end to support their lifestyle, they went on
In my first years, I also got rejected from an interview due to productivity issues. An excellent hiring manager assembled a task that could only be completed if you exactly knew what you were doing. I had to download the task from a server and had 45 minutes to complete it. I could complete around half of the task, because it took me too much time to set everything up instead of generating code with a boilerplate generator or using my own boilerplate. Tasks with a time limit filter out people who cannot get in the zone. The side-effect of this filter is that you also filter out anxious developers who experience stage fright, therefore, use this filter cautiously.
During a live coding challenge, screen for clarity of thought, debugging skills, and also generic coding skills. If a candidate writes a for loop without knowing what will happen afterwards, you are interviewing someone who executes some unclear thoughts and just pretends that he knows what he is doing.
If a candidate becomes overly defensive, chances are, you can screen someone out who would choose superficial work over getting things done the right way. The research paper The Impact on defensive barriers on organizational performance and learning highlights that there is a correlation between defensive behavior at the workplace and lower company performance. In more detail, the paper Defensive Behavior in Organizations presents that defensive people tend to be more insecure, anxious, exhausted, self-conscious, they bluff more, they misrepresent their performance, and above all, they are less productive than people who have an easier time developing mutual trust with their team.
According to my experience, these are the types of developers who make sure they take the lead in closing the most GitHub issues, and therefore, they always choose the easiest issues available, at an expense of their colleagues.
Let’s summarize what you can do to screen for productivity:
- Screen for emotional resilience. A resilient developer is less affected by outside-the-comfort-zone experiences
- Screen for defense mechanisms versus integrity
- Screen for clarity of thought and debugging skills.
- Give developers sensible time constraints that seem too tight if they don’t know what they are doing, but seem more than enough if they know how to do their job.
The Cost of Maintaining a Positive Peer Group Effect
We identified some undesirable behavioral patterns in the first section.
The argument in this article stated that the described productivity issues are contagious, meaning that maintaining the work of some developers takes more effort than doing the work yourself.
To understand this section, let’s continue with a definition. A 10x or x10 developer is someone who is ten times as productive as the average. This definition is vague, because the definition of productive is subjective.
The article There are no x10 developers, but there are certainly 1/10 ones re-enforces this idea and warns companies about the consequence of employing someone for 3 weeks. This person got less than 1 hour of work done, while other team members must have sacrificed days of work on him.
After an unsuccessful attempt of employing someone, you need to rehire them. According to this study, productivity loss can move up to $30.000 over the average hiring time of 43 days. In-house recruitment costs more than $10.000. An agency may request $20.000 bounty on a hired developer. This is a lot of money for a bad decision. Observe the magnitude, not the exact numbers.
Keeping an unproductive developer is even worse. In countries like Germany, after 2 years, companies are obliged to offer permanent contracts. This implies that the only legal way to fire a developer who does not care about their work is to make the position redundant. Even then, the developer may argue with this decision and take your company to court. Even without a court case, no-one may be hired in similar positions in the near future.
Be aware that exceptions apply in the form of temporary emergency situations in the life of developers. If the cause is outside the scope of the office and seems temporary, the common sense solution is to wait until the issues of the developer are resolved.
After concluding that net undoers should be encouraged to cooperate or leave, let’s examine the effect of a 10x developer on team spirit and productivity.
This effect comes down to the definition and context of the 10x developer. Recall the difference between productivity, efficiency, and effective work. If we use the term 10x developer on describing effective work, any 10x developer in the team makes the whole team more effective.
If we merely target productivity on a short-sighted KPI (key performance indicator), chances are that a 10x developer will hurt the team by creating technological debt and writing solutions that others don’t understand. Alignment on business goals and deliverables is the name of the game. Once alignment is established, the best developers raise the standards of the whole team through peer group effect. These developers are worth keeping even if it means paying them a top 10% or even top 1% salary according to PayScale.com data. By doing the math, 10x effectiveness and a positive effect on others is worth twice or three times the average salary.
As more companies start realizing the positive effect of 10x effectiveness, it is also worth learning soft-skills from the perspective of software developers. In his book What Got You Here, Won’t Get You There, the author Marshall Goldsmith argues that beyond a certain level, everyone is competent enough. At the top, the utility of an employee is determined by the soft-skills the employee uses at work. If you want to learn more about soft-skills check out my book, The Developer’s Edge.
Supporting Effective Work
The best companies have established processes to support effective work.
Recalling the introduction on the human brain, the most productive hours are spent in deep work. One technique to encourage deep work is the Pomodoro technique. By using this technique, you have time to focus, and time to rest. The default is 25 minutes of focused worktime, and 5 minutes of pause. By doing just 8 pomodori a day, you get more tasks accomplished in better quality than the average software developer in a day.
Companies that protect their developers from interruptions to keep them in the zone encourage effective work. If an interruption happens, a developer in deep work can decide whether the cause is an emergency situation, and only handles emergencies. For educational purposes, the default answer for a non-emergency interruption is “I will get back to you in about an hour”. Although the benefits of flow state are gone, the message is still delivered: deep work should be respected.
Breaks in the pomodoro technique are there for a reason. Encouraging regular breaks is the interest of everyone. In the best companies, breaks are taken to the next level. At Google, people meditate on a daily basis. Meditation is pure training on flow. It declutters the mind. Mindfulness meditation takes you back to the present. Twenty minutes of meditation a day has obvious benefits.
Companies encouraging developers to openly give and receive feedback address another productivity waster. Defensive behavior not only creates technological debt, but also prevents developers from experiencing flow. Breaking down defense mechanisms with an open culture encouraging learning from mistakes is a great company value.
The 40 hour work week is an old construct, yet, some companies abuse working hours assuming that developers are in the zone during 60 or 80 hour work weeks. For the duration of a week every year, this strategy could work. Yet, in the long run, developers will accomplish less than their peers who work 40 hours per week. Exploitation of resources is a lose-lose situation both for the company and for the employees in the short run. Even if overtime is unpaid, it often results in a net loss.
There is one more problem preventing deep work: loud environment. I can recall a discussion back in the days when a nordic person worked with his mediterranean colleague. Nordic standards were calm, quiet. Mediterranean standards were loud. Sometimes a heated debate on technology seems like as if two people started physically threatening each other. Just imagine. An average nordic reptilian complex senses danger. The limbic system of my nordic colleague coudln’t find a reasonable social context to calm his reptilian complex down.
A short but interesting conversation emerged out of the situation. My colleague went to the debating engineers, and said: “Please stop shouting!”.
The reply was phenomenal. One of the engineers shouted, “WE ARE NOT SHOUTING!”.
The end result was an all hands meeting, where all parties solved noise issues. Heated debates were moved to a meeting room.
Beyond noise, overusing the neocortex to figure out what to do next is also unhealthy in terms of productivity. The neocortex is our conscious brain, and it is very resource intensive. The reward for depleting our resources is called depleting our willpower. Willpower is a finite resource. Decision fatigue makes people feel uncomfortable, and the compensation for this feeling is often a visit to social media land to create an illusion of connection, comfort, variety, and sometimes significance in case of people with a form of narcissistic personality disorder.
A company can combat decision fatigue with a clear and well executed goal setting process, scrum, kanban, or other ways of organized cooperation.
For a role model on orchestrating effective work, I can highly recommend watching this video on the Spotify engineering culture.
Training Coworkers Pays Off
A meme emerged on LinkedIn a few years ago advertising this blogpost. What if we train our employees and they leave? What if we don’t… and they stay?
You might already know from this article where to start. Some ideas are:
- Batching communication, muting non-emergency communication channels
- Encouraging deep work, for instance, by allowing people to do their pomodori
- Train everyone to give and receive feedback
- Train everyone to contribute to goal setting
- Transparent communication on what matters to a company
- Train meaningful habits
If I could choose one book on productivity, it would be Eat That Frog by Brian Tracy.
Anything else that works for you is worth trying out.
Lack of productivity costs companies a lot both on individual level, team level, and on the level of recruitment costs. It is the interest of each individual to assemble a peer group of self-aware developers who cooperate in raising standards.
Productivity issues are often uncounscious. Self-awareness helps developers realize these unconscious problems.
Self-awareness leads to other-awareness, that can be used to hire and keep A-players, and help C-players become at least B-players. Not everyone has to change the world, but everyone has to contribute. If someone is not willing to help his or her company succeed, it is inevitable to let this person go for the interest of everyone.
The best developers make everyone else more effective. This is why they are called 10x developers.
An encouraging environment can help everyone become more effective and more productive. Eliminating distractions and putting good processes in place helps everyone bring their company forward and experience a fulfilling career.