This article from the Economist brings to mind some of my experiences, and the resulting Hacker News thread on the subject was good additional commentary from experts (one of the % of threads where Hacker News commenters are actually experts, as opposed to geopolitical discussions).
Wanted to share some of my own experiences on the subject, on a much smaller scale. I’ve hired a dozen or so freelance developers or small agencies myself, and while that’s very different from global IT companies, I think this info is much more relevant for small business owners.
Lesson 1 – Only Experienced Developers Can Hire Cheap Developers
Think you can find a really good, cheap developer overseas if you’re just a marketing guy? Think again.
You likely are overestimating your knowledge, as I have.
I’d argue that only trained web developers have the eye to find truly good talent on the cheap. In order to find the talent, you have to have the skill level to evaluate their quality of work. You are not qualified to make that discerning filtered decision if you’re not the expert yourself.
An exception may be a product manager that has worked with developers for years and knows how to interview and evaluate, but even they would likely say that you should have a developer friend also help qualify.
As a parallel example, others in the SEO industry bemoan all the time of companies hiring cheap and bad SEOs. But it’s because the hiring company thinks their getting a good deal, when really they don’t have the expertise to evaluate.
One solution is to bring in a friend or consultant that’s an expert in the field to do the vetting and hiring for you. Easier said than done, but it will save you a lot of headaches in the long run of the project.
One quick story on this – I once worked with a company where owner commissioned his friend’s development agency to create a web app that would essentially allow users to create lists of travel destinations they wanted to go to. The owner had no technical expertise and just relied on his friend’s development agency to run with it. As far as I know there was limited discussion on scope, goals, monetization and how it would support the current company and it’s revenue streams. The project ended before I was hired on so I didn’t have a chance to get involved, and the story is that it took over a year, over $100k to build, and it never launched. I’m sure there are bigger stories about multi-million dollar projects like this, but in our situation, it was a small business throwing away $100k, which really hurts.
Lesson 2 – Interview Thoroughly on the Phone
I’ve made the mistake of hiring outsourced developers that spoke intermediate English. I wish I could speak their language, but this is reality and I don’t.
I assumed that email and messaging would be fine to get the point across. And it works at a basic level, but if you can’t communicate fluently on the phone, there will be a misunderstanding multiple times throughout the project.
If you can get them on the phone for the pre-vetting sales phase, you’ll learn so so much more, and very quickly, than if you drag it out over email.
If you get on the phone and the communication is hard, well at least you’ll know what you’re dealing with. You can still decide to hire them, but you’re not duped by thinking that they are better at communicating than you think. It’s easier to fudge language skills via email than it is on the phone.
In addition, you should decide slowly. I put artificial pressure on myself to make a hiring decision within a few weeks of talking to potential developers, but why? There may be the client deadline but it’s much better to make a slow, methodical decision after interviewing 5-10 people than just shooting from the hip and dealing with it later.
Lesson 3 – Beware of the Platform Promise
Codeable.io says they hire experts and you don’t need to do much work interviewing them before deciding on the project. Ok, I did that, and the project got done but I found out later the developer was only doing this part-time and didn’t have a ton of experience under their belt, he was more of a marketing person doing WordPress development on the side for some extra cash. The project took 5x longer than anticipated, and the poor guy was working 18 hour days to get it done, so nobody won in that situation.
The platform fooled me into thinking I didn’t have to do the interviewing, which was false.
Another platform that might do this are Toptal – I haven’t used them but as I understand they give you like 1-2 people to interview at a time.
With UpWork, they tell you to do all the interviewing on your own and make no promises, so at least you know that going into things.
Related to this note, it may make more sense to hire a small dev agency in your country with an owner that has actual skin in the game. Ideally, by hiring a team with an owner overseeing you’ll get better quality. Not always the case, and sometimes finding that freelance expert developer means better quality, but it’s worth understanding the incentives and accountability of who you’re dealing with.
Lesson 4 – Tiny Projects Are Much Better to Outsource
A universal law of software development is that as the scope increases, the time and difficulty increases exponentially.
The best experience of outsourced projects involved a very simple change. “Add my author photo to the blog post.” That was done in a flash for $20 on Fivver.
“Redesign and re-platform our travel site, adding new UX and UI and new configurations.” That was $10,000 then $15,000 and months of my time. (Still cheap by first-world standards).
That leads us to…
Lesson 5 – Don’t Expect the Outsourced Developer(s) to Think For You
They don’t know your business, and they can’t learn it in a few weeks. You have the intimate knowledge.
You can’t expect them to see the whole picture. They are there to do the development.
If you hire a firm based in your country, that has true business and marketing consultants involved, then yes they can get much closer.
But if you’re hiring cheap outsourced developers, you have to realize that they will take direction from you and nothing else.
Don’t expect them to foresee problems and circumstances down the line. They may see a few code glitches, or higher-level architecture issues if they are experienced, but they won’t see the customer and business issues like you might.
Conclusion
I’ve learned there are universal laws that apply to project and product management when working with developers that are applicable everywhere. Don’t hire the cheapest or it will bite you in the end. Interview and vet thoroughly. Set realistic timelines. Meet often. Be nice but firm. Be an expert if you’re hiring someone cheap, or go expensive if you’re not the expert.
Additional Note:
After writing this I did a bit of Googling and found this article worth a read: Five Pitfalls To Avoid When Outsourcing Software Development, but then this comment was even more clear and lucid:
We have long known in the software industry lengthy specs and rigid timelines simply do not work. In fact in my experience they are one of the biggest indicators to failed projects. Technical or not no one truely understands a project and its requirements until it has been seen, played with and shown to real users.
So whats a better way to engage?
– Build in small autonomous chunks, and deliver working software quickly. If you don’t see something running and solving a small problem in the first few weeks something is probably wrong.
– Try and get the risky bits solved sooner, what small steps can you take to answer risk today, or in the next week.
– Be involved in the build process, evaluate and change direction as you go. You want to know ASAP if the project is going in the wrong direction and correct it. The best way to know is to look at working software, and test it vs your users.
– If the vendor isn’t delivering what you want, find this out really early and work to resolve it either with the vendor or by finding a new one. Moving codebases (especially large or poor quality ones) between vendors is really expensive, so you want to avoid this if possible.
– You tend to get what you pay for, be wary of companies that estimate low. Projects estimated low often end up costing much more. These vendors tend to resolve price overruns in fixed price work by frequent change requests or poor quality work.
– Fixed price work tends to end by delivering a product which may meet some interpretation of the spec but doesn’t meet the actual underlying need the software was built for. The only comprehensive spec is working software.
And you know what, I remember reading that article and comment late last year, but I still made this mistake again this year in Spring of 2020 for a new project. So let’s hope I’ll truly learn my lesson for the next time.