Brad Hargreaves | Building Things

Brad Hargreaves on entrepreneurship, community and life

Archive for the ‘development’ tag

Finding Developers and Women

with 5 comments

I’ve been stewing over this post for a while. It gets a little bit closer to being written every time I meet with an “idea guy” who is looking to find a hacker to build his or her (but typically his) dream site. Interestingly, a lot of these guys spend a decent amount of their spare time at an analogous task: picking up women.

I’ve always wondered why they don’t see the natural parallels. For some reason, the principles that apply to meeting women are a lot easier for people to intuitively grasp than the same principles applied to meeting developers. Unfortunately, most of these guys happen to live in NYC, where there are way more available women than available technical cofounders. But the same ideas apply:

Go into their world. If you’re looking for single women, you probably need to venture outside of sports bars. Go to a more female-friendly club or volunteer for a cause. Go anywhere single women congregate. Similarly, I meet way too many “business guys” who only hang out with people like themselves — other business guys — and stick around events and meetups that are dominated by folks who think pointers are the handheld lasers you use to give Powerpoint presentations. If you want to meet the technical co-founder of your dreams, you need to find the places they hang out — technology-specific meetups and user groups, Hackers and Founders, et cetera.

Understand their motivations. Or alternatively, “Don’t assume their motivations are the same as yours.” In the dating scene, this is obvious — not everyone wants the same thing from the evening’s encounter. And as many of us know, variations in motivation and interests can lead to some pretty awkward situations. Similarly, developers often have very different motivations than non-technical entrepreneurs. First of all, many (most) developers aren’t entrepreneurs. Given that entrepreneurship can be a bizarre and irrational pathology, this can make for a pretty big delta in motivations, perspectives and interests. Money, for instance, may or may not be a big motivator to an engineer — in fact, I’d say a plurality of engineers I’ve met would say that making a lot of money would be “nice, but definitely not necessary.”

This is a generalization, and above everything it’s important to understand the motivations and interests of the individuals you’re talking to, not the generalized category “developer”.

Show your value. Unemployed, balding 40-somethings have a much harder time picking up women than rich, balding 40-somethings. Truly smart, well-connected business co-founders aren’t easy to find. Be that person and demonstrate it early and often.

Speak their language. The number of “idea guys” who don’t even attempt to understand the basics of web development is hugely frustrating, both to me and most startup developers. Even if you can’t code, take some time and learn the basics. But don’t take learning the basics to mean that you actually know anything about making high-level development decisions — it just shows that you care. And like women in bars, technical co-founders appreciate it when you care.

Don’t try to fuck on the first date. Pretty self-explanatory. Get to know someone first, then seek a deeper relationship.

We need more hackers building startups and fewer writing black boxes for hedge funds, so I’m being honest when I say I hope more non-technical folks can use the skills they have to recruit talented developers into the startup world.

Written by Brad Hargreaves

October 10th, 2010 at 1:15 pm

Cargo Cult Game Design

with 10 comments

During World War II, many remote Pacific islanders received their first taste of modern goods when Allied or Japanese armies showed up and took over. Soldiers built airstrips, control towers and barracks, and planes regularly flew in and out. To avoid conflict, the islanders were bribed with food, alcohol and amenities. Then, the war was over and the soldiers left, tearing up their bases and taking their planes with them.

When these remote islands were visited again by anthropologists years (or even decades) later, some islanders had created “cargo cults” mimicking the soldiers’ activities. By building landing strips, wooden control towers and straw planes, islanders hoped to re-create the bounties of cargo. That is, they were copying the process without understanding the underlying principles.Plane from a Cargo Cult

As the idea of building game mechanisms into everything becomes the next new hot thing, I’m seeing a lot more cargo cult game design, or “let’s stick a leaderboard on it”. Lots of companies are copying the games they see others build without really understanding what they’re building or why they’re building it.

Don’t get me wrong — the people who are thinking today about building game mechanics into their non-game products are way ahead of the curve and should be commended. But good game design is hard – look at how long it took some of the smartest game designers in the world to figure out how to create really compelling, blockbuster games on Facebook. The Facebook platform was lost in the wilderness for over a year before anyone started figuring it out — but when they did, they revolutionized an industry.

I get a couple emails a week from people interested in making their company’s products more game-like. The person tasked with this is typically in product development, product management or marketing. They’re all pretty smart people, so they look around to see what else is working. Sadly, examples of good games built into non-game products after a product release are few and far between. So they find something that May Be Kinda Similar But May Also Be Different In Some Fundamental Ways (really, that just means foursquare) and co-opt it to their company’s product development plan while changing as little of the original game as possible.

But this doesn’t really work. In fact, it’s not that much different than building a plane from sticks and bamboo and expecting to receive wondrous gifts from the heavens in return. Games are fun when they fit organically into the theme around them. If everything has its own standardized leaderboard of people who have generated points doing X, I’m going to get tired of leaderboards pretty quickly. Game design isn’t black magic (that’s SEO), but it does have to be tailored — or even re-engineered — to fit its environment, audience and purpose. And often, the fundamental questions that need to be answered in these companies can’t be addressed by game design. Game design must come after there are answers to core questions like who are the users? and what do we want them to do? In other words, it’s not a cure-all for core business issues.

So when friends ask me how to wrap a game around whatever they’re doing, I point them in the direction of some fundamental game design writings by guys like Raph Koster and Greg Costikyan. Ultimately, you’re better served by building something from the ground up. Start with the basic principles of psychology and game design and build them into your product at a fundamental level. Otherwise, it’s just an elaborate cargo cult ritual that mimics the process but fails to understand the underlying truths.

Written by Brad Hargreaves

April 17th, 2010 at 6:55 am

When You Should Hire a Dev Shop (other than “never”)

with 14 comments

I’ve always subscribed to the YCombinator / Paul Graham ideal that the best companies are built by founding teams of hackers, with perhaps a business guy or two (for example, someone with a strong business development, user flow or marketing background) thrown into the mix. But this often isn’t the way things turn out. Many capable founders aren’t developers, and I frequently meet with entrepreneurs that have taken a very different path. Most disturbingly, I’ve occasionally found myself agreeing with an entrepreneur’s decision to hire a development shop to build their product. Sometimes, it just makes sense.

But for every entrepreneur who has seriously considered the pluses and minuses of working with a dev shop in the context of the specificities of their business model, there are five who are hiring a dev shop because (a) they are lazy, (b) they don’t know any better, or (c) all of the above.

The reasons why I am not a big fan of development shops are too numerous to go into here. In brief, startups succeed because there is strong alignment of interests among all parties, especially with the people who are actually building the product. Development shops who work for $100+/hour and take no equity are poor partners in a startup. They have zero incentive to create a quality product or understand the nuances needed to capture a market and please end users. But all that is for another post.

For you entrepreneurs who are considering working with a dev shop to build your beta, I’ve written a handy guide to help you decide whether or not to pull the trigger. Read the scenarios and give yourself points accordingly:

3 Points: You actually do not know any software developers. I doubt this is the case for anyone who is reading this blog, but if you really can’t think of a single person to go to for introductions or advice, you may need to pay for it.

3 Points: You are pretty sure a LAMP stack is the pile of books on your coffee table, and Rails are what the Acela runs on. You probably aren’t the best person to hire and manage a developer.

4 Points: Money is no object. Don’t laugh. We’ve all seen projects like this.

4 Points: You are an exceptionally poor manager. As in you’ve been in management situations in the past, and you’ve been removed for being so incredibly bad.

4 Points: The development firm in question has some sort of special knowledge that is hard to find. Examples could be (a) experience building Facebook games under the new notification rules or (b) knowledge of how to build exceptionally secure e-commerce sites.

5 Points: You are developing software for government or major corporate clients. Being able to point at a specific development firm as “taking the responsibility” for the quality of the software is often reassuring to many government and corporate clients. I don’t necessarily agree with this bias, but from an entrepreneur’s perspective, it is what it is. Plus, most decent dev shops can point to at least a couple names of well-known previous clients.

5 Points: You have a development shop that will work for equity. This can be a good or a bad thing, and I should probably clarify it by adding “… and will actually get the job done in a timely fashion.” But equity-based work solves the misalignment of interests — there are just few dev shops willing to do it.

6 Points: You have a ridiculous project timeframe. For example, you need a beta built in four weeks. In this case, going through a hiring process is not an option. First, question why you need to get a beta out that fast. Then, really question why you need to get a beta out that fast. If your reasoning still makes sense, go hire a dev shop with the understanding that very little if any of the code that’s written can be re-used.

-4 Points: You don’t know exactly what you want. This doesn’t necessarily mean that your spec is vague; typically, it just means that a product will likely have to go through several major modifications before the dog food starts getting eaten. Unless there’s already a successful product out there that looks very similar to yours, you probably fit in this category. Iterating on a beta is a critical part of the startup lifecycle, and it is where the dev shop / entrepreneur relationship typically starts to sour.

Add all your points up. If you have more than 10 points, you can use a dev shop. If you don’t, you should go hire a team of hackers and build it the right way.

Written by Brad Hargreaves

March 7th, 2010 at 9:02 am