How to hire without sinking your software project
Hiring a software developer who can successfully deliver a software project is a near-Herculean task riddled with uncertainty. The stakes of failure exasperate this problem. A poor choice can easily double the cost of a project and create long-term problems for anyone who may inherit the failed project.
I once hired so poorly that the results killed my project. Yes, you read that correctly. I once made a hiring decision so egregious that the project was forever shuttered and remains dormant to this day. The goal of hiring this developer didn't align with any core business need, which was my first red flag. The result they delivered (a poorly architected production server & CI system) made shipping slower, broke the existing workflow, and ultimately made momentum stall to the point of calling the project off. The odds of hiring that badly are (thankfully) very slim. However, the moral is that momentum, workflow, and even the morale of the team—will all be affected (good or bad) by the decision to bring new personnel into the project.
To exacerbate the problem, figuring out which devs are good and which are bad is a hilariously hard problem. The dev I hired above? That's right—5 stars on Fiverr, reasonably priced: not too high, but certainly not too low, and complete with rave reviews. It's no wonder that, to this day, word-of-mouth continues to be the single best way to secure world-class talent. The best engineers in the world never send out a single resumé. You should leverage this fact by tapping your networks to find developer talent long, long before you dare to reach out to an agency or risk evaluating an unknown developer yourself.
Did you think an agency is the "easy button" to this problem? Not so fast. If you're lucky, you'll only spend 10x more than you should to launch software that might be better than what a single developer could deliver. I once consulted a client who was quoted $150,000 to upgrade a small application by two versions for a framework that the agency themselves specialized in (meaning it was a trivial job for them).
The final slap in your poor as-of-yet-not-developer-having face is the fact that even if you surpass all the hurdles above and secure yourself a great engineer who can quickly, correctly, and financially reasonably build your solution, you've now secured the table stakes to finding a great hire. You see, any decent engineer will be able to code well enough to build your solution. But now you have to consider the entire lifetime of the solution after it has been delivered.
- Who maintains it?
- What does it cost to get your newly-found developer back in to fix bugs?
- Will they educate any existing staff on the solution?
Suppose there's any uncertainty about any of the above. In that case, you'll want to ensure your developer has solid guarantees to go with his work. At a minimum, they should guarantee that their solution will be defect-free. This would involve fixing any bugs, free of charge, for some time after the engagement. I recommend a minimum of 3 months after the engagement.
The icing on this cake should be some communication around how the hand-off will proceed. It is tragically common to see a good relationship get fumbled right at the goal line when passing the solution off to a client. Often, developers are already working on a new project and do not put the care into the final inch as they did during the first 90 yards. A guarantee regarding the terms of the delivery and even the support for the client for the first week or two after delivery is a nod to the guarantee of craftsmanship and professionalism.
"Hold on, Adam, this seems excessive. There's no way this much needs to go into getting a guy to slap some code down."
Well, my skeptical friend, you are correct. This is excessive. Truthfully, you don't have to do this much work to get your software project off the ground. These guarantees don't even promise success.
However, there's a reason that upwards of 70% of software projects fail to deliver expected value. Sometimes it's management, sometimes it's technical decisions—but these problems always start with mediocre hiring.