Don’t Make the Mistakes I Made When Hiring Developers

Please, learn from my mistakes. 🙏🏽

I have hired some wonderful software developers over the years, but I have also hired poorly. In the last couple of years, I hired some developers who looked good on paper but just could not perform in the start-up team environment.

So what did I do wrong? I decided I need to know, and to find out I used the Polynize Job Analyzer to break it down and learn from my mistakes.

The Job Description

I thought I had written a pretty good Job Description (JD) — concise, to the point and covering the skills that I needed for the job.

So now, let’s paste that job description into the Job Analyzer and start analyzing what went wrong. 🧮

Click here to check out the live analysis of this job description.

Mistake #1: 95% Focus on Technical Tasks

Looking at the Job Analysis, the first thing that jumps out is that job description specifies only technical tasks. Check out the tasks analysis below:

The tasks are correct as far it goes and they do indeed belong on the JD, but the fascinating thing is what I left out — the tasks that I did not specify which were an integral part of the role:

• attending and contributing to effective meetings
• timely feedback and documentation of work
• fast, iterative collaboration with other team members etc.

The fascinating thing is that, looking back, it was *exactly* these non-technical tasks that the hired team member struggled to perform and thus led to “hiring failure”.

Mistake #2: Poor Communication Skills

Look at the skills matrix for the job description:

The first column — Communication Intelligence Skills — is completely blank! And sure enough, looking back on the JD, there is zero emphasis on communication skills. 😢

That was a big, big mistake. Looking back, I can recognize how friction in communication built up over time in the team until it began to really slow us down. Remote developers especially need superpowers in this area to overcome the natural barriers of distance, timezone etc.

[Some of the key specific skills that would have been so good to focus on — clarity, precision in communication, ability to explain and inclusive communication that other members of our global team could understand.)

Seems so obvious now. It’s not that I was *completely* unaware of communication as being important, but I would say now that is was critical — communication skills were least 5x more important than I thought.

Mistake #3 — Changing Requirements Needed Adaptability

Over on the functional side of the Skills Matrix, I can recognize another big gap — I didn’t focus on the key skill of being able to adapt to changing requirements.

This is a huge, huge mistake for all remote teams but start-ups in particular. The start-up environment means requirements for building software are constantly changing, on a weekly or even daily basis. It’s nothing like we are trained for in universities, where we build to requirements that are set ahead of time and don’t change for years.

This is exacerbated in remote teams because the communication cycles mean that these changes are only ever communicated in clumps. So you can wake up and find changes to your required work in your inbox. You’re building in an evolutionary environment, not a fixed scope / task system.

This can be exhilarating for the right kind of developer, and very stressful for another. In this job, I ended up with the latter type, and it grew to be a big issue, causing a lot of friction and unhappiness. All because I never hired for someone who can adapt. 👎🏽

Mistake #4: I Needed Visual Intelligence

Now to something I did include in my JD but didn’t think deeply enough about — visual intelligence skills. Specifically, the UI/UX work that I needed in Polynize is pixel-perfect, high standard design work. So even though this was a front-end “software developer”, I should have focussed much more on aesthetic and visual capabilities.

This became a real issue as I had to constantly “retro-fit” good design onto the work that I was receiving. It might have been functionally OK, but as a user experience it wasn’t up to the standards we needed.

Mistake #5: Key Collaboration Skills Missed

I had thought about collaboration, but not deeply enough. Specifically, looking at the Job Analysis now I can see where failure points came later on:

• Questions — without getting back effective questions, I couldn’t tell if my team member had understood task requirements. This is a common problem with software developers.
• Translate — everyone in the team had different backgrounds, so it was imperative to be able to translate ideas into forms that others could understand. That didn’t happen, and again this is common for developers who e.g. can’t explain to non-technical people.
• Leadership — in a start-up, everyone has to be able to lead at any given time. Tasks only get done with task ownership / leadership. What kills teams are developers who will follow but never lead (i.e. only do “what they’re told”).

Conclusion

Now that I have started, there is actually more, I could go on for ages. But I will leave it there. Doing the Job Analysis has showed both what I completely missed, and what I didn’t miss but under / over-estimated in importance.

Here is my TL;DR — I missed and underestimated all non-technical tasks and wasted time on technical task ability. I would say that I have *never* seen hiring failure because of a lack of technical task ability.

i.e. 95%+ of the hiring risk for your company is in non-technical skills.

And it’s exactly these skills that we can’t measure, develop, train and hire for. This is a huge failure point for all software teams, and it’s only getting worse with distributed, remote teams.

Hiring poorly hurts you as the employer, the company and it hurts your new team member too. It’s a lose-lose and no one ends up happy. Please, if you’re hiring developers, read this article and learn from my mistakes! 🙏🏽

Hiring? Paste your JD into the Polynize Job Analyzer which is free to use right now in beta pre-launch!