Job titles in the web industry

Chris Coyier blogged an interesting take on job titles in the web industry yesterday, aiming to provide some standardised terms that we can all use to gain a common understanding, and to avoid the ridiculous “ninja” / “rockstar” terminology.

Citing two primary issues of “The opinion on their usefulness range from harmful (i.e. leads to “not my job” syndrome) to vital (i.e. people change companies sometimes and need common language).“, this is something that I can relate to. As I said in my comment:

“I fall into the recruitment gap you mention. I’m freelance at the moment, previously an employee, and nobody has a consistent term for the job I do. It makes it hard to search for opportunities, and hard to keep an elevator pitch short!”

This is indeed one of the most difficult things I’ve found about explaining what I do to people. Despite the variation from person to person in more commonly understood roles such as ‘Front-End Developer’ or ‘Web Designer’, there’s generally a good understanding of what these terms involve. Instead, I find that if people are unfamiliar with a job title, they often try to pigeon-hole it into their own understanding of job roles, and match it against something they already know. “So you’re a bit like a Business Analyst then?” | “Oh, so you’re kind of a developer, but you don’t actually develop?” | “At my company we just call that a Consultant”. Worse, sometimes particularly narrow-minded people can even write your work off as ‘something not that important’ seeing as they don’t necessarily have a label for it, or haven’t heard that particular term being thrown around the big agencies.

I attempted to use a resource the other day which centred around average rates for different roles. As expected, none of the titles that I feel reflect my job came back with any results, due to the system not recognising similar terms. On entering two which I felt were a pretty close match, I received wildly different results. This is the problem of poor standardisation, and of not having a particular understanding to benchmark yourself against.

All of my freelance work to date has been through referrals, and contacts that I had met previously. I’ve been lucky enough that all of these people have sat down with me, listened to what I do and what I feel is important, and haven’t just judged me on a top-level title then tried to fit me in to their needs based on that. I have not yet tried to pick up any work found online, or through agencies, but I imagine that if I do I’ll come across some wildly different terms for very similar roles. I know that I’ve already revised my description of myself on this site and my LinkedIn profile several times through the year as I’ve come across different terminology.

The rest of my comment on Chris’ post was as follows:

“My current contract labels me as “Technical Analyst”. Sometimes called Solutions Architect, sometimes Technical Architect. The problem there is that different places have totally different definitions and requirements for these roles. Me? I work mainly alongside UXers, researching technical integrations, sussing out what can be done with APIs, investigating the impact of different technologies, building POCs, talking to people, and making sure that the technical solutions proposed meet the user and business needs rather than being a solution forced for the wrong reasons. I feed into the creative process based on opportunities and options from my research. I help devs plan solutions with my research in mind, but I don’t actually code on the project (though my background is development).

In my eyes it’s a very important role, albeit not one yet widely adopted, but it’s incredibly different to the traditional, more software-led “Solutions Architect”, who is often more someone who is handed requirements and spews out UML and schemas. I ask questions, listen to answers, and use technology to find creative solutions to problems.”

Whilst a common language and standardisation is really important, and would personally really help me when introducing myself and looking for jobs, what we don’t want to do is to go too far and put people in little generic boxes that don’t always match their roles. We don’t want to over-generalise roles that are in reality often very broad, and we don’t want to narrow someone’s perception of our skill set, or put a slant on it that isn’t applicable for our particular focus, just for the sake of common consensus. Let’s try and move towards standard terminology, but don’t let that be our sole pre-conception of someone, their abilities, and what they are passionate about. We’re all still people, and we’re all very different creatures within our little boxes.