Supposedly Irrelevant Factors

I’m halfway through reading one of the best books I’ve read in a long while: Misbehaving, by Richard H. Thaler.

One of the things that most stuck with me was that of “supposedly irrelevant factors“, which refers to something that, in theory, should not affect or influence the thinking of a rational person but does.

Thaler has also written about this in an article for the New York Times. The example that Thaler shared in the article is that of the grading of the notoriously difficult midterm exam that he gives, which he uses to separate his really good students from the rest.

As per the usual practice in academia, the maximum marks you could get in that exam was a hundred. But this posed a problem. Because of the difficulty of the exam, his students were averaging only 72 out of a possible hundred.

Though it didn’t affect the overall grades the students got, since their relative scores were more important than their absolutes (see: bell curve), they didn’t quite like getting such low marks and many complained.

Thaler got worried that the complaints might eventually lead to the loss of his job. So he made a change: instead of having the exam be out of a hundred marks, he made out of 137.

This change had a couple of things going for it: firstly, it made it more difficult to calculate a percentage score; at the same time, it allowed him to give students higher marks, closer to what they would have got on the usual, less challenging exams.

Students were on average now scoring 96 instead of 72, with some delightfully achieving scores above a hundred. Despite the lower percentage scores his students were getting (70 now instead of 72!) his students were happier.

This wasn’t supposed to happen. But it did.

To him, test scores were a supposedly irrelevant factor. To his students, they were anything but.


The concept of supposedly irrational factors really appeals to me because it’s something we tend to forget, especially in a work setting (because everyone’s somehow less human!) and yet something that may have large consequences.

Imagine this conversation between you and your boss:

Boss: Run this report for them every day by noon.

You: Why? They shouldn’t need to see the numbers at that high frequency – no actions can be taken at this late stage that will change anything anyway.

Boss: Just do it.

How would you feel? Would it make you a little more likely to be unhappy? To consider quitting and doing work that feels more worthwhile?

The knowledge of why could be seen as a supposedly irrelevant factor.

Knowing why you’re doing it wouldn’t really change anything – doing what your boss tells you is part of your job. Maybe she knows something you don’t.

But still, it just doesn’t feel right and the knowledge that there might be a purpose that isn’t shared doesn’t make you any less unhappy.

But what if your boss said this instead after you’d asked “why?”:

Boss: Maybe it won’t change anything. And I know it seems pointless from an actionable point of view. But what I know is that it helps calm their nerves; it helps calm their boss’ nerves. It’s not easy being in their shoes – they’re currently under immense pressure, and I’m hoping to support them in whatever way we can.

How would you feel now? If it were me, I’d actually feel even more empowered than before, and that I was making a positive difference in people’s lives.

The simple knowledge of why changes things quite a bit, though it really shouldn’t.

We’re not quite the uber-rationals we think we are.


Some interesting “supposedly irrelevant factors” examples that I’ve come across:

  • Choice architecture, and the default option – we go for default options more often than would be expected, even if the default’s the worst option available
  • Decoy pricing – Classic experiment done by The Economist where the introduction of a third, obviously poor subscription option made the most expensive option much more appealing
  • The Endowment Effect – Owning an item makes it seem much more valuable than it was before ownership came about

Anticipation, proactivity, and the Invisibles

Just read an article via Slashdot on this thing called “Tab Warming” that the Mozilla team is testing for the Firefox Web Browser.

I won’t go into the details, but in essence what Tab Warming does is that it anticipates whether or not you’ll click on a link, and if it does it “paints” the page in the background saving you milliseconds of loading time when you eventually click on it.

Despite the seemingly very small difference in absolute time, (I mean, really, milliseconds?) it has the potential to be the difference between somebody thinking about the page loading versus somebody not thinking about the page loading at all and purely on the content of the page.

And that’s huge. Isn’t the ultimate aim of interface usability to become invisible, after all?

This reminded me of how the best people I’ve worked with are those who pretty much do this all the time: they anticipate what I may need, and even before I’d mentioned it they’re bringing it up and telling me it’s already done.

And to me, despite my never thinking about them (because I don’t have to!), they’re the ultimate stars in our work lives.

To the invisibles: Thank you.

The Run

We act very much as if we were on a voyage. What can I do? I can choose out the helmsman, the sailors, the day, the moment. Then a storm arises. What do I care? I have fulfilled my task: another has now to act, the helmsman.

If the weather is bad for sailing, we sit distracted and keep looking continually and ask, “What wind is blowing?” “The north wind.” What have we do to with that? “When will the west wind blow?” When it so chooses, good sir.

– Epictetus

I went out for what was supposed to be a short run today.

Didn’t feel like it. It was a long day; I was tired.

But the run was scheduled. “Not my problem,” the schedule seemed to say.

You don’t fight schedules. They don’t listen.

*****

Shoes on, I walked out the door.

Took a step; then another; then another.

A slow trot. Then quicker.

It’d rained earlier; the air felt fresh and cool.

*****

Reached a fork in the road.

Turn left as planned and in 30 minutes I’d be home.

Turn right and in 30 minutes… in 30 minutes I’d be 30 minutes from home.

I looked left. Turned right.

*****

29 minutes in and my legs were feeling good.

One-two-inhale; one-two-exhale. The rhythm felt like poetry.

But my mind — it disagreed.  “You can’t keep this pace,” it said. “Slow down.”

I feared it was right. Last time I ran this quick I fizzled out at 30. Which was… now.

*****

Then I remembered Epictetus.

My mind chose this route; this pace; this moment. It’s job was done.

My legs didn’t think there was a problem and neither did my lungs. They were fine; they were strong.

“Trust them,” I told my mind. “Trust them to do their job. If I collapse, I collapse.”

*****

Until then, I run.

The problem with running a team at full capacity

I shared this earlier on LinkedIn, but thought that it was worth sharing it here too as a reminder to myself: Six Myths of Product Development

I came across the article above while researching why a team that traditionally does great work may sometimes stumble (yes, mine). The past few weeks had been a whirlwind of activity, with team output close to or at an all time high. We were publishing and developing things left and right, and everyone was running close to capacity. It was great.

Then came an e-mail that questioned the quality of the output. Then another. Much of the great work threatened to come undone, but thankfully most made it through unscathed. We were still, generally, in a good place. But this was a wake up call. Something needed to be done.

After I explained to her my conundrum, my knowledgeable friend, Google, suggested an article from the Harvard Business Review website called “Six Myths of Product Development.”

It was a most excellent suggestion.

The article highlighted six myths or fallacies:

  1. High utilization of resources will improve performance.
  2. Processing work in large batches improves the economics of the development process.
  3. Our development plan is great; we just need to stick to it.
  4. The sooner the project is started, the sooner it will be finished.
  5. The more features we put into a product, the more customers will like it.
  6. We will be more successful if we get it right the first time.

It didn’t take long for me to realise that our problem was very likely linked to #1: I’d neglected slack.

You see, I normally tend guard slack time jealously as I know time-pressures are often a big cause of low quality output. But given the myriad of “urgent” business needs had allowed myself and the team to run too close to full capacity.

We have seen that projects’ speed, efficiency, and output quality inevitably decrease when managers completely fill the plates of their product-development employees—no matter how skilled those managers may be. High utilization has serious negative side effects… Add 5% more work, and completing it may take 100% longer. But few people understand this effect.

It’s funny how bringing down the amount of expected output may actually increase it.

(As an aside, I love point #6 – I’m a big fan of “fail fast, fail often” as I believe strongly in “the wisdom of crowds”, where we can aggregate feedback and iterate quickly, especially for early development. But it’s not always easy to get business buy-in, especially when all they see in “fail fast, fail often” is “fail”!)

 

What are you doing to help the person next to you?

Was taking a break from my studies (exams next week, people!), having my dinner and watching some YouTube vids on “leadership” (just because) when I came across Simon Sinek and this video.

Reminded me of something I knew very well sometime back, but forgotten in the hustle and bustle of corporate life: that we sometimes have to put ourselves aside, ignoring the modern social beat of “I, I, me, me“, and think about how we can help and serve others, not in the hope for some future karmic gain, but because we can.

Developing a Culture

Seth Godin wrote a wonderful post on how we sometimes need an external push (through laws, policies, cultural guardrails) to do what’s best for us. It can be basically summed up by the following statements (from the post):

  • We know that wearing a bicycle helmet can save us from years in the hospital, but some people feel awkward being the only one in a group to do so. A helmet law, then, takes away that problem and we come out ahead.
  • Guard rails always seem like an unwanted intrusion on personal freedom. Until we get used to them. Then we wonder how we lived without them.

I was just thinking about true this is for so many other aspects of our lives. The friends we choose, because of the context they set, determine many of the decisions we make, and consequently many of the paths of life we take.

When setting up a company, a department, a team – how important it would be then to make sure that the cultural norms we encourage and enforce are the ones we want.

Whether it’s a culture of success (however you define it); freedom of experimentation; openness of communication; risk taking; or hard work, it is our job as servant leaders to ensure that it’s the least awkward thing to do.