May 30, 2012

Whistling Into a Tape Recorder

A friend of mine once told me a rumor about a famous film composer. According to rumor, his process consists of watching the rough cuts of the film, whistling into a pocket tape recorder, handing the tape to a team of orchestrators, and waiting for them to compose the actual score.

It probably isn't true, but it makes me think of a lot of first-time startup founders I've met lately that are trying to find a "technical co-founder."

Forget for a moment the hackneyed truisms about ideas and execution. Ideas are easy. Execution isn't so bad. What people never seem to get is that translating ideas into execution is the hard part.

There are a lot of names for this. There's Hofstadter's Law. Merlin Mann calls it "Just-a-button guy." Ze Frank calls it "brain crack." Steve Yegge calls it "Shit's Easy Syndrome."

But no matter how you stack it, shit isn't easy. Once you've committed to an idea, if you keep pushing, you eventually fall off the precipice of think mode and land in do mode. It's not always obvious once you've stopped falling. And it doesn't matter how deeply something has been specced or how experienced the team is, it never ends up going how you thought it would.

There's a precise moment when a product is more reality than idea. It's not always when someone actually starts coding it; sometimes it can come after months of work or even days before shipping. It's an emotional tipping point where you stop procrastinating little decisions, stop thinking about what could be, and focus on what's actually going to be done for 1.0. It can feel painful, like pulling off a bandage. But once that point is reached, it's all downhill.

Anybody who makes anything — writers, musicians, architects — seems to develop a gut feeling for this and gets better at bringing about the transition with a minimum of fuss.

CODE IS WHERE THE RUBBER MEETS THE ROAD

In software companies, engineers are often (but not always) in a good position to develop a knack for this simply because the last chance to find out if an idea has been fully thought through is when someone sits down to code it. All sorts of questions start popping up. Did you really figure out all the edge cases? Did you forget to design a screen or two? When you put that one feature in at the last minute, did you really think about how it interacts with the other ones? Did you really think about whether people want this?

You can spend months planning and specifying but these kinds of problems always come up at the worst time. Sometimes they can be avoided early-on by sharp product managers and designers. Or by setting shorter milestones and using agile practices. But more often than not, code is where the rubber meets the road.

EVERYTHING IS TECHNICAL

This is why it irks me when people try to sort others into "technical" and "non-technical". Being technical isn't about technology, it's about technique. Techne. Skill in something.

Shipping a software product requires skill in quite a few fields. So many that, at an early stage, you couldn't possibly employ a full-time specialist to perform each unless you have a lot of funding and a lot of patience. There are many types of engineering, many non-overlapping kinds of design, business/partnership development, marketing, press, support, writing, finance, legal, the list goes on.

So it would seem that if you're going to form a team to take on all of this, you should have people that are good at some of these things, and willing to try the rest until they get it right. Anything else can fall on hired help or advisors.

The pervasive idea that a founding team must have one person dedicated solely to engineering and one person for "everything else" is completely arbitrary and possibly dangerous. It's one that's been made into an archetype by people like Jobs and Wozniack, but isn't all that typical in the grand scheme of things.

The only situation where this possibly makes sense is if the "technical" person on the team is the neckbeardiest of the neckbeardy – the kind of person who shuns anything except for pure code. And those people belong in cubicles anyway.

The problem with this archetype is that once you accept it as a given, it becomes not just a divide in skills, but can be conflated into a divide between ideation and execution, thinking and doing, executive and worker, alpha and beta. And once that happens, you risk introducing all the inefficiencies of large companies into your two or three person team.

HOW TO REALLY FORM A TEAM

If, like me, you're pondering what kind of people you want to work with and what role you want to have in a team, it's probably best to forget the archetypes and just find collaborators who:

1. Can do — that is, have definable, testable skills.
2. Can think.
3. Can switch back and forth between the two.

It's a little vague, but it's a start. I'm going to try it out for a while and see what happens.

EDIT: Removed incendiary subtitle. East vs. west isn't the main point.

May 20, 2012

IndieDevLab

I'm going to be speaking at Indie Dev Lab alongside Jay Freeman, Nate True, and Ben Zadik. The conference is June 11-14 in San Francisco.

(see announcement on TUAW)