Budget Sourcing 101: Building a Talent Pool in Github
Working at a start-up is awesome; as a Recruiter / Sourcer it’s one of the most impactful positions at the company. You’re responsible for attracting and hiring great people that will make your company successful. But hiring at a start-up can also be stressful for many different reasons.
One of the things that I’ve experienced in my previous job is that some start-ups have to be careful with the money they spend, so with every decision I made that involved money I had to think: Is this really necessary? Can we do this in a less expensive way? Can we build it ourselves?
Sometimes having little money to spend on tools can be frustrating. On the other hand, why don’t you turn that frustration into something great → creativity!
Using GitHub to Build Pipelines
All the credit for the original idea of using Github to manage Talent Pools goes to my former Blendle colleague Thijmen Klompmaker. He came up with the idea, and during the time we worked together, we made it better and eventually managed to get important insights from it (but that’s a story for another time).
Github?
Yeah, Github. It’s a web-based hosting service for version control using git (ask your developers — they probably use it).
For us (Recruiters & Sourcers) our ATS or CRM is the go-to place, just like checking LinkedIn is a daily habit. But I noticed that for the people around us (in my case the developers I work with) it’s not a part of their daily routine. And to be completely honest, why should it be?
The auto-reminder emails that they receive when you mention them in your ATS disappear in their email (also in mine).
The thing is, when you work at a small company you want the people around you to be as excited about hiring as you are. Hiring should be everyone’s priority. For me that comes down to this: I want to know, before I spend my time creating the perfect outreach, if my feeling about someone being an awesome candidate is right and get more input on what makes them great. I’m kind of techie and I get what makes a candidate interesting, but I’m not a developer and I can’t judge if someone is great based on their code. That’s where the team comes in. It’s like Machine Learning → you feed me information and I’ll learn and get better at it 🤖. I want the team to say something about the profiles I find and I want to know why they think this person is good, or not. Especially when you’ve just joined a team, this is quite important.
When reaching out, I want to tell someone why I’m reaching out and why we need them in our organization. Next to that, I want the team to be 100% in before I reach out to this person. That’s why I also started using GitHub (instead of Lever) to manage my Talent Pool at Poki.
Here’s how I use GitHub to collaborate
Some quick takeaways before you continue to read:
- You should only do this in a private repository, you don’t want all your data public!!! I don’t think that’s legal… even if it is, I don’t think you should want that.
- Link to how to do this: https://help.github.com/articles/making-a-public-repository-private/
- Ask your team to help you if you don’t have access to your company environment in Github; they will know what to do.
- Doing this only makes sense if your teams works with Github. If they don’t, ask them what they do use and figure out how you can collaborate in that environment.
Overview
I created this repo as a test, feel free to click on stuff and play around to figure out if this is something that works for you:
This is the page where you will spend time adding candidates. I like the simple overview. No complex buttons and hidden areas, this is what it is… and I like that.
As you see in this screenshot, every candidate will be an issue. And every issue will get a unique number. That’s awesome if you want to start collecting data. You can sort the issues based on author, labels and projects.
Labels
You probably want to start with editing the labels. Each role has their own label. So for example: Frontend, Backend, Data Science and so on… you get my point, right?
Next to giving each role a different label (with different colours for the overview). I also have 3 labels with a rating. This is the most important label for collaboration. The team will use those labels to rate the candidates.
Creating projects
Working with projects is my favourite option in GitHub. It gives you an awesome overview of who is where in what stage.
Projects are a bit like a Kanban Board, when you add a project to an issue (aka: the candidate), they will show up in your projects.
This is what the stages in my projects would look like. The fun thing is you can set this up however you want. You could just use it to work together before you reach out and then move candidates to your ATS. Or you could also use it for all the stages in the recruitment process. When you’re in a small company and the sourcing volumes aren’t that big, this is perfect.
My settings are like this:
- First column: new / preset: to do / move all newly added issues and pull requests here.
- Second column: not interesting / preset: done / move all closed issues here.
- Other columns: have no special settings.
So every time I source candidates for a certain position and add them to a project they will end up in the first stage. From there you can easily move them to whatever stage you want.
From here it’s just trying things out, check what works for you. Edit the team settings so the people who need access get access, and the people who don’t need it don’t.
How I made it work
I made it work by telling people what I expected them to do and more importantly, by telling them what I didn’t expect them to do. Giving context is key. Make people understand why this is so crucial for you!
To prepare everyone for this change I sent them an email, telling them why I did this and what to expect. The email is quite long so I’m not going to copy and paste everything in here. But I’ll share the main point with you (copied and pasted straight from my email).
Here’s what I’ll do: When I find a new candidate I will add them as an issue in the recruitment repo + links + my thoughts /comments. I will label them: front-end / backend and will attach them to a project. When we decide to contact a person I will put them in Lever and stuff :).
Here’s what I don’t expect from you guys: I don’t expect you to constantly check all the candidates in there — so you might want to opt-out on notifications. If you do want to watch and comment — be my guest 😄.
And here’s where you come in: During this time I will ask you to go through the repo to review profiles in a project and label them from 1 to 3 stars.
Please tell me why they are not interesting, or why they are — and if you see cool projects or smart things that I could use in my outreach, please tell me → it makes it easier for me to contact them when I have some personalized touch points.
I will learn from that and get smarter each time you feed me more info — maybe one day I will be able to know everything without your help 🔮.
One week later…
I know, there are a lot of people who don’t go over their candidates with the team before they approach them. I get that, but I just wanted to share with you what works for me. It might inspire you to do things differently or maybe it will inspire you to keep up your current way of working.
That’s the great thing about sourcing and recruitment, it’s not set in stone. And it is different in every company. By learning, sharing and contributing to each other’s work we’ll eventually find our own path to do things in a great way :).
This article was first published on sourcecon.com
Thanks for reading! Holler at me if you have any questions, suggestions or comments… happy to hear / answer them. You can find me on Twitter, LinkedIn or via Email. XOXO Sjamilla
