When it comes to software developers, we always hear about quality over quantity.
This motto keeps coming up in software engineering and management books, theses, and blog posts. However, many companies that I have consulted with are having a really tough time tackling this problem. In this post, I want to recap why having developers that are below standard can cause major issues in the company. I also want to go over some of the reasons I have heard from consultee company owners to not address this problem immediately, and share my thoughts on these inactions.
The domino effect of substandard work and worker
I really don’t like the phrase: “the group is only as strong as the weakest link“, but I do think it’s partially correct. Having a substandard worker can drag everyone on the team down. The work that they produce might take longer to code review, and in many companies with insufficient review process, their work causes client facing bugs, server downtime, inefficient code, and bad design choices that is hard to recover from (eg. design that requires big data migration that might be costly in terms of time and money). This kind of work also has an impact on the whole company culture. If the worker did not reasonably improve over a period of time, other developers might feel frustrated to constantly have to deal with the fallout of the bad code; some developers may even start to feel complacent or indifferent because of it.
Let’s NOT kick the can down the road
Here are three reasons I have heard for not taking action regarding to this issue:
We can get some extra work done out of them: Most of the time, with a consultee, we would compare the review time and amount of back and forth for a feature or bug. In many of those instances, we find that the amount of time spent on the reviews are close or surpass the development time. I think it’s very easy to fall into this way of thinking: believing more developers = more throughput, but in reality that line is never linear.
We can get them to work on work that is less impactful: many of the consultees would mention moving the substandard developer to work on less impactful task, or KTLOs (keep-the-lights-on tasks): tasks that are minimal and repetitive, but might not make sense to automate them yet. While I think this is ok in the short term. I believe in the long term, it’s quite harmful. The worker could feel demoralized working on these tasks. Depending on how open the company’s pay and hierarchy structure is, other developers that do not know the full situation might feel slighted as well.
They have been with the company for a long time, and accumulated tons of domain knowledge: I think in this case, there are some follow up questions to ask:
Are they knowledgeable enough to be a product owner or product manager?
Do they have product skill sets such as talking to customers or gathering requirements?
Does it make sense for the company to move this person to product?
Does this person want to move to a different department?
If all those answers are yes, then great, you just got a new member in your product team! Otherwise, having this worker doing half development and half product is a recipe for disaster, because that particular job expectation and description is extremely difficult to set.
The next step
Be honest with the worker in question. Let them know where they currently are in terms of productivity. Work with them privately on improvement goals and timeline. If the worker did not reach those goals in the given timeline. Then it’s time to part ways. While it’s always difficult to let someone go, take solace in the fact that this is beneficial for all parties involved. For the company, the positive impacts are mentioned in the previous paragraphs. For the worker that is being let go, they can find a job that suits their current level and improve in an environment that is less stressful; therefore, more likely to succeed in their career.
How to identify this problem
There are a few signs to watch out for, such as: slower development time, more bugs, longer review time, and increased technical debt. While these problems are not uniquely linked to substandard workers in the organization, it is a good idea to start paying more attention. If you are a company owner and not very technical, then make sure to bring this issue to your technical lead/CTO. Otherwise, it might be a good idea to hire a good technical consulting firm to go over the company organization to gauge the developers. (shameless plug, you can hire Back Pocket Labs to do an organization review😉)