Are Titles Important at a Startup?

My two co-founders and I signed our first company into existence on a hot summer day in 2008. Prior to signing the document, we had to decide what our titles would be. Our lawyer assured us that we could give ourselves any titles we wanted and it would not have an impact on the legal process. We thought it would be fun to sport executive titles, so we each chose a grandiose executive title and then returned to our shared apartment and kept hacking.

After several years at both companies, only the CEO title stuck. Although we remember what job titles we each picked, they ended up being largely unimportant. 

Size Does Matter

Organizations give titles to members to help people outside the organization understand who they are speaking with. When you get interviewed for a job, you want to make sure you aren't talking to a sales associate, you want so-and-so from HR. When a member of the press deals with a company, speaking with the CEO lends more weight than if the representative is a summer marketing intern.

But the orienting power of a title breaks down when the organization being represented is small. If you are being interviewed for a position at a 5 person startup, it's less important who you talk to because you can be more certain you are talking to someone of importance. Similarly, if a member of the press talks to one of a three person founding team, it matters less what title they chose and more that they are one of the co-founders.

For small startups, job titles are less important, if not entirely meaningless--except for the title of CEO.

Head Honcho

So why does the CEO badge remain important even at a tiny company? At both of my companies, we made it clear to our customers and business partners who we were, and we didn't made any attempts to look larger than we are. So at least in theory, an email from any one of us should have carried equal weight. Internally this was true, but externally, it remained useful to call one person the head honcho. Even in a super-small startup, it helps clarify to outsiders who the organization recognizes as the leader or point of contact.

None of us made business decisions without unanimous consent, we all checked each other's commits, and we all read each other's support emails. But startups deal with thousands of people in their lifespan and it's easier on everybody to avoid explaining egalitarian cooperation and simply point to one guy and say "he's boss."

This doesn't mean, however, that tiny startups can get away without a clear internal division of labor. Titles need not be assigned, but somebody has to know it's their job to file this year's tax return on time. At both of my startups, I was referred to as "head businesser." Nick was a "programmer," and Scott was a "programmer and accountant." The fact that Nick and Scott were labeled CTO and CFO on paper was only superficially important. Their understanding of their roles at the company, however, was of paramount importance.

Conclusion

If you are starting a startup and are wondering whether you and your cofounders should have titles, I would give this simple advice: decide who the CEO is and stop worrying about other three letter acronyms. Incidentally, this is exactly the advice that YCombinator tells it's founders.

Startup Advice That Bears Repeating

When you are running a startup, there are countless concerns to hold in your head at any given time. You might be concerned about an employee's work output, whether or not a funding round will close, or whether that big first client is going to make a purchase. I've cofounded two startups and I know all too well how the chaos of the moment makes it easy to worry about the wrong problems. There will always be the unexpected, but there are three pieces of categorical advice that don't change. These issues get brought up on Hacker News often, but (as the title of this piece asserts) I believe that these topics need to be repeating frequently to keep them in the forefront of your mind.

Design interfaces for real people.

There are always going to be new design fads, don't let them distract you. Always get real people to sit down and try your prototypes. Having people go through that workflow that you think is "totally idiot-proof" will give you valuable insight not just into how they are navigating your site, but how they respond to such critical things as your value proposition.

Also realize it's going to take a long time to really polish the UI. Don't expect to tape together a new version and have it fix all of your usability problems.

At Skritter it took one of us about 1-2 months of part time labor to overhaul and redesign our vocabulary system. We did that 5 times. Our 6th attempt worked pretty well, but the process taught us it's about incremental improvements and persistence.

Business partnerships are mostly a waste of time.

Guy Kawasaki describes partnerships like this: "Men  have a fundamental genetic flaw[...]: The desire to  partner (verb!) with anything that moves."

But most partnerships fall through. Those that don't fall through are unlikely to solve any of your pressing business problems. There are always examples of business partnerships or client relationships that take a struggling startup and make it a mind-blowing success. There's a reason you've heard those stories: they are the lottery winners of the business world. Like all success stories, business partnerships suffer from a strong file-drawer effect and for every success you hear there are hundreds of failures. Resist forming partnerships as much as possible.

At both Skritter and CodeCombat, we were asked to form business partnerships many, many times. We have had several partnerships that worked out really well, but it took a lot of time intensive trail and error to find those. My advice: protect your most important asset (time) and avoid partnerships, especially early on.

Don't build too many features.

Call it feature creep, call it over-engineering, call it whatever you like, it is an insidious, subversive problem in web startups. In Skritter's first funding pitch we actually had a point that said "we will avoid feature creep." A year later we were still not measuring exactly how our paying customers used the product. As a result, we built things that deep down only satisfied ourselves. Our customers said they liked our new features, but most didn't make us money.

Worse, building all those features was inefficient and hard on morale. Every time we added a new feature we thought "great, this new feature will definitely boost the value of the product by 5%!" What we found, time and time again, was that the new feature had no discernible effect on the bottom line. After you've spent 6 months building a boatload of features that were supposed to increase sales dramatically, you and your co-founders have probably exhausted a lot of positive morale that you will need later. 

Conclusion

You've heard all these points before, but they bear repeating. 

1. Buckle down and spend real time designing for actual people, not just those user stories in your product spec.
2. Be wary of partnerships and hoard your time jealously. Very few partnerships are worth the costs.
3. Create a sign for the office that asks a simple question "Will this feature help us achieve our business goals?" Answer the question honestly when deciding to built new stuff.

Even after founding two companies, going through YC, and reading thousands of startup blog posts, I still forgot these basic tenets and my forgetfulness has cost us. Everyone needs to be reminded about the basics now and again.