Monkeys and bananas: stifling innovation in the workplace

The story I wrote for our SQLskills Insider newsletter on Monday last week resonated so well with people that I thought I’d publish it here on my blog too (which I only do rarely). I try to mix things up in the newsletter so it’s not all about SQL Server technical matters; people seem to really like career topics too. You can sign up for the bi-weekly newsletter here (and get all the 100 past issues too) – more than 12,000 people get it now!

Here’s the story, from the newsletter section I call Paul’s Ponderings. Enjoy!

Last week Jonathan pointed me at an interesting story about a psychology experiment involving monkeys and bananas and the reinforcement of constrained, negative thinking. The experiment actually never happened, but the story is quite illustrative. You can see a graphic of the story here: http://i.stack.imgur.com/MyQki.jpg (totally safe for work), and I’ll paraphrase quickly below:

  • A group of monkeys are trained to know that if any one of them attempts to climb a stepladder with a banana at the top, cold water is sprayed on all of them (i.e. temptation is prevented by the spraying of cold water, so the group prevents any individual from trying to get the banana).
  • When a new monkey is introduced, and tries to get the banana, all the other monkeys prevent it as they don’t want to be sprayed with water. The new monkey learns that it can’t get the banana.
  • Eventually all the monkeys are replaced, and they all know not to try to get the banana, but none of them know why, as they’d only been told not to get the banana by the others.

It’s a really interesting story of how conditioning can become groupthink (even if the experiment didn’t actually happen).

There are obvious parallels in human society, and specifically in the work environments of many of you reading this newsletter. Let me explain:

  • A new person (A) joins a team. The new person has a great idea for how to do something differently/better, and everyone else on the team prevents them from expressing their opinion because that won’t be allowed, it won’t work, and/or they could get into trouble (e.g. from an intransigent and influential boss/architect/senior developer).
  • Eventually all the original people leave the team and it’s only A and the people who joined the team after A that are left. They all have the ingrained knowledge that they can’t try anything new, or try a specific technology because they won’t be allowed to etc.

In other words, being constrained to incumbent technologies and methodologies becomes “the way it’s done around here, because it’s always been that way.” It doesn’t matter if the wider world knows that’s maybe not the best way to do it, the historical groupthink wins out.

We see this with new clients over and over, and it can be really difficult to educate the client team as to different (usually better) ways of approaching a problem. Sometimes it’s just one person who stymies all thoughts of innovation or change in the team, and sometimes it’s the collective groupthink that does it.

In fact, there was a client (years ago), that Kimberly actually “fired” because of this. One meeting was enough but she told her contact (“the management”) that she’d try again and meet again for a second session. In her post-mortem with management, her main quote was – your problems are more than technical (specifically person “X”) and until that’s resolved, I can’t help you.

Here are some simple examples of ingrained behavior we’ve seen and corrected:

  • Always use NOLOCK to work around blocking and deadlocking problems (and then it’s used everywhere, and no one even realizes the negatives)
  • Only ever rebuild an index to remove fragmentation, without considering FILLFACTORs or trying to reorganize rather than rebuild
  • Always use a heap and never use a clustered index because heaps are faster
  • When creating a primary key, always use a clustered index as that’s the default so Microsoft must know that’s always the right way to do it
  • For each column that’s used in a WHERE clause, create a single-column nonclustered index
  • Always use OPTION (RECOMPILE) to prevent plans being put into the plan cache and taking precious memory away from the buffer pool
  • Always use sp_executesql to put a plan into cache for ad hoc statements so that their plans get reused
  • Always create one file per processor core for tempdb, because that was the Microsoft guidance for SQL Server 2000

As I hope you can see, these are all very blinkered (and in some cases downright wrong) views on a variety of SQL Server topics. There are cases when some of these are the right thing to do, but not ALL the time just because ‘that’s the way we do it here’.

Does this remind you of anywhere? Or of anyone?

It’s a dangerous way for a team to work because it can lead to all kinds of problems (such as poor performance, failed disaster recovery, good people leaving the team, business failure) that can be extremely hard to fix unless someone takes a stand or someone from outside the team helps to break the impasse. And even then, it’s a delicate process to provide education and slowly change the thinking of the team, or of that one person who dominates the team’s thinking.

Call to action: Consider the environment you work in and whether the situation described above is how your team operates. Are you the person to take the stand to try to change the groupthink? Do you do it or do you move on? Or are you the person who’s unreasonably dominating the team’s thinking? Do you allow yourself to be changed or continue in your intransigence? It’s a difficult situation to recognize you’re in, whatever your role is, and a hard choice to decide what to do about it.

8 thoughts on “Monkeys and bananas: stifling innovation in the workplace

  1. Of course this results from a good practice. None of us can remember all of the Why’s and Why Not’s so we adopt what I refer to as “old man’s Rules” to guide us. Some examples are almost always benign. For example, I almost always alias every table in the From, spell out the join type, and nest the join condition(s). This does not hurt anything and arguably makes the query more readable.
    I also almost never use UDF’s in the Query and I preach that to developers. We see generations of “old man’s rules” in this one. The original rule was “code reuse is good so always put common code in a function”.
    When I talk about coding guidelines I often refer to guidelines and rules based on lessons learned the hard way. Unfortunately the lessons can be hard to unlearn when we move to newer versions or different environments.
    :)

  2. The original parable is ironic because, were it real, you’d have to acknowledge that the monkeys are *right* not to climb up the ladder — they’d get sprayed with the hose! Of course the final group of monkeys can no longer produce a rational reason for not climbing up the ladder, but that doesn’t change the fact that their actions achieve a rationally desirable outcome (no hosed monkeys — I mean, you *know* it’s bad when your monkeys get hosed). We can hardly expect them to try “every so often” in case the hose has gone away on its own. And if they did, that would just be that much more hosings.

    Let’s take it one step further. (Unreasonably overanalyzing parables is *always* fun. And totally justified when they’re presented as thought experiments in psychology, because these things get promoted to gospel 15 seconds after the first person relays them.) Suppose that the ladder climbing monkey wasn’t just beaten, but told beforehand “don’t go get the banana, we’ll all get hosed — seriously, I know a guy who knew a guy who remembers the Spray of ’74”. Suppose the monkey was only beaten after doing it anyway and giving everyone another cold shower. Now the final group of monkeys, when asked “why don’t you go up the ladder”, actually have a rational answer as to why they don’t: “when anyone went up the ladder in the past, we all got hosed”.

    Of course this doesn’t mean that hosing is an unavoidable fact of life. Pioneers could still go and say “well, that banana just has my name written all over it, go get your raincoats”. Or indeed, “maybe we can develop some way of testing whether hosing will still be imminent when our proximity to the banana drops below a threshold, in a controlled manner”. Our hypothetical group of monkeys has now turned the table on our equally nonexistent scientists by becoming students of empirical thought themselves (presumably they were all hosed after this, banana or no, for ruining the testing protocols).

    In conclusion: if you’re going to be a monkey, be a smart monkey. Always keep your eye on the banana, but be mindful of people when they speak of the hose. And don’t fling your poop when you get agitated, because that’s just disgusting.

  3. While the motivating story sounds like it’s relevant to RDBMS development, it isn’t. The psych- experimental types have been doing such for decades. The point of the experiment(s) isn’t stifling of the individual or support of hidebound thinking, rather it is whether, and if so how long it takes for, group survival to be imposed over individual pleasure-seeking. Should you be allowed to drive a Hummer when gasoline is in short supply? And so on. Think of it as Ayn Rand meets Karl Marx. These days, Rand has certain mindshare where the real world evidence (climate change, to name one) indicates Marx is closer to the truth for species survival.

    If you’ve been doing RDBMS for more than a decade (two or three is better), then you’re aware that the “innovation” of the last few years amounts to re-assertion by client coders that relational databases should be replaced by siloed flatfile datastores or IMSlite. Just like your Grand Pappy used back in the 1960s.

  4. This article is exceptional in how well it points out the exact way it really is.
    I took over a team of SQL Server DBAs in a government department a few years ago with nearly every one of the team being around 25 years of age or younger (one was older and had already gone through the punishment-for-thinking-differently route). Every, single one of them had the ingrained government mentality of “That’s the way we’ve always done it so that is the way it’ll always be”.
    I was reprimanded for various things including refusal to break the law (by Directors, mind you) and also had one ‘remind’ me that I wasn’t paid to think. Seriously.

    The beauty is that I am now out of government again – and while I miss the higher superannuation payment and leave-loadings, it is worth the cost to be able to get things done.

  5. The story doesn’t ask you to get your fingers burned every day of your life.
    Don’t foolishly run up that ladder, but instead socialise a little. Ask stupid questions. Or leave it, when you have the feeling you’ll bite off more than you can chew. ;D
    Put the answers to the test, in your own room/lab, where you know there are no hoses. It might just turn out to be a nasty written trigger.
    You wouldn’t leave a Table without a clustered index on a Date column, when you’ve got tons of range scans and tons of updates. At least not for a very good reason like a table with just one single row. ;D

  6. I have personally experienced the behavior explained in the above story. As a contractor I would bring up proven methods and then be told by one person repeatedly that will never work here. Come to find out it was her lack of people skills that made it so no one would cooperate with her to do anything she wanted done. Answer me this why do Human Resource departments tolerate this kind of idiotic behavior while losing 7 highly qualified really talented people that quit working there due to this one employee that was so negative, rude, and dragging the whole department down by constantly saying that will never work here?

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.