Why You Should Hire for Reliability, Not Just Talent

Given the right amount of money, would you rather buy a Ferrari or a used Toyota Prius? A young Padawan will surely choose a Ferrari, while an experienced Jedi will get a used Prius in the blink of an eye. How come? See, if you have a Ferrari, the moment you get a crack in your windshield or pierce a tire – it's game over for you. Just like that. Insert coin to try again. The maintenance is crazy expensive, and you might have to wait months on end to get the necessary part. Owning a Toyota Prius makes your life easier. You can even repair it yourself. It allows for a lean approach to car owning.

‍

‍

The same happens with your hiring culture. You hire a superstar, pay a hefty amount of money every month, everything goes well, but then Something Happens™ and you're suddenly left without your beloved Ferrari. What you're left with is a pile of code not even Stephen Hawking would understand. So, game over, you go to square one and try again.

There are a couple of fundamental flaws in that approach. It neither allows for scalability, nor for crisis management. So, here are some tips on how to leave your Padawan training and finally become an experienced Jedi:

Work environment

Don’t make your developers use their own task managers, planners, or GitHub accounts. Seriously, letting a developer work in their own ecosystem is a recipe for disaster. Some will ask, some will beg not to use Jira or Trello, but you should be wiser. Breakups can be ugly. It's a bit of a pain in the ass, but the day your developer leaves you, you'll still have all the tasks, issues and roadmap laid out for the new developer . On a side note, don't skimp on good, high quality software  – work tools should help with the work, not interfere with it.

Documentation

Make it a part of your (or you project manager's) routine to check on the project documentation. I assume that if you're managing a tech project, you have at least some minimal understanding of programming. So, as a golden rule – the documentation should be written and structured in such a way that you could kind of barely understand it. You might not know the words themselves, but you should understand the general idea. Your new developer will thank you. Also, are you planning to scale your product? I mean, I doubt you're planning on launching, operating a couple of months and then going MIA. Scaling a tech project without proper documentation is damn near impossible.

Login info

Another good practice is to keep track of all the login info used by the developer (relative to the project, obviously – don't ask them to give you access to their social media accounts, for God's sake). If for one reason or another your developer leaves you, change all the passwords immediately. Have a corporate GitHub account, a corporate Stackoverflow account, keep track of Apple Developer Program login info if it's relevant – you name it.

Job listings

Don't delete your job listings the day you find your new dev. Keep them going. Maybe, skip on the job listing promotion part, but keep them. And update them on the go. Have you noticed a particular skill your developer has, which is very useful, but you haven't listed it in the original job description? Update it with the new info. This way, you can start hiring as soon as you see that your relationship with the developer is coming to an end. Also, it might be a good idea to have a couple of experienced developer resumes in your drawer, just in case.

Team structure

Now, a less obvious point. Have at least two developers in your team – a senior-level dev and a junior one. First of all, it's necessary not to be left with 0 developers in a critical moment, but most importantly, this way, when onboarding a new developer, the senior-level dev can explain all the tech stuff much better than you or the project manager can.

Onboarding protocol

Speaking of which, have a clear, well-written onboarding protocol in place. Everything should be documented. Have a welcome email, have the new developer introduced to their colleagues on a formal call, have a document with all the passwords, a project timeline, work environment – everything. 20% of effort brings 80% of results as they say.

Lawyering up

Again, breakups can be ugly. You don't want to be left without project files, you don't want to pay more than you have to pay by law. That's why lawyering up is so important. Your lawyer will help you prepare an air-tight contract so that your sleep is healthy and uninterrupted.

You can never be too sure. For all the fun, active and dynamic stages your startup will pass through, there will always be a healthy dose planning, preparation and preventive crisis management. So, if you want to succeed, do your homework and try to never rely on chance – being ready is all that matters.

Thinking of replacing a developer? Scaling up your team? Left out of the blue with no developers? At Match.dev we connect you with top talent, quickly and affordably. And keep in mind, you're not outsourcing a dev – you're getting a full-fledged team member who seamlessly integrates into your project management ecosystem and works in line with your product strategy. Drop us a line and let us help you find the right developers! team@match.dev

‍