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.

Mentoring: the Class of 2015

A couple of weeks ago I kicked off a competition of sorts, to find some people to mentor to celebrate the community voting me “Person You’d Most Like to be Mentored By” in the annual Redgate Tribal Awards.

If you remember my terms, all someone had to do to be considered is write a blog post and post a link (and the link had to work!). Below is the list of everyone who qualified, with links to their posts, in the order they were received.

  1. Garry Bargsley
  2. Dean Savović
  3. Anthony Nocentino
  4. Shawn Melton
  5. Shane Bryant
  6. Chris Bell
  7. Peter Baillie
  8. Martha Schofield
  9. Dennis Cheung
  10. Tim Moss
  11. Max Vernon
  12. Snehabandakavi
  13. Robert Bishop
  14. Peter Tran
  15. Clive Strong
  16. Marcos Galvani
  17. Sarah Falkavage
  18. Derek Czarny
  19. Siva Ramasamy
  20. Mark Sinkinson
  21. Derek Hammer
  22. Pat ? (Incessantlearner880)
  23. Steph Locke
  24. Arun ? (blobeater)
  25. Giacomo Gozzi
  26. Steve Hall
  27. Charles Olatunji
  28. Terri Champlin
  29. Sandra Gaw
  30. Todd Kleinhans
  31. Sina Hassanpour
  32. Dan Stefan
  33. Ryan Desmond
  34. Kevin Feasel
  35. Mika Sutinen
  36. Matt Bowler
  37. Kyle Hayes
  38. Paul McHenry
  39. Praveen D’sa
  40. Josh ?
  41. Gilbert Quevauvilliers
  42. John ? (logosphos16)
  43. Ognjen ?
  44. Sam Bryant
  45. Lalitha ?
  46. Tracy Boggiano
  47. Paul Popovich Jr
  48. Paulo dos Santos
  49. Priya ?
  50. JP Godoy
  51. Mark Wilkinson
  52. John Wells
  53. Travis Gan
  54. LongHairedWeirdo

I said I’d read through the blog posts and pick three men and three women to mentor over the next couple of months.

How could I figure out who to pick? Is X more worthy than Y? Would A benefit more than B? Who am I to judge that?

So…….

EVERYBODY WINS!

Yes, I cheated a bit. I had no intention of trying to arbitrarily pick someone over someone else – that would just leave people disappointed. So I told myself that I’d mentor anyone who was motivated enough to write a blog post and submit it for consideration. That was the first test.

Yup. I’m going to mentor all 54 people on the list. And I’ll spread it out over the rest of the year, rather than trying to do it all in the next two months. Yes, it’ll take a bunch of my time, but it’ll be fun.

The second test for all the people on the list is that they have to send me an email using the link in this post, from a non-work email address (as we’ll end up discussing your work probably), by the end of February. You don’t need to say anything in the email – I just need an email address to contact you to kick things off.

Congratulations to everyone on the list!

(Hopefully this will work out really well and maybe I’ll do something similar next year)

Physical security

TSQL2sDay150x150_388014A5

This month’s T-SQL Tuesday (hosted by Kenneth Fisher – @sqlstudent144) is about security This hasn’t been my area of expertise for a long time, although I did write a long TechNet Magazine article about common security issues and solutions back in 2009.

There’s a huge amount that’s been written about implementing security in SQL Server and Windows – working towards the security of the data while it’s in the database, being sent to the client application, and within the client application. This can be incredibly important for your business and your clients and so the focus there is justifiable.

However, I think there’s an aspect to data security that’s often completely overlooked: physical security.

Consider the infrastructure in your environment, and ask yourself the following questions:

  • Are the servers running SQL Server physically secured so only authorized people have access to them? I’m not just talking about whether someone can walk out with a server under their arm (and then get the hard drives with the data on – the actual server hardware isn’t a physical security risk if there is no data storage in it), although this is something you should consider. I also want you to consider whether an unauthorized person can walk up to such a server and insert a USB drive that could have an auto-run program on it that installs some kind of security hole.
  • And what about if the server has server-local storage? An unauthorized person could grab a hard drive from a server and clone it really quickly, maybe overnight so no-one’s available onsite to see why the server went down. Here‘s a link on Amazon to a machine we use for quickly cloning laptop hard drives when we upgrade them. Really useful, but also useful in the hands of someone with nefarious aims.
  • Are the storage arrays where the data resides physically secured so only authorized people have access to them? And what about the routers? Here is a thread from the Dell support forums about making an MD3000i password reset cable from scratch. You don’t want someone to be able to physically reset the password on some storage array, and then make a connection to it from an unauthorized server on the network and gain access to the data on the drives. And then there’s the question of someone just popping out some of the drives and walking away with them…
  • Are there cameras monitoring all of the above?
  • For the questions above, now ask them about your failover data center. And what if you data center is hosted? Does the hoster guarantee physical security of your data?
  • Now let’s think about your admin users. What kind of physical security protects the desktops of the people with secure access to the data? Is it possible for them to walk away and leave their screen unlocked? Is it possible for someone to walk up to their computer and plug in a USB drive with some auto-run software on it?
  • Now let’s think about your admin users’ laptops. Same questions as above. What about if they take their laptops home? Or they use their own systems at home? Are they physically secured so someone can’t access your data from these people’s systems?

Still think your data is secure?