Recognition for a Job Well Done

This time of year, many companies and organizations begin to evaluate their employees to give them their annual appraisal. It occurs to me that the way organizations evaluate their people is most likely related to their theory of management and employee high performance. Two basic methods come to mind: The collegiate method and the ranking method.

The Collegiate Method

I called this first method of appraisal the collegiate method because it follows what one might see in a college setting. That is, each person can vie for the top spots and if they complete a set of requirements or goals they get rated at the top. So, if I get a 100% on a college exam, I get an A. If my neighbor gets 100% they also get an A. Since knowledge of the topic is the primary concern, multiple people meeting high standards can mean that there is a broad understanding of the topic. Unfortunately, it can also suggest that the measure may be flawed.

I see the advantage of this method of appraisal being that each person has an opportunity to receive a top rating if they follow certain guidelines. If done properly, employees that work hard and meet the goals of the organization are rewarded, while those that do not are not. The problem seems to be that just like college grades, the top slots may become inflated because the managers are not doing their jobs—they avoid the tougher conversations with the employee.

The Ranking Method

I am calling the second method of appraisal the ranking method. Unlike the collegiate method, only a select few can be at the top—and some people must be at the bottom. The advantage of this type of appraisal method is that you reward the best of the best and can concentrate on improving the lowest contributors (at least, lowest relative to their peers). So, even though I may meet a set of goals for the organization, I may not have gone above and beyond: in my prior analogy, I cannot get the A because someone else did.

I see the advantage of this method of appraisal in trying to initially build a higher performing team. It gives the team and you a way to understand where your top contributors are. On the other hand, doing this for too many cycles would seem to erode trust in the employee population—especially if you are not continuously replacing the lowest people. Since people's performance does not always change that much from year-to-year, the same people may wind up at the bottom. That cannot be good for their morale.

Agile Software Development - Business Culture and Change

Traditional software development methodologies primarily focus on the process that an organization follows to build and release software. Agile software development methodologies approach software from a social perspective and advocate collaboration over strict processes. This is not to say that traditional methodologies ignore the social perspective or that agile methodologies ignore the process perspective.

Nevertheless, the methodological emphasis of traditional software development can become woven into the culture of an organization, making it difficult to adjust to agile methodologies. Large organizations would seem to have the most difficulty making changes to their culture (in general) due to the number of people they need to convert and the higher probability that individuals and teams are not in one location, making communication and reinforcement more difficult.

I have heard that deep cultural change in an organization can take 7-10 years to be successful—particularly in a large organization. While individual agile techniques predate some of the traditional methodologies, their working in synergy and the social emphasis did not come about until the late 1990s. But, putting it all together and gaining traction in an industrial environment are two different things.

As we sit on the cusp of 2008, I am starting to see some real traction in large organizations. Agile has matured as well: the zealots who wanted us to do everything in a one-size-fits-all fashion (while decrying similar calls from their more traditionally oriented bretheren) seem to no longer dominate the conversation. Nevertheless, I find myself wondering when that 7-10 year period began (or will begin, as the case may be) and whether we will be moving on to something else once that transformation is complete, as I am sure we will be.

In my own case, I think I can peg the beginning of that cultural change in my organization to early 2004 when, after a series of highly visible internal project failures, people began to ask whether they were developing software the right way. I have to admit that I was in the right place at the right time. I have always had a solid record of delivery and was asked to lead and "clean up" this troubled area. The fact that individuals were more likely to try something new is something I was happy to take advantage of. In the end, I was only able to go so far before the culture got in the way.

I guess that means we are only four years in. The next three-to-six years will be interesting.