all bits considered data to information to knowledge

11Apr/100

Why Performance Reviews are Evil

Coming from Professor of Management at UCLA Anderson School of Management Samuel A. Culbert this statement deserves more than knee-jerk rejection (and – on a personal note – I am glad to see my gut feelings vindicated so eloquently!)

Here is but a couple of quotes from the professor's new book  Get Rid of the Performance Review!: How Companies Can Stop Intimidating, Start Managing--and Focus on What Really Matters  that distill  it:

"Performance reviews instill feelings of being dominated. They send employees the message that the boss's opinion of their performance is the key determinant of pay, assignment, and career progress. And while that opinion pretends to be objective, it is no such thing."

"Most performance reviews hurt a company's case because they aren't honest assessments of a worker's performance."

I might add that this only applicable to the corporate hierarchy environment, "boss/underlings" situation. Feedback from an independent party is absolutely necessary.

P.S. This also made we wonder - if only by association - about Programming Code reviews... in context of software engineering, continuous integration and SCRUM daily stand-ups. Would continuous code inspection be possible?

29Aug/090

Reviewing code for fun and profit

Everybody would agree that a review is a good idea – code review, design review, performance rev…let’s stop right there 🙂

Yet there aren’t many as universally hated team activities as code review. A programmer is solitary animal – XP methodology notwithstanding – and generally does not like explaining his/her code to the group. Now, this does not apply to truly agile engaged team where people are fully aware of each other strengths and weaknesses, trust each other do do the best job possible, and do not get defensive at critique. The rest – read: most of the teams – do have these problems, to some degree.

As I see it, the defensiveness could have several plausible explanations, and none of them flattering:

  • incompetence – the programmer knows or suspects he’s not up to the team’s standards, and does not want this fact to be discovered by his peers and managers
  • arrogance – the programmer believes that team is not “qualified” to review his code; usually comes with primadonna syndrome
  • laziness – the programmer is getting paid to “produce code, not to discuss it”;  implies equavalency of good and bad code(design)
  • lack of reviewing skills – the programmer was never educated on the value of the code review (or the education did not sink in), much less in reviewing methods

NB: The list is far from being complete – feel free to add your own entries.

All of these could – and should – be addressed rather sooner than later if team is to succeed. The first two dwell mostly in project management domain, while fallacy of the last two could be rectified with proper education and process automation.

I will talk about automating the review process in upcoming blogs.