Assessing technical skill levels

[original PM]

Whilst I hate doing this 'the management' have asked that we get all of our engineers to assess their skill levels.

So we have come up with a skills matrix and we are trying to decide what grading will look like.

So far we have come up with

Amateur - less than 2 years experience, have only used the skill in a very narrow requirement set.

Competent - up to 10 years experience, have used the skill in more than 1 scenario and across multiple applications.

Expert 10+ years experience using the skill in multiple applications on multiple environments, has written peer reviewed articles.


Anyone any ideas or suggestions? do we need more than 3 grading options for example?

Any feedback most welcome!

[MyUserName]

I am not sure the writing peer reviewed articles bit fits. You can be great at programming without being published and you can get published without necessarily being good at programming.

[ladymuck]

I'd go for a 4 x 4 type rating so...

Proficiency
0 - Basic
1 - Intermediate
2 - Advanced
3 - Expert

Experience
0 - less than 2 years
1 - 2 - 4 years
2 - 4 - 6 years
3 - over 6 years

You could have someone with 10 years experience of something but they're actually pretty rubbish at it, or you could have a script kiddie with 2 years experience but is capable of hacking into your bank account and adding a few zeroes to your balance.

You can then plot people on an x,y scatter plot to see the distribution of experience vs proficiency/capability

[original PM]

I'd go for a 4 x 4 type rating so...

Proficiency
0 - Basic
1 - Intermediate
2 - Advanced
3 - Expert

Experience
0 - less than 2 years
1 - 2 - 4 years
2 - 4 - 6 years
3 - over 6 years

You could have someone with 10 years experience of something but they're actually pretty rubbish at it, or you could have a script kiddie with 2 years experience but is capable of hacking into your bank account and adding a few zeroes to your balance.

You can then plot people on an x,y scatter plot to see the distribution of experience vs proficiency/capability

That's a good point - will try that.

One of the challenges is that one of our devs is about 50 ish - has been with the company for 25 years but only rates himself as competent.

This is causing some people in 'management' to get a bit upset because he should be 'better' (which seems to just mean do more stuff quicker but..) - however for me the guy never complains, clearly has no interest whatsoever in doing anything but coding - and also when he delivers stuff it rarely has any bugs in it.

He is happy to try new stuff - but it can take him a bit of time to learn it - i think generally he is not academically great (think he started with the company stacking shelves before taking a role in the IT department many years ago)

Anyway the point I am trying to get to is is it acceptable to only be competent at your job or should you always try to be an 'expert' and 'leader in your field'?

[WTFH]

Anyway the point I am trying to get to is is it acceptable to only be competent at your job or should you always try to be an 'expert' and 'leader in your field'?

Some people are happy to do a good job and are not interested in being considered an expert, etc.

I think the management should ask themselves 3 more questions:
1. How often is the code delivered on time?
2. How reasonable were the timescales for the delivery?
3. How often does the code go back for rework due to bugs?

[original PM]

Some people are happy to do a good job and are not interested in being considered an expert, etc.

I think the management should ask themselves 3 more questions:
1. How often is the code delivered on time?
2. How reasonable were the timescales for the delivery?
3. How often does the code go back for rework due to bugs?

Good point - will float that question.

Think the main problem is new big boss has come in and so everyone needs to 'save money' (to make big boss look good obviously) - so saving money generally means working more hours for the same pay.

Which generally thoroughly pisses people off because the benefits of that go to 'big boss'.

So generally the new big bosses management team are tulipting themselves and looking for ways to lay the blame at the feet of other people.

Nothing new to see just getting bored of dealing with dick heads I suppose!

Hey ho.

[NotAllThere]

How you rate yourself is just a starting point. What matters is how your peers rate you. Management generally are not competent to rate technical skill.

I'm in agreement with WTFH - it's total cost of ownership of development that's important. Not how quickly you bash out version barely alpha.

(Incidentally, in my team, I'm the oldest by at least ten years, yet it's the young whippersnappers who seem reluctant to try anything new - or even not new. Yesterday one of them told me doesn't use a specific construct because he's never learned it. It's only been part of the language for 20 years..! )

[Hobosapien]

Isn't this the point of annual performance reviews so they can assess how the permies have performed to expectations?

If asked to self-assess then may as well say you're the dogs bollocks and it's up to the management to prove otherwise.

Agree with others, if billy big bollox boss wants to cut costs then it's competence of delivery rather than base skill level that matters. Otherwise the dolt will end up getting the best resources fired and left with a shambles.

Seen it all before, new boss comes in, restructures to prove himself (which may include outsourcing projects/teams), ends up in a worse position than when started, moves on swiftly to another company before his peers realise he's an incompetent fool. Can spot them on their CV as senior managers that change jobs every couple of years.

[WTFH]

Seen it all before, new boss comes in, restructures to prove himself (which may include outsourcing projects/teams), ends up in a worse position than when started, moves on swiftly to another company before his peers realise he's an incompetent fool. Can spot them on their CV as senior managers that change jobs every couple of years.

And they’ll claim that they were brought in to reduce headcount and costs, and that they succeeded. Once that was done they moved on as they needed a new challenge.

Very common, particularly among people in jobs way beyond their ability.

[woohoo]

I agree with most people here, time served with a specific technology is no indication of the level of proficiency.

The developer that describes himself as competent in my book is being honest. The more I learn the more I'm happy to call myself competent.

Really, if you are going to judge and rate developers then you need some decent criteria to do it against.

1. Are the projects they involved in generally a success.
2. Is their code easy to read and maintain. This is huge to me.
3, Do they mentor other developers or are they out to show they are the top dogs. Again, this is a biggy.
4. Extensive business knowledge? Again, this is important for problem solving.


You could go on, I usually do.