We have a team of 20+ developers, of mixed skills and varying levels of ability in each.
Some are C#/MVC4/.Net 4.5 developers cutting new code, some are VB6-ers maintaining our critical legacy apps.
For each, we have a 'Career Progression Framework' - an internally available list of what you need to do in order to move from Trainee Analyst Programmer Levels 1, 2, 3 and 4, to Analyst Programmer Levels 1, 2, 3 and 4, into Senior Analyst Programmer Levels 1, 2, 3 and 4.
Admittedly, the CPF we use is well out of date and needs reworking, which is a straightforward process itself.
With new technologies coming out in the .Net field all the time, this framework almost needs to be akin to walking up an escalator as in moves downward, as the newer stuff should be known to the top of the 'tree' before the trainee gets to it.
One thing to bear in mind here, is that at each stage, the developer is given a small pay increase, as a reward for their efforts, but in most cases, this is the incentive to 'climb' the ladder in the first place; if they've received an increase for getting the new stage, HR might have issues with it being removed!
I know developers should be keen on keeping their axes sharpened, but in reality, not all developers are like that, unfortunately, and they are what they are.
The problem is I am trying to determine the best way to grade our developers based on their specific skills and framework knowledge and am wondering the flaws with my specified approach. Please keep in mind that answers should be pertinent and exclusive to the unique challenges in grading software developers in the organization.
EDIT: On-site and off-site training is offered to developers.