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

The more flexable, in my experience, the better.

[Bob_Robertson]

I've worked in a few different shops, doing lots of things. I'm not a programmer by "trade", I'm a network engineer. To get here I've done CompOps, NetOps, Helpdesk, security system installation, pumped gas, sold crap at Target and RadioShack, etc.

I have found that leadership, rather than management, works best. This allows people not to be restricted in their actions by job titles as such, there is more cross-training and sharing of ideas, and far more working together than saying things like "That's not in my job description" or "Hey, you can't do that, that's mine."

There is one absolutely critical function: Leadership. The buck has to stop somewhere.

By that I mean that unpleasent or uninteresting jobs must be assigned from time to time to specific individuals. There must be accountability for tasks done badly or not done at all.

I'm not in the Japanese style "Your work reflects on all the members of your team" credit/blame sharing. Not officially. I have seen, however, that when something says "These people, the Operations Staff, have gone beyond our needs and done wonderfully" etc etc, there certainly is a good feeling to being part of that team.

Treat people as valuable individuals, respect their talents and skills, and listen to them as individuals. Fire them as individuals if they are not performing, also. I hate open door policies. If I go to talk to the boss, there are times I want that door SHUT and no record kept. Honesty should never be punished.

Also challange the team. There should always be a view or goal that everyone is working towards at once, as well as the individual tasks. This makes getting there a personal as well as team success.

Bob-

Easy Answer...

[gnovos]

Think about it in this way, which kind of response would you be more comfortable hearing:

1) As Chief Departmental Specialist of Bold Fonts, I find it impossible to comply with your request for me to alter your web page text as it is completely written in italic fonts.

2) Well, I've been doing only Perl development for the last five years, and haven't really seen a lot of Python... but sure, I'll take a look at your Python script and see if I can figure out why it's pulling info from the old database.

The more specific you make a job title, the more often you'll see people steering clear of work that they are perfectly able to do, but isn't covered by thier job description.

In the software world, specialization is not a very good thing. If I am proficent in ONLY Oracle 7.0.2.831b, and nothing else, then I am a very very poor DBA. The same is true in as aspects of software engineering. You want to hire poeple who undersand CONCEPTS, *not* who have a particular skill.

Too often these days you'll see cluelees recruiters and companies who think that, despite your 10 years in software development, you are unqualified becase you don't posess fad skill X. They don't think for a second that the guy who DOES know X probably knows ONLY X, so in 5 months when your business plans change and you cease to use X, he won't be able to adapt,a nd there you are out looking for somone with skill Y. The rejected applicant with the 10 years of expierence would have taken a week or two to get accustomed to X, but after that, he would be as good as the other guy, and when it came time to switch directions, he would be just as comfortable with learning Y.

Defined team, undefined people

[Jon Peterson]

I don't think it's too useful to have individuals with highly specific job titles. It _is_ useful to have teams with highly specific job titles.

I think it's good to keep the tools team separate from the development team, separate from the systems team and the support teams. People should be able to move with relative ease between the teams, but it's important that people don't try to do everything.

Most /. ppl I imagine like the idea of undefined roles where you can do whatever you think you're good at. I've worked in places that take the specific job titles path, and if well managed that works too. However, it does assume that the work to be done fits easily into the structure you create for doing it.

It's often a good idea to have a defined person or role in charge of speed optimisation or security, or user experience, or platform compatability. If you just tell an unstructured development team "Hey, make sure you've all read the security specs and that you meet them!" you simply won't get the same level of security as if the security guy is sitting there creating test scenarios and reviewing every code release for possible flaws.

Well, unless "It matches the spec" is your idea of a good program.

Hmmmm, this was a thinking-aloud-post.

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.

Excellent question

[mosch]

This is an excellent question, and an intelligent way to proceed. By showing the new HR department that 15 semi-anonymous inhabitants of the Internet prefer the method you prefer, they'll surely adopt your preferred scheme, stat!

Oh wait...