[LRUG] Hiring a pair rather than an individual contractor

Thayer Prime thayer at team-prime.com
Wed Dec 18 05:58:49 PST 2013


My brief 2p as I'm a bit snowed atm (but happy to have a call with anyone
seriously going down this route):

Never had a client request it, fairly sure it'd be a hard sell unless the
client already knew you and respected your work and working methods enough
to trust you bringing a junior onto their code if they wanted a (senior)
dive-straight-in contractor. Also, I know we know the benefits that they
might reap, but to them it's taking on someone that you're training on
their time, extra liability and potentially you adding a mark up on
(whether you actually are or not).

I think it could work with the right client relationship, but could most
likely be be a can of worms from a liability point of view. Is that person
contracted by the company, or by you? And if you, you'll need to get
specialist insurance which can be rather spendy. If by them, do they have
capacity to support any potential errors/fixes?

HOWEVER, on a more positive note, I've seen this model work well in an
agency I know, where they always send out teams in multiples of two, and at
least one of the pairs is always a junior who's learning and picking off
the lower hanging fruit. But that's an agency model where people have been
brought in to complete whole projects (or offsite) rather than being thrown
onto something to try and make it happen faster and/or on time or because
not enough perm resource.

Let us know how it goes if you do it though, be interested to hear.



On Wed, Dec 18, 2013 at 12:54 PM, Jasim A Basheer <jasim.ab at gmail.com>wrote:

> Hi Tim,
>
> I'm a developer-partner at Nilenso Software (http://nilenso.com/). We are
> an employee-owned software co-operative based out of Bangalore, India. Most
> of our work is remote and our team sizes are almost always even numbered.
>
> Before we start an engagement with a client, we make it explicit that we
> pair program, do TDD, and follow agile. We charge a blended rate for our
> pairs - this accounts for the difference in experience level. We don't have
> to sell pairing to clients who have previous experience in an agile/extreme
> environment since they already understand the value it brings.
>
> One of our recent work was a rescue project - the codebase was a ball of
> mud, the devs who built it thought writing tests was a waste of time, and
> the lack of any kind of encapsulation was described to be 'functional'. We
> had to rebuild the entire system from scratch after a failed and costly
> attempt at reusing the existing codebase. Having learned about the
> importance of code quality through an expensive experience, this client was
> particularly happy about the XP practices that we followed.
>
> We haven't had much difficulty even with clients who have little prior
> experience building software for the web. Most of our work comes from one
> happy client referring another. This ensures that there is a fair amount of
> trust in the relationship that we will do the right thing for their
> business.
>
> As to our pairing practice, we pair when it makes sense (which is most of
> the time). We also use our judgement to solo on things that are either rote
> work, or complex spikes where it is better to think independently and
> discuss later. Most of this is transparent to the client, but is never made
> a big deal out of.
>
> It also helps that we discuss our velocity frequently with the client so
> that they have a sense of the progress we are making. They also appreciate
> the fact that at least two people who share the same context are involved
> during discussions. Everyone is happy as long as we are delivering value
> and it should be apparent to the client in a couple of iterations.
>
> However as Louis mentioned, we work mostly with startups who are already
> happy to do remote. Our experience might not be representative of
> conventional organisations with outdated people policies.
>
>
>
> On Wed, Dec 18, 2013 at 5:38 PM, Louis Goff-Beardsley <louisror at gmail.com>wrote:
>
>> ·         From a recruitment perspective I’d say in 2013 around 20% of
>> the contract requirements I’ve had were from companies which would be open
>> to at least discussing this..
>>
>> ·         I’m not sure if you could negotiate a day rate for both
>> developers high enough to make it worthwhile until you’ve proved that its
>> more effective than one remote developer. Might have to take a bit of a hit
>> in the first couple of contracts until the junior developer is productive.
>>
>> ·         The companies which would go for this are open minded teams
>> which don’t have a problem with remote workers, more established teams
>> which typically hire through HR departments and look for onsite developers
>> are going to take issue.
>>
>> ·         In the last year I have had success in hiring pairs of
>> developers into companies, although in both cases it was pairs of senior
>> remote developers who had long histories of working together.
>>
>> ·         Might be companies are interested in this for hiring senior
>> perm remote developers with a junior pair located near to them (rather than
>> contract, as its more of an investment for the company).
>>
>> ·         Merry Christmas.
>>
>>
>>
>> Best
>>
>> *Louis Goff-Beardsley*
>>
>>
>>
>> *“You know I'm not a fan of recruitment consultants, right? @LouisRoR is
>> good. You should talk to him if you're looking for Ruby work or staff”  **Paul
>> Robinson – Senior Ruby-on-Rails Developer & CTO - @P7R*<https://twitter.com/p7r/status/291537402084864001>
>>
>> http://goo.gl/WvuTj
>>
>> [Louis Goff-Beardsley]
>>
>>    > Ultra-Specialised Independent Ruby-on-Rails Recruitment.
>>
>>    > Software Sales, Business Development & AC Acquisition for the RoR
>> community.
>>
>>    > LinkedIn:  http://www.linkedin.com/in/louisbeardsley
>>
>>    > Skype: LouisGB1 - Googletalk/Jabba: LouisRoR at gmail.com
>>
>>    > Email: LouisRoR at gmail.com
>>
>>    > Mobile:  07449 324 851 ¦ Land Line: 01183 xxx xxx
>>
>>    > Twitter:@LouisRoR <https://twitter.com/#!/LouisRoR> – Below is
>> ASCII Art that will go totally wrong in plain text :(
>>
>> *__________         __ __           __________               *
>>
>> *\______   \_____  |__|  |   ______ \______   \ ____   ____  *
>>
>> * |       _/\__  \ |  |  |  /  ___/  |       _// __ \_/ ___\ *
>>
>> * |    |   \ / __ \|  |  |__\___ \   |    |   \  ___/\  \___ *
>>
>> * |____|_  /(____  /__|____/____  >  |____|_  /\___  >\___  >*
>>
>> *        \/      \/             \/          \/     \/     \/ *
>>
>>
>>
>> IRC: LouisRoR - irc.freenode.org #LRUG, #NWRUG, #ruby, #rubyonrails
>>
>>
>>
>>
>>
>> [image: Description: Description: Description: Description: Description:
>> Description: Description: Description: Description:
>> http://download.skype.com/share/skypebuttons/buttons/add_green_transparent_118x23.gif][image:
>> Description: Description: Description: Description: Description:
>> Description:
>> file:///C:/Documents%20and%20Settings/louis.beardsley/Desktop/LouisRoRTag.JPG]<https://twitter.com/#!/LouisRoR>
>>
>>
>>
>>
>>
>> *“I was speaking to [Senior Ruby Developer] recently about a variety of
>> things and he mentioned your name. In fact he recommended you as a
>> recruiter. *Actually* recommended too, not as in "he's not as evil as the
>> rest", but as in "you really should speak to this guy first"”*
>>
>>
>>
>>
>>
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. This email (and any attachment) may be confidential and legally
>> privileged. Access and/or use by others is unauthorised and may be
>> unlawful. This message contains confidential information and is intended
>> only for the individual named. Contents of this email should not be
>> disseminated, distributed or copied.
>>
>>
>>
>> *From:* chat-bounces at lists.lrug.org [mailto:chat-bounces at lists.lrug.org] *On
>> Behalf Of *Tim Cowlishaw
>> *Sent:* 17 December 2013 12:20
>> *To:* Ruby Group
>> *Subject:* [LRUG] Hiring a pair rather than an individual contractor
>>
>>
>>
>> Inspired by Ali's 'Technical  Intern' job ad, I've got a few questions
>> for those of you who hire independent contract engineers!
>>
>>
>>
>> Some context: I've thought a great deal about stsarting an initiative
>> like Ali's, whereby I take on a more junior engineer to pair with me on
>> contract work. Being a freelancer is an insane privilege, and I've thought
>> it'd be a great opportunity to both help train people starting out on a
>> career in software, as well as encouraging more people to work
>> independently who might not otherwise consider it, or have the opportunity
>> to do so.
>>
>>
>>
>> With that in mind, I'd be very interested to know, from those of you who
>> hire contractors, whether:
>>
>>
>>
>> (1) You'd be open to the idea of hiring a mixed-ability pair in place of
>> an individual engineer? Would such an arrangement work within the structure
>> of your organization?
>>
>> (2) You'd perceive this is an arrangement with potential productivity
>> gains (or just as a deadweight loss since the more experienced engineer
>> would spend some time coaching the less experienced one). What sort of
>> multiplier would you be prepared to attach to the cost of a single engineer
>> for such an arrangement?
>>
>>
>> Cheers,
>>
>> Tim.
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>
> Best,
> --
> Jasim A Basheer -- http://nilenso.com
> http://twitter.com/jasim_ab
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>


-- 
Thayer Prime
--------------------
CEO & Founder
Team Prime Ltd
http://www.team-prime.com

http://www.linkedin.com/in/thayerprime
http://www.thayerprime.com
@Thayer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20131218/8446fb49/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1918 bytes
Desc: not available
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20131218/8446fb49/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 1401 bytes
Desc: not available
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20131218/8446fb49/attachment.jpg>


More information about the Chat mailing list