DaveWentzel.com            All Things Data


On Being a Team Player

Ah spring!  Birds chirping, flowers blooming.   As I sit here smelling the freshly cut grass my mind wanders to thoughts of whether the grass may actually be greener on the proverbial other side.  An email just popped into my inbox from some recruiter I've never heard of for a consulting gig that appears to be a good fit for me.  Advanced SQL Server skills, knowledge of data modeling, ability to do performance tuning.  And it's a great rate and good location to boot.  

But there's one thing that's an instant turnoff for me.  "Must be a team player."  Please don't get me wrong...I love working on teams and I enjoy discussing technical problems with knowledgeable colleagues.  But "Must be a team player" is just fluff to me.  Of course your company wants a team player!  Why must that be stated prominently on the job req?  Makes no sense to me.  No company would ever advertise for Benevolent Dictators for their team and they would never advertise for a non-team player either.  I've [Freelinking: unknown plugin indicator "</span><span style="line-height"] about other needless phrases on job reqs...like "senior-level".  Everybody thinks they are senior-level.  Instead, tell me exact skills the job requires.  

I'm waiting for the day when "Must have good oral hygiene" is listed on a req.  Honestly I'd rather see that on a req than "team player."  There are SO many people walking around with bad breath and it affects team productivity when you have to work in a close-knit scrum room.  

Further, have you ever heard anyone describe themselves as "not being a team player"?  I've been accused of not being a team player and I'm sure others have too.  Being accused of not being a team player is sometimes a sign that you have a maverick who is willing to buck consensus for what she believes is right.  I'd rather have that "non-team player" than a team player who is merely a yes-man for the status quo.  That's how companies lose their market edge and go bankrupt.  Too many team players that don't have the backbone to affect positive change.  

I really question whether a company would want a "team player" for certain roles regardless.  Team players are great if you just need a staff programmer or jr DBA.  But if you need a good architect on a Death March Project, then maybe a team player isn't what you need.  Perhaps you need someone to question the most basic premises in your organization.  Perhaps you need someone who won't be afraid of being a maverick if it means the difference between success and failure, or profits and bankruptcy.

I just really hate seeing "must be a team player" on a job req.  It's a big turnoff for me.  Might as well say, "Requires 5 years of experience with SQL 2012"  (it's 2014 as of this post's publication).  Or perhaps, "requires proficiency with word processing applications and email".  Really?  This is for an IT job and I'm expected to be functionally literate with Outlook?  Oh my.  

Seriously though, I'm not sure how any senior-level person (I hate "senior-level" too, see above, but it's apropos for this post) could fathom applying for a job with "must be a team player" in the req.  I would rather apply for a job with a more concise description that does not contain fluff.  

Pavlovian and Operant Conditioning

In my last post, Post-restore Process, I outlined a process my DBAs use to ensure a restored database is always setup properly (TRUSTWORTHY, ENABLE_BROKER, sync logins/passwords, etc).  The actual proc is ridiculously simple and there's nothing new there as far as TSQL goes.  The point is that the process is so patently obvious (to me), yet I see so many environments where things are not sync'd properly after a restore.  And this is at every client engagement.  So, why did I post something so obvious?  The hardest part of implementing a process change like this is the TRAINING.  Your DBAs have probably been following the same processes for years and are resistant to change. 

So how do you get behavior modification quickly and cheaply in Corporate America?  Use Pavlovian and Operant Conditioning.  I knew when I rolled out PostRestore at my company that our 30-year veteran DBAs would be resistant to a process change.  I've seen this behavior at many companies.  Just mention "agile" at a legacy software company and you'll hear the moans and groans, yet they'll be receptive to the underlying ideas if they are not presented as being "agile".  That is resistance to change.  When trying to affect change in the past I tried training sessions, being overly nice, hootin' and hollerin', documentation, wikis, blogs...nothing worked.  So when I rolled out PostRestore a number of years ago for my last company, I decided to try a new approach.  

Pavlovian vs Operant Conditioning?

You've likely heard of Pavlov's dogs.  Pavlov rang a bell and followed it with a treat.  Pretty soon if Pavlov just rang the bell the dogs began salivating in anticipation of the treat.  Operant conditioning is reinforcing good behavior, or punishing bad behavior, to affect change, likely also by providing or removing a treat.  BF Skinner is most associated with operant conditioning.  The main difference is pavlovian responses are more automatic, reflexive actions outside of the subjects control (salivation) and operant conditioning applies a reward or punishment ex post facto.  

How to Use Conditioning to Your Advantage

Grab a bag of candy.  It should be your favorite candy (might as well be something in this for you too).  It should be one type of candy, maybe even one brand.  A grab bag of miscellaneous Halloween candy may work, but not as quickly nor as well.  Your candy can be Smarties, Snickers, Skittles, pretzels, whatever.  But pick one.  We want our people to associate a behavior with this candy.  I used Snickers bite-sized candies (my favorite).  

When I most recently presented PostRestore (a number of years ago actually) I wanted to use Pavlovian and operant conditioning to get the DBAs to use this immediately.  There were too many non-prod envs that weren't properly setup, causing delays and hard-to-dissect bugs.  I passed around a Snickers to every participant every time I executed the proc during my demo.  Now, really, how hard is it to execute a stored proc after you restore a database?  It didn't take long before the subjects, er DBAs, were getting antsy.  They clearly felt I was wasting their time.  No matter, the goal is not training, rather behavior modification.  I then had a handful of the DBAs each try executing the proc for the group by coming up to my laptop and pressing F5 while I projected the image to the group and providing positive reinforcement...and I gave each subject a Snickers for being a good assistant.  As people were leaving I gave them another Snickers as I reminded them to, "remember to always run PostRestore."  By now I was getting strange looks from the DBAs...why so much candy?  

This is a bit Pavlovian and a bit operant.  But I was just getting started.  I knew that invariably I would still have to deal with support issues for a few weeks because Service Broker was disabled (which was the hardest to diagnose due to its asynchronous, non-GUI nature).  The cause was always, of course, PostRestore not being run.  This meant I still had some behavior to modify.  I would then walk over to the DBA and tell him he didn't earn his Snickers today.  The first few times I did this I got a blank stare, followed quickly by that unmistakable lightbulb going off over his head...indicating he just remembered he forgot to run PostRestore.  This was followed by perfuse apologies and guarantees that this would never happen again.  As I would leave I would toss a piece of candy at him.  This is obviously operant conditioning.  

So I had operant conditioning covered, but why not got a little Pavlovian too?  Right after my first training session I arrived at the office a bit early and place a bowl of Snickers right in the middle of the DBA bullpen.  No note attached.  My hope was the visual image of Snickers sitting in the middle of the room would subconsciously help at least one DBA to run PostRestore.  I would pop over every morning for a few weeks and top off the bowl.  

Within a month, using the Pavlovian and operant conditioning steps I mentioned above, I never had to troubleshoot a problem due to a disabled broker on a restored db.  NEVER.  

That's behavior modification.  It didn't require and hootin' and hollerin'.  It didn't require a line item on an annual review.  It didn't require nasty emails.  It only required a little effort on my part and a sawbuck's-worth of Snickers.  

You may find this story funny, you may find it degrading...but you will find that a little conditioning will affect behavior modification.  


Here's a few reasons I know conditioning works.  

  1. We recently got a new batch of interns in our department and they were sitting through Basic Training with the DBAs.  I happened to be in the room for another meeting that was boring me to tears.  I overheard one of the DBAs say, "and every time you restore a database to refresh an environment make sure you run PostRestore."  I then saw him subconsciously reach over to the candy bowl and grab a piece of candy.  I did a spittake with my iced coffee.  This occurred 3 years AFTER the initially training session.  
  2. I swear our DBAs have all gained weight.  
  3. One day I was passing through the DBA team room and I swiped a piece of candy from the bowl.  One of the smart alecky DBAs yelled after me, "Hey, if you're not gonna stay and help us restore these environments don't bother taking our candy!"  I just chuckled and kept walking

Prunes Analysis vs Fletcher's Castoria

Did you ever have somebody ask you:  

  • At what fragmentation level should I REORG vs REBUILD?
  • How many indexes should I have on my table?  
  • How often should I update my statistics?
  • Should I change my oil every 3000 miles or 5000?
  • What is the correct federal funds rate to ensure full employment and low inflation?  

I call these "Prunes Questions".  And I call the process of arriving at a satisfactory answer to these questions "Prunes Analysis".  I named this process after the famous Fletcher's Castoria commercial from the early '60's.  

Just like the commercial says...The problem with prunes is...if I'm constipated, is 3 enough?  Is 6 too many?  

This question haunted housewives and moms for years until the advent of Fletcher's Castoria in the mid 1800's.  Generally, the best laxative at the time was a good dose of prunes.  But how many do you eat?  If you don't eat enough, you're still constipated.  If you eat too many you'll have diarrhea.  

I know, lovely thought.  Fletcher's was supposed to eliminate this enigma.  You just give your kid the dose on the bottle and forget about it.  But of course, even with Castoria you might need to take a second and third dose.  

Where am I going with this?  People, especially IT people, like every question to have a firm (pun intended?) answer.  Given a choice between some prunes and a proper dose of Castoria, most people will take the Castoria every time.  People think of Castoria as the "known" and the prunes as the "unknown".  Known is viewed as being better.  

But not every problem has one "known" answer.  Sometimes "it depends" is a valid answer.  The questions I posited at the start of this post are examples of "prunes" questions.  Every person may have a slightly different answer and who is say who is right and who is wrong?  The answers are often difficult to prove.  In every case the "it depends" is referring to all of the variables that cannot be held constant.  

But most people hate being told "it depends" as the answer to their query.  They view the tergiversator (ambiguous respondent) as lacking knowledge or being standoffish.  But that's not always the case.  Answering "it depends" can be especially perilous if you are a consultant.  Clients like to know that their consultants have all of the answers.  

So, unless I'm trying to be purposefully equivocating, my stock answer to these types of questions is, "Is 3 enough? Is 6 too many?".   This answer makes the questioner stop and think.  I'll then give my answer/opinion, given the knowns, without having to say "it depends."  It's usually good for a chuckle too, especially if the questioner is a bit older.  

Putt's Law

My manager recently quit and it's time to interview for a replacement.  Whenever a manager quits it's common to hear the requisite, "I guess we'll have to train a new one" comments, but I'm going to take the process a little more seriously this time.  

Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand.  --Putt's Law

If you are in IT and are not familiar with Archibald Putt, I suggest you stop reading this blog post, RIGHT NOW, and go buy the book Putt's Law and the Successful Technocrat.  How to Win in the Information Age.  Putt's Law, for short, is a combination of Dilbert and The Mythical Man-Month.  It shows you exactly how managers of technologists think, how they got to where they are, and how they stay there.  Just like Dilbert, you'll initially laugh, then you'll cry, because you'll realize just how true Putt's Law really is.  But, unlike Dilbert, whose technologist-fans tend to have a revulsion for management, Putt tries to show the technologist how to become one of the despised.  Now granted, not all of us technologists have a desire to be management, it is still useful to "know one's enemy."  

Two amazing facts:

  1. Archibald Putt is a pseudonym and his true identity has yet to be revealed.  A true "Deep Throat" for us IT guys.  
  2. Putt's Law was written back in 1981.  It amazes me how the Old IT Classics (Putt's Law, Mythical Man-Month, anything by Knuth) are even more relevant today than ever.  

Every technical hierarchy, in time, develops a competence inversion.  --Putt's Corollary

Putt's Corollary says that in a corporate technocracy, the more technically competent people will remain in charge of the technology, whereas the less competent will be promoted to management.  That sounds a lot like The Peter Principle (another timeless classic written in 1969).  

People rise to their level of incompetence.  --Dave's Summary of the Peter Principle

I can tell you that managers have the least information about technical issues and they should be the last people making technical decisions.  Period.  I've often heard that managers are used as the arbiters of technical debates.  Bad idea.  Arbiters should always be the Benevolent Dictators (the most admired/revered technologist you have).  The exception is when your manager is also your benevolent dictator, which is rare.  Few humans have the capability, or time, for both.

I see more and more hit-and-run managers where I work.  They feel as though they are the technical decision-makers.  They attend technical meetings they were not invited to.  Then they ask pointless, irrelevant questions that suck the energy out of the team.  Then they want status updates hourly.  Eventually after they have totally derailed the process they move along to some other, sexier problem with more management visibility.  

I really admire managers who follow the MBWA (management by walking around) principle.  This management philosophy is very simple...the best managers are those who leave their offices and observe.  By observing they learn what the challenges are for their teams and how to help them better.  

So, what I am looking for in a manager

  1. He knows he is the least qualified person to make a technical decision. 
  2. He is a facilitator.  He knows how to help his technologists succeed.  
  3. MBWA


A Stored Procedure Blessing

Everyday at my current gig I'm asked to "bless" some change that some developer wants to make to some database code somewhere.  

The Netflix Culture

The Netflix Culture from Reed Hastings is must-read material.  I happen to think Netflix is excellent at transforming itself and staying competitive.  Imagine how difficult it would be to change your successful DVD mail-order business model into a streaming model in about 18 months, into an original content provider in less than a year.  I haven't worked at too many places that can adjust and move that quickly.  Others may disagree.  


Managing Developers...Part 10...Summary and Next Steps

"As a manager, I see now that I need improvement"
...so how do you affect change to be a better manager? Just listen. Go to your meetings but don't speak, just listen. If your team is apathetic then just wait, don't force dialog. Then, when they start speaking, don't just listen, "hear" what they are saying.


Managing Developers...Part 8...Dealing with a Productive Staff that Loves You

"But My Staff is Productive and Loves Me"

I've heard plenty of managers proclaim this publicly. It's then interesting to look around the room and see who is chuckling. It's very possible that your staff does love you and you have no issues. But you really need to scrutinize the situation to make sure that is actually the case.


Managing Developers...Part 7...Anarchist Tendencies

Some managers claim that their developers are just anarchists at heart and hate any form of management, bureaucracy, or governance. (See my Benevolent Dictator comments for immediate refutation.) "No one could manage these people." Managers who have failed at forcing scum/agile or kanban, or whatever, down their team's throat will claim that their developers will never accept any structure and process. This is wrong. You'll find that developers LOVE structure and order and process...what they hate is stupidity.



Subscribe to RSS - Management