

Keeping and Recruiting Hackers as a Non-Hacker - LPTS

We've heard a lot from hackers with a lot of anger or derision towards non hackers with business plans.  I happen to be a non-hacker who has recruited one dev to do my database and web design.  I am seeking one more hacker to do the iPhone portion of my project.<p>So, you can imagine how horrified I was to read all the people who are just dripping with contempt for people like me.  I would like advice on recruiting a hacker and keeping my hackers happy.  For hackers who have had successful startups with non-hacking partners, what worked?  Rather then hearing about how bad and infuriating these relationships are, I would like to hear a different perspective about how they can work well from a basis of mutual respect.  If you had a bad hacker-nonhacker partnership, how could the non-hacking partner have done better?<p>Also, how can I refine my approach when approaching and recruiting a hacker?
======
aggieben
I think the most important things, generally, are that everyone is able to
bring something to the table, everyone knows what everyone else is bringing to
the table, and everyone is rewarded in some reasonable proportion for what
they bring to the table.

Mutual respect is a very important ingredient, and the best way for the
business-oriented individual to win respect from the hacker is to prove that
what he brings to the table has value. Part of this is educating the hacker on
why your assets are valuable.

What drives us crazy about the stereotype that you see discussed here is the
perception that all or most of the value will be brought to the table by the
hacker, while most of the reward will be accrued by the other guy. Emails like
"I have an idea and a business plan all worked out, I just need a hacker" are
translated as "I want to pay you to build something that will glorify and
enrich me". You want to instead say something that will be translated as "I
need a partner with complimentary skills to my own so that we may achieve
_______ together!" and insert "glory and wealth" or "social change" or "a
solution to X problem", or whatever floats your boat.

So, you ask, what's something I could bring to the table that hackers would
find valuable? Characterize it this way: all the things hackers don't want to
do but must be done to run a business. Law expertise, especially in taxes and
intellectual property rights, is extremely valuable. Expertise and experience
in dealing with state and federal regulators is another valuable asset. You
need something specific to point to that can be "valuated" in some qualitative
way (quantitative is even better).

A business plan does not carry any value, unless you can point to specific
things in that plan that will help you achieve success (i.e., if evidence of
the valuable things I listed above are in the business plan, then maybe your
approach should be "read my business plan from the perspective of a partner.
I'd like your feedback"). Any doofus can write out some pages explaining what
they want to do and hand-wave about how it's going to happen. It takes someone
with skill and good judgement to write a plan that references market data
(perhaps even with results of hiring a market research firm), a viable
marketing strategy with a rationale based on data, a strategy for growth made
on reasonable assumptions that should be based on data, leads on funding,
leads on talent recruiting, relevant legal issues and proposals for dealing
with them, etc, etc, etc.

Perhaps you don't have the skill to do even that. Then prove that you have the
connections and funding to assemble the team that does have the skills needed
to make your venture happen.

Hopefully this helps. I could go on, but this is already a long post.

~~~
LPTS
Very helpful. In our case, our company exists to solve a problem. The problem
is a combination of a medical and design problem. (I don't want to give away
anything). Before I found a hacker, I did a lot of the design work, and have
been accruing medical information on my project for months.

Our strategy is for the hackers to create a demo and backend to achieve my
design objectives while I flesh out the rest of the medical research.

Armed with a demo and medical research, I will be able to prove to potential
partners and angels that there is a big medical problem, that design can solve
it, that much research, when considered together, provides a picture of haw to
solve the problem, and that I solved it. Then I will find a partner for
business aspects and look for funding.

One thing I'm definitely not doing is trying to get fat on the work of others.
I don't want to say that I don't care about money, but my motivation is
entirely solving this problem. I need hackers who want to be partners and are
excited to grow a company they have a good stake in.

Thanks for typing so much, it's very helpful and constructive.

~~~
aggieben
At the risk of sounding too critical (which isn't the point), allow me to help
you hear yourself:

    
    
      Our strategy is for the hackers to create a demo and 
      backend to achieve my design objectives while I flesh out 
      the rest of the medical research.
    

This is exactly the kind of thing I want to warn you against. If the hackers
are your _partners_ (as they should be), then "my" design has to become "our"
design. Invite your hackers to make suggestions and tweak your design. Have a
whiteboard fight (what's better than a whiteboard fight?). Take their
suggestions seriously, and if you disagree, don't be dismissive: try to
convince them why they're wrong; get buy-in. If you can't get buy-in, then
either your design is broken, or these aren't the hackers you're looking for.
Then once you're all on the same page, turn them loose on the implementation
while you get busy with your medical research. To my mind, that is a better
way to divide labor without losing the sense of partnership.

    
    
      Armed with a demo and medical research, I will be able to 
      prove to potential partners and angels that there is a 
      big medical problem, that design can solve it, that much 
      research, when considered together, provides a picture of 
      haw to solve the problem, and that I solved it. Then I 
      will find a partner for business aspects and look for 
      funding.
    

This sounds great!...except, make _...that I solved it..._ into _...that our
team solved it..._ \- because once you take on partners, you're _partners_.
Founders really have to be able to swallow some pride and share ownership to
keep everyone on board. You may be the leader, but especially at this stage,
being the leader shouldn't mean a whole lot other than a job description.

Even in your language you have to be careful about the messages you're sending
to your partners to make sure that they are, indeed, _partners_. When you take
on _partners_ , your vision has to become _their_ vision, and you have to be
willing to let your vision evolve with new blood and new ideas (obviously, you
don't want to loose the essence of the business...)

Consider the result of a subtle change in language:

    
    
      Armed with a demo and medical research, I will be able to 
      prove to potential partners and angels that there is a 
      big medical problem, that design can solve it, that much 
      research, when considered together, provides a picture of 
      haw to solve the problem, and that our team solved it. 
      Then I will find a partner for business aspects and look 
      for funding.
    
    

This is much better, because it's evident that your hackers are your
_partners_ , and that the things you're doing for the venture are valuable
(performing a demo, persuade partners and angels, find funding, find the
additional talent you need, and medical research skills).

Again, I hope you find this helpful. This is all stuff I've been reflecting on
a lot lately, so it just comes pouring out of my head through my fingertips.

~~~
timr
Oh man...you hit the nail on the head.

I made the mistake of joining a small company where the founder did the exact
opposite of everything you have described: the product was _his_ , the plan
was _his_ , and the design meetings inevitably degenerated into lectures on
why we (his employees) didn't understand the market we were in, and therefore
weren't qualified to do anything but follow his guidance. There were certainly
no whiteboard sessions (after all, why would you need a whiteboard, when you
can just describe what's going to happen using a powerpoint presentation?)

The result was terrible morale, and a bad product. Where we _should_ have been
reacting to the demands of the market that we were in, we were plodding along
a pre-determined path to failure, without the ability to change strategy or
tactic.

As a result, I now have a well-developed filter for people who have this
tendency, and I avoid them like the plague. Comments like _"I'll flesh out the
design"_ immediately send me running.

------
gruseom
_you can imagine how horrified I was to read all the people who are just
dripping with contempt for people like me_

Don't take it personally. It's a reaction against a tendency in the industry
to undervalue hackers and treat them as interchangeable drones. Because good
hackers are rare and what they do is incredibly creative, this tendency can't
last, so eventually it (and the emotional reaction against it) will pass.
(Some of it's also just immaturity. Also some programmers are themselves
arrogant - avoid these. Everything we're saying about respect cuts both ways.
Besides, they're usually not very good.)

Pay attention to the comments here (aggieben's replies to your questions are
worth their weight in gold) and change your thinking accordingly, and you'll
be in a better position.

Speaking for myself, what I would want is: a significant share of ownership;
an interesting and challenging problem; freedom to work in the best way I know
(including freedom to choose my tools and find the best designs); full
participation in important decisions; complete mutual respect; the feeling
that it is fun to work together (this is a chemistry thing that has nothing to
do with stupid motivational tricks); the kind of team where everybody puts
their ideas on the table and hammers at them until the best one is agreed on,
and nobody cares (or even remembers) who contributed what.

It absolutely has to be "we". I would always give credit to the person with
the original idea and expertise (you, in this case), but if I ever felt I was
working _for_ that person or that they regarded me as "their" hacker, it would
gnaw at me until it ruined my feeling about the thing. It's hard to explain
how deeply this goes. I don't want higher status than anybody else; conversely
the thought of being pegged at a lower status is intolerable, partly because
it's degrading but more importantly because such structures _inhibit
creativity_ and that is what I care about most.

------
ALee
As a non-hacker on a team with two exceptional hackers, I would recommend the
following startup advice:

1) DO have incentives that reflect contribution- all of us have equity split
evenly, everyone brings something to the table; these guys will later also
help determine the direction of future hires (and I trust their abilities to
do so)

2) DO be more open than usual- the difference between bullies and real
partners is being able to include everyone in the process, it makes everyone
feel like they're working toward the goal. Definitely make sure that you're
adding value and let others know of what you're doing and say why. Include
people in meetings if they want, usually, your biz dev meeting are so boring
that your partners don't want to sit in (they want to be there for the
decision, but not for the meetings before it).

3) DO NOT micromanage- I think Sam Altman said this in an interview that the
greatest startups are where you have a bunch of people doing amazing things
all at the same time and they're driving to a goal. Definitely set milestones
for each other, but do not question when your hacker takes time off to play
Guitar Hero

4) DO make it about the company- You're building a company and that's the
bigger goal, it's not about you, it's about the company. So, stick to
milestones, stick to atomic goals, and go hard down the path to victory.

5) DO make the environment easier to hack- Your job is to get a product out,
so that includes some management and creativity, while also doing the other
tasks that distract (biz dev, etc.)

6) DO learn to hack yourself (not for the business, but for yourself)- I'm
learning Python and it gives you a better perspective of what your hacker
partners are doing. Don't hack for your business, choose some problems that
you want to tackle yourself and do those on the side.

As to hacker recruitment, hire slow and make sure that person can work with
your folks. It's all about that culture, so it starts with the list above and
making a hacker-friendly culture. It's no surprise that Google and Facebook
are obsessive about that.

------
pg
The hard part (unsolved as far as I know) is for a non-hacker to find good
hackers. But assuming you can, the key to hiring and keeping them would be to
give them freedom to work the way they want to, including letting them have
their way if they feel strongly about design decisions. Since we've assumed
you've got good hackers, their design choices will tend to be right, so this
is a safe move.

~~~
wumi
what about the Auctomatic guys?

~~~
ALee
They also did try to learn and hack:

<http://blog.harjtaggar.com/?p=37>

------
webwright
Great question (and approach). I'm _kinda_ a non-hacker (started as a
designer, now do a bit of front-end coding, etc).

The mutual respect thing (as aggieben says) is huge. The best way to approach
this is to put in the line what you're going to do. How are you going to
contibute AT LEAST your fair share in the early stages of the project. Not
"When we're ready to talk to VCs, I'm the guy!" or "I'll talk to lawyers so
you don't have to!", but "Here's the stuff I'm going to do EVERY DAY while you
code."

Hopefully you have a good story to tell there. I've found that most people
(who aren't hackers or designers) really DON'T, when it comes right down to
it... But every business is different.

If you can't commit an equal share of the work (which is likely-- project
management is not a fulltime job for a team of 2-3-- and it's honestly a
burden for good hackers on teams of this size), then put something else on the
line. Money is a good start.

If you don't have money and you don't have "buidling" skills, then I'm hard-
pressed to understand how you could motivate "builders", other than the
promise of "If you guys manage to build something great, I'll help make it
successful".

The big problem is that it's hard to build something great (which is why a lot
of people advocate for bring in biz ppl when and if you manage to pull that
off).

------
pchristensen
Sounds like you definitely are bringing something to the table. Emphasize your
demo and domain knowledge (from other comments:

"Once our demo is working, we will decide together how to go forward, but I
probably will be focused on design and medical aspects"

"A large aspect of our company will include components like creating a medical
protocol, clinical trials and medical demographics"

Also, as CEO you probably have the final say on decisions, so _make sure you
make smart decisions_. In order to make smart decisions, you need to know the
costs and consequences of technical decisions, and you need the hacker to give
you these.

You need to have enough technical knowledge to assess what you're given. For
instance, how much do you know about the iPhone, the new SDK, the background
processing limitation, and the possibility of Andriod looming in the distance?
If you can't have a discussion about that, you're going to have a hard time
hiring a hacker that can do that work. Rule of thumb: you can't hire someone
if you can't have a long conversation about what you want them to do.

------
mixmax
I've been there, and have had great experiences with hackers. I'm a non-hacker
myself. What I found to be succesful was:

1) Be intellectually curious. If you are interested in what a hacker does
he'll like you. If you understand and learn what he does he will respect you.

2) Treat hackers on an equal footing with the guys that wear ties. Hackers
should decide technical stuff - not people with ties.

3) Talk straight - hackers seem to hate politics and hidden agendas, and often
aren't very good at them.

4) Keep hackers informed of all aspects of the business. This partly relates
to 4) but a sidepoint is that they like to learn. I know at least one hacker
that now knows a decent amount of marketing ;-)

5) be fair and play nice. Keep the dirty side of the business out of the way
of the hackers. This relates to 2), 3), and 4)

6) give credit where credit is due.

------
dusklight
If I see that you are less intelligent than me, and do less work than me, but
you make more money than me, then well what do you expect?

I think fundamentally it is a matter of respect. If you respect the hacker,
the hacker will respect you.

I think the easiest thing to do is to demonstrate that you have valuable non-
hacker skills that contribute just as much to the project as the hacker does.

It is also a matter of trust. If you trust your hackers, they will trust you.
A big problem for you, however, is that it will be much harder for you to
figure out which hackers are trustworthy without hacker skills.

------
noodle
i'm talking from the hacker standpoint.

if i would leave, it would be because the non-hacker in charge of the
"business aspects" thought they meant that they were in charge of the
direction of the business as a whole. this would manifest itself as not
taking/considering the hacker's advice on things that the hacker knows better,
not including the hacker on important decisions, etc.. if you're getting a
hacker or two as a co-founder, they're a co-founder, not a low-level employee.

if you want a good environment and recruits, make sure that the work style is
open and full of communication on important issues, and there are spheres of
influence. for example, hackers know code. from a business standpoint, you can
suggest features and such, but the hackers should get the final input on what
happens with the code and therefore the product. and vice versa, hackers
should have input on the business aspect if you're the business person, and
you should take their input seriously, but in the end, you're the business
person and you have the final say. the spheres shouldn't necessarily be
exactly like that, but they should be well defined and stuck to, imo.

my $0.02.

~~~
LPTS
Thanks!

I'm not actually the business person either. I worked in medicine, and some
constantly stupid things I see make me angry. I think I can design a product
to take the stupid out of the processes I saw working in medicine. I also
think that my solution to the problem I see might work as a platform for other
health care innovations. Once our demo is working, we will decide together how
to go forward, but I probably will be focused on design and medical aspects
and hire a person for the business aspects too. Because our company is
basically applying design and tech to medical problems, this means I will be
CEO, so our focus stays there. However, my style includes being aware of my
limitations, and delegating 100% of tech to the hacker, who wants to grow into
CTO. A large aspect of our company will include components like creating a
medical protocol, clinical trials and medical demographics, with tech being
about 30-45% of what we need, so we may be substantially different then most Y
startups in that respect.

I'm working on setting up a wiki to help organize our information and
communication and preserve spheres of influence. I used to do some minor
hacking as a kid back in the day, but just enough to have some respect for
hackers and know I'm (way) out of my league if I want it done right.

~~~
noodle
i'm working on a medical-related startup myself ;)

~~~
LPTS
Fun. I hope we are not competing. :)

Out of curiosity, are you working on implementing your own idea or did a non-
tech person contribute the idea you are working on?

~~~
noodle
non-tech person came to me with the idea and i accepted based on the idea,
market feasibility, business model, and the work load.

for reference, i don't think we're working together. but i really hope we're
not competing, its a fairly stagnant, old market and i don't want to have a
new tough competitor :(

~~~
LPTS
There are certainly plenty of stagnant old markets in the medical industry.

~~~
noodle
and lots of opportunity for startups to grow and profit, is what i like to
tell myself.

------
tracyreed
The mere fact that you read ycombinator and even think of asking such a
question surely puts you light-years ahead of the meat-heads being railed
against. I wish I knew something about iPhone development and were looking for
a job because you are likely the kind of person I would want to work for. I
wish my boss read ycombinator!

------
paul_reiners
Read "Smart & Gets Things Done" by Joel Spolsky:

<http://www.joelonsoftware.com/items/2007/06/05.html>

~~~
LPTS
I ordered it. It's on it's way. Thanks for the suggestion!

~~~
shiranaihito
Judging by Joel's articles, he at least claims to hire only the best of the
best of the.. you get the idea.

Depending on how challenging your software is to develop, you might want to
set the bar a bit lower (than the _seriouslyfreakingabsolute_ best).

A genuinely good developer should be more than enough for most tasks, but
maybe your product can't be built by merely good developers.

Hackers seem to be quite idealistic too. They would probably like the idea of
doing something "good".

Maybe even something to make the world a better place - and who knows, maybe
your medical thingie qualifies! (Sorry, I'm feeling a bit playful here, and
right now I can't see the post where you explained things)

What can you offer that would lure hackers to your venture?

How about offering to get them hot chicks? Moderately hot ones? .. only
slightly retina-burning chicks?

At first, I thought of suggesting you respect your "hackers" as fellow human
beings, and make sure they find you respectable too. I guess that's my two
cents after all.

------
icky
The same way a non-expert should hire a good sailor, mercenary, sommelier,
writer, butler, lawyer, guide, pilot, surgeon, mechanic, etc.

Find out who's regarded as knowledgeable and effective within their fields
(preferably by people who know firsthand), be prepared to pay them well, tell
them what you want done, and stay out of their way. Expect a certain measure
of mild disdain when you clumsily tread on their domain, and listen to what
they have to say.

------
wumi
I think this is why it's so valuable to know and be friends before the
relationship of "non-hacker" and "hacker" begins.

then, everybody will most likely be on a equal footing and not be worried
about revenue, equity, and such.

btw, all hackers do not do the same amount/quality of work, so will we now
institute a weighted system of value for hacker vs. hacker as many people here
have for hacker vs. non-hacker

------
chris123
Helpful thread for a business co-founder such as myself. While the goal has
always been a "co" relationship, this has helped me think about and
communicate that.

------
craig-faber
Thanks, LPTS, for asking that. I'm in a similar possition. And thanks for the
replies, especially aggieben.

------
monkkbfr
You can start by not calling them 'hackers'. Only hackers get to call hackers
hackers.

~~~
sah
The last thing we need is more words that work like that.

~~~
Jesin
Yes, really. I hate the idea of words that only a select group can use.

