Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I'm a new intern in a fairly large company's IT department. I've been learning a whole lot of stuff and I'm loving every minute of it.

However, the more people I meet in the company, the less I understand their titles or the general title hierarchy. Here are some examples:

  • Senior Designer
  • System Architect
  • Systems Analyst
  • Systems Analyst II
  • Technical Support Analyst II
  • Infrastructure Operations

To name a few. But from what I gather sometimes two people will have the same title and do 2 completely different things, whereas sometimes they will have different titles and do the same things. No more do I actually understand anything from the titles themselves.

share|improve this question

closed as primarily opinion-based by gnat, MichaelT, GlenH7, Snowman, Dan Pichelman Apr 17 at 1:55

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Job titles vary by organization. Your best bet is to get job descritpions for the titles from someone in HR, they should be able to provide it. The rest of us, we'd be guessing - a System Architect in your company might not do quite the same thigns as one in my company. Also, this question pops up very often around here, so I'm sure there's a duplicate somewhere... – FrustratedWithFormsDesigner Jun 16 '11 at 18:28
Twas always thus. When I went to work for National Semiconductor (many, many moons ago), in order to meet my salary demands they gave me the exalted title of Senior Systems Programmer, Specialist II, even though I was simply an applications programmer. Each one of the additional words put me in a different salary range. You gotta love HR. – Peter Rowell Jun 16 '11 at 18:30
My bad if there is a duplicate, I didn't see one in the title suggestion box thingy. However, let's say I'm a System Architect at one company and put that on my resume. Isn't it hard to figure out what I actually did and what I CAN do based on a title that changes from place to place? – n0pe Jun 16 '11 at 18:30
For those of us at smaller companies, there's not a good title to be had short of "That guy that does all the technical stuff, but isn't a product developer." I spend some time on internal sites, external sites, SaaS deployment, systems deployment, top tier customer support, and a bunch of other things. – Jeffrey Jun 16 '11 at 18:39
@Jerry Coffin: I think they prefer "Sanitation Engineer". ;) – FrustratedWithFormsDesigner Jun 16 '11 at 18:40

5 Answers 5

up vote 10 down vote accepted


IMO - Because knowledge work is incredibly hard to encapsulate. And the evolving world of software is even worse. People may move from leadership to high level individual contributor work at the drop of a hat depending on project/company needs - so you don't necessarily want to stick "manager" to anyone. And people should be able to move from one specialty or responsibility to the next without it being either a promotion or demotion within a certain range of responsibility. Since there's no easy to define responsibility or contribution level in any way beyond the relative, it becomes incredibly hard to give someone a title that works long enough to make printing business cards worthwhile.

General term definitions I've come up with:

"software" - makes software. Bugfix, development, software requirements, something where there was no functionality before and after the team comes through there's a new bit of functionality.

"systems" - broader and more eclectic than software. Usually a fusion of disciplines, generally responsible for bigger picture than a single area. Often concerned with how systems come together with users and other key ingredients. May be called the experts of the 'problem domain'.

nothing or "junior" - an entry level engineer - someone with 0-5 years of experience, give or take a few years.

"senior" - capable of working without much (or any) supervision. Knows at least a few major areas well enough to teach others. Knows more than at least some of the other engineers in the company.

"principle" - knows more than senior engineers, responsible (at some level) not just for their own personal improvement but the increase in capabilities of some portion of the overall engineering workforce in the company. Does something major and strategic most of the time.

"developer" - works in a company that actually makes stuff

"support" - does something in the realm of responding to problems - usually customer problems.

"test" - mainly responsible for something in the realm of testing/quality control.

"QA"/"EQA" - really fascinating - in commercial industry, it's similar to someone with "test" in their title. In defense contracting, it's likely to be the person responsible for making sure that engineering follows the process that was promised in the contract. Not the same thing as "product quality", more of a "process quality"

"designer" - does something artsy. Seriously, I usually see this in the softer areas, like where computers encounter Humans, a la "GUI Designer". May or may not have full on software development skills.

"Analyst" - means the company is confused on what this person does too, but they are really smart and should be respected. OK, not really, but it's such a wide range of tasks that it's always fair to ask the analyst what that really means in his industry/company.

"I", "II", "III" - a good case for only being able to define roles relatively. Usually I is least contribution/rank/influence and the higher you go the more important the role. I don't often see much past III.

"Operations" - responsible for something fairly large that is servicing a fairly large number of users who are trying to get something done. I usually find that "Operations" and "Development" are mutually exclusive.

The really sarcastic answer:

Engineers usually get paid good money. The company wants to be able to ask them to just about anything from setting up picnic tables at the company picnic to the hard stuff that requires years of experience and really good judgment. The stuff on the high end doesn't come through every day, more days are filled with easy stuff than hard stuff - especially at the upper levels. So management wants titles to be so vague that no one can argue about the days they are asked to set up picnic tables at the company picnic.

share|improve this answer
Wow, most of what you've said makes perfect sense and I can see what you mean in the office. +1 and accepted – n0pe Jun 17 '11 at 14:39

IMO the reason is because there is only so far you can go in Enterprise IT before jumping the management rail. So HR departments try to come up with innovative solutions for those that do not want to go in that career path (management). You end up with a lot of crazy titles and positions that are there to make people feel like they are progressing.

share|improve this answer

To grab what you have, here's what I think when I see them. YMMV, and they'll probably be somewhat vague.

Senior Designer

Pretty self-explanatory. This person is a designer. What they design will be likely provided by the context. This could be a web or print designer (or hell, a t-shirt designer for all I know), so the description will help here (or asking them, or whatever else gives it context). They're senior level, which means probably about 5 years experience, or at least 3+. They might even have minions.

System Architect

When I see anything "system," I think that hardware or operating systems are involved (as opposed to developing software), at least part of the time. That's not always the case, but it's what I've seen. This person could do a few different things, but it will likely be based on designing (architecting) structures of things, such as networks (what groups to build in Active Directory, who goes in what groups, who gets what base permissions, etc). In my experience, an architect that does software development related stuff is a software architect. Same idea, though. They put the puzzle pieces together for the business.

Systems Analyst

This one's pretty generic, I think. Usually just ends up being a fancy name for someone on the helpdesk somewhere. Not really a Tier 2 or 3 tech, but might do some of the same jobs.

Systems Analyst II

Same for this one, though higher rank. Probably has more responsibilities (maybe server admin thrown in) and minions.

Technical Support Analyst II

A fancy name for Tier 2 helpdesk tech (TSA I would be Tier 1 and TSA III would be Tier 3). May also refer to seniority, though that can be the same regarding the Tier system.

Tier 1 tech support are the people you talk to first when something tech-related breaks. They're the ones that try to fix your problem over the phone (or via email) if it's a quick fix. Tier 2 is who you get escalated to if Tier 1 can't fix it. They might remote in or even come deal with your computer in person. Tier 3 is the next place if Tier 2 can't fix it, but then it starts getting into server stuff, in my experience.

Infrastructure Operations

Fancy name for a server and network admin, probably used most when the same person does both.

share|improve this answer

Managers don't know what we do, so they need some convenient label to slap on us to make it easier to cope with the situation. Generally titles like Systems Analyst II with a number at the end are a way to cope with salary ranges.

share|improve this answer

This is how things generally have broken down for me (YMMV):

  • System Analyst: generally speaking, systems analysts are responsible for gathering or deriving system requirements. Also known as business analysts and system engineers. They're generally the ones who figure out what the software needs to do. However, bear in mind that my offical title was "Computer Systems Analyst" for seven years and all I did was sling code.

  • Designer: could be visual or technical. In the technical sense, is responsible for the design of the software, or how it does what it needs to do. In the visual sense, it's all over the map.

  • Architect: responsible for the technical big picture - decides which technologies, products, communication protocols, etc., to use. Participates in the overall system design, but only at the high level. Makes sure all the systems (in-house and vendor-supplied) play nice together.

  • Support Analyst: helps customers identify and work around problems, issues defects against the system on behalf of customers. This is not help desk work; it requires real troubleshooting skills and enough familiarity with the software to both provide workarounds (scripts, schema updates, etc.) and to communicate what needs to be fixed to the development team.

  • Support Engineer: fixes bugs, issues patches, etc.

  • Infrastructure: responsible for setting up and maintaining computer systems, user accounts, networks, etc. May also be responsible for builds.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.