Having worked on projects in the start-up world mostly in collaborative and shared workplaces, I was lucky to have the guidance of a number of project & hiring managers who taught me a few “tricks of the trade” that you may not normally learn through your journey in Project Management.
One of my favourites is a highly effective technique I was taught to help me select the right satellite team member for a project. It didn’t come with a name (and after doing my best to search for it – I still couldn’t find it) so as an homage to my love of basketball, I like to call it the Triple-Double Rule (or the TDR).
Let me paint the scene – the organisation was expanding and I was in charge of a small project that required 2 CRM developers with HTML, Java and SQL experience to help with building out and customizing a number of features within our CRM platform. I’d created a solid project mission, vision & success statement and was given a budget alongside a bit of coaching on where to find competitive rates on international developers (I highly recommend www.upwork.com). I posted the contract ad and within hours I had applications flowing in.
This is where the TDR comes in. The reason it’s called that is:
If you need (x) amount of (y) for a project, shortlist & test triple of (x), interview double of (x) then hire your (x).
So in this instance: x = 2 and y = developers. I shortlisted 6, interviewed 4, and hired the best 2. Following me still? Let’s get into the actual steps on why I found this effective. I’ll keep using my project as the example to keep it simple.
The Five Steps of the TDR
- Choose your Triple – find 3x the amount of required workers
- Spend $ to Save $ – ask them each to do a little work for small sum
- Compare Results – identify who did exactly what you need
- On the Double – cut the list to 2x your need and interview further
- Landing the Fish – choose required number and provide them with the other examples done by previous applicants
1. Choosing your Triple
When choosing the shortlist of contract candidates try to find:
- 1 or 2 “Champions” – highly experienced contractors (most expensive) to act more as a barometer for the others (unless you have the budget room).
- 2 or 3 “Soldiers” – moderately experienced contractors (lower price) who mostly suited my needs for the project.
- 1 or 2 “Wild Cards” – someone with less experience and usually cheaper but potentially a hidden virtuoso hungry for a chance to prove their worth.
In this instance, I went with 2 Champions, 3 Soldiers, and 1 Wild Card.
2. Spend $ to Save $
My favourite part of this technique is using some of that budget to make sure you 100% find the right people. It starts by offering your shortlist a:
- Cash incentive (relevant to their hourly rate)
- Small task (2-3 hours work at most)
- Set of questions to complete before considering them for the bigger project.
Remember – on UpWork all contractors are subject to a public rating and review post-project (think of eBay crossed with Facebook). One really bad review can really hurt an UpWorker.
For an initial $100 per developer – I asked each of them to:
- Answer a set of questions relative to the project, i.e. “How would you tackle this issue?” Or “if you were going to create this – what would you do?”. Usually 5 is a good amount.
- Create an ‘Analysis’ document on both the existing layout of our system, recommendations on how they’d solve the needs of the project using their skills AND/OR provide a small working example of the work they could do relative to the project (I provided them temporary access to a sandbox instance for this)
- Accept $50 instead of $100 to do the same project.
- Finish this by a specific deadline.
Looking at those requirements, I was thoroughly identifying and solving a number of common pitfalls when hiring international contractors:
- Who would be flexible on their price?
- How good was their English & communication skills?
- How competent were they with the software?
- What was the overall quality of their work and business experience?
5 accepted my rate request except for one Champion who still wanted the $100. I accepted this and I’ll explain why shortly. I was spending $350 to get the RIGHT people for the job.
3. Compare Results
The next day I had 6 (very different) project analysis documents. I created a quick spreadsheet that outlined a number of key categories aligned to the 4 above questions and did my comparison:
- Champions – the $100 applicant provided a very robust outline of how they’d do the project and a small snippet of working software. The other only provided a document outline that honestly seemed like they’d rushed it.
- Soldiers – Two out of three gave me solid yet reasonably different documents and working software, the other just software and a small description.
- Wildcard – They surprised me the most by giving me a (potentially too) large analysis document and some decent working software to boot. Had I struck gold?
4. On the Double
It was easy to cut away the two developers I didn’t want to proceed with – the cheaper Champion and the weaker Soldier. They were happy earning $50 for their efforts and I got two unique views of how to do this project in document form in return.
With four candidates remaining I jumped on a few video calls to conduct further interviews. Prior to this, I sent copies of all the other analyses to review if they chose to. On the calls I asked them specific questions about their previous work history, their own analysis’ approach, some of the other developers’ analyses (all of them seemed to have read the other versions) and finally what their going rate was.
5. Landing the Fish
After using the same categories to rate my initial 6 candidates, I decided to go with one Soldier and the Wild Card. Obviously keeping Time & Cost down was important, but because these two developers had already gotten an idea of the Scope and had thoroughly reviewed the other developers’ analyses – they were eager to sink their teeth into something they’d already started.
The Results
- Spent $350 for 6 separate analyses and 4 pieces of working software.
- Provided all the gathered analysis documents & software examples to my final chosen developers. This was particularly helpful for my Wildcard as it showed him how more experienced people in that field did the same work, and provided him with a myriad of options to consider & new skills to learn.
- Hired two people who were already invested, had accepted a better rate and were able to communicate effectively. They’d proven their commitment and work ethic through their own analysis and by reading the other documents provided.
- Project was done on time, under budget and there was nothing out of scope.
Things to Note
- Don’t always go with the Wildcard. Sure, they’re usually cheaper, but know what you’re paying for and be sure to interview them rigorously.
- This method may be challenging for large scale projects, however if you’ve got the time & resources to do so, it’s guaranteed to save you even more of the same at project completion.
- The TDR can be used for most industries. I used a similar approach trying to find a blog content writer for an education website. I ended up picking 3, paying them a small amount to write a little piece, interviewed the best 2 then hired #1.
I hope that you get some value out of this technique. I’d also love to hear some of your experiences if you choose to use it (or have in the past), questions, feedback or if you’ve seen this used elsewhere under a different name – please let me know and I’ll credit it accordingly!
Good luck!
