Working at a start-up is incredible; 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 necessary? Can we do this less expensively? 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).
Image credit: GitHub Octodex
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).
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 excellent candidate is right and get more input on what makes them great. I’m a techie, and I understand what makes a candidate interesting, but I’m not a developer, and I can’t judge if someone is excellent 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:
https://github.com/Sjamilla/recruitmentexample/issues
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.
My friend Adriaan said it was okay to use him as an example, make sure to send him a message if you also think he’s awesome 😉
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.
You can create as many labels as you want, just try out what works best for you.
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.
You want to create columns in the projects to see where candidates are in the funnel.
These are the settings for the first column, where new candidates who are assigned to a project will start. This is important because it will save you time ????.
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.
When I add a project to the issue (aka: candidate), it will show up in the first column.
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.
Add individual collaborators or add whole teams to your repo.
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.
- 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 one to three 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 ????.
This was one of the positive responses I received from my colleagues in regards to this process
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.