Examples of bad relations to avoid
During my entire practice in IT industry I frequently encountered the necessity to find and involve contractors to my projects. I worked with both individual freelancers and teams – and my experience varied a lot. In this article I am going to describe some negative aspects I encountered when I working with particular contractors.
Below is a list of situations that I would strongly recommend to avoid.
Bad skills level
Developer is poorly skilled in programming languages and technologies, has a limited understanding of development practices and makes mistakable decisions which leads to the overall low quality of the delivery. Usually this situation creates a necessity for a customer to spend significant time to test and report obvious bugs. Meanwhile, the process is better-organized when a customer only suggests improvements (such as UI tweaks, new use cases, etc) but not makes a QA testing work which is a development team’s responsibility .
When I collaborate with new people I often encounter the following communication issues:
- Lack of interest. Reluctance to actively discussing an actual problem. Instead of it, the developer is doing some lower-prioritized tasks and postponing the problem discussion for later.
- Logically incorrect sentences, language and communication barriers. It causes difficulties when trying to understand the pressing issues or explain them.
- Aptitude to criticise teammates/customers instead of resolving mistakes. It is rather a personal characteristic, not a communication problem.
There also exist etiquette problems, such as interruptions during voice calls, personal criticism, lack of respect, raising the voice while communicating. Etiquette problems are critical for me, so I stop working with such people at the very beginning.
Poor level of understanding and business analysis
Small interest to understanding the requirements, reluctance to think and analyse out of the boundaries, reluctance to think like a customer or imagine particular cases from the end-user perspective.
Apart from motivation problems mentioned above this can also be triggered by a lack of sufficient IT experience which makes it impossible to understand project requirements in detail.
Attempts to deliver a crap
It is a common and well-known issue when a developer either knowingly or mistakenly delivers an unfinished or wrongly done job and hopes to be lucky enough to get it approved. This is a waste of customer’s time and budget in attempt to earn easy money.
Lot of promises
Within skilled and well-organized teams developers usually tell statements like “currently mobile part has been done, delivery estimate for the remaining part is Jul 5” in response to customer’s inquiries about the status update. However, the lack of organization is a very common problem among contractors, If this is the case, the customer can continuously find delays in delivery and thus demand realistic answers from the developers. Answers like these should make you alert: “Don’t worry, we will do that all by tomorrow”, or even worse: “Don’t worry, we can do it” which is not good and obviously means that this is a time waste. Btw, I have a rule – if someone uses a phrase “Don’t worry” then it is nothing else but a decent indicator to worry.
No respect to customer’s business
When developers work on particular tasks but have a very little interest in what the final plan and business objectives are.
When I attempt to find new people, I conduct interviews for the selected ones and involve shortlisted people to the trial projects. Afterwards, I work on the ongoing basis with those who passed our evaluation.