A man walks down the street,
He says, Why am I soft in the middle now?
Why am I soft in the middle?
The rest of my life is so hard!Paul Simon, “You Can Call me Al”
On a previous post I described some “Contracting Nightmares“.
Today, the focus would be on the full half of the glass. The freelancers that killed a dragon for us.
The ground rules are:
- Hire a person you know well, and consider to be a top performer (“Shakel” in Hebrew). Don’t lower the bar for temps.
- Hire a trust worthy individual who shares your core values and understands your “language”.
- Hire him, or her, to work in their field of expertise.
- Hire “over qualified” contractors, for short-term assignments.
[picapp align=”none” wrap=”false” link=”term=dragon&iid=5130299″ src=”http://view.picapp.com/pictures.photo/image/5130299/close-toy-dragon/close-toy-dragon.jpg?size=500&imageId=5130299″ width=”380″ height=”234″ /]
In my experience, only the following combinations work out well
- A Well defined, isolated project
For example “back-porting open source Japanese fonts library from 2.4 to 2.6″.We had to do it for our SSL-VPN products.It was an ugly job, but somebody has to do it. It was not really related to any domain expertise we had inside the company and it was a non trivial task. On the other hand, it was a pretty well-defined project so the contractor could scope it well.
- Hire a contractor for at least 6 months as an integrated team member
For our GUI team we needed an additional developers(see post) but could not find candidates that met our expectations.
We had three hiring experiments with outside help. The one that works well is outsourced from an external company, but has passed all our usual tests. He was not a “compromise” in any way. Moreover, he is an expert in .Net ,so training time was less than a month. Since he came from an external company we got a 12 months commitment.As a result the on-boarding costs are smaller, and we still have a lower financial commitment.
We also examined the company’s background, since in previous attempts we realized the “best” in some companies may not be productive enough in our environment. In other words – contracting is more expensive than in-house, therefore contractors should be just as good as full-time employees , if not better.
One drawback for this method is that the freelancer cannot become an owner of core functionality, since his future is always “at risk”.
The other drawback is that such contractor requires managerial attention,making it suitable to well established teams.
- A research and scoping project
In Cloudshare’s very early days (aka as IT Structures) we wanted to have our first paying customer ASAP. Our feeling was that real customer’s feedback is critical for our success. We only had two developers at the time, so we hired I.Z to help us with building a virtualized networking architecture.
IZ was an experienced team leader and architect that lead two complex networking projects in his previous roles. He was in between jobs, as he was considering his next career steps (being both a great singer + a talented coder).
We were considering which remote console protocol to use ( VNC\RDP\ICA) and needed objective results showing how well each worked over different latency and packet lost conditions. To our surprise, there was not updated research available.
IZ came out with objective and clear results in a new territory’s for us in which he had domain expertise. Till this day our remote access performance is one of our key advantages over other solutions in the market.
I trusted him, so we could work on time and materials base. He trusted us that we will not nickel-and-dime him. I always prefer to pay by the hour, as scoping is hard for complicated projects.Both sides feel wrong if the estimate is wrong for a fixed costs project.
To conclude – contracting can work well, but it is not a silver bullet. Chances for success improve if some basic rules are followed.
- 5 Red Flags You Shouldn’t Ignore When Hiring Remote Employees (businessinsider.com)
- Why I Don’t Like Time & Materials Gigs (T&M). (jarrodloidl.blogspot.com)