Agile Performance Reviews

What are we doing wrong?

By and large, the annual performance review process at most companies is broken. The very idea of having a meaningful conversation about performance once per year is laughable. Unfortunately, this mentality persists in many of today’s corporations. Most people simply don’t know a better way, and despite constant grumbling and cynicism from the staff about the process, few companies are willing to change.

To change, either keep performance reviews as they are or eliminate performance reviews. This article is an attempt to propose a third solution to the problem.

Certainly Adding Objectivity Couldn’t Be Bad

For the companies that do accept the need to change, they generally end up going the wrong direction. They hear complaints about the process being unfair in one way or another, and they attempt to pile on a bunch of objectivity in order to correct the perceived unfairness.

There are two main problems with your KRA and Objectivity. The first is that any key performance indicators that are easy to measure are rarely the things that you really care about. The second major problem with this approach is that, even conceding that you can find very specific things on which to measure performance, human judgement still has to enter the picture in order to make a rating for that key performance indicator. As soon as human judgement enters the picture, all objectivity is cast out the window.

I completely understand why it seems like we should strive for objectivity, but I feel strongly that objectivity is the wrong approach. In addition to the reasons mentioned above, the strengths that make one employee good at their job are completely different than the strengths that make another employee, in the same role, good at their job. Adding objectivity to your performance reviews is an uphill battle that you’ll lose every time.

Move Away From KRA and Towards Free-form Feedback

Instead of rating employees on row after row of key performance indicators, try providing them with meaningful feedback about behaviors that they exhibit. While results are what the company wants to see, targeting behaviors that lead to those results is the proper way to give feedback to an employee, positive or negative. This feedback should target behavior, should be specific enough for the employee to understand what was desirable or undesirable about that behavior, and should explain why you care about that behavior.

On a side note, for feedback to have the maximum impact, it needs to happen as close to the observed behavior as possible. What this means is that anything that appears on an employee’s review should have already been discussed with that employee at some point during the review period. If the employee is surprised by something on their performance review, you have some work to do as a manager.

Instead of trying to come up with specific criteria for each job, strive to provide the employees with positive and negative feedback based on the mission, vision, and core values of your company. Here are some examples of what that might look like.

Q. What does the employee do well?

• When we needed a QTP solution for a customer, you stepped up and volunteered to learn new technologies to make it happen. Always add value.
• When on an extended support call, you overheard the customer mention she was hungry and schedule call after lunch break of an hour. Delight the customer.
• When a customer installed software on their server that broke certain functionalities, you got the team together to come up with a solution. Create and innovate.

Q. What could the employee start doing that they don’t already do?

• I know you don’t like to sit through customer support calls, but sometimes that support reps really need developer input to solve problems.

Goooooooooaaaaaaaaaaaals

I’m sure we’ve all heard that goals need to be S.M.A.R.T. (Specific, Measurable, Attainable, and Realistic, Timely). But do we need goals at all? Personally, I feel that if an employee clearly understands the expectations of the job, they can be successful. I’m not going to force anyone to come up with some arbitrary number of personal or professional growth goals above that. I would certainly prefer that someone stretch themselves and attempt to exceed those normal duties, but just meeting expectations is still a successful employee.

However, there’s a big difference between a successful employee and a “strong” or “outstanding” employee. If I choose to spend my time at home playing with my kids instead of attending training or reading books about leadership, I don’t think I should be penalized for that. I can still come into work and do a good job.

Feedback From Your Peers

One of the most powerful aspects of a performance review is feedback from peers. There are many ways to collect and deliver said feedback, but I usually anonymize feedback in order to encourage candor and honesty. However, this does not mean that anyone can say anything about another person and be off the hook. If you can’t back up your feedback with specific behavior, you’re not helping, you’re complaining. Complaining is not going to go on a review.

Recognize that not everyone is going to be comfortable providing feedback about their peers. Some people will only give you positive feedback, some people will provide very vague (and thus unhelpful) feedback, and some people will give you no feedback at all. Don’t push too hard, but feel free to train others in the organization about how to provide feedback, and ensure that you’ll keep the feedback anonymous in order to garner candor. It might take several review cycles to get everyone comfortable with providing feedback, but the results are definitely worth it.

We’re All Still Just A Number

Lastly, because at some point we HAVE to, but not because I like to, we have to rank employees against a known scale. I’ve played around with a lot of scales, and the one I like the most is essentially a five point scale that goes something like unsuccessful, variable, successful, strong, and outstanding. Right in the middle is “successful”, which is just what it sounds like. You come in everyday, you meet expectations, you get the job done. There’s absolutely nothing wrong with that, but there’s room to grow.

Unsuccessful employees simply aren’t getting the job done, and are usually causing a distraction in the workplace. It’s quite rare for an employee to receive an unsuccessful rating on an official review, because unsuccessful employees are generally removed from the organization long before a formal review is conducted.

Variable employees can be outstanding at some tasks and unsuccessful at others. Variable employees also tend to not be with the organization for very long, so seeing a variable rating on a review is typically pretty rare. Certainly the same employee should never get a variable rating twice in a row. A variable employee who is not improving is probably one that should be removed from the organization.

Strong employees tend to perform at very high levels most of the time. Not only are they performing their job very well, but they’re pushing themselves towards growth by reaching outside of their comfort zone.

Finally, outstanding employees excel at everything they do, and encourage others to do so at every opportunity. Outstanding employees are typically rare.

So, we’re still just numbers…!!!

Must Read Sample Performance Review

Happy Teachers Day...!!!

माधवराव पेशवा अपने जन्मदिन पर दान कर रहे थे। अन्न, वस्त्र, स्वर्ण आदि का भारी मात्रा में दान किया जा रहा था।

पंक्ति में खड़े एक बालक ने उनके सामने आने पर यह दान लेने से इंकार कर दिया। चौंकते हुए पेशवा ने उस बालक से जानना चाहा- 'क्यों भाई! आखिर तुम किस प्रकार का दान चाहते हो?'

गंभीर मुद्रा बनाकर उसने कहा- 'पेशवा साहब! इन नश्वर पदार्थों के दान की बजाए आप मुझे शाश्वत दान प्रदान करने की कृपा करें।'

'अपना आशय स्पष्ट करो वत्स!' पेशवा आश्चर्यचकित थे, 'शाश्वत दान से तुम्हारा अभिप्राय?' पेशवा ने बड़े ही स्नेह से पूछा।

'शाश्वत दान है विद्या। अतः मुझे विद्या दान की आकांक्षा है।'

पेशवा ने उस बालक की बात से प्रभावित होते हुए उसे अध्ययन हेतु काशी भेज दिया। उन्होंने राजकर्मचारियों को इस हेतु प्रबंध के निर्देश दे दिए।

शाश्वत दान पाने वाला यह बालक आगे चलकर प्रसिद्ध न्यायाधीश रामशास्त्री बना।

Should class attendance be mandatory?

Mandatory attendance in college has always been a highly debated subject. Should class attendance be mandatory? Students, Professors say No.

Professors want students to attend all of their classes so they can teach them directly, but many students want to be given the freedom to decide which classes to attend. Due to the difficulty of regulating a college-wide attendance policy, most colleges and universities give professors the authority to set their own attendance rules.

“Nirav” as a student of university, said he does not agree with mandatory attendance policies except in the case of lab work because it is usually completed in class with very little work outside of the classroom.

He noted that many professors say regular attendance is necessary to do well in a course and agrees that attendance and course performance are positively correlated.

“That being said, there would be no need for mandatory attendance as students seeking high grades will quickly learn that they need to attend the course regularly,” he said. “Inflating grades with 10-20 percent of your score coming from attendance is a poor judgment of an individual’s competency in the course.”

Professor Mr. Shah who teaches Maths at University and does not implement a mandatory attendance policy. Instead, he gives his students the opportunity to earn participation points via weekly quizzes and discussion questions. Interestingly more students are interested in such policy. They generally come to class for actively participation or discussion, though attendance is not mandatory.

This policy works well for Mr. Shah and saves his lot of time and hassle.

“It’s beneficial to me because I don’t have to worry about marking who’s there, who’s not, who’s late, who leaves early,” he said. “Additionally, I don’t have to haggle with students over any grades associated with ‘excused’ and ‘unexcused’ absences.”

While Mr. Shah’s non-mandatory attendance policy makes his job easier, he’s not sure if it is beneficial to his students. “I would hope it is since it suggests I’m treating them as adults,” he said.

A common argument brought up by students regarding mandatory attendance is that, as tuition payers, they shouldn’t be punished for missing something they are paying for anyway.

“As students paying to enroll in these courses, the attendance should be up to us and not roped into course grading in any way shape or form,” Nirav said.

An additional aspect of mandatory attendance that must be taken into consideration is the possible distraction caused by students who show up to class only to earn credit points yet distract other students as they do everything under the sun except listen to the professor. For instance, it is not uncommon to go into a college lecture and see many students doing one of the following: sleeping, Facebook chatting, online shopping, watching funny animal videos on YouTube, streaming live sporting events etc…

“Tapan”, a student at University, does not believe professors should allow students to get away with missing a large number of classes. However, he also thinks a policy that requires attendance to every class is too limiting. Instead, He thinks professors should have mandatory attendance with a few absences allowed.

“I don’t think attendance should be mandatory unless a few ‘free days’ are provided, because I think by the university level, students have the right and responsibility to prioritize their own time,” Tapan said. “I think it would be unfair for a student to be penalized if they, for instance, chose to forgo a lecture in favor of working on a semester project.”

Tapan said most of his professors either don’t have an attendance policy or, if one is in place, students are allowed to miss a certain number of days in the semester without being penalized.

“I think this is preferable to a more strict attendance policy, as it allows students appropriate control of their own schedules,” he said.

While Tapan does not mind professors who have attendance requirements, he recognizes that not all of his peers share his opinion. He said he tries to regularly attend his classes to learn from the lectures, but he knows there are many students who do not share his learning style and would prefer to learn the material on their own.

“For them, a strict attendance policy seems detrimental,” he said.

In the end, Tapan believes attendance policies must balance both sides and find a happy medium.

“We’re adults, but still college students at the same time,” Tapan said. “Universities should have some regulation, but we should be primarily responsible for our own education and I think attendance policies should reflect that.”

The case of the 500-mile email...!!!

The following is the 500-mile email story in the form it originally appeared. Describing a day in life of technical support or system admin...!!!

From trey@sage.org Fri Nov 29 18:00:49 2002

Date: Sun, 24 Nov 2002 21:03:02 -0500 (EST)

From: Trey Harris

To: sage-members@sage.org

Subject: The case of the 500-mile email (was RE: [SAGE] Favorite impossible task?)

Here's a problem that *sounded* impossible...  I almost regret posting the story to a wide audience, because it makes a great tale over drinks at a conference. :-)  The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining.

Here is a story, enjoy…!!!

I was working in a job running the campus email system some years ago when I got a call from the chairman of the statistics department.

"We're having a problem sending email out of the department."

"What's the problem?" I asked.

"We can't send mail more than 500 miles," the chairman explained.

I choked on my latte.  "Come again?"

"We can't send mail farther than 500 miles from here," he repeated.  "A little bit more, actually.  Call it 520 miles.  But no farther."

"Um... Email really doesn't work that way, generally," I said, trying to keep panic out of my voice.  One doesn't display panic when speaking to a department chairman, even of a relatively impoverished department like statistics.  "What makes you think you can't send mail more than 500 miles?"

"It's not what I *think*," the chairman replied testily.  "You see, when we first noticed this happening, a few days ago--"

"You waited a few DAYS?" I interrupted, a tremor tinging my voice.  "And you couldn't send email this whole time?"

"We could send email.  Just not more than--"

"--500 miles, yes," I finished for him, "I got that.  But why didn't you call earlier?"

"Well, we hadn't collected enough data to be sure of what was going on until just now."  Right.  This is the chairman of *statistics*. "Anyway, I asked one of the geo-statisticians to look into it--"

"Geo-statisticians..."

"--yes, and she's produced a map showing the radius within which we can send email to be slightly more than 500 miles.  There are a number of destinations within that radius that we can't reach, either, or reach sporadically, but we can never email farther than this radius."

"I see," I said, and put my head in my hands.  "When did this start?  A few days ago, you said, but did anything change in your systems at that time?"

"Well, the consultant came in and patched our server and rebooted it. But I called him, and he said he didn't touch the mail system."

"Okay, let me take a look, and I'll call you back," I said, scarcely believing that I was playing along.  It wasn't April Fool's Day.  I tried to remember if someone owed me a practical joke.

I logged into their department's server, and sent a few test mails.  This was in the Research Triangle of North Carolina, and a test mail to my own account was delivered without a hitch.  Ditto for one sent to Richmond, and Atlanta, and Washington.  Another to Princeton (400 miles) worked.

But then I tried to send an email to Memphis (600 miles).  It failed.

Boston, failed.  Detroit, failed.  I got out my address book and started trying to narrow this down.  New York (420 miles) worked, but Providence (580 miles) failed.

I was beginning to wonder if I had lost my sanity.  I tried emailing a friend who lived in North Carolina, but whose ISP was in Seattle.

Thankfully, it failed.  If the problem had to do with the geography of the human recipient and not his mail server, I think I would have broken down in tears.

Having established that--unbelievably--the problem as reported was true, and repeatable, I took a look at the sendmail.cf file.  It looked fairly normal.  In fact, it looked familiar.

I diffed it against the sendmail.cf in my home directory.  It hadn't been altered--it was a sendmail.cf I had written.  And I was fairly certain I hadn't enabled the "FAIL_MAIL_OVER_500_MILES" option… J 

At a loss, I telnetted into the SMTP port.  The server happily responded with a SunOS sendmail banner.

Wait a minute... a SunOS sendmail banner?  At the time, Sun was still shipping Sendmail 5 with its operating system, even though Sendmail 8 was fairly mature. 

Being a good system administrator, I had standardized on Sendmail 8.  And also being a good system administrator, I had written a sendmail.cf that used the nice long self-documenting option and variable names available in Sendmail 8 rather than the cryptic punctuation-mark codes that had been used in Sendmail 5.

The pieces fell into place, all at once, and I again choked on the dregs of my now-cold latte.  When the consultant had "patched the server," he had apparently upgraded the version of SunOS, and in so doing *downgraded* Sendmail.  The upgrade helpfully left the sendmail.cf alone, even though it was now the wrong version.

It so happens that Sendmail 5--at least, the version that Sun shipped, which had some tweaks--could deal with the Sendmail 8 sendmail.cf, as most of the rules had at that point remained unaltered.  But the new long configuration options--those it saw as junk, and skipped.  And the sendmail binary had no defaults compiled in for most of these, so, finding no suitable settings in the sendmail.cf file, they were set to zero.

One of the settings that was set to zero was the timeout to connect to the remote SMTP server.  Some experimentation established that on this particular machine with its typical load, a zero timeout would abort a connect call in slightly over three milliseconds.

An odd feature of our campus network at the time was that it was 100% switched.  An outgoing packet wouldn't incur a router delay until hitting the POP and reaching a router on the far side.  So time to connect to a lightly-loaded remote host on a nearby network would actually largely be governed by the speed of light distance to the destination rather than by incidental router delays.

Feeling slightly giddy, I typed into my shell:

$ units

1311 units, 63 prefixes

You have: 3 millilightseconds

You want: miles

        * 558.84719

        / 0.0017893979

"500 miles, or a little bit more."

Trey Harris

Jokes of the Month

A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you tell me where I am?"

The man below says: "Yes, you're in a hot air balloon, hovering 30 feet above this field."

"You must be an engineer" says the balloonist.

"I am" replies the man. "How did you know."

"Well," says the balloonist, "everything you have told me is technically correct, but it's no use to anyone."

The man below says "you must be in management."

"I am" replies the balloonist, "but how did you know?"

"Well," says the man, "you don't know where you are, or where you're going, but  you expect me to be able to help. You're in the same position you were before we met, but now it's my fault."

----------------------------------------------------------------------------------------------------------

Fall was upon a remote reservation when the Indian tribe asked their new  Chief what the coming winter was going to be like.  The modern day Chief had never been taught the secrets of the ancients.  When he looked at the sky he couldn't tell what the winter was going to be like.

Better safe than sorry, he said to himself and told his tribe that the winter was indeed expected to be cold and that the members of the village should stock up on firewood to be prepared. 

After several days, our modern Chief got an idea. He went to the phone booth, called the National Weather Service and  asked, "Is the coming winter going to be cold?"

"It looks like this winter is going to be quite cold," the meteorologist at the weather service responded.

So the Chief went back to his people and told them to collect even more firewood in order to be prepared. A week later he called the National Weather Service again. "Does it still look like it is going to be a very cold winter?"

"Yes," the man at National Weather Service again replied, "it's going  to be a very cold winter."

The Chief again went back to his people and ordered them to collect every scrap of firewood they could find. Two weeks later the Chief called the National Weather Service again.   "Are you absolutely sure that the winter is going to be very cold?"

"Absolutely," the man replied. "It's looking more and more like it is going to be one of the coldest winters ever."

"How can you be so sure?" the Chief asked.

The weatherman replied, "The Indians are collecting firewood like crazy."

----------------------------------------------------------------------------------------------------------

A city boy, Raju, moved to the country and bought a donkey from an old farmer for Rs 100.00. The farmer agreed to deliver the donkey the next day.

The next day the farmer drove up and said, "Sorry son, but I have some bad news, the donkey died last night."

Raju replied: "Well then, just give me my money back."

The farmer said: "Can't do that. I went and spent it already."

Raju said: "OK then, just unload the donkey.."

The farmer asked: "What ya gonna do with him?"

Raju: "I'm going to raffle him off." (Note: To raffle is to sell a thing by lottery - draw lot - to a group of people each paying the same amount for a ticket)

Farmer: "You can't raffle off a dead donkey!"

Raju: "Sure I can. Watch me. I just won't tell anybody he's dead."

A month later the farmer met up with Raju and asked, "What happened with that dead donkey?" Raju: "I raffled him off. I sold 500 tickets at two rupees a piece and made a profit of Rs. 898.00."

Farmer: "Didn't anyone complain?"

Raju: "Just the guy who won. So I gave him back his two rupees."

DevOps, Culture and Engineer

Once upon a time there were two teams in charge of creating great software: Dev and Ops. Though they worked on the same product, their goals were diametrically opposed to each other. On one hand there was the Dev team pushing for feature changes, and on the other hand was the Ops team striving for stability.

Since the advent of the personal computer in the 80’s these teams have been siloed and burdened with dysfunctional communication during a product lifecycle that has historically led to delays and broken code. It was a sad tale to tell to end users everywhere.

Today, things have changed, radically. An entire movement was formed by new technology like cloud infrastructure and virtual machines. This cultural change in perspective combines the two teams into one lean mean rapid deployment machine, leveraging code to manage the infrastructure. It is called DevOps. And an engineer who is doing such tasks called DevOps Engineer following only one mantra, “Infrastructure as a Code”.

Transparency, collaboration and cross-functional teams with polyglot skills are breaking down the walls with automation and rapid deployment. Software gets shipped quickly, more often, code failures are detected and corrected faster and the product runs smoother. This speed up process allows innovation to flourish and companies to do more in less time.

In short, DevOps is the marrying of process, infrastructure, and product. I pretty much agree with most of people's views about DevOps job title. In regards to DevOps title. Yes, I have seen individuals working under the title of DevOps and I have seen organizations hiring DevOps roles.

To be frank I was not looking at "DevOps Engineer" job title. I guess I am coming from an organizations perspective as to how to get the team to be trained up or if there is anything that we should look at.

The first and foremost important aspect of DevOps in my perspective is mindset of individuals. Attitude of applying the right skills to deliver to business. That's where we take the handle of agile methodology of "individuals and interactions".

When we have right set of people delivering to the current business need, there comes an opportunity to look further down the chain as to what are the essential skills that we need so that going forward we are adopting and delivering.

“Systems Engineer” and “DevOps Engineer” titles been showed up in DevOps Department, IT Operations, Development and Engineering Departments. Job satisfaction also highly correlates with DevOps practices and culture. Just as some suggest that happy cows make better cheese, DevOps practices increase employee satisfaction, which leads to better business outcomes. Instead of managing tasks, people get to make decisions, employing their skills, experience and judgment.

We all know how job satisfaction feels: It’s about doing work that’s challenging and meaningful, and being empowered to exercise our skills and judgment. We also know that where there’s job satisfaction, employees bring the best of themselves to work: their engagement, their creativity and their strongest thinking. That makes for more innovation in any area of the business, including IT.

Being said that, just love what you’re doing and keep going. It’s really that simple, isn’t it!

Robert the Bruce (and the Spider)

HUNDREDS of years ago there was a king of Scotland and his name was Robert the Bruce. It was a good thing that he was both brave and wise, because the times in which he lived were wild and dangerous. The King of England was at war with him, and had led a great army into Scotland to drive him out of the land and to make Scotland a part of England.

Battle after battle he had fought with England. Six times Robert the Bruce had led his brave little army against his foes. Six times his men had been beaten, until finally they were driven into flight. At last the army of Scotland was entirely scattered, and the king was forced to hide in the woods and in lonely places among the mountains.

One rainy day, Robert the Bruce lay in a cave, listening to the rainfall outside the cave entrance. He was tired and felt sick at heart, ready to give up all hope. It seemed to him that there was no use for him to try to do anything more.

As he lay thinking, he noticed a spider over his head, getting ready to weave her web. He watched her as she worked slowly and with great care. Six times she tried to throw her thread from one edge of the cave wall to another. Six times her thread fell short.

"Poor thing!" said Robert the Bruce. "You, too, know what it's like to fail six times in a row."

But the spider did not lose hope. With still more care, she made ready to try for a seventh time. Robert the Bruce almost forgot his own troubles as he watched, fascinated. She swung herself out upon the slender line. Would she fail again? No! The thread was carried safely to the cave wall, and fastened there.

"Yes!" cried Bruce, "I, too, will try a seventh time!" 

So he arose and called his men together. He told them of his plans, and sent them out with hopeful messages to cheer the discouraged people. Soon there was an army of brave men around him. A seventh battle was fought, and this time the King of England was forced to retreat back to his own country.

It wasn't long before England recognized Scotland as an independent country with Robert the Bruce as its rightful king.

And to this very day, the victory and independence of Scotland is traced to a spider who kept trying again and again to spin her web in a cave and inspired the king of Scotland, Robert the Bruce.