Maverick Review Process

Abstract

The Maverick Review Process is a method in which each person reviews those that affect or are involved with their work. Also an individual evaluates each department of the company. There are no evaluation levels that are unattainable.

The Maverick Review Process is not the same as 360 Degree Reviews; however, as with most review processes there will be similar aspects.

Introduction

As with any Maverick approach one of the first things you should do is ask yourself, "What are the real goals of the review process?" Maverick Reviews identify the main goal of the process as being the improvement of the team. Another goal of the review process is to recognize an employee's performance.

Maverick approaches include the idea that salaries are known throughout the company. If you do not adopt the "known" salary policy you can still use Maverick Reviews. In justification of the "known" salary policy consider it thusly; simply stated everyone should be proud of their salary and feel they are worth receiving it, if not then they should consider if there is fairness in their workplace.

The Maverick Review process is different than 360 degree reviews. Granted there is no standard for 360 degree reviews, therefore one may exist essentially identical to the Maverick approach. Unlike the Maverick Review Process, 360 processes are typically managed and controlled by HR in a rigorous fashion. 360 reviews are setup and determined by management. Since the 360 review is complex and requires a significant amount of time to perform the process can not be continuously performed. 360 reviews are often driven by a questionnaire and thus being formal and specified can be fed into systems to create reports from the review process. After the score from the 360 review is determined the employee and the manager go over the report and the manager suggests actions, goals, and methods for improvement that I will call an action list. The employee has the opportunity to modify the action list and once agreed upon the action list is then kept so that it can be consulted as the employee is monitored by the manager. Usually in six months the review process is repeated.

In the 360 review process the most difficult task of management is to compile and analyze the data. This is probably true with most review processes. Management has the burden of interpreting the data and making the best business decisions possible. It is estimated that it takes 20 hours of work to analyze and synthesize the data of each reviewed employee. That is why it is suggested that management sets up the review schedule, because it is expensive.

In the 360 process everything is kept confidential. It is assumed that if the reports are not confidential then people will not give honest reviews of other people. Also, a 360 review is not a performance evaluation. It is concerned with how you are perceived by others and how to better work with the team. It is termed a developmental approach instead of an appraisal approach.

The setup of a 360 review has many essential elements to any review process. First you set up the review categories to be aligned with business goals and objectives. In subsequent reviews the categories are built upon the previous review elements and thus the review process is evolutionary.

Finally in 360 processes it is recommended to use software to perform the review and generate the review reports. Since the 360 process is not a performance review and is very costly to perform they are not done continuously or as regular as a performance review. As you improve your 360 process you will increase the throughput of the process.

Maverick Reviews are concerned with the productivity of a group or workers and the individuals that make up such a group. 360 reviews is a general approach that has a wide application. Therefore the Maverick Review process is considered what is known in the industry as a customized instrument for software development organizations.

Maverick Reviews are a type of mulit-rater feedback. Because multi-rater feedback systems can be manipulated it is essential that you have the right people. This is a chicken and egg problem. To find out if you have the right people you need to perform a thorough review. To do a thorough review you must have the right people. If you want to apply a 360 process or Maverick Reviews to an existing team then be very careful. You could easily create a severe problem. Just as you can not dump democracy on a communist state you can not dump Maverick Reviews on a traditional company. However, gaining the benefits of the Maverick Review process make it worth considering how you can introduce Maverick Reviews into your workplace.

Maverick Reviews do not require an HR department to manage and administer the reviews. This eliminates the expense of traditional 360 processes. The reviews are simple enough to be performed regularly. The 20 hours of analysis per review of a 360 process is eliminated. There is no specialized software for tracking the review process. The process is simple and to the point.

The Goal of Maverick Reviews

To improve the employees on an individual, team, and company level.

How Its Done

Each person on the team reviews everyone else on the team, them self, and their management. The review ranking can be one of the following: great job, good job, or poor job. Great job and good job rankings may merit some type of reward. Poor job will mean that the reasons for the rating will be specified and discussed. Realize, a poor job rating will be taken personal because it is personal. Also, a great job rating is personal and when a person receives a great job ranking he/she is glowing and smiling and people congratulate him/her and all that is personal as well. All ratings are personal. Just remember that and work with it. A poor job rating has a concise list of the issues that caused the poor job rating. If a person gets two poor job ratings then they will lose their position on that team and will have to find a new position within the company or in another company.

Teams also rank other teams that have an effect on them directly. If there is a company wide bonus and it is based on product delivery and sales then the development team is responsible to deliver and the sales team is responsible to make the sale. In-depth knowledge of the day to day work of external teams will not be sufficient to allow rankings of individuals. Therefore a team ranking will be performed based on public knowledge of published team performance.

An example may help.

Suppose a team of five software engineers, a software engineer team lead, two software testers, a project manager, a product manager, and a department director. Each person reviews every other person. The reviews are taken and tallied. Suppose that the product manager and one of the software engineers receive a poor job rating, one software engineer and one software tester received a great job rating, and the rest received a good job rating. When the ratings results are posted the two that received the poor ratings are visibly concerned. Their faces become reddened and they scowl at a certain team member as if to say, "I knew you didn't like me." Let's suppose that the product manager actually breaks down in tears and leaves the room.

Now there are several things that must be done. One is the consideration of natural human feelings. Another is the specifying of the reasons for the poor job rating. Also it must be determined if there is a coalition or some kind of attempt to control the outcome.

First there must be some time for emotions to settle. When this has happened bring the review group back together. I would suggest that the review results are presented in the morning and the discussion of the review commences after lunch. Now comes the open discussion of the reasons why the ratings were given. All of the ratings must be reviewed and not just the poor ratings.

Let's suppose that when reviewing the reasons for the poor rating for the software engineer there isn't a clear issue. The engineer had given them self the rank of good. It was the other engineers on his team and the team lead that had given the poor job rating. The reason they give is that the engineer doesn't work well with the team. The engineer doesn't make his code fit within the architecture that the team has adopted. The engineer does deliver the projects and product features on time and with high quality. For this reason the other reviewers gave the good rating. However the other reviewers do not understand the ramifications of not working within the architecture as does the engineers and the team lead.

Now the review of the product manager is considered. The poor rating comes from four of the software engineers and the two software testers. It is stated that the reason is the product manager continually changes features and their priority. The product manager had given them self the rating of great job. The reason the product manager says is that the customer is extremely happy with his responsiveness in adding and prioritizing the features for the product.

Now the other ratings are reviewed. It is discovered that there may be some block voting amongst the engineers in that four of them ranked them self great and had ranked each other as great. This is suspicious because it is typical that truly great people under-rate them self. It is also typical for people below average to continually rank them self higher than their true rank.

Also the team ranks other teams that affect them in some way. In this case they rank the sales team and the executive committee.

What You Do With The Results

Now is the time for edifying. Edify is a great word. While living in Spain and learning Spanish it soon became apparent that the word edify is about building. So, it is time to build the team. It is time to build the team members. Why do a review process if improvements are not expected?

The engineer needs to understand the architecture better. In this mocked example it is discovered that the engineer didn't use the architecture because the team didn't take the time to teach the architecture. This engineer was the last one hired and had been left out because of the urgencies and other factors that detoured the necessary training for the new hire. Since the engineer is very talented he was able to deliver his features independently. Now that the reasons are understood the person is re-rated. Considering the actual work environment the engineer had performed a good job and everyone agrees to change the rating.

The product manager needs to understand the effect of changing priorities and features. In this mock example it is discovered that the customer really wants the changes that the product manager keeps requesting. The customer is very happy with the project manager's effort but disappointed that the company doesn't seem to care. Everyone comes together and they realize the project manager needs to revamp the development process to be more agile. Once again the team rates the product manager and gives a rating of good.

Finally everyone is looking at the four engineers that ranked themselves as great. They realize immediately that they had not been great because they had let down the new hire by not training them properly on the architecture. Also they realize that the were not great because they had been complaining about the flip-flopping product manager and had not kept themselves current in new development processes in which they would have recognized that a change in process was needed. They re-rate themselves to a poor rating of which the group overturns and gives an overall good rating.

The results are used to improve the team. This means that you have intelligent, thoughtful, and considerate team members. Injecting this process into a team that is known for its good old boy networks, heroes, and empires will cause disruption. How do you know if you have a team that will not work well with Maverick Reviews? First, open your eyes and your ears. What do you hear? Do you hear things like, "Don't ever invite so-and-so to a meeting, they drag them out forever over fringe concerns that are not valid" or "I had to work 80 hours a week for the past two months to save this company because no one around here knows how to do anything" or "We need to start an elite team of developers to engineer the next generation product and here is the list of people that qualify." Those are some of the things you may hear. But what about things you may see? Are there certain teams that get all of the perks, all of the ten cent options, or the lion's share of the bonus pool? Are there certain groups that walk on water, than can not be frustrated or disturbed, or that are declared hands-off?

In Maverick Reviews there are no ranks that are used as an enticement. There is no exceeds expectations rank that no one can attain and is continually dangled as a carrot.

The results of the review do not need to be archived or maintained in a database. Any "dirty laundry" from the review stays with those that participated in the review. Talking about someone's performance to other teams and individuals will result in the "informer" getting a poor rating once they are discovered.

How Often Do You Have Reviews?

This will depend on the software development methodology that is being used. The goal would be to review the team members after the team members have met some kind of milestone. In an XP world this could be at the end of each release. In a Waterfall world this could be at the end of the development phase for each feature, component, or whatever your choice is for dividing up the work.

Since the team members perform the review you do not need to schedule HR or any resources other than the team itself. Maverick reviews also include the review of other teams as well as your own. Those reviews would be done when a larger corporate milestone is met such as the completion of a business quarter. Remember, this is a Maverick approach so do the review when it makes sense. When does it makes sense to do one? Probably when there is some data available such as the quarterly numbers, the results of the end of release reflection, or any other event that your company deems important.

A little story to help in deciding how often to review. My example is a basketball game. The scenario is this, there is one 0.2 seconds on the clock, your team is down by one point, and you are at the foul line. You miss both foul shots and the othe team in-bounds the ball and the clock expires. You lose. Everyone looks at you because you lost the game. I call this the last shot at the end of game syndrome. No one seems to remember that in the first half of the game that the Center missed two easy dunks and had the ball stripped from his hands four times.

I hope you get the point of my story. If your company does reviews on a six month or once a year basis then you need to make sure you don't goof anything up in the last few weeks before the review. All of your other activities during the year will be discounted due to human nature.

Review often so that the results are timely with the current state of the company.

OK, Now I Have To Fire Someone

As a guideline the participants of the process that hires someone are the participants in the process that fires someone. When hiring a member of a software development team the entire team participates in the hiring process. Thus the entire team participates in the firing process. When hiring a manager the participants are typically the ones that make up the reporting chain. When firing a manager the participants of the reporting chain will consider the reviews given by each team that works with the particular manager.

Suppose that someone has two successive poor ratings. The person must find a new position. You can feel confident that the review process is accurate. In Maverick Reviews and other multi-rater review process you will have fewer problems with correct ranking. The burden doesn't rest on someone that may be removed from the real work. The burden doesn't rest on one individual. The, what have I done for you lately, the last shot of the game syndrome, the horns and halo description is eliminated or at least greatly reduced.

In Maverick, if someone is "fired" from their team they can apply for any open position within the company. Just because a person doesn't perform well in one circumstance doesn't mean that they will not excel in another. Realistically it would be difficult for the person to find a position unless the team they left has a bad reputation of treating its members unfairly.
Whistle Blowing and Anonymous Complaints

There are other ways to learn information about a team or individual. Sometimes there is a whistle blower that can bring attention to a problem that needs addressing. Sometimes there are simple complaints that are made. These are all tidbits of information that should be taken serious. Listen, watch, and learn. That is the key. Don't delegate the responsibility of knowing your team and your company to the bean counters or soul-less reports, charts, and dash boards. Use their information but don't depend on it solely.

Conclusion

Maverick Reviews are a customized instrument for a multi-rated or 360 degree review process.

Make sure you have a team that is concerned about the welfare of each other before you introduce the review process.

A fundamental piece of information to make the review process work is that of everyone's salary is known. This does not cause civil war unless salaries are unfair. Unreasonable people will be removed through the review process.

The goal of the review process is to improve individuals, teams, and companies. Maverick teams are teams that are made of individuals that want to do a good job. It is the people that make the difference.

References

The Great Debates About 360 Degree Feedback
360 Degree Feedback: The Good, the Bad, and the Ugly