Sometimes a developer is simply not a good fit for a specific project. Being able to manage that person requires a deeper understanding of the issue, of what makes them not as good at the job as needed, and where the accountability for that falls.

Why keep a developer who isn’t very good?

Perhaps the first question is: should you keep a developer who isn’t very good? The answer to that is: sometimes yes, sometimes no. If a developer has a good understanding of the function of the business, the overall ecosystem, is happy in what they are doing, and supports a good energy among the team, then yes, it might be good reason to keep them, even if they aren’t that good.

If, however, a developer is the only person who knows how things work because they have focused on information retention to make themselves irreplaceable, if their ego is poison to the team, then the old adage of ‘hire fast but fire faster’ may apply.

Why isn’t the developer good?

In order to decide how best to handle the situation, you must first understand the issue. To do this, you must start with the developer’s deepest desire. In today’s world, we have the power to build the lives we want, and the career of a developer is no different. Various options and opportunities in a variety of specific niches are available for them.

Understanding who your developer is, what they want, and the challenges they face, can help you better understand your developer. Maybe they are unhappy with the work they are doing or maybe they find the work challenging because it requires a skillset they don’t have. Sometimes, the issue behind them being ‘not very good’ goes deeper.


If the developer is unhappy with the work they are doing and so is not working to their potential, the questions become: can the developer be assigned to a task that is more suited to their interests, or if the work they are doing is required and it must be done by them, can they push through and improve their performance until something more interesting comes up? If the answer to the latter is no, then should they be seeking other opportunities that are more aligned with their interests? Rather than firing the developer, a discussion between them and the founder can lead to an understanding and agreement on the best steps moving forward.

Underdeveloped skillset

We cannot all be rock stars or experts in everything. If the issue is that your developer is not very good because they lack the skillset needed, you may need to determine whether there is time and opportunity for them to learn and develop what is needed. If not, again, a mutual agreement may be made that will allow the developer to opt for an opportunity more in line with their skills and needs. If there is time, and the developer is interested, this can be an opportunity to build a loyal and more experienced team member.


Where the issue relates to ego, it may be useful to find ways for sharing of information, skills and knowledge that will allow the developer to support the team and to shine in their capabilities. Where the person can be useful to others on the team, creating a better circle of collaboration, you may find that the developer becomes much more successful.

Not focused

It is not uncommon to come across developers who are termed ‘not very good’ because instead of sticking to the plan, they go off and develop based on other ideas that come up at work. It is key for the founder to have in place a framework, a plan for what is expected, to ensure that the developer knows specifically their goal and to avoid giving too much freedom.

Even in a small company with horizontal management, there needs to be goals, opportunities for feedback and input, in order to keep everyone focused and working well together.

Whose fault?

When a developer is ‘not very good’ it is important to understand that whoever placed them in the role they are in bears some of the responsibility. Whether it was a mismatch of skillset, a lack of communication of the specific goal, or not understanding the desires and interests of the developer, the founder must take some responsibility and act in the best interests of both parties in finding a solution.

What difficulties have you had managing developers? What have you learned through your experiences that you wish you had known earlier? Share your stories here.