How to Deal with Underperforming Developers: A Practical Guide to Boosting Team Performance

A high-performing and motivated dedicated team is the key to efficient, cost-effective software development.

Underperformance of engineers can be extremely expensive for a business. According to Gallup’s State of the Global Workplace: 2023 Report, disengaged workers cost the global economy $8.8 trillion annually, or 9% of global GDP.

The problem is that there is no simple fix for making underperforming software engineers do their best. 

Why?

Both an organization as whole and its individual members are responsible for building and nurturing a working environment suited for sustained high performance.

If you see a performance drop, you must identify the reasons for it. Only then can you take corrective action.

Below, we evaluate common causes of underperformance among software developers and discuss how you can make meaningful improvements.

These are clear signs that you are working with underperforming software engineers:

On the other hand, these issues can signal various problems apart from insufficient skills and competencies of software engineers.

For instance, a team taking over an ongoing project may possess the required expertise. They may understand the business goals and do their best to meet them. 

But if the previous team produced non-functional code and a non-scalable architecture, the new team will likely underperform compared to their work on similar past projects. 

In fact, it will be easier for the new team to scrap the code and start anew rather than try to save the client’s initial investment. 

The costs of improving the existing code will be higher than the cost of developing the same functionality from scratch — and even after improving the existing code, the quality will remain low. 

Let’s take a closer look.

Here are common reasons why a software engineering team could show weak performance:

The most obvious reason on the list is also the most dangerous. 

Low-performing software engineers can lack the necessary skills or experience for the task. As a result, they may:

The productivity gap between top and bottom performers is colossal in software development:

More importantly, underperforming software engineers often cannot complete complex tasks successfully. They produce source code to pass tests. But their code will never work in the real world. 

Also, they undermine the team’s morale and performance. Overall performance drops when developers have to deal with low-quality code.

Some people may be brilliant engineers but lack basic social skills and be unable to work in a team. Such engineers may ruthlessly defend their decisions against changes while criticizing other team members’ personalities but not their ideas. 

Such developers can become a communication bottleneck, transmitting incomplete and inconsistent information. 

As a result, the team will start depending on a single developer’s opinion, which can easily lead to loss of control when the decisive developer quits without a replacement.

Performance can drop when a developer is going through a hard period in their life. Personal circumstances can create immense pressure, leading to loss of concentration, stress, and anxiety.  

Also, developers can have personal issues with a project. They can experience burnout because tasks are too complex or too easy. Or, they may be uncomfortable working with an unknown technology or with legacy source code. 

After a promotion, developers may feel impostor syndrome, resulting in loss of confidence and fear of taking ownership of complex tasks.

A senior-only team is an option only for rare, highly complex projects where expertise is critical. In most cases, you want a balanced team of software engineers with different skill and performance levels. 

This way, you can distribute tasks so that senior developers work on architectural decisions, middle developers move the project forward, and junior developers spend time on low-value-added but still important tasks. Everyone completes the tasks that best fit their skill level.

Personal clashes, mismatches between skills and tasks, and insufficient learning and upskilling opportunities can negatively affect the work environment. 

Poor lighting, cold and noisy workspaces, inadequate hardware, and a lack of sufficient software licenses can also decrease productivity. 

Moreover, choosing the wrong metrics can create a bad work environment. Developers may start focusing on meeting KPI targets instead of on delivering solutions for emerging problems, which will lead to project degradation in the long term. 

Making sure expectations are clear and shared between the team and the client as well as inside the team is crucial. To avoid scope creep, all project participants must be aware of project goals, challenges, and possible trade-offs to understand what they must do.

IT Craft teams consult with potential clients whenever project details are not clearly understood. This is the only way we can ensure clients get what they expect.

Often, projects fail because of a lack of transparent communication. Developers need to share goals and challenges, know the progress of team members’ tasks, and get instant updates on project changes.

Also, productivity drops when onboarding processes are ineffective and developers:

Sometimes, when clients do not trust the team and think it is slow, they want to approach the issue directly and boost the team’s productivity by meddling in the estimation process.

A client can bring down an impossible estimate, add more functionality to an existing sprint, or simply not accept the team’s estimate.

As a result, the team starts overworking and compromises quality by cutting corners and accumulating technical debt. Or, developers miss deadlines and receive unjustified criticism from the client. Eventually, such projects will fall apart.

Some factors can be completely out of a team’s control. For example, low-quality source code can completely block project progress, even if the project seems to be 90% done. In this case, software engineers will endlessly work on fixing bugs and flaws instead of launching the project. When they fix one thing, another will break in response. Despite the team’s talent and attitude, the client will not meet the desired deadline.

Developers will not meet all requirements when the scope of work is too large for the available budget (i.e., when the hours they can spend on the project are not enough for its successful completion).

An insufficient budget often leads to making the wrong sacrifices, such as hiring inexperienced developers, saving on test automation and/or quality assurance, neglecting documentation, or postponing technical upgrades. Those sacrifices lead to project degradation, forcing the team to miss delivery dates.

After you have identified the roots of underperformance, it is time to focus on fixing an underperforming development department. 

Here are specific actions you can choose among or combine to target several weak spots at the same time:

Evaluate what exactly holds back underperforming individuals: lack of skills, lack of motivation, or both. To do this, distribute your team members into four categories using a two-by-two matrix:

Source: Better Bosses

By categorizing team members with this matrix, you will see who carries the project, who is ready to improve, and who acts as a blocker. The matrix helps you take actions needed to increase motivation, assist with skills development, and boost individual developers’ performance.

It is possible that an underperforming software engineer does not want to or does not feel a need to improve. If you give a software engineer time yet see no signs of progress, you should manage them out, replacing them with a more flexible and motivated engineer.

Project managers may feel uncomfortable about replacing team members but they should do necessary steps to avoid future problems:

Therefore, it is critical to manage both personnel changes and succession plans. Organize your processes to ensure a smooth role transition and efficient knowledge sharing to remove possible dependency on an engineer who has lost motivation.

Achieving top performance in software development is a balancing act. You need each team member to receive tasks appropriate for their skill level or that are slightly difficult (but not overly difficult) to ensure professional growth. 

To maintain motivation, allow engineers to change roles when their skills start exceeding the requirements for their position or when they become interested in taking on new responsibilities. 

Also, to eliminate burnout, rotate people in and out of roles that involve boring and routine tasks for a significant period of time.

IT staff augmentation can help when the project workload grows but hiring a new team member is impractical because the workload will drop after the release. It can also help when you need someone with specific and narrowly focused expertise on a temporary or part-time basis. 

If you see that the workload is growing quickly, you can hire an expert at a specialized company instead of assigning team members new duties and, thus, lowering their morale. Staff augmentation lets you lower costs and access required expertise quickly and on beneficial terms.

Ensure your team members can discuss any project questions with each other and with you. If programmers have no questions, do not share concerns, or hesitate to contact you when issues emerge, big problems will go unnoticed, eventually affecting everyone’s productivity.  

Also, keep in mind cultural differences when working with an outsourcing team from a low-cost location. When you don’t have any prior experience working with an offshore team, you might consider nearshoring software development. The costs will be higher, but the cultural barriers will be low to nonexistent.

Completing a discovery phase lets you see future issues at a glance and early, such as a misaligned vision, inefficient project planning, a disjointed team, and lack of required expertise.

You can detect a weak development team during project discovery. If the team cannot handle the discovery phase, it is unlikely to complete the project successfully. Problems will only snowball later on.

Measuring developers’ productivity in a meaningful way is possible, albeit difficult. You must measure developers’ performance carefully on three interconnected levels: 

• Individual
• Team
• System

To do this, you need to analyze a number of metrics (DORA, SPACE, opportunity-focused). Discuss together with the team which parameters best connect deliveries to the spent time and effort.

A sprint retrospective is the best time to reflect on what the team can do differently and more efficiently next time. During a retrospective, you can listen to your team members and discuss what changes could prevent future problems. 

This is also the time to discuss the team’s plans for the next sprint: what it should include to bring the most business value and how to maximize the chances of reaching sprint goals. Offer your help with staying on track.

Adorama, an established film and photography equipment seller, operated its online store using a specially designed e-commerce platform.

IT Craft experts developed enterprise web software emphasizing enhancing the client’s team’s capabilities by handling back-end development, quality control, and maintenance.

To make sure that your team works together smoothly and that each team member can hit the ground running, you may need to identify and eliminate complex problems. 

Identify what causes performance drops if you see regular deliveries behind schedule, same issues across several deliveries, or drop of engineers’ morale. 

Then, you will be able to figure out how to deal with underperforming developers. It can be tricky to do this, but the benefits include timely project completion, the ability to efficiently adjust your project to changing business needs, and increased loyalty among team members.