Hacker News new | past | comments | ask | show | jobs | submit login
Keeping and Recruiting Hackers as a Non-Hacker
21 points by LPTS on April 4, 2008 | hide | past | favorite | 39 comments
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.

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?

Also, how can I refine my approach when approaching and recruiting a hacker?




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.


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.


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.


what about the Auctomatic guys?


They also did try to learn and hack:

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


They got all their hackers through YC.


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).


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.


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.


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.


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.


Please don't worry about sounding too critical. Just be honest. This is much more helpful with the true critical parts not obscured by worry about hurt feelings.

That "I solved it" is painful. That is very obvious. Gotta get rid of that mindset.

I used the term "Design objectives" from a medical protocol standpoint. We're working together closely to translate the protocol design (which I have objectives for, in the form of information flowing between components of the system, and providing certain outputs and inputs to patients and doctors) into technical designs (which the tech guys make). We are tracking areas where we disagree as open questions on a wiki, and we revisit them once we've done more research and thinking. I'm not giving them pages of screenshots and saying make it work, I'm saying the medical system must move information like this, and that creates a technical puzzle as part of a medical puzzle. I don't override them and I encourage them to be as critical and creative as possible.

Thanks again for your comments. That "I" thing is something I will watch carefully for and is good to hear.


Hi LPTS, I think we should talk more. Are you going to be at startup school?


We should talk more. I'm not going to be at start-up school though. I live in Washington and can't make it. I'm thinking about shooting for the next one (if it wouldn't be a distraction from the booming business development and R&D of my prosperous company by then ;P ).

EDIT: I guess to talk more you probably need this. lifepod technology systems (as one word) at the gmail.com one.


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.


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.


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.


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.


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.


When approaching hackers, perhaps you should present yourself as someone with expert domain knowledge, as opposed to someone with a business plan. That's probably more enticing to a hacker; it says "I know an interesting problem that we can solve" as opposed to "I know how we can make money."

Caveat: I am a graduate student, not a startup person.


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


I'm a medical doctor looking to join a healthcare startup. Not interested in residency right now; interested in rolling the dice. Shoot me back if interested.


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?


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 :(


If you are competing, you could consider finding some way to merge and work together on it. On the other hand, maybe not. It's just something to consider just in case.


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


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


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!


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

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


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


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.


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.


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


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.


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


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


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


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


Computer programmers, then?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: