Career Pathing?

I know that companies have the best intentions. They want to provide opportunity for their employees in hopes of retaining them and encouraging desirable behaviors. They want to reward those who perform well and eliminate the dead wood. Even so, it is 2010 and career pathing is done, like annual reviews is done, like the 80s are done. This is doubly true for agile organizations where the dynamics are so very different.

The old idea was that an employee would join a career path, and that path would lead them to some management or technical position that would provide them with respect from peers and superiors, autonomy (perhaps their own team to lead), and increased compensation. Employees could see if they were tracking or not, and this would provide incentive to excel by doing the things the employer most highly values. This is not a bad idea and it used to make a lot of sense.

Now career-pathing is an answer to a question that nobody is asking.

• Formal roles and titles have never meant less. Organizations are (thankfully) flatter now, and teams are likely to be mixed groups of seniors and juniors and consultants and contractors. Gone are the days of the guru programmer directing a team of insensate code monkeys. Gone are the days of specialized stratifications. Generalism is killing the career path.
  
• The average time a programmer stays with a company is 3 years. Many of us have outlived multiple employers, even. We don't have the long-term stability that the IBMers had in the 70s and 80s. What is the sense in pathing a career for someone who won't be around? Why build a path that lasts longer than your company? Temporariness is killing career pathing within any given business.
• Programming is not a management skill (as management is practiced), so a path that leads one from writing server back-end code to vice presidency does not really make sense. The Peter Principle explains how much it hurts to promote people out of their competencies. Rising through the ranks is not necessarily the value proposition it was once considered. It still makes sense to groom someone whose interests lie in the area of software development management (Lord knows we need competence there), but in general, the Peter Principle has called career pathing for programmers into question.
  
• Career pathing limits rather than expands options. A technical person has many directions in which to grow. They may take a strong interest in IT and tool-building, database management, performance management, systems administration, user interface development, team coaching, technical writing, technical management, human resources, or any other useful skill. Many paths are necessary to move the professional forward in a way that is meaningful to him.
  
• There is a means/ends juxtaposition in career pathing. It becomes important whether one is tracking well, rather than whether he is doing good work and producing value for the company's customers. It has happened often enough that the things that make our customers successful are not the things that get us promoted, and can even get us fired. Distracting from customer value degrades the career path.
• In a typical career path, employees compete against each other for increasingly rare positions at higher levels. Esther Derby has written much about how this defeats morale and teamwork. In some situations one might find the "kiss up, kick down" strategy to be successful, where one panders to his bosses while sabotaging his peers and underlings. By political maneuvering, he is promoted (even "fast-tracked"), at the cost of productivity and harmony within the company. Distructive abuse of the career path discredits and defames the process.
  
• Organizations adopt an "up or out" point of view, so that people who perform well in their current position but show no enthusiasm for the next station on their path are devalued. Depriving the company of skilled, satisfied technical workers brings disdain upon the career path.
• Again referring to Esther Derby's work, we find that it is not possible or advantageous to try to isolate and rate the work of an individual in a collaborative effort. It is sufficiently hard and damaging that career pathing among highly-productive, coordinated teams actually reduces the effectiveness and harmony of the organization.
  
• Career pathing isn't even a particularly good way to award respect, autonomy, or compensation. Profit sharing, cost-of-living adjustments, etc have shown to be better ways to award people who work on teams.
  
• It's not a lean nor agile way to proceed, as career pathing done well is a complex system that is not needed to produce quality work and increase team collaboration. It is unnecessary to improve quality and morale. It is an expensive waste of time and a distraction from the work of doing work.
• You already know who the skilled programmers are, who the subject-matter experts are, who the weaker players are, who has leadership potential, who is watching the calendar and the budget, and who is just watching the clock. On a modern team (esp an Agile team) we try not to separate the leaders, but keep them in the team to bolster the weaker players. A strong team member earns respect from his peers by doing good work, which lends him further autonomy. An official tracking system only serves to usurp earned organic authority, which casts further doubt on an official promotion track.
  

Realize hat the author claims to have no special HR savvy other than having been a human resource for going on 31 years as of this writing. From his viewpoint, the career path is naive, damaging, and irrelevant in 2010. He remains willing to be convinced otherwise, and welcomes all arguments to the contrary as well as encouragement and further mentoring on the subject.