Firing a developer: Part 1: When Should You Fire your web or app developer?
Everyone thinks they’ve hired the right developer at first. But sometimes you wonder if you made a mistake. The question is, when your project does hit a roadblock, when do you decide that you should replace your developer? The first step is to determine where the problem lies.
It’s not you, it’s me.
When something goes wrong with your project, it’s a temptation to assume that it’s the developer’s fault. And often it is. But sometimes there are things that you as the client could have done to prevent the problem. It’s never easy to face this, but it’s still something you need to consider. So before you fire your developer, before you even complain to him, think about whether he’s the reason things went wrong. Ask yourself these questions:
Was I clear on what I wanted?
If your developer made something that didn’t work the way you intended, look at your original instructions and ask yourself how well you explained what you wanted. Are your directions clear? Did you have detailed wireframe diagrams for every section of the application? Do you have descriptions of every feature that you expected to be there? In short, pretend you don’t know anything about your idea, and look at your plans. Would you understand your planning document?
Did I monitor progress?
If you’re upset with your developer, it’s probably because he made a big mistake, not a small one. But the key to fixing most mistakes before they get big is to keep checking in with your developer, and to keep track of what they’re doing. How often do you check in with your developer, and how often do you look over their work? Are you giving them guidance as to whether they’re on track or not?
Did I ask the right questions?
Before your developer began his current task, did you ask him about potential problems with your plan? Did you ask about alternative approaches that might be better? Did you listen carefully to their response? A developer will usually do what you tell them to do…even if it’s not a good idea.
These are all signs that it might not be the developer’s fault. But how can you tell that it is his fault?
It’s not me, it’s you.
So what are the signs that the problem’s with the developer, and not with you?
Lying: If your developer tells you he’s done something when he hasn’t, that’s a bad sign.
Suspicious hours: If you ask your developer to correct a misspelled word on your site, and he claims it took him 4 hours, there’s something funny going on.
Demanding more money without justification: There are a lot of legitimate reasons for a project to cost more money than the hourly rate. There may have been unforeseen expenses. But if a developer can’t adequately explain his bill, you should probably be running for the exit. It’s even more of a warning sign if he’s holding your work hostage and refusing to update your project until payment is made.
Bugs that should have been caught: This is a tricky one to judge. Every site/app/program has bugs in it, so you shouldn’t hold that against your developer. What you want to watch for is bugs that are very obvious and should have been spotted. Mistakes are fine. Consistent careless mistakes are not.
Disobedience: You should always encourage your developer to give you their thoughts, and to disagree with you. And you should always listen to his objections. But at the end of the day, it’s your money, your project, and your decision.
With all of these issues, what you’re looking for is a continuing pattern. If you see these things happen once, you can let it slide, or have a polite talk with your developer where you can get an explanation and try to get things back on track. But if it keeps happening over and over again, you might have a problem on your hands.
Next time I’ll talk about some alternatives to firing a developer.