I often hear that software developers are the most difficult hire for non-technical founders.
The process and questions to determine a candidate’s fit is a mystery to most of these founders. And regardless of whether they’re looking for a Chief Technology Officer or a freelancer to help hack the first version of a product, they often feel completely out of their depth when speaking with developer candidates.
As a result, they rely on what they think they know about recruiting talent. For the most part, this means relying on their own experience in hiring people which as it turns out is usually, at least for first-time founders, very limited. And let’s be honest, there are few people in the world who have a perfect hiring track record.
If your venture relies on software, and just about all do, the need to get hiring decisions right is important. In fact, it’s crucial because (and speaking from experience) getting it wrong can be terminal.
At a macro level software developers are (and will continue to be) in high demand. But the rate at which developers churn from one business to another is also very high
as is the number of graduates from software development courses.
So if there are software developers looking for their next opportunity why are they so difficult to find?
It often comes down to how the founders approach the hiring process. The punchline is that they forget, deprioritise or don’t give any consideration to seven important ideas.
1. Thinking of developers as machines
This might sound strange but non-technical founders have a strange affinity for relating software development output i.e. code, with the idea that it is created by a machine.
This notion becomes even stranger when these same founders think that all machines are created equally. In other words, they think that developers know everything there is to know about software development.
This bias influences hiring and workplace practices and fundamentally devalues the role that developers play in digital companies.
As obvious as this sounds, developers are people. Treat them like people.
2. You never captured their imagination
Following on from the first idea, many non-technical founders never sell the vision to developers in the same way they would to investors, partners or customers. Instead, they lead with the task or capability-based job description or worse still, software ‘requirements’ documents to gauge interest.
The ‘why’ matters to every hire.
I remember making this mistake at AirShr when we engaged an offshore software development team to accelerate product development. They were polite, competent and delivered what we asked. The only issue was that I completely forget to explain why they were working with us.
Their output tripled once they learned AirShr’s why because they could relate to the use case. They also saw the global application for the technology they were building. Most importantly, they started to act like owners and make appropriate risk-weighted decisions when we couldn’t be contacted because they understood the context and mission.
3. You think engineering is all science…and no art
This point also ties back to the first idea and the notion that code looks structured and scientific to non-developers. The reality is that while there are best practices for how to write, structure, annotate and deploy code across the many software languages, there is also a myriad of ways that code can be written, structured, annotated and deployed.
This is because at its most fundamental, writing software is all about creating and making. It is a very artistic pursuit and one that takes time.
This point is often missed by non-technical founders. As a consequence, they can become frustrated with developers reluctance to provide concrete deadlines for delivery of tasks, particularly those which require building features or whole products from scratch.
4. You think developers assimilate quicker than other people
Imagine this. It’s 12 pm and a friend walks into your office and asks for your feedback on a 10,000-word university assignment. The assignment carries a significant weighting for the final mark and they have left it to the last minute. Your review is critical and you would love to help but they need your feedback by 4 pm because it’s due for submission at 5 pm.
Could you provide detailed feedback in time? Probably not.
I use this anecdote with non-technical founders who are frustrated when it takes more than a day for a newly appointed developer to get ‘their head around’ a code base they had no hand in writing.
Whatever your estimate of time for new developers is to become familiar with your code, quadruple it.
They need time to understand what’s there.
Pro-Tip: As part of the onboarding process, ask the new developer how they would write the code if they could start from scratch. This will make for a productive start to the relationship.
5. You don’t audition each other
6. You expect to be in a monogamous relationship
Never happens. Every software developer has a side project.
Providing it doesn’t adversely impact the agreed workload, be good with it. Ultimately, this is helping the developer improve their skillset.
7. You lead with the wrong incentives
Startups are resource constrained. You know it and so do developers.
The opening gambit from most non-technical founders is to offer equity to offset the discounted wage that they have no choice but to offer. That is in the best interest of the company but it’s usually a long way from satisfactory for the developers.
Apart from developers being very sensitive about not getting paid for work they have done (there are too many experiences where developers have been short-changed by founders due to various misunderstandings), founders often forget three fundamentals.
First, developers will engage if the problem is interesting enough. If there is lukewarm interest, there is no point talking incentives because you are likely to get lukewarm performance (at best!).
Second, developers, like everyone else have expenses and need to be paid. Don’t overplay the value of equity as a means to pay them less. This will be harmful to the relationship in the medium term, especially if it’s later discovered you could afford to pay more. In any case, developers understand the risk of startups and know the chance of equity appreciating is always lower than advertised.
And as the old adage goes, you get what you pay for.