Another point I'd add/emphasize is: don't treat engineers as stupid. This includes downplaying complexity and the amount of work involved, but also not being serious about the business side of things.

The worst thing to say is "Just build it, and let me worry about selling it", or "Everyone will be excited about this, trust me". To an engineer this just sounds like you haven't done any actual work yet, besides thinking of the idea, and you are unlikely to do anything, ever. If you expect a coder to build something for you, have a plan of work that you will contribute (even though it will change).

Also: "Anyone who hasn't spent a whole night awake writing blog posts, calling Japanese leads and obsessing over traffic numbers will probably view the product as the most important thing in the enterprise."

Should it be "will probably not view the product..."? And what about partnerships a being bad thing to mention? This would be helpful to me too, to know more about what to watch for :)

> Should it be "will probably not view the product..."?

I don't think so; the idea that the author is attempting to convey is that people who haven't spent a lot of time working on the parts of a business that aren't building the product won't realise how important those other things are. Admittedly it could have been explained a lot more clearly—I had to go back and read that sentence over too.

Ahh, I get it now :) I thought the sentence was about why this specific product is the most important out all products out there. And it's actually comparing the product to other things involved in making it, like markering and customer support.

Thanks for picking that up, rewritten to hopefully be easier to parse.

Thanks! Good idea. I have heard both of those things before and it put me off pretty badly.

WRT partnerships...

They often take forever to sign up, even longer to integrate, and frequently don't produce any results because one partner backs out.

For every successful partnership (erm...) I can quote you three partnership development projects from my own experience that bombed without seeing the light of day.

Maybe I'm just scarred by some bad experiences :-)

If you're the first technical person in a company, you're either a founder/co-founder or an chump. I simply not only refuse to answer emails from "business guys" who "came up with the next great idea and are looking for an engineer to build it", but I also will not even consider funded start-ups that don't have technical co-founders: it's safe to say, that they will lack true technical leadership and their engineer team will be composed not of people who wish to work in a start-up, but of people who have nowhere else to go.

More often than not, if you look at successful technology companies even the "business guys" (the CTO and even the CFO) often have an EE/CS/Math/Physics degrees and have, at one point, have held technical roles. Engineering/math/natural sciences act as "brain gymnastics" which come in handy in any role which requires fast, analytical thinking.

That being said, in enterprise software having a strong sales team is often more important than having a strong product. Ideally, you'd want to have a founder who had worked in roles such as field sales/application engineer/sales engineer/consultant and has a Computer Science background: this way they will understand both the technology involved and the acute pain the target customers experience.

For consumer Internet, however, "sales guys" are only needed when you have something to sell (e.g. a critical amount of impressions in an advertising-supported site). The canonical examples (Craigslist, eBay, Google AdWords/Overture) are brilliant in that they're self serve: you don't need a large sales force to sell them.

I'll throw in some more advice: if you're going to start a company w/o a technical person, pick an idea that allows you to pre-sell. Enterprise applications are a good, because it's not uncommon to get commitments from buyers before the product exists. If you can do this, it demonstrates two things to prospective developers:

1) The idea/market has legs

2) You can pull your own weight

I wouldn't start an enterprise software company w/o a technical person either. A non-technical sales person from an enterprise company won't be aware of the acute pains the customer's IT/engineering departments have. They'll be able to make sales pitch, but given an equal sales pitch by Oracle/IBM/SAP and a start-up-you-never-heard-of, which one (as a non-technical manager) would you choose?

As I've said earlier, the best person to start an enterprise software company would be an applications engineer/field sales engineer/professional services consultant from either a large or fast growing enterprise software company.

Not only will they know how to sell, they will also understand the technology, be able to program well enough to create a prototype, be interview developers, know how to support the customer, deal with the end-users and know most importantly what the end-users want (best enterprise software is the enterprise software employees are begging to install).

also, buzzword-laden mass emails sent from business school students to engineering student email lists are real turn-offs :) if you're a business school student, i'd advise to get some friends who are hackers to read over your recruiting emails before sending them out.

If they had hackers as friends, they wouldn't need to send out recruiting emails. Most of the time your first hires are your friends. If you can't convince a friend to be a cofounder, how can you ever expect to convince a stranger to work for you?

In some sense, hiring engineers is like selling. In both cases, you need to convince them that you've got something that they want. Neither group cares about what you need/want.

Two related points.

If you can't "sell" an engineer, why are you sure that you can sell to your proposed customers?

While developing your pitch, be sure that you'll be happy with folks who want what you're offering. If it's not unique, you'll lose the good ones to folks who offer "more".

> Engineering respect is an inverse log scale

What is the inverse log scale? 1/log(x) or exp(x)?

And for God's sake, don't ask for "programming ninjas".

Finding engineers/programmers seems to be a real problem for potential entrepreneurs.

I thought I might try and write up some of my experiences - I plan to post this to a whole bunch of the London start up lists where the worst offenders hang out. If you have any suggestions for improvements I would appreciate them.

Thanks!

My opinion: make it clear that they will not be drug tested nor do you care about how they may choose to relax in their free time. This will set you apart from many large corporate environments as well as indicating that you value a programmer's productivity rather than their conformity.

While I agree with ALL of the OP's points, I also wonder why any serious engineer would even bother reading these kinds of requests in the first place. It's usually obvious within the first few words whether a potential client "gets it" or not.

Thanks to everyone, some very good comments. I'm doing a revision before posting it :-)