jon steinberg

Everything but code

The notion of  the ultralight hacker team has permeated web startups over the past few years.  There were always teams of two to three individuals building software, but the extent and quality of the output of these teams seems to me to have reached a new level in recent times.  Entire, fully-functional products are now created and operated by teams of typically two; tumblr, tipjoy, and disqus immediately come to mind.  (Paul Graham may deserve part of the credit for institutionalizing the team of two, but I’m sure someone will point out plenty of prior art.)

What I have not seen emerge quite as much is the “everything but code” (EBC) team member.  Just like the agile coding members of the team can do anything required in creating the product, the EBC can do anything required in non-product creation.  This includes primarily deals and sales but extends also to operations, project planning, legal etc.  The EBC may also do things closely tied to coding, such as developer outreach, API policies, and product roadmap, so a technical understanding is required.

Rolled all together the EBC tasks make up one coherent and efficiently busy role for a startup. Further so many of the tasks are the same rose by different names: when have deals not required salesmanship and selling not required dealsmanship?  Shouldn’t someone who’s in charge of the sales pipeline be capable of managing the product rollout pipeline.

Yet despite the obvious nature of the EBC role, we continue to see specialty segmentation on the business side in startups that we would consider passe on the coding side.  In startups, we’ve moved away from the rigid classification of software development specialities, and yet on the business side we model roles on the bureaucratic classification systems employed by companies like Dunder Mifflin and Innotech.

Many startups find themselves needing 1/3 of a business development person, 1/3 of a salesperson, and 1/3 of a marketing person.  They struggle to divide these responsibilities amongst an already small and already incredibly efficient/busy/taxed technical team, and wait to make a hire in each area until it hits 3/3. Or suboptimally, they hire a “sales guy,” who doesn’t do business development, and has 2/3rds of slack capacity.  They should have just hired one EBC at the point of the three 1/3 needs, and recent conversations lead me to believe that there are a lot of EBCs out there.

If one or two all terrain hackers can handle everything related to product creation, the EBC should be equally broad in non-coding tasks.  We’ve witnessed this efficiency on the technical side, so it seems only logical to model it on the business side.  I would extend this logic and argue that the release early and iterate philosophy with code should be applied to partnership deals, pricing strategies, and marketing approaches.

If one or two people can build/code an early to mid-stage product, surely we should model that into the business side and create the same kind of efficiency in everything but code.