Slashdot Mirror
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?
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-
The Ludwig von Mises Institute. The reasoning individuals economics
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.
"Your superior intellect is no match for our puny weapons!"
A human being should be able to change a diaper,
plan an invasion,
butcher a hog,
design a building,
write a sonnet,
set a bone,
comfort the dying,
take orders,
give orders,
solve equations,
pitch manure,
program a computer,
cook a tasty meal,
fight efficiently,
die gallantly.
Specialization is for insects.
-- Robert Heinlein
A bitter disagreement in one area, complete agreement in another.
By Cromm, I do love multidiciplinary discussion forums.
Bob-
The Ludwig von Mises Institute. The reasoning individuals economics
Besides, when you get a payraise, do you want to tell people that you've been promoted from "Junior Admin for Icons and Buttons" to "Senior Admin For Icons And Buttons", or would you rather just get a $1.13 payraise because your bitmap skills have improved?
Another aspect is that too many job titles can breed discontent. If you have a guy whose been working there for a few years, and just worked up to "Senior Admin for Icons and Buttons", but some new guys shows up and is only a "Junior Admin for Icons and Buttons", but does know more, he's going to get upset that he's not promoted. (And I do happen to agree that seniority and time spent with a company should be a factor in determining who gets promoted.)
`Lex - Find Me Here: Text Appeal
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.
/. 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.
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
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.
-----
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.
It's all very well in practice, but it will never work in theory.
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.
It's all very well in practice, but it will never work in theory.
Oh wait...
I cut, pasted and sent that to my boss.
Oh dear, I hope you spell-checked it first, ha ha!
Why is it that people dont understand this.
Honestly, I think it's becuase people are so used to brick and mortar jobs that they can't bridge the gap to software. In a typical position, you either know the skill of you don't. If you are only a master carpenter then you aren't qualified to lay electrical wires. If you are an accountant, then you probably shouldn't be hired to write marketing slogans. People in the hiring roles don't have enough expierence with software development (or systems administration, for that matter) to teach them that anyone who understands the concepts behind programming can do it just as easly in Java as in ADA. Sure the syntax is different, and there are slightly different functionalities, but as long as you are not programming in INTERCAL, a loop is a loop is a loop.
Telling somone that they don't qualify for a job becuase they don't have any expierence with DCOM is like trying to define mathematicians as either doing "polynomial" math or "differential" math, and saying that one type of mathematician doesn't have the skills to do the job of the other...
"Your superior intellect is no match for our puny weapons!"
The amount of real (customer-consumable) output generated by an organization is the important thing. I would think this is especially true in groups that have been merged -- it often take a while for things to become productive again.
Having lots of specific titles creates all kinds of non-value-adding work. Each title needs a job description, a salary range or band, means of distinguishing one level from another, promotion criteria, evaluation criteria, etc. There is often agonizing hair-splitting as you try taxonomize the work done by the group.
Of course the HR people want to do this! It's like having a Full Employment Act created for HR department. The work is endless. It will spawn endless new definitions, redefinitions, rescoping, etc., year after year.
And it gets not one extra line of code or chunk of hardware out the door. In fact, as a manager who has been buried in meetings dealing with this nonsense, I can say that a whole lot LESS real work gets done.
-- Man Roy
A while back during a re-org, a group of us were allowed to decide our own titles for purposes of business cards, and we all decided on 'Senior Consultant'. That describes what I do a little better, but is still general enough that I don't need new cards printed every time there is a minor shift in my responsibilities.
Recently I've been using 'Java Architect' as my title, since that is the role I've filled for the last 5 years or so. Our lab generally equates the 'architect' moniker with a particular pay grade range. Nobody assigned me the title 'Java Architect', I just took it on at some point after taking responsibility for JDK porting activities as the best description of what I actually do. When presenting at user group meetings or submitting articles for publication I find this preferable to a more general title.
I think of this as similar to Navy (or Star Trek, if you prefer) practice of calling the master of a ship 'Captain', regardless of actual rank. Describe the role you fulfill as broadly or specifically as appropriate in various contexts, while letting the HR folks continue to treat everyone as 'member of technical staff'.
I suppose letting everyone pick their own title could lead to a free-for-all of title one-upsmanship, but I've actually never seen it happen in the groups I've worked with.
Subscribers can see articles in the future? So what? Everyone gets to see them in the future.