Job titles are MetaphorsWeLiveBy
. Our designated role in a software development effects the way we work. This is a start on a canonical list of Job titles, what they mean or should mean and which are equivalent.
- Sorry but I want to interject a thought here Since I generally do *all* sorts of things as part of "getting the job done" and typically most (if not all) of my colleagues also do the same, I've always felt that the ideal title is something like "Member, Technical Staff".
- This is the title given entry-level (degreed) engineers at my first employer, and they flat refused to hand the title of "Engineer" to anyone with less than 3 years' experience. Because everyone in the place was an "Engineer" of some degree (Senior, Staff, Senior Staff, etc.), this made the title seem like an insult. Among my "MTS" peers, most would have preferred even "Junior Engineer".
- Nobody knows everything (even CowboyCoders). In every project, it will quickly become apparent who the leader(s) are. In my experience, organizationally imposed worth tends to damp down the contributions of *organizationally less-valued* staff. I've been on both sides of this.
I used to be happy with Engineer; that title was reserved for people with 'higher' diplomas when I embarked on my career as a programmer, and when finally I was an "official" Engineer (says so right here on my business card) I could be a little less embarrassed with my lack of higher education. With time, I came to (mentally) adjust the title to JustAnEngineer
. Today I'm overjoyed to be "officially" a Software Architect, for slightly different reasons : I view it as the recognition that my job is not just to write code, but also (and officially) to care about how
I write that code. A SoftwareArchitect
whose opinion about methodology counts.
My current job has me (and all my peers) titled as a SoftwareDeveloper
. The theory is we're all professionals here and don't need to be ranked. My previous job tacked on "Associate" to the front of that title for folks who had less experience and "Senior" for folks who had more, creating the whole hierarchy thing that big companies like. I guess "Developer" sounds more more prestigious than "Programmer." And it's less contentious than "Engineer." But I suspect that, when it all boils down, it's really JustaProgrammer
I suspect there are cultural as well as technical difference in job titles.
My title is Doer, though like GeorgeCarlin
, I often prefer Foole.
moved from ChiefArchitect
Two related factors:
TheTroubleWithTitles? - Since most software building occurs inside commercial enterprises, the oddities of that milieu make a strong impression on our field. In the business world, compensation and respect and freedom all flow from title. That is not an absolute, just the typical situation. In any knowledge-work endeavor the person at the top of any selected hierarchy rarely produces as much positive influence on the outcome as those at the tips of the hierarchy, yet they nearly always garner the greatest rewards. This makes us all gravitate towards title when seeking those deeper desires.
TheProgrammerSalaryCap? - Being JustAProgrammer usually severely limits one's earning potential and influence. And there exists an absurd notion throughout the more dysfunctional regions of the the business world that says that a manager should make more than that manager's "direct reports." Star NBA players earn multiples of the salaries of NBA coaches and executives, yet the stars of the programming field routinely earn less than even the most mediocre DirectorOfThisOrThat?. Titles like ChiefArchitect often help our stars gain salaries more commensurate with their contribution to the organization, and bust through the cap.
Moved from TechnologyArchitect
another example for JobTitles
, used for example at Tritus.com.
I imagine such role becoming more and more important in large projects. A while ago our design organization had a crisis situation where several design teams had opted to use the same technology, but where all unable to interoperate. CORBA implementations didn't talk to one another, C++ libraries that wouldn't link using other compilers, SNMP stacks that couldn't sit on the same machine. The situation didn't improve until someone was given overall control of technology use throughout the project.
I always thought "Guru" would be a good title for a senior, non-management tech person who has such extensive experience about a given technology, platform, OS, language, subject, etc., that it's not that much of an exaggeration to say that they know "everything there is to know" about it. The Guru is the person you go to for Answers. Examples: SQL Guru. C# Guru (probably no one qualifies for this yet). Design Patterns Guru. Etc. I've seen "irreverant" titles before (like Jeff Bezos') but this is one I'd almost be willing to put on my business card, if I qualified for it, since it actually communicates something about you rather than (or in addition to?) indicating that you're a smartass.
There's also the matter of official job titles and unofficial ones. Many offices have someone who isn't on the IT staff who is nevertheless "the guy you go to when you have a PC problem." Indeed, some projects have a TechnicalLead
who is not the official TechnicalLead
Rather than specific titles per person, being a SetWeenie?
, below I will attempt to provide a list of typical IT functions. In most cases, especially in smaller companies, a given person will perform more than one of these, and often several.
- Technology Expert - Knowledge about a specific tool or product. Example: DBA, Java API whiz, C++ language guru.
- Domain Expert - Expert on the business logic and rules, and if part of IT, usually has the ability to translate them into detail sufficient to implement or hand off to an Implementor. Interacts with the customer to obtain requirements or understand a process better.
- Implementor - Takes instructions given to them by the Domain Expert and turns them into programming code or hardware. May consult Techology Expert on the tricky parts.
- Project Manager - Focuses on staffing, schedules, versions, and feature tracking of software projects.
- Trouble-Shooter - Studies or dissects projects or products to find the cause of problems.
- Help-Desk - Person who takes problem calls or messages from customers/users and verifies and/or documents the nature of the problem, and then routes it. Often works closely with Trouble-Shooter.
- Tester - Checks the results of the Implementor. Reads description(s) given by Domain Expert to compare.
- Decision Manager - A manager who "calls the shots" when there are conflicts of opinion, and makes all final large-scale judgements.
- Process or Content Administrator - Somebody who moniters periodic processes, checks server status, changes configurations or meta-data as requested, etc.
- Visual Desiger - Look-and-feel, GUI, and esthetic expert.
- Could be subdivided in larger companies between visual designer and visual implementer.
To describe what a particular individual does, a percentage breakdown can be given. Example:
- 20% Trouble-Shooter
- 30% Domain Expert
- 40% Implementor
- 10% Technology Expert
A "web master" would look something like this:
- 30% Technology Expert (expert in HTTP, HTML, etc.)
- 30% Process or Content Administrator
- 20% Visual Designer
- 20% Domain Expert
Now I agree there is usually a lot of overlap and that percentages can be tricky. But one way to think of it is pretend you are in a very large company with a strong division of labor along the above lines, and at any given moment ask yourself who would be doing that particular job. Sample your time throughout the day and that would give you rough percentages.