Why we're a titleless startup

Colin Powell very much eschews the command and control structure in his advice for leadership.

"Organizational Charts and fancy titles count for next to nothing"

http://www.blaisdell.com/powell/

Also, the modern business suit is heavily inspired by military command dress.

Impressive sounding titles are for resumes, not egos. Most people here recognize the importance of explaining a product in as few words as possible so the people who want what you're selling stay for more, but for some reason, the same effect in hiring is overlooked.

If you want future jobs that carry the kind of responsibilities that a VP of Engineering, for instance, would typically handle, those jobs will be easier to get if that title's already on your resume. Forcing people to accept the title of "Irreverence Engineer" is forcing them to leave money on the table, and it's not a necessary feature of a culture that deemphasizes hierarchy.

That link deserved its own submission. Thanks and upvoted.

It's a good article, but there's a flip side to not having titles: You risk confusing people who don't know much about your company yet.

To put it another way, titles aren't just about establishing a pecking order -- they are also about helping others identify who in your organization is responsible for what.

A journalist who wants to talk about your innovative technical solution wants to talk to the CTO (or VP engineering or whatever.) But if they instead unknowingly send an email to the person in the CEO role, that message might sit in the CEO's inbox for a while before getting redirected to the right person.

Or a legal threat could end up in a junior staff member's inbox, where the staff member might take the threat less seriously than a CFO would.

And the problem isn't just about where to send emails. What happens when you grow to a staff of six, three of whom are working on website development? Who is ultimately responsible for the application? The UI? The servers? Someone could ask questions and ultimately figure it out -- but it'd be a lot easier if they could just contact the "sysadmin", the "designer," and the "developer".

To be fair, the article does mention using "role based" titles when talking to the media. And I think that the author's real issue is with the "pecking order" aspect of titles. But forgoing titles altogether isn't the right solution.

Likewise, choosing something that completely obscures your role, like Mad Hatter, is like choosing random names for the variables in your code. You might think it's humorous to have $foo and $bar and $number in your code, but it doesn't help anyone who has to read your code later.

The biggest practical downside I can think of is if in checking references, your former boss gets called and has a reaction of, "John Doe, Senior Foobar? I don't think we even had a Foobar". So might be worth running it by whoever it is from the company you'd be likely to put down as a reference. I've met founders who are perfectly fine vouching for any reasonable title the employee wants to pick, though.