Organization Structure Recommendations for Technical Depts? 20
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?
The more flexable, in my experience, the better. (Score:5, Insightful)
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... (Score:5, Insightful)
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.
Robert Heinlein quote... (Score:2)
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-
Are you hiring? (Score:1)
I cut, pasted and sent that to my boss. Why is it that people dont understand this. Just because they have a Certificate from a software vendor doesnt mean they can fix anything. If you understand how everything works from the ground up, to a reasonable detail, you should be able to solve anything.
It took you one sentence to say what Ive been trying to say for years.
Re:Are you hiring? (Score:2)
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...
Promotions (Score:2)
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.)
Re:Promotions (Score:2)
Ugh. It should be a (very small) factor. It does breed discontent when some "wiz kid" goes straight to the top without "paying dues."
OTOH I have had to work sorta-kinda under some real dubmasses who just occupied a chair so long without doing anything to get fired that they got promoted. That wasn't good for the company or my blood pressure.
-Peter
Re:Promotions (Score:1)
...once I was an associate webmaster :-) (Score:1, Informative)
Maybe reading some of Tom DeMarcos books can help you
CU,
KnopP
Defined team, undefined people (Score:3, Insightful)
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.
Re:Defined team, undefined people (Score:1)
Specialism is not the same as seniority (Score:4, Interesting)
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.
Status (Score:1)
Just my $.02
Seniority should reflect ability and contribution. (Score:2, Interesting)
Excellent question (Score:5, Funny)
Oh wait...
Value-added work versus non-value-added work (Score:2, Insightful)
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.
You CAN have it both ways (Score:2, Insightful)
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.
compensation per personal contribution (Score:1)
I have no respect for human resources and believe that those few empty seats on the proverbial bus load of lawyers should be filled by human resource "professionals".
I have no respect for human resources because as soon as you develop a "system" for screening applicants or employees it is doomed to failure. Human resources should have nothing to do with deciding what the structure of a team is. The whole essence of a team is based upon one thing, achieving a common goal. And the last time I looked human resources did not contribute anything except mandatory orientation to the company. They do however have the added responsibility of maintaining a list of all the racial and sexist categories of all their employees and strive to fill their quota so that the company looks good. In short, the hr department is only there because of the regulations imposed by the government which takes them away from scouting for quality talent.
In light of titles and designations I would approach a description that is centered on the concept of say, football. You have a project leader, quarterback for offense and linebacker for defense, special teams have been purposely left out for brevity. At this level the project leaders do not pick the team. The coaches pick the team and the captains drive the project. The human resources department, in this scenario make up the talent scouts, no more.
If you were to take this a step further then the answer to your question is somewhere in between. The quarterback is the team leader, he might be called on to run the ball or in some special situations he may act as a receiver. The half back might be a halfback in this formation but he might move out to become eligible to receive in another or a third area of "expertise" might arise and he might have to fill the fullbacks shoes.
More specifically, I like the comments so far that chose a generic title with many different job descriptions. And forget (explicative removed) the human resource department because they need to be scouting for talent. If this is not so then they are probably friends or relatives of some of the coaches and they think they run the team. Let's see them get run down by eleven guys who more than double their size.
HR isn't pure evil.... (Score:1)
If you've ever been in the position where you had to recruit 20 or 30 people in a few months, you'll appreciate the help of a good HR specialist. Sure, they might not bother to forward the CV of the eccentric but inspired genius who submits his resume in object pascal. On the other hand, they will shield you from the deluge of bozos who think that because they can spell "www" they can code. Or the "I know you asked for skills in code wrangling, but I feel my experience in the catering sector uniquely qualifies me for this role" hopefuls.
I also think a good HR team can help the rest of the company to be fair about who gets rewarded, who gets promoted, and what to do about those who don't make the grade.
All this stuff is annoying, distracts from the real goal of the team, and frequently clueless - "duh - how can you compare the unique skills of a 3d artist with whatever the hell a C++ programmer does when dishing out bonuses". But just try and run a team for more than 6 months without this kind of support. Try and explain that you blew your annual bonus budget on the guy who wrote a cool screensaver, so you can't reward the team which delivered the space shuttle software on time.
It doesn't always work like this - I've been in lots of places where HR were a self-sustaining bureaucracy with no clue as to what the real organisation was doing. But when it works, the HR team is as much a part of the special teams as the people who keep the laser printer supplied with toner.