Individual Productivity in Software Development

This is the second blog post in the "Productivity in Software Development" series. To start from the beginning click here .

 In this part we are going to talk about productivity of an individual team member (developer, tester, product manager, …).

 Productivity is Not Linear

 In the physical word the productivity is linear. If you double a number of workers who are digging a trench you can count on finishing it twice faster.

Not so in software. Knowledge-based industries are governed by the Complexity Theory and linear assumptions are not very useful. Unfortunately, most commonly adopted management practices were developed for industries with linear productivity - manufacturing and construction. This sometimes leads to misconceptions when managers without engineering background are put in charge of software development teams.

Productivity between software developers vary greatly based on experience, talent, and domain knowledge. Developers with similar resumes can easily have a tenfold difference in their productivity.

It is not even uncommon to have a team member, whose productivity is negative, as his colleagues waste time on rewriting his code and fixing introduced bugs.

Productivity and Compensation

Which leads to an interesting topic of the correlation between developer's compensation and productivity. While more talented developers are paid more, the difference is usually in the range of 20 to 30%. Their productivity, however, can be 200-500% higher. Do the math!

What's more, great developers are not only very productive themselves, they also have a great impact on the productivity of other people who work with them. That leads to another productivity multiplier.

 To achieve the maximum productivity the goal of any company is to have the best engineers possible in all positions from junior to senior. So, should you hire a junior, intermediate, or a senior engineer? You need a healthy mix when it comes to seniority. The most important rule is - hire smart ones!

Antipatterns

1. Capping salary increase

This is a common problem in large and less flexible organizations. Market rates for software engineers are growing faster than salary increase caps set by HR policies leaving managers without tools to provide a fair compensation to their best and most productive people. This is also a contributing factor to two other antipatterns below.

2. Hiring junior developers on a low salary and not adjusting compensation as they get more skilled

It is quite common to hire new grads or interns and offer them a starting salary. There is nothing wrong with this approach as they have little experience at that point. Many managers, however, miss the point when a new developer has quickly gained skills and started to show her real potential. The gap between person's capabilities and the compensation could grow very fast. Miss the moment, and a potential star on your development team puts out a resume and leaves to a position that can easily pay 40-50% more.

3. Paying more to new hires than to long term employees

I observed this problem in many organizations and it makes no sense from the productivity perspective. Existing employees are extremely valuable to the organization as they have all domain knowledge and experience in their heads. If they are not compensated fairly, eventually, they will leave. The company is loosing in multiple ways in such case. A replacement will take time to find, he is likely to be more expensive, and it will take him several months to fully learn a new system and reach the level of productivity of the person he has replaced.

Familiarity with Technology, Application, and Domain

Developer's productivity greatly depends on how experienced she is in the technology stack used. Even a senior developer may struggle to adapt to a new programming language, development environment, cloud platform, etc.

A backend developer can be very productive while coding a microservice in Java and struggling for several days to find a small bug in React JS frontend application.

A developer, who worked in a company for a while and knows the application from top to bottom, will be much more productive then a new hire who could take several months before reaching the same level of efficiency. It would be even more challenging for a developer who does not have experience in company's business domain.

This needs to be taken into account when planning, scheduling, and estimating development work. A "simple-thing-to-do" is a very relative notion indeed.

 Antipatterns

• Not adjusting estimations when changes in a technology stack are introduced
• Assuming that new team members will be as productive as long-timers
• Assigning work to developers without proper experience in required technologies
• Not cross-training developers on different parts of application to spread the knowledge and reduce the "bus" factor

 Productivity & Long Hours

Everybody in the software industry has experienced working long hours or skipping vacations to get things done. Sometimes, longer hours are pushed by management. In other cases, developers put in extra hours without external pressure simply because they are really engaged and enjoy what they are doing. Dedicated people, who are ready to work long hours, produce more.

But this stays true up to the point. Overtime can lead to a higher productivity when used for a short time. Making it a norm has the opposite effect. People get burned, bad decisions are made, more errors are introduced.

 Antipatterns

• Company enforces overtime for a long period of time
• People never take vacations

 Productivity and Employee Engagement & Happiness

The best developers don't work just for money. It is important for them to have a purpose, to be challenged, to do something cool and exciting, to see their product contributing to a larger cause. When creative people are given freedom to pursue their passion, to contribute and implement their ideas, and feel appreciated for their skills and efforts, their productivity soars.

 Antipatterns

• Ignoring engineers' opinions and having "just-do-what-you-are-told" approach
• Blame culture
• Not showing appreciation
• Limiting learning and training opportunities

 In the next two posts I will discuss what affects productivity on team & organization levels.