So, a friend of mine was fond of saying, "What if we turn the knobs up to 10 on good practices?".
We give semi-continuous feedback on all aspects of contribution. Everyone has a mentor that may or may not be the person they are working with on a daily basis. Anytime there is conflict within a team, we encourage it to be dealt with. We also tend to have retrospectives every two weeks on most projects which is mostly about "how do we work better together?" We have one-on-one meetings between mentor and mentee every 1-3 weeks for everyone (weekly for more junior or recent members of the team, less often for those who are well established in the culture). We use checkins (15five.com) so people take a few minutes each week to reflect and report on how they are doing, what challenges they are facing, and what progress they are making on their priorities each week. Then we have general reviews to get peer feedback every 3-6 months on how people are progressing in all the areas of "expectations" and pick 1-3 things the person should focus on that won't naturally happen without some effort.
We review compensation yearly independent of all these things... but the feedback we've given and gotten throughout the year feed into it. Occasionally, when someone is clearly knocking it out of the park in their progression, and we feel they are clearly underpaid, we'll give them a mid-year bump.
We also make sure the "bag of money" is somewhat distributed on a quarterly basis with profit sharing bonuses... so more emphasis is on the contributing to the success of the company and "sharing the wealth... as long as there is wealth" than on the "what's my raise this year"... everyone gets a raise every time we have a good quarter.
That said, in addition to reviewing base compensation once/year, we tweak our bonus formulas every year based on what we've learned over the previous year(s). We also give each person a yearly offer (once we lay out the tweaks in the bonus formulas) with the option to trade off some things about their compensation (more time off vs. more money, putting more of their compensation at risk for a increased reward based on company profits). Someone who wants to take some more time off with their family can do that whether they've worked for us 1, 5, or 10 years. Someone who has a pretty good handle on their finances and is willing to share the risk and reward can do so.
So, everyone gets feedback and gives feedback. What one person wants/needs is not what the next person wants/needs.
Not perfect, but the best we've got.
Continuous Feedback Loops... it's not just for Extreme Programming any more.
Take a look at a simple process called Team-Set Salaries. I created it in 2002 when I was a manager with a team of 50 agile developers and have used it ever since.
It embraces subjectivity instead of fighting it. TSS is collaborative and completely decouples this quaLitative feedback Kent is talking about from quaNTitative performance appraisals you need for compensation.
Fair salary-setting has become a non-issue in my teams.
Compensation should be tied to results, great working code, and the team's performance and, ultimately, the company, not so many feelings and emotions. Too much "subjective" noise in who has the most friends, goes to happy hour every Friday with the popular kids, wears cool clothes, and eats lunch with the CIO gets the big raise is far too common in the workplace.
I have seen, practiced, and experienced (both good and bad) that you can quickly drive desire behaviors by linking your expectations in combination with performance goals into the performance plan and then moving that fact home in your one on one or conversations with your direct reports and team.
Closing the feedback loop to every week with this information and keeping a "sliding" real-time performance mark is by far the best way to not make that quarterly or annual performance review the worst experience of an employee's career.
Add PLENTY of room for peer and self-evaluation in this process so it's a level playing field and you know where the team member's perception of their performance is relative to the team and others.
Add requirements in the "goals" section of the performance process for much-needed failure\experimentation and extreme-self-improvement (something that seldom exists in most "cheerleader" type goal-setting processes). Goal guidance is like, "set a goal to fall on your face extending yourself far beyond your abilities and then review\reflect and attempt the goal again record your progress or lack-there-of and share this experience with the team."
Well, I offered my last team the option on deciding how to split the sack of money for salary adjustments. The only condition I gave was that they would have to do it in such a way that they actually agreed, and that there would be no hurt feelings in the team.
They threw me out of the meeting to talk, and then came back to me after ten minutes and said they trusted me, and wanted me to do it. That worked well until the day I left for new pastures. They would have liked more money to exist, but they were not unhappy with how the money that existed was distributed.
I think most of the reason why that worked was that I am a developer, too, and we had already done an exercise to check if we agreed on who was the most skilled and productive team members. There was very little disagreement in the team on the relative rating of team members. We also found out that everyone is harder on themselves than the rest of the team that way.
So, a friend of mine was fond of saying, "What if we turn the knobs up to 10 on good practices?".
We give semi-continuous feedback on all aspects of contribution. Everyone has a mentor that may or may not be the person they are working with on a daily basis. Anytime there is conflict within a team, we encourage it to be dealt with. We also tend to have retrospectives every two weeks on most projects which is mostly about "how do we work better together?" We have one-on-one meetings between mentor and mentee every 1-3 weeks for everyone (weekly for more junior or recent members of the team, less often for those who are well established in the culture). We use checkins (15five.com) so people take a few minutes each week to reflect and report on how they are doing, what challenges they are facing, and what progress they are making on their priorities each week. Then we have general reviews to get peer feedback every 3-6 months on how people are progressing in all the areas of "expectations" and pick 1-3 things the person should focus on that won't naturally happen without some effort.
We review compensation yearly independent of all these things... but the feedback we've given and gotten throughout the year feed into it. Occasionally, when someone is clearly knocking it out of the park in their progression, and we feel they are clearly underpaid, we'll give them a mid-year bump.
We also make sure the "bag of money" is somewhat distributed on a quarterly basis with profit sharing bonuses... so more emphasis is on the contributing to the success of the company and "sharing the wealth... as long as there is wealth" than on the "what's my raise this year"... everyone gets a raise every time we have a good quarter.
That said, in addition to reviewing base compensation once/year, we tweak our bonus formulas every year based on what we've learned over the previous year(s). We also give each person a yearly offer (once we lay out the tweaks in the bonus formulas) with the option to trade off some things about their compensation (more time off vs. more money, putting more of their compensation at risk for a increased reward based on company profits). Someone who wants to take some more time off with their family can do that whether they've worked for us 1, 5, or 10 years. Someone who has a pretty good handle on their finances and is willing to share the risk and reward can do so.
So, everyone gets feedback and gives feedback. What one person wants/needs is not what the next person wants/needs.
Not perfect, but the best we've got.
Continuous Feedback Loops... it's not just for Extreme Programming any more.
Take a look at a simple process called Team-Set Salaries. I created it in 2002 when I was a manager with a team of 50 agile developers and have used it ever since.
It embraces subjectivity instead of fighting it. TSS is collaborative and completely decouples this quaLitative feedback Kent is talking about from quaNTitative performance appraisals you need for compensation.
Fair salary-setting has become a non-issue in my teams.
Compensation should be tied to results, great working code, and the team's performance and, ultimately, the company, not so many feelings and emotions. Too much "subjective" noise in who has the most friends, goes to happy hour every Friday with the popular kids, wears cool clothes, and eats lunch with the CIO gets the big raise is far too common in the workplace.
I have seen, practiced, and experienced (both good and bad) that you can quickly drive desire behaviors by linking your expectations in combination with performance goals into the performance plan and then moving that fact home in your one on one or conversations with your direct reports and team.
Closing the feedback loop to every week with this information and keeping a "sliding" real-time performance mark is by far the best way to not make that quarterly or annual performance review the worst experience of an employee's career.
Add PLENTY of room for peer and self-evaluation in this process so it's a level playing field and you know where the team member's perception of their performance is relative to the team and others.
Add requirements in the "goals" section of the performance process for much-needed failure\experimentation and extreme-self-improvement (something that seldom exists in most "cheerleader" type goal-setting processes). Goal guidance is like, "set a goal to fall on your face extending yourself far beyond your abilities and then review\reflect and attempt the goal again record your progress or lack-there-of and share this experience with the team."
I really do like decoupling feedback and ratings from compensation. The question that remains is, how do you decide on compensation?
I haven’t gotten to that part of the book yet.
Well, I offered my last team the option on deciding how to split the sack of money for salary adjustments. The only condition I gave was that they would have to do it in such a way that they actually agreed, and that there would be no hurt feelings in the team.
They threw me out of the meeting to talk, and then came back to me after ten minutes and said they trusted me, and wanted me to do it. That worked well until the day I left for new pastures. They would have liked more money to exist, but they were not unhappy with how the money that existed was distributed.
I think most of the reason why that worked was that I am a developer, too, and we had already done an exercise to check if we agreed on who was the most skilled and productive team members. There was very little disagreement in the team on the relative rating of team members. We also found out that everyone is harder on themselves than the rest of the team that way.
Ymmv. Worked for me.