I'm not a big fan of career ladders. Or, more accurately, perhaps I should say, companies that pursue a
detailed career ladder system often get something different than they expected, and, like pandora's box, once you're Microsoft and have and incredibly complex and byzantine system, it's often impossible to put everything back the way it was.
The idea of a career ladder seems so simple; plenty of books on testing and test management have a bunch of templates in the back you can practically cut and paste.
But ideas have consequences. If you'll allow me, I'd like to share a little bit about the unintended consequences of a career ladder - and some things to do about it.
Some Cultural Assumptions
Thanks to the early work of "visionaries" like Frederick W. Taylor, most corporation make some distinction between managers, who 'work on the work', and do-ers, who actually do it. In Taylors words, we "separate" the workers from the work.
And some people really do want to Just Do Stuff, or JDS. There's nothing wrong with that. To paraphase Ron Padavan, taking all of our best and brightest and pushing them into management leaves the people who are left as the 'dumbest and the stupidest.'
So, eventually, enlightened management may agree that it's okay for some very senior people to be payed more than some very junior management. So we create a "senior" job description.
But a one-step career ladder is a paradox. After all, the promotion a kind of a stick to incent people to work hard. But once people have the "senior" title, they've got nowhere to go. What's next? The company needs to develop an entire career ladder.
The Evolution of the Career Ladder
Did you know there is an entire job category called a "compensation specialist"? You can actually earn a certificate in it, which is, in some HR circles, a respected credential. The next common tactic is to hire a compensation specialist into HR, then set up job descriptions and detailed technical career track. It typically looks something like this:
Technicians typically require a high school education or so and fit wihin a certain pay range.
Analysts generally require a two-year degree and fit within a different pay range.
Developers and Engineers require a four-year degree or equivalent experience.
Any job can also have a small number of
Coordinators or
Administrators. Coordinators essentially do "management" work without supervising, which administrators are deep, highly-compensated specialists with a job description.
Leads are managers in training; they do not actually do the annual review themselves.
Supervisors are first-time leaders.
Managers are second-line leaders, and we can have directors, VPs, etc above that.
Any job can then be Associate (or "Junior"), "plain", or Senior. We'll have sub-stata pay grades within each job, so for example, a senior technician might be pay grade 20 and an associate analyst might be pay grade 19. Or 200 and 190; I believe the multiplication by ten happens in order to allow still futher sub-strata. For example, we could now create a level 195 if needed.
The administrator jobs provide a technical career track. You might call them "distinguished test engineer" or "Architect."
You know a compensation analyst is running the show when you try to create an "architect" role and it comes back "administrator" and someone in HR tells you it
just has to be that way.
And it's all crap.
You see, after going through this massive exercise, you'll likely have a mountain of job descriptions - but by the time HR has blessed them, they'll be out of date. They'll also be designed by committee, so they'll be sanitized to only what everyone can agree on. (The old joke that a camel is a horse designed by committee has more than a little truth in it.)
To keep these things from being out of date, you'll end up using generic terms, like "the test engineer does testing on projects, and may provide some leadership on Medium Projects."
Thus, the difference between the test engineer and the senior test engineer is that the word "medium" is replaced with "large." And for the lead test engineer, we insert a bullet point that says "leadership"; in fact, we insert pretty much the same bullet point for every type of lead, just switching the words around.
If you've picked up on it, the overwhelming desire here is to make all jobs look the same, so we can easily manage them from an HR point of view.
The problem, which long time readers have already picked up on, is the vast difference between doing something the easy way and
doing it well.
A different way
Now in a large organization, there will always be these legal issues why we need a career ladder. You know, we have to provide a paper trail for why we pay Joe $50K/year and Sally $70K, in case Joe wants to sue.
It's just that, in my experience, all the time invested in job descriptions doesn't provide a lot of value to the business. The company announces an initiative to redo job descriptions to solve some specific problem, we go off and spend two years retooling things, compromise with HR a thousand times and within our departments a thousand more, and end up with ... something at the end. A few people involved with the project get a gold star on their annual review. But does anyone notice if the original business problem was solved?
In my experience, it hasn't been. What job descriptions often do is provide the tech staff the ability to say "that's not in my job description" and push back on work. Or, like the
paper airplane game, job descriptions can split team artificially into Folder, Bender, Pilot, and Project Manager, when the team might be best of self-organizing and figuring out for itself who should do what.
The return on investment from the job description effort may be tangible, but it's likely not a very big number. In many cases, he company would do better to take the hours invested and instead put the money in a saving account.
In my life
At Socialtext, I'm a member of the technical staff. Somewhere out there there is a job description document for me that says "QA Lead", and my salary is provided parameters by that, but we just don't focus on it. My main incentive -- the one that really matters - is to help the company be successful. The objective measure of that is that I get to keep this great work from home job, that salaries will go up, and my stock options will become more valuable.
In the mean time, in order to accomplish our goals, I've been in constant communication with my boss, our vice president of engineering, and even our CEO. Less than my title, I care about what type of work I am doing and the scope of my responsibilities.
Conclusions
I do believe that senior people who stick around at the same company can be extremely valuable - and should be rewarded for it. So yes, I do agree that it's good to have a few very highly compensated technical roles - Distinguished Engineer in Test, Chief Tester, Technical Fellow, Partner, Principle Consultant, and so on.
What I don't want to do is to spend so much time ganking around with job descriptions that we lose track of the mission - to deliver value to customers through software. And I've noticed that the detailed job description game is a black hole from which value doesn't want to come out much.
So if you're talking about that road at your company, please, do it with your eyes open. Another option to consider is the 'Federal' Organization, where every company consists of many, many, small independent business units, each with it's own profit and loss, each independently operated. Peter Drucker wrote about that in
The Concept of the Corporation in 1946; every MBA I have ever met had to read Drucker in Business School. Paul Graham describes how any company can organize this way in his essay
The Pooled Risk Company Management Company.
My real-world boss, Ken Pier, worked at a division run like that for nearly three decades. A tiny little division of Xerox called the Palo Alto Research Center (PARC). In that time, they delivered the world's second personal computer, invented the etherrnet, the mouse, the windowed operating system, and object-oriented computing.
I'm for career development, but, focusing on job descriptions and titles? I suspect we can do better.
UPDATE: Jim Terpstra emailed me to ask about Construx, the software company created by Steve McConnell. Construx has a reputation (that I agree, they earned) for a well-defined and mature career ladder. What about that?
Well, a few things. First of all, the construx career ladder has some actual well-defined requirements for the levels, including what kind of professional development someone should do in order to move up levels. They are, as I implied above "doing better", and showing one way to do it.
I can't help but notice, however, that something is going on between
version 1.0 (more detail
here) and the
current version of the construx ladder. It's got a bunch of changes - each one small, individually they seem to make sense ... but when you add them up, there whole is less than the sum of it's parts.
I suspect the construx ladder has been committee-ified.
Still, it's far better than what many other companies provide, and for that, they should be applauded.
I can't help but notice two other things about contstrux - one, they are a consulting company, and, for some reason, career ladders tend to work better in consulting companies -- after all, if the consultant increases his value in a 'measurable' way, he can also increase his bill rate. And if the bill rate goes up, consulting companies generally tend to be ok with passing on a title and some of the money to the consultant. I don't have a problem with that, in my book, that is ethical behavior in a free market system.
I can't help but notice that in IT shops, things get more complicated; they just don't tend to turn out that way. That is what this post was about.
Secondarily, regarding "not in my job description", check out what constructs adds to a
typical job description:
Inclusive Job Definition. Over time, Construx will always work to maximize the match between a person’s interests and the available work. At any given time, however, Construx requires employees to be flexible in keeping the company running. At times this can include activities as mundane as stocking the soda machine, sweeping the floor, unjamming the printer, and so on. As a small company sometimes the job description is "Whatever needs to be done by whoever is available to do it."
-------> One other thing I said is that the ROI of job descriptions is surprisingly low, and I stand by that. By open-sourcing it's career ladder and using them as a (valid) marketing mechanism, Construx found a way to multiply the ROI of it's career ladder effort - and good for them. They deserve it.