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.

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...