Organization Structure Recommendations for Technical Depts?

michael_cain asks: "Due to a large corporate merger, we're in the process of combining two technical organizations with radically different structures. One has lots of very specific job titles ('Senior Assistant Software Engineer for Icons and Buttons'), each with a specific description and a very narrow compensation range. The other has essentially one non-management title ('Member of Technical Staff') with a wide range of compensation. I admit to a bias due to more than twenty years in a single-title structure, but believe that said structure makes it easier to compensate people and teams based on their contribution, to encourage staff to learn new skills and grow, and to shift resources to meet changing business needs. The merged human resources group tends to favor the rigid title-driven structure. Which would you prefer?" I'm a firm believer in the old addage: less complicated something is, the better. I think this would apply to organizational structures just as well as it does for code. Thoughts?

Comments

Specialism is not the same as seniority

[PinglePongle]

As part of a reorg, I am trying to change my team's job titles so that instead of reflecting their specialism, it reflects their seniority. So, I've moved the "Senior designer of buttons and fonts" to a role called "Senior Developer",the "Junior designer of buttons, fonts, and logos" to "Junior Developer" etc.

This only reflects the reality of how we work - everyone moves between projects and uses their specific skills to contribute where they need to, it shows that there is a career path that reflects your contribution, rather than some org chart structure (oh, I am the Junior Database Column-adding specialist - there's no position on the org chart for Senior Database Column-adding Specialist - how do I get promoted ?).

The main risk to this strategy is that it makes it harder to explain to the senior management team what all those people do - they rarely understand what it takes to build software. So in these uncertain times, it's a lot easier to say "You want to fire Joe ? Look at the org chart - Joe is our Senior User Interface Designer - we'll always need a user interface designer - you can't fire Joe !", rather than "You want to fire Joe ? He has really good skills at User Interface Design ! Well, yeah, so does Jane - but Jane is our lead Object Specialist ! Well, okay, Gunther knows a bit about objects, but we really need his skills as..." etc.

It seems that in most organisations, HR and the executives like to know what people do for a living, and the easiest way for them to achieve that is to insist on an org chart with specific titles. The way to ease this desire is to help them to understand the way the team works, show good results on major projects, and build trust.

Seniority should reflect ability and contribution.

[PinglePongle]

not longevity. I do think it's a good idea to have a defined career structure - I have interviewed a lot of developers in my time, and most of them want to know how their contributions are recognized. A simple hierarchy of "junior/senior/principle" or something at least shows that we have a clue on how to recognize what people contribute and that there are visible signs of that recognition.