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

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.