what to expect in Annual Review
-
Hey guys, My review is coming up and i just wanted to make the best of the time when i have a chance to interact with my supervisor Any advice ?
One of the reasons I am stearing away from full-time employment and more interested in contract work is because of the issues associated with raises. It is rare when I see full-time employee developers: - Whose reputation soars - Who work hard on grunt projects and persevere and succeed to get into the club so that they can work on more interesting projects - Who are so valued by their companies that the company offers them more money so that they don't "defect" to a competitor. More often, I see developers whose reputation is undermined by gossip, who get bored working on inane projects, and that there is zero loyalty between employers and employees. I also think that it is somewhat absurd to base a raise based on how a developer interacts with his team-mates. How would you like to rate a house constructor on whether he plays sports, or how quickly he responds to your voice messages? A developer should be measured and awarded based on clear and easily measured objectives, like bugs per # of lines of code. My opinion is that the review process for developers, as I have seen it, is usually useless. I have never seen a developer who knew what his/her key performance indicators are. As a result, the comments from the review come as a complete surprise, which everyone knows is a no-no. You might want to read this book. I read it, and it helped me: www.corporateconfidential.com. You should at least watch this: http://www.corporateconfidential.com/press/CNNHeadlineNews02282006.php4. I wish you luck in your review! Richard
-
Yes, it does. In all the reviews I've ever had over my, well ... long, career I'd have to say that the VAST majority of the issues with any review had to do with interpersonal skills and very little to do with technical ability. Very interesting. -CB ;)
CodeBubba wrote:
VAST majority of the issues with any review had to do with interpersonal skills and very little to do with technical ability
Translated: "It's a popularity contest but we're not really allowed to tell you that...." I tend not to be very popular with the raise givers because I actually tell them the truth of the matter rather than what they want to hear. Generally what they want to hear is 180 degrees out from the reality.
Mike Poz
-
CodeBubba wrote:
VAST majority of the issues with any review had to do with interpersonal skills and very little to do with technical ability
Translated: "It's a popularity contest but we're not really allowed to tell you that...." I tend not to be very popular with the raise givers because I actually tell them the truth of the matter rather than what they want to hear. Generally what they want to hear is 180 degrees out from the reality.
Mike Poz
Mike Poz wrote:
Translated: "It's a popularity contest but we're not really allowed to tell you that...." I tend not to be very popular with the raise givers because I actually tell them the truth of the matter rather than what they want to hear. Generally what they want to hear is 180 degrees out from the reality.
Hi Mike, Yes, as unfortunate as that might be - it's often the truth. -bruce
-
Ware@Work wrote:
maybe, but more likely were underpaid or now overpaid.
Or maybe I'm just really good at what I do and the company really recognizes that. Plus, I dont know of amny programmers who don't feel they are underpaid. Just a thought
"Well yes, it is an Integer, but it's a metrosexual Integer. For all we know, under all that hair gel it could be a Boolean." Tom Welch
Psycho-*Coder*-Extreme wrote:
Or maybe I'm just really good at what I do and the company really recognizes that
There's an inherent flaw in the salary system for many companies that hire software engineers. The longer you've been at any given company, the more likely you are to be making *less* than a new hire at your current level. It's not that you're not worth what they are making, or that the new hire is worth more than you, it's typically just that salary increases don't always happen the way they should to maintain that equality. Eventually the inequality in salaries comes to a boiling point (usually after a fair number of legacy workers have complained loud enough to management) and so "adjustments" are made rather than "merit increases" to restore the balance.
Mike Poz
-
Psycho-*Coder*-Extreme wrote:
Or maybe I'm just really good at what I do and the company really recognizes that
There's an inherent flaw in the salary system for many companies that hire software engineers. The longer you've been at any given company, the more likely you are to be making *less* than a new hire at your current level. It's not that you're not worth what they are making, or that the new hire is worth more than you, it's typically just that salary increases don't always happen the way they should to maintain that equality. Eventually the inequality in salaries comes to a boiling point (usually after a fair number of legacy workers have complained loud enough to management) and so "adjustments" are made rather than "merit increases" to restore the balance.
Mike Poz
In my experience the 'adjustment' is that all the guys with the experience get fed up and leave takeing their many years of experience to another company. TBH it's almost the only way out of the 3% trap Russ
-
One of the reasons I am stearing away from full-time employment and more interested in contract work is because of the issues associated with raises. It is rare when I see full-time employee developers: - Whose reputation soars - Who work hard on grunt projects and persevere and succeed to get into the club so that they can work on more interesting projects - Who are so valued by their companies that the company offers them more money so that they don't "defect" to a competitor. More often, I see developers whose reputation is undermined by gossip, who get bored working on inane projects, and that there is zero loyalty between employers and employees. I also think that it is somewhat absurd to base a raise based on how a developer interacts with his team-mates. How would you like to rate a house constructor on whether he plays sports, or how quickly he responds to your voice messages? A developer should be measured and awarded based on clear and easily measured objectives, like bugs per # of lines of code. My opinion is that the review process for developers, as I have seen it, is usually useless. I have never seen a developer who knew what his/her key performance indicators are. As a result, the comments from the review come as a complete surprise, which everyone knows is a no-no. You might want to read this book. I read it, and it helped me: www.corporateconfidential.com. You should at least watch this: http://www.corporateconfidential.com/press/CNNHeadlineNews02282006.php4. I wish you luck in your review! Richard
Thanks a lot for your advice , That book seems to be awesome, will buy today and read it before the review :)
-
No matter how good the company you work for is - you should always take corporate promises with a grain-of-salt. If they actually come through on a promise then consider that a bonus; then you won't be disappointed. I think much of the time these promises are made with good intentions - but in business I've found that good intentions don't usually amount to a hill of beans. I work for what I consider to be an excellent company - but there always seem to be circumstances that come up that cause promises to be broken; so it's better to just smile when they make the promises and not count on it. -CB ;)
CodeBubba wrote:
you should always take corporate promises with a grain-of-salt
thanks for your advice , after reading all these , i am definetly disappointed a bit but became more real i think
-
If you are on this site much than you should be good enough that the programming won't be a roadblock for your career. I would interact with your manager, and everyone else for that matter, in the nicest way possible. Just be amicable, agreeable and try to make people laugh. It is unfortunate but politics usually matter more than performance. To help the cause, in your review, ask your manager if her boss has any problems with team and if there is anything you can do help. Say to him, "if you're happy, I'm happy". Oh and accept any criticism and say that you will do your best to improve. Don't make excuses, managers hate that. Once you are having your review, your salary increase has probably already been determined so there's no point in arguing during the review.
Thanks for the suggestions, I am afraid , i will never be able to do that. Most of the time i keep the talks to the work level only. If salary review has already been determinded, then why do we need to TRY to make your supervisor happy with all the happy go lucky attiitude ?
-
DeepWaters wrote:
thats so sad
but true. In our case, sometimes they have to scramble to get to talk to everyone before it shows up in your check. There are a couple of times over the last 16 years they missed and you got the surprise in your check before you got your review. As part of the review process the supervisor has to often submit his request for raises to upper management, who then forward it up as a per line item up to the higher level. They then either approve the total increase in wages, or reduce it and let the managers fight over who gives what to whome. In other cases, like here, there is a "raise pool" meaning it flows down from the top. The highest level of management determine the dollar figures for raises that period. Then the next level of managers discuss distribution with upper management, when that is decided it again flows down to the next lower level and reviews are compared for a median level raise, lower level raise or upper level raise, the net total must equal the pool for that division. This is why it doesn't do much good to argue the subject. Not to say you cannot, but recognize that if you do, it must go back through that process from bottom up for approval and it will take a while. The larger the company the slower the process. Once the raise-pool has been determined any changes in that has to come out of someone else's pay (laying off someone) or out of company profit. There is some margin in there, emergency hiring, or temp hiring, or loosing someone and overlapping for training, etc. But pulling from that margin means they can't use that margin for what it was intended for, so it is put into careful consideration and weighing the risks. Recognizing the process is more complicated than telling your supervisor, "I wish it were higher," is good for you and them. You are not the only employee, so the weight of the raise situation is weighed company wide not just for you.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
that seems to be a lot of insider information, i was totally not aware of thansk a lot
-
CodeBubba wrote:
VAST majority of the issues with any review had to do with interpersonal skills and very little to do with technical ability
Translated: "It's a popularity contest but we're not really allowed to tell you that...." I tend not to be very popular with the raise givers because I actually tell them the truth of the matter rather than what they want to hear. Generally what they want to hear is 180 degrees out from the reality.
Mike Poz
Hey Mike thaks so mmuch for your advice as a matter of fact , i think i am quite good technically, but in the popularity contest , i might be far behind :(
-
Plan ahead, work out a few options.
ahah thats a good suggestion :D i can see the ray of light