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.

4 Replies to “Getting on board: dealing with insubordination”

  1. Wow, “experience in military leadership” is no exaggeration. You’re literally trying to run a software team like you’d run an army. That sounds as disastrous as trying to run an army the way a software team is run.

    I won’t question the philosophical implications of trying to run a team this way, but I will question the pragmatic ones. Programmers generally have control over nothing, except the code they have to maintain. When you take this away, you’re taking away one of the primary reasons they’d want to work for you in the first place.

    Unlike the military, a software team is not a monopoly maintained through use of force. If you make developers frustrated and angry, they will simply leave, and probably find an even higher paying job by the end of the week. They’ll go work for your competitors, who aren’t treating employees like this.

    The team lead may have the authority to treat his team any way he chooses, but he should also have the responsibility to treat them in a way that doesn’t make them want to quit. As they say: people join companies, but quit their managers.

    “If the individual is not a fit, then move him to another team that might have a different control style.”

    Yes. I suggest moving the team lead to a line of work where “control” is the name of the game. Perhaps the military…

    1. Sam, if you read the article, then you saw that 1) I was not the team lead that was being referenced. 2) The article was referencing how to deal with teammates that are consistently being insubordinate. Do you feel that you have the right talk back to your supervisor and out right refuse tasks or things asked of you that are part of your duties and responsibilities within your job description?

      1. Yes. In particular, if my leader labeled my pushback (or any of my behaviour for that matter) as “talking back”, I’d take that as a sign I should start looking around for other opportunities. As far as duties and responsibilities, if my job description literally said I should be an unquestioning code monkey, perhaps “insubordination” would be an appropriate word to throw around. But most tech jobs expect devs to exercise judgement, and true leaders enable that wherever possible. It really should be the job of the leader to convince those she/he is leading of the right solution and to compromise, themselves, when they see it is necessary.

        1. I don’t think you are wrong with these thoughts. It’s hard to put a correct definition on a teammate that is out right defying you, but you have to complete tasks because of constraints on the project (i.e., timeline, business process, etc.) that have a heavy outside influence on development cycles and developer characteristics. Check out the article I wrote on leadership characteristics. One principle that great leaders exemplify is that a leader should surround themselves with great people and allow those great people to do great things and be responsible for the team’s success and ultimately the leader’s.

Comments are closed.