Getting on board: dealing with insubordination

This had a great response on Hacker News.  See everyone’s discussion/comments here.

BLUF: Sometimes you have to directly inform a team member and be explicit about expectations.  Implicit tasks are not always common sense.

Recently I encountered an issue with a team leader who was dealing with a teammate who was being insubordinate.  It was not the first time that they were being abrasive and clearly defying what was being asked of them.  How do you handle this situation effectively?  In this case they couldn’t afford to move the individual from the team.  It was already a small team and there was a tight timeline for a release.

The team lead had already documented the experience 3 times, and was not advancing to a solution.  The conversation in general went like this.

Lead: I need you to implement “X”.

Teammate: No.

Lead: This is not a choice.  I am telling you to do this.

Teammate: You need to convince me.

This is the short version of how the conversation, but suffice it to say that the teammate decided he was in control and wanted the team lead to convince why he should implement a private variable in a class.  The teammate thought it was bloat and the lead just wanted it done to finish out the pull request.  Who is right?  No one is right, but the lead has the authority to expect tasks to be accomplished when asked and has the responsibility of delivering the release on time.

I have had previous blog posts about decision making.  You have to be able to decisions with the information given.  Based on the information the lead wanted the work done to keep everything on schedule.  I call this “Pole vaulting over mouse turds.”  (<– I stole this from another colleague).  This quote is the equivalent of “shaving a balloon” or “break through red tape” except I think it is a more accurate description of how some people treat issues with a terrible solution.

All the lead wanted was a single private variable placed in the class and the amount of effort it took to get that accomplished was a multiple day discussion.  There are processes in place to get things like this removed.  If you are iterating and being “agile”, then you can remove it later realizing your mistake, and if you code it right, then it will not be intertwined into code so deep that is causes a delay.  Just write the less than 80 characters line to add the variable and move on.

The bigger issue in all of this is that the teammate did not want to comply with the lead’s request and decided to go the other direction, and not just stick his tongue out, but gave the middle finger and walked away.  Clearly exemplifying that he was going to do what he wants.  A couple of ways I would have handled this.

  1. Counsel the individual by explaining the roles and how tasks are assigned and accomplished.
  2. Remove the individual from the team before it spirals out of control.
  3. All else fails.  Move on to the lead’s supervisor.

If the individual is not a fit, then move him to another team that might have a different control style.  He isn’t a bad worker, but the relationship between the leadership style and his work style are clashing.  However, to keep the team rolling this problem needs to be resolved ASAP.  It is decreasing productivity and efficiency of the individuals and team.

Normalization of Deviance

BLUF: You must maintain standards in order to drive projects to the right place.

In January of 1986 Challenger launched and shortly after succumbed to an explosion.  It was later found that an O-ring caused the explosion and they later learned that it was a set culture to accept deviation from the norm.  All actions pointed to an almost certainty that Challenger was not going to make it.

Dr. Diane Vaughan wrote about this situation and coined the phrase normalization of deviance.   It is defined as “The gradual process through which unacceptable practice or standards become acceptable. As the deviant behavior is repeated without catastrophic results, it becomes the social norm for the organization.”

Normalization of deviance is a widely known problem in many areas, but most obviously in aviation because of the safety aspect that encircles the aviation industry.  You can accurately chart a timeline where safety violations occurred prior to a major safety accident that was either major damage to an aircraft or a person.

In software an example would be that you continuously let teams or teammates manually deploy out of cycle to fix bugs or when you let a merge occur without unit test(s).  You continuously let this occur and you eventually do it yourself without fixing or adjusting the problem.  Eventually you don’t notice the problems and every merge request continuously becomes worse along the way.

I recently admitted to exactly this problem.  I was allowing the team to commit merges without the proper merge request process where we need two developers to review the merge requests before a merge can occur and you also need to write unit tests.  I let these slide because the timeline was quickly approaching and for 2 months I didn’t adhere to the process.  When the deadline passed and we had some leeway in our timeline.  I recaged everyone’s expectations to know that they need to have 2 other teammates review the merge request and ensure that unit tests are written if needed.

While you are working through a project and if you are looking at team trends through after action reviews (AARs) or retros.  Plot the bad things that happened and track your team trends to find the violations that could create a damaging issue in the future.  Take the time to exercise on an issue that already occurred to see if you can find the precursor events that you could have changed before the event occurred.

Contingency Planning

BLUF: There are times when you won’t have 100% of the answers to create a plan.  Creating a contingency plan is to account for the remaining percentage of the answers you couldn’t find.

Contingency plans are critical to any operations or projects.  It is the “if X, then Y“.  You have to be able to account for these possibilities.  Play devil’s advocate or punch holes in the plan.  In the military this is a common practice.  After we devise a plan a group will provide all of the counter plans that the enemy will execute.  This is all in the process of war-gaming.  In war-gaming you answer all of those IFTTT questions.

In software development you can also apply contingency planning.  Have you ever been creating an architecture design that requires other teams to provide services or architecture in order for your design to work?  I run in to it regularly.

  • What if we don’t have access to a SQL Server database?
  • Who controls federated logins?
  • When will customers transition?

What is your plan at certain decision points?  At some point you have to just build your solution knowing that you no longer have the ability to talk to a SQL Server instance and you have to use PostgreSQL.  You have to run with it.  Do you extend your deadline claiming you couldn’t get it done?

Always have a contingency plan for your project critical paths.  A contingency plan is not pivoting.  It is providing a solution to get over blockers or hurdles, and sometimes that solution is compromising with the product owner that there will be risks in the application if we cannot do things a planned way.  Eventually you need to accept the risks or mitigate some or all of them.  Only after that will you make the decision to not deliver on time because the risk is catastrophic to cause customer issues – exposing confidential data.

It doesn’t take long to run through some simple scenarios where you think something might go wrong.  Cover your bases in the situations that you don’t have accurate or unknown answers.  What database will you use if you don’t have access to a SQL Server instance at the current moment when you are designing and planning.

Volunteer To Tackle Problems

BLUF: Don’t complain to people unless you have a solution that you think is viable.

Everyone complains, and no one likes a complainer.  There is a distinct difference between my kids complaining to me about eating vegetables versus my team member complaining about using AngularJS instead of React.  If you are going to complain about an issue, then you need to have some assemblance of the solution to the problem.

We have issues that come up daily.  Most recently I had a team member bring up – “Why don’t we put in tickets for these issues that we are talking about.”  My response was:

Me: “Have you put in a ticket yet?”
Him: “No.”
Me: “You have access to do it.”
Him: “Well…”
Me: “You can put in the tickets.”

This is a simple example to illustrate what I am talking about.  Don’t mistake this for me getting annoyed or mad about him saying something.  We have to be able to call people out at any level.  If my teammates cannot tell me that my code sucks or my tests are failing, then we aren’t a team.  What the take away is if you are going to complain, then make sure you follow it up with a solution.

Him: “Why don’t we put tickets in for these issues?  I’ll add that to my daily tasks today to make sure we capture these issues for later when we have time.”

Look, I am stressing the point.  I don’t expect a team member to have this very “elegant” sentence, but the bottom line is that I want my teammates to be thinking ahead and not just what’s in front of them.

You should be the one that wants to volunteer to solve the hard problems.  This action will garner you career capital.  People will seek you out for your input, and you are solving the problem that no one wanted to.  People always solve low hanging fruit problems first, which leaves a lot of undesired issues to be tackled and these are your money makers.

Go out of your way to solve issues.  As a leader you don’t let a problem persist.  Attack it head on, assess the problem, and implement a solution.  These things can spin out of control quickly.  I had a commander once tell me that small problems in mass can cause a catastrophe.  We need to be able to break the chain of events before the catastrophe.