Lessons Learned: The First Hire
In February we made our first full-time hire with Dan McClain. He came on board at a time when our company was not very stable but we needed to grow to accomodate the larger contracts we wanted. I want to discuss the risks and benefits on making the first hire.
You will lose money
One of the first things you learn about making your first full-time hire beyond the founders is that you will most likely lose money. Which is kind of backwards because the entire point of hiring is so more money can be made. Brian Kaney at Vermonster told me this after we had already hired Dan. I was accustomed to balancing 3 people’s salaries and now a 4th was in play and we didn’t have any extra money coming in. So we the partners had to take less money. After Brian told me that Vermonster had similar growing pains it made me feel better. I’ve since spoken with others that have said the same. I suspect this is partly due to my inexperience as a first time business owner, if I ever start another company I can plan better for this. It is also due simply to the fact that we didn’t have any extra work coming in and were now dividing the money 4 ways instead of 3. The employees have to be paid, the partners don’t. I took on the brunt of the risk and actually just started paying myself for the first time in 2012 at the start of August. It was totally worth it.
Be picky who you hire
I’d like to say that Dan hired himself rather than we hired him. He was somewhat new to the Boston Ruby community but was going out of his way to make himself known. He took the initiative to introduce himself to me and wanted to make contributions to the BostonRB website. He developed a feature, made a pull request, and I gave him feedback. What impressed me was how quickly he adapted to the feedback I gave him. This told me one thing: Dan was a very quick learner. Before DockYard was even looking to hire Dan contacted me and expressed interest in being hired. When it came time for us to make a hire he was the first name that came to mind. I think the lesson to learn here is if you want to work somewhere, don’t wait for them to hire for your talent. Contact them, let them know you are interested even if they don’t have anything available. When the time comes they’ll remember you.
Make full-time hires, don’t contract to hire
We hired Dan on a contract-to-hire basis. The idea at the time was to have Dan on a “trial” period, test him out, see how he fit. I didn’t like how this went and I don’t think it was fair to Dan to hire this way. If you are hiring for a position, hire full-time. If things aren’t working out you are always within your rights to let the person go. Whenever you are hiring someone there is always the risk that it won’t work out.
Be mindful of taxes, benefits, salaries, etc…
Now that we had our first full-time on board we had to standardize everything. The best way to describe how I was handling all of this up until our first hire is “half-assed”. I was the only one living in Massachusetts where it was required to have health-care so I was using the MA Health Connector (a terrible service), we were handling time-off as “whenever you want” which of course doesn’t fly well as you scale, and taxes were a mystery to me. Let’s break each one down to see what we’ve done:
I went for the best health-care I could find for employees. When it comes down to it we’re only talking about the difference of a few hundred dollars each month. If we go under because of this cost then I deserve to lose my company. If one of my employees cannot see the doctor they need to because of sub-standard health coverage I run the risk that they will not be back to work as quickly as they would otherwise. This risk costs far more than the extra $$$ for the better plans.
DockYard is currently covering 3/4 of the healthcare and I hope to bring that up to 100% in 2013.
We’re doing 3 weeks of paid vacation per year. Employees can take off two weeks at a time. I am also experimenting with how to handle overtime. Because we’re doing client work and sometimes deadlines have to be met I’ve told everyone that there will be a day when they get Lumberged. I’m going to be the guy that will have to ask people to work over a weekend, I don’t like it and I would be pissed if I was on the receiving end of that. So, to compensate we’ll offer an added vacation day in exchange for each weekend day. Of course employees can say “no” to working on the weekend. I understand that there are sometimes plans that are made well in advance.
This is something we have struggled with. Everyone has always been paid but sometimes it has been a day late because of mistakes on my part. Originally I was cutting checks to everyone and mailing them myself. I would manually enter the data into QuickBooks for our accountant. This sucks. I eventually got it down to where it would only take me 5 minutes to do but for a while it was pretty disruptive. We eventually moved over Direct Deposit through QuickBooks. This was much better, and quicker. If you are not doing Direct Deposit you should highly consider it.
We’ve recently moved from QuickBooks to Less Accounting and Sure Payroll. QuickBooks blows. We only used it because our accountant suggested it. Here is some advice: don’t let your accountant make software decisions for you, especially if you are a software consultancy. Our accountant is awesome, but QuickBooks is not. We lost an entire month of payroll, tax, and vendor payment data because a QuickBooks file corrupted. Never again.
One huge mistake I made even before hiring Dan but continued into a month after he was hired was not withholding taxes from paychecks. We were losing money after our first quarterly taxes were paid and I couldn’t figure it out. In retrospect it is pretty obvious what I should have been doing but keep in mind this was my first company, I never had to deal with this before, and simply fucked up. Things turned around after I corrected this. I didn’t ask for employees to payback the money. I’m not trying to push this idea that I’m a “good guy” but this was my screw up and I took the hit.
Also, pay people well. “Industry average salary” will earn you “industry average employees”. If it is well known that you are paying high salaries you will attract talented people. Talented people will more than make up the difference.
Hiring ain’t easy
I’ve heard the term “peak people” thrown around a lot recently. It refers to the huge talent shortage that the tech industry has. It’s true, it exists. You know why? Because everybody wants to hire top talent and nobody wants to train. I think it is pretty bullshit for companies to not train developers. Personally I would rather hire a developer that requires training that is a quick learner than hire a mid-level dev that is set in his/her ways. We got lucky with Dan, he required very little ramping up. Mostly just a push here and a push there. We’ve recently hired Doug Yun as a trainee. I told Doug that we are experimenting with him, I want to establish a training program at DockYard. So there will be ups and downs to it as we establish a playbook. I realize we run the risk of devs training up, then bouncing out. There are ways to address this. We can offer employment term benefits. If you are at DockYard for a year your salary will increase by X% every year. Let them know what the path for advancement is. We need to get better at this and it is something I want to focus on over the next few months. I would love to hear feedback and how others are approaching this.
It pushes you to make things happen
The best benefit of hiring is that it personally motivates me to grow the company. When it was just the co-founders we always had the fallback that a payroll period could be skipped. As I mentioned earlier that is not a choice when you have employees. Money must come in, people must get paid. Personally I have found this to be a good motivator for growing DockYard.
Share your experiences!
If you agree/disagree with anything I said, have a different perspective, or any general advice I’d love to hear it.