Why we came up with Born in the Barn
Monday, June 06, 2011 2:50:18 PM (GMT Daylight Time, UTC+01:00)
Some of you may have already come across our new recruitment drive -www.borninthebarn.co.uk but I thought I would write a few blog posts about the thinking behind the website. This post concentrates largely on the business reasons behind it, I'll post separately about our findings and the technical/design aspects of the site later.
Firstly, if you've not already had a play, go to www.borninthebarn.co.uk and see what you think -and then tell your friends and family about it.
A little background
We started looking for someone to join The Site Doctor team a couple of months ago and followed the usual routes -we posted on job boards, shouted about it on various social media sites e.g. Twitter and LinkedIn, and took out an advert on a job website (in our case cwjobs.co.uk -who were good).
Despite a reasonable response from our efforts (discounting the recruitment firms), we didn't find anyone we felt fitted, so we took a moment to reflect and we realised why:
- We weren't offering a high enough salary to attract someone to our location or selling ourselves properly
- We were following run-of-the-mill methods but were looking for someone special
- Our efforts weren't concentrated and (because we were busy) lacked our complete attention
- Our portfolio was (and still is) woefully out of date and didn't overview the cool stuff we've been working on
But most importantly, we realised that it shouldn't be about us, all the job adverts we've seen to date have been about what we want from you and what we'll be giving you in trade -but why should it be all about what we want? Surely it's more important to know what you -the candidate wanted? As soon as we realised this, it gave us a whole new perspective on our recruitment drive.
Identifying The candidate
Once we'd realised it shouldn't be about us, the next step was to re-think our ideal candidate. Rather than thinking about the skill set, we needed to think long and hard about what they stood for and from this we would be able to work out how to "find" them.
One of the key things we're looking for in the ideal candidate is the right attitude. Looking around at people in the industry, there seems to be a clear divide between those who see it as just a job and those who enjoy -and have a passion for the work they produce. You've got to care about and enjoy what you're doing otherwise it really shows in the work that's produced.
So how do you find someone that cares about their work -and the industry as a whole? We feel they will be:
- Active on social media -Just by having a Twitter/Facebook/LinkedIn account shows a certain level of interest in new technologies
- Attend community events -It doesn't matter whether it's one of the big conferences (e.g. DDD, FOWA, NAConf etc) or a local meet e.g. MultiPack, just attending shows a certain level of interest
- Interest in new technology -HTML5
- Blogging -Ok not everyone has the time to blog (including me) but throwing up a post every now and again goes some way to showing that you care about others in the community and want to help them learn
So what could we do?
The obvious answer was to start again (one might say with a blank card!), put out another advert with a higher salary, more words on why we're great and more buzzwords but that would more than likely result in a similar response -a lot of time spent telling recruitment agents that we're not interested. More to the point it still wouldn't sell us to the candidate. The fact of it is that people get excited about different things -and it's not always all about the money (despite what some people say).
We needed a way of finding out what developers really wanted, we felt we knew what our best attributes were, but which were candidates looking for? Knowing which of them were something were good enough to tempt you to join us was the unknown. The original concept was to design a microsite which over-viewed the role, buzzwords, our clients along with any other selling points, but while sketching it out, it hit us -it's still all about us not you. So after a little more procrastinating, we thought, we're not sure what you would want so why don't we just ask?
Asking the community what they wanted from a job meant that even if we didn't find the candidate through the process, we would at least have a good idea of what people looked for in their role -which would then allow us to focus any future advert on just these. Giving people the chance to submit their own cards also meant that they were able to suggest other benefits/features that we hadn't thought about but may already offer (or be able to offer). Ok we're likely to get some joker posting that they want £1m or similar but we expect to get some gems among the rough.
And so was born the concept that is now www.borninthebarn.co.uk
Why we didn't focus on the role itself
You may have noticed that we don't really talk about the actual role itself -or salary. This wasn't an oversight on our behalf. We did this because we're flexible on both. Looking at the process more of a negotiation rather than set sale meant we were able to see what people felt they needed to join us.
On discussing salaries and competency internally, one thing that came to light was that people frequently over -and under value themselves. For example, I probably wouldn't apply for a senior developer role because the people I work with and socialise with at conferences etc. are what I would consider advanced developers (and so suitable for the senior role) and their knowledge blows mine out of the water. But what you forget is that these people also work on the platform that we use to code, they write books -and talk so as far as industry is concerned they're way beyond advanced.
Allowing the candidate to specify their worth meant that we don't discount the candidate before we've had a chance to think about whether we feel they're worth what they're asking (rather than them discounting the role before knowing whether it's what they'd want to do). At the end of the day, we have a maximum salary in mind, if we feel they're the right person but a little over our maximum salary we can then make the decision as to whether to stretch to their demands or not.
What do we hope for?
First and foremost we're hoping for someone to join the team at The Site Doctor's HQ but failing that, we're be happy to get a clearer idea of what people are looking for in their roles so we know what to talk about in our future job postings.
As I think this is also a better way of looking at the recruitment process (the focus being on your new employee rather than just what you need) I hope that other companies take heed and start looking at the way they conduct their recruitment processes. I realise that not everyone has this luxury but they could at least focus a little more on what's in it for the candidate, I think it would be the start of a better (and longer term) working relationship for both parties.
Calculating what an employee will cost you
Monday, December 20, 2010 10:17:56 PM (GMT Standard Time, UTC+00:00)
As people are now looking to employ I thought it would be helpful to overview the general costs involved with employing someone in the UK and how you can factor that back to an hourly charge.
Some Assumptions
- As most of my readers are within the IT industry, I've based these figures on hiring within our sector
- For simplicity's sake, someone who is over 21 (minimum wage and the factors vary when employing someone younger).
- The employ won't earn over £844 (around £44,000pa) to avoid needing to account for different NI values (refer to Directgov for more information)
The calculations
I've created a spreadsheet for you which calculates the hourly cost for employees on various salary levels. It should be fairly self explanatory, if it's not, leave a comment and I'll explain as necessary.
Download: Hourly_Rates_Breakdown.xls
Other costs to consider
Once employed, there are a number of other costs that haven't been factored into the spreadsheet:
Downtime
It's unlikely that your employee will be working at full capacity (if they are you should consider employing another!) so it is important factor in some downtime within your calculations.
First Year
Although the process of employment doesn't have to be too costly by using free job sites and pre-written employment contracts, there is still an inherent cost with employing someone.
Think carefully about what you'll need to buy for the new employee -you will need to give them somewhere to work (i.e. a desk), something to use to do the work (i.e. a computer) and importantly somewhere for them to sit!
On-going
As everything in business needs to be broken down to a monetary value so here are some other things that you will need to factor into your calculations:
- Office space -apportion the employee's area of the office's rent
- Stationary -pens, paper and ink all costs
- Telephone
- Training/course fees
- Electricity
- Software and licenses
- Business insurance (if this is your first employee this is likely to increase substantially)
Conclusion
Breaking the salary down to an hourly charge should help give you confidence in being able to afford the additional resource. If you're working flat out at £50ph and finding that work isn't getting done, you can in theory employ someone at around £25,000pa and by keeping them busy still earn £55,594.66 (approximately!) yourself without needing to do any work. I'm sure you can see that by adding to your team and keeping them busy you can very quickly start growing your business.
It's also worth noting, when making a considerable investment such as employing someone, it would be wise to have a contract written specifically for your role.
Update: I've already had some great feedback on the spreadsheet courtesy of Sean Ronan from Active Pixels. He added a new table "Weekly billable hours needed to break even". This breaks the total cost of employing someone down into the weeks they can actually work. As they're unlikely to work 52 weeks a year, it works out the number of weeks based on the other information you entered. Great idea, thanks Sean.