Shrink Annual Performance Reviews

Adobe has abolished annual performance reviews in favor of more frequent, lighter-weight check-ins.  My company has annual reviews but since I became a manager it has been my goal to make those reviews a non-event. That is, I try to have weekly check-ins (one-on-ones) that bite off performance review a week at a time.  Read the article for Adobe’s take.

My own challenges:

  • It can be easy to be too zoomed in during weekly check-ups. So I’ve been adding monthly and quarterly triggers for higher level discussions.
  • In an agile development environment it can be hard to set long range goals.  Each developer is more or less committed to doing whatever comes next off of the backlog. Creating metrics that give concrete feedback while valuing all the important work being done is an enormous challenge. I’ve found that when you do hit on a good metric people are relieved to see the evidence of their good work being recognized.

Thank you to this week’s Mad Sad Glad from Manager Tools for the link.

You may not be able to abolish performance reviews, but if you’re a manager you can shrink them.

Brakes That Don’t Slow You Down

As an engineering student I was impressed by the intricate harmony of development processes. It was probably the same part of me that loved the uniformity and audacity that is xml. These days I use JSON 100 times more often than xml. I’ve similarly fallen out of love with process. But there’s still a grudging respect there. Like… Continue reading Brakes That Don’t Slow You Down

Two Common Release Plan Types

Two basic types of release plans that are widely used are scope-boxed release plans and time-boxed release plans. “In a scope-boxed plan the work that the team will do is defined in advance, but the release date (time) is uncertain. In a time-boxed plan the time and release date is defined in advance, but the specific work that people will… Continue reading Two Common Release Plan Types

WOTD: Poka-Yoke Means Mistake Proof

Your word of the day is poka-yoke: mistake-proof. Such as keying on network cables that ensures they can only be inserted correctly. From Wikipedia:

Poka-yoke (ポカヨケ?) [poka yoke] is a Japanese term that means “mistake-proofing”. A poka-yoke is any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.[1] The concept was formalised, and the term adopted, by Shigeo Shingo as part of the Toyota Production System.[2][3] It was originally described as baka-yoke, but as this means “fool-proofing” (or “idiot-proofing“) the name was changed to the milder poka-yoke.

http://en.wikipedia.org/wiki/Poka-yoke

To eliminate defects we embrace poka-yoke instead of blaming people.

Dumb, Costly Errors Should Be Hard To Make

Building computers for fun in the 1980’s I ruined at least one floppy drive because I plugged the controller cable in backwards.  Nowadays those kinds of screw-ups are much more difficult to make.

My favorite story about being committed to not blaming people comes from my father’s career. They had chemicals next to each other in identical vials that made it easy for him to mistakenly waste about $10,000 of material. (Double that figure when you adjust for inflation.)

When he hesitantly told his manager about it the guy said, “Well, we shouldn’t have made it so easy to make that mistake.”

Roberto’s 5 Decision Making Myths

A discussion I was having with a frustrated coworker reminded me of these decision making myths from Professor Roberto. We maintain a belief in a number of myths about how decisions are made in groups and organizations… “Myth #1: The chief executive decides. Reality: Strategic decision making entails simultaneous activity by people at multiple levels… Continue reading Roberto’s 5 Decision Making Myths

I Was a Condescending Jerk

illustartion of expressions of face on white background

Dear ManagerJS, I’m upset about something stupid I did yesterday. I was in a meeting with several peers. One of them suggested an improvement to our hiring practices. Before I knew what I was thinking I was already speaking. I said, “I categorically reject that suggestion.” Can you believe that? Not, “I see it a… Continue reading I Was a Condescending Jerk

Lovallo on Confirmation Bias

Confirmation bias Is probably the single biggest problem in business, because even the most sophisticated people get it wrong. People go out and they’re collecting the data, and they don’t realize they’re cooking the books. Dan Lovallo, interview with Dan Heath, quoted in Decisive, Chip and Dan Heath, page 12.

Roberto on Fundamental Attribution Error

we don’t attribute correctly when we think about others versus ourselves.  We have a bias in the way we attribute the causes of success and failure — particularly failure “When we observe … highly flawed decision making we often ask ourselves, ‘How could they have been so stupid?’ We often attribute others’ decision making failures to a lack… Continue reading Roberto on Fundamental Attribution Error

I’m Sorry I Was Rude Today

illustartion of expressions of face on white background

You can have intellectual curiosity. You can relish inquiry. But I still think people don’t like being wrong. And as much as I dislike being wrong, I hate being in the wrong. I snapped at a direct report today. It was in a tense voice, at a normal volume. It was one sentence long.

Next page