The person sitting in the next cube over from you may be doing the same type of work, perhaps even working on the exact same code that you are. However, she may be making 20% or 30% more than you. Sometimes the pay disparities are even greater. Of course, in most cases you won’t be aware of this since salary information is closely guarded.
Such disparities exist for a number of reasons. Technical skill sets, negotiating skills, etc. factor in, but often it’s just a matter of experience, or tenure if you will. The longer a person is at a job the more raises they’ll get. And even if those are just modest cost of living raises they can add up. If someone has the same job as you but they’ve been in that position for 10 years longer, with a 3% annual raise they could be earning 35% more. And with 4% annual raises the difference would be 48%.
But what if the other person has comparable levels of experience, or worse, less experience than what you have? What would explain the pay disparity then?
It’s possible that the other person may just better at their job. They could be more productive, writing more code with fewer bugs. They may be better at estimation and meeting their dates, and they may have more significant accomplishments. They may also work in a more high profile area and be more visible to management. They may also be better at advertising their accomplishments, as distasteful as that idea may be to some.
If you have accounted for all of these possibilities and still feel that you are underpaid, you need to look inward. Is there a reason why you might be underpaid? Or in fact, are you really underpaid at all? The only true way to tell is to test the job markets. You can probably get a feel for your market value from recruiters, or from doing a few interviews. You might very well find that you are already at market pay. And if not -- well, you already have a head start on finding new job options.
Wednesday, January 28, 2009
Sunday, January 25, 2009
Performance: Perception vs. Reality
When providing feedback to employees, you will often find that employees respond to negative feedback with surprise. It’s inconceivable to them that anyone could fail to recognize the brilliance of their work. And if there were any problems with their work, it was due to someone else’s mistakes.
Of course I’m exaggerating, but not by much. Fact is, most people have a fairly high opinion of themselves (and I suppose that would include me as well). Most people like to think of themselves as stars, or at the very least above average.
And yet, it’s been shown (sorry, no link handy at the moment) that the true stars tend to rate themselves more modestly than the less stellar performers. Why is this? Perhaps it’s because the top people are well aware of their limits and acknowledge them, whereas the lower performers have no idea just how limited their skills are. And when confronted with those limits, they often deny the charge, blame others for their failures, or deem those limits not important.
So as a manager, how do you reconcile an employee’s inflated sense of self with your somewhat less flattering assessment? You need hard facts: metrics, examples, data points. The employee will typically try and shift the blame, and you need to be prepared for that with hard evidence that is undeniable.
Of course I’m exaggerating, but not by much. Fact is, most people have a fairly high opinion of themselves (and I suppose that would include me as well). Most people like to think of themselves as stars, or at the very least above average.
And yet, it’s been shown (sorry, no link handy at the moment) that the true stars tend to rate themselves more modestly than the less stellar performers. Why is this? Perhaps it’s because the top people are well aware of their limits and acknowledge them, whereas the lower performers have no idea just how limited their skills are. And when confronted with those limits, they often deny the charge, blame others for their failures, or deem those limits not important.
So as a manager, how do you reconcile an employee’s inflated sense of self with your somewhat less flattering assessment? You need hard facts: metrics, examples, data points. The employee will typically try and shift the blame, and you need to be prepared for that with hard evidence that is undeniable.
Friday, January 16, 2009
Providing Feedback
Far too many managers fail to provide any meaningful performance feedback until it’s time for a review. It’s no surprise then that many employees are sometimes taken aback by critical reviews, as they never see it coming.
In an ideal world managers would provide continuous feedback and course corrections to their employees. However, most people, managers included, hate giving negative feedback. They worry about a conflict that may arise, where the employee takes the news badly, gets defensive, or becomes argumentative.
Perhaps these people have read Dale Carnegie’s seminal book, “How to Win Friends and Influence People”. In it he urged readers to never engage in criticism, which some equate with giving negative feedback. They interpret the advice to mean that if a manager has only negative feedback, they shouldn’t provide any sort of feedback at all. i.e., if you can’t say something nice about a person…
However, this is poor advice, or at least a bad interpretation of what Carnegie meant. Most employees in fact would appreciate feedback -- any kind of feedback, even negative -- over getting no feedback at all. At least with negative feedback they know where they stand with their manager.
As an employee, you should welcome feedback of any kind. Good feedback is always nice, of course, but aside from the ego stoking it’s not particularly valuable. More useful is negative feedback, as long as it’s constructive. In other words, what you want is feedback on what you’re doing poorly, and how you can improve your performance.
If you do receive negative feedback, it’s important that you not become defensive. If you do become defensive, your manager may also become defensive, and it can turn into a “He said, she said” type of blame game. Instead, you should take the criticism to heart, even if it seems unwarranted. Even if the criticism seems totally off base, you should take time to think about why your manager sees things in that way. It might just be a matter of perception, for instance, which might be remedied by keeping your manager better informed and engaging in a little proactive PR.
In an ideal world managers would provide continuous feedback and course corrections to their employees. However, most people, managers included, hate giving negative feedback. They worry about a conflict that may arise, where the employee takes the news badly, gets defensive, or becomes argumentative.
Perhaps these people have read Dale Carnegie’s seminal book, “How to Win Friends and Influence People”. In it he urged readers to never engage in criticism, which some equate with giving negative feedback. They interpret the advice to mean that if a manager has only negative feedback, they shouldn’t provide any sort of feedback at all. i.e., if you can’t say something nice about a person…
However, this is poor advice, or at least a bad interpretation of what Carnegie meant. Most employees in fact would appreciate feedback -- any kind of feedback, even negative -- over getting no feedback at all. At least with negative feedback they know where they stand with their manager.
As an employee, you should welcome feedback of any kind. Good feedback is always nice, of course, but aside from the ego stoking it’s not particularly valuable. More useful is negative feedback, as long as it’s constructive. In other words, what you want is feedback on what you’re doing poorly, and how you can improve your performance.
If you do receive negative feedback, it’s important that you not become defensive. If you do become defensive, your manager may also become defensive, and it can turn into a “He said, she said” type of blame game. Instead, you should take the criticism to heart, even if it seems unwarranted. Even if the criticism seems totally off base, you should take time to think about why your manager sees things in that way. It might just be a matter of perception, for instance, which might be remedied by keeping your manager better informed and engaging in a little proactive PR.
Tuesday, January 13, 2009
Productivity Ratios and Negative Producers
Numerous management studies have found there can be a 10-to-1 ratio difference in productivity between engineers.
Of course, the widest performance spread can be greater than 10-to-1 if you take into account your worst engineers. Technically it could be 100-to-1, or infinity. In fact, the math can break down if your worst engineer is a net negative producer.
How does an engineer exhibit negative productivity? Typically they write awful code that causes breakages and which have to be cleaned up by teammates. Or they may waste time in meetings arguing contrarian positions just because they like to yank peoples’ chains.
As a manager it is your job to isolate these negative producers and insulate your team from them. Ideally you’d show these people out the door, but there are usually complicating factors that keep them at their jobs longer than you’d like.
Also, it’s important not to blind yourself to the possibility that it might not be the individual that’s at fault for negative productivity. It could be the environment, or the team chemistry, or the nature of the technical problem being tackled. As I mentioned previously, a person can be a star in one realm and flounder in another environment. It’s up to the manager to spot these problems and do everything possible to mitigate them.
Of course, the widest performance spread can be greater than 10-to-1 if you take into account your worst engineers. Technically it could be 100-to-1, or infinity. In fact, the math can break down if your worst engineer is a net negative producer.
How does an engineer exhibit negative productivity? Typically they write awful code that causes breakages and which have to be cleaned up by teammates. Or they may waste time in meetings arguing contrarian positions just because they like to yank peoples’ chains.
As a manager it is your job to isolate these negative producers and insulate your team from them. Ideally you’d show these people out the door, but there are usually complicating factors that keep them at their jobs longer than you’d like.
Also, it’s important not to blind yourself to the possibility that it might not be the individual that’s at fault for negative productivity. It could be the environment, or the team chemistry, or the nature of the technical problem being tackled. As I mentioned previously, a person can be a star in one realm and flounder in another environment. It’s up to the manager to spot these problems and do everything possible to mitigate them.
Thursday, January 1, 2009
Writing Software is a Lot Like, Well, Writing
Continuing on the prior post’s theme of skills used in software development -- there are many analogies and comparisons between creating software and other endeavors. Putting up a skyscraper and designing an automobile are a couple of examples.
My favorite analogy for writing software however is writing a book. What type of book, specifically? Well, it would be easy to compare software to a nonfictional reference work. But I’ll compare writing a program to writing a novel, a piece of fiction.
In both software development and writing you have multiple threads or storylines that have to converge at certain specific points and in certain ways; otherwise the results could be disastrous for your characters and your application. Your characters might miss important developments in the story, and your program can end up deadlocked or crash.
There are differences, of course; with a novel the author may start writing freely without a predefined notion of where the story will end up. Sometimes the storyline works, and other times they may (figuratively) rip the page out of the typewriter and crumple it up, tossing it into a wastebasket that is already overflowing with crumpled up pieces of paper.
You generally can’t adopt such a haphazard approach to software development. In most cases you’ll start with a pretty good idea of what the finished product should look like. Still, some approaches to software development advocate the idea of ‘throwaway’ prototypes, or at least iterative methods of development where each iteration gets you closer to your ultimate goal.
There are other similarities I can think of between the two endeavors, tortured as the analogy might be. Authors of books need to flesh out the characters sufficiently so that readers can visualize them in their minds. Software developers also need to put a UI or ‘face’ on their applications, one that users can react to positive and productive ways.
Perhaps my favorite part of this metaphor is that both a book and software (say a website) are guided experiences. You have to anticipate and plan out what the user will see, and make sure the experience is a coherent and pleasant one. Of course, on a website a user may click anywhere and navigate at their leisure, while a book reader is unlikely to skip ahead. That just means the guided experience with software is more difficult to create, but it still remains a guided experience, as with a good book.
My point? Software is much more of a creative process than people recognize.
My favorite analogy for writing software however is writing a book. What type of book, specifically? Well, it would be easy to compare software to a nonfictional reference work. But I’ll compare writing a program to writing a novel, a piece of fiction.
In both software development and writing you have multiple threads or storylines that have to converge at certain specific points and in certain ways; otherwise the results could be disastrous for your characters and your application. Your characters might miss important developments in the story, and your program can end up deadlocked or crash.
There are differences, of course; with a novel the author may start writing freely without a predefined notion of where the story will end up. Sometimes the storyline works, and other times they may (figuratively) rip the page out of the typewriter and crumple it up, tossing it into a wastebasket that is already overflowing with crumpled up pieces of paper.
You generally can’t adopt such a haphazard approach to software development. In most cases you’ll start with a pretty good idea of what the finished product should look like. Still, some approaches to software development advocate the idea of ‘throwaway’ prototypes, or at least iterative methods of development where each iteration gets you closer to your ultimate goal.
There are other similarities I can think of between the two endeavors, tortured as the analogy might be. Authors of books need to flesh out the characters sufficiently so that readers can visualize them in their minds. Software developers also need to put a UI or ‘face’ on their applications, one that users can react to positive and productive ways.
Perhaps my favorite part of this metaphor is that both a book and software (say a website) are guided experiences. You have to anticipate and plan out what the user will see, and make sure the experience is a coherent and pleasant one. Of course, on a website a user may click anywhere and navigate at their leisure, while a book reader is unlikely to skip ahead. That just means the guided experience with software is more difficult to create, but it still remains a guided experience, as with a good book.
My point? Software is much more of a creative process than people recognize.
Subscribe to:
Posts (Atom)
