Increasing growth and complexity brings about distinctive roles in an organization. Let's take a tour of an established information technology divi...
For further actions, you may consider blocking this person and/or reporting abuse
Nice write up.
I think it would be interesting to differentiate between junior, senior and lead roles and where they can be (like in a developer team), same for mobile, frontend and backend developers.
As well, QA could be split into manual testers, automation testers and QA management.
Another important roles could be agile coaches/scrum master,although seems more a specialization of PM.
In my experience the simpler the layering between dev roles the better. I currently work in a multi tiered environment where we have developers ranging from 1-3, Senior and Leads. The difference between the first 3 roles is tiny if any at all, it's really just a way to mark there experience levels. I find the lead roles have the biggest contrast in responsibilities because i have worked with very active leads, who commit a lot of code and leads who basically act as middle managers and spend most of there time planning and managing expectations.
I don't concur with these definitions. In particular, all of these roles are part fo software development, thus they are all software developers. The role you label "Developer" is better labelled as "Programmer".
"Quality Assurance" is about total processing management, what you describe here is "Quality Control" or "Testing".
UX Designer/Designer are not solid distinctions. A UI consists of usability and aesthetics.
The separation between networking, and operations doesn't make a lot of sense. Any company organized that way is likely to have a crappy network. As would any company where the hardware (infrastrcuture) people are not a part of, or tightly bound to the operations team.
"Architect" is an artificial role. Admins and programmers must work together to come up with an architecture. Any company that has a specialist who is not on one of those teams likely has a garbage architecture.
You can have an IT division that doesn't develop any software at all and still require all of these roles outside of programming. I chose developer to identify programmers/engineers because the people who fill that roles most readily identify with the title "Developer": insights.stackoverflow.com/survey/...
Not sure what you mean about QA and total processing management.
You're right that UX Designer/Designer is vague distinction, but that's how they're known. A designer may choose a color scheme, a UX designer ensures that the use of color is meaningful.
I've gotten a good amount of feedback on Operations. My best guess is that it's understood as the more general term that includes anything that is not application development and support. I've never met a network engineer or systems administrator who refers to what they do as Operations. I have seen Network+Infrastructure groups with a separate Security group, Network+Security groups with a separate Infrastructure group. How I distinguish the Operations team is as a group of Operators (who manage and monitor scheduled jobs, and do not do networking, infrastructure nor security).
I wouldn't agree that Architect is "artificial". Individual teams aren't expected to have that enterprise-wide viewpoint. For an IT Division that does not believe in in-house development, an architect may ensure that vendor products aren't functionally overlapping or point out vendors that have solutions at a marginal increase in cost vs a new vendor contract.
As a closing note: there is bound to be a serious amount of variation, role compression and/or segmentation in any particular IT division. What's important is an organizational structure that works to the benefit of the company and it's people.