How do you handle a developer that doesn't play by the rules?

Software development teams are fickle groups. It seems everyone has their own pet peeves that set them off, and a group that is cohesive and functioning well can quickly turn into one that shows little output for the time spent working.

In order to create and nurture a software development team takes leadership that understands all of the idiosyncrasies of their team members, and ensure that no one member derails the rest of the team. While some may use this as a way to discriminate against entire groups of people, if done properly, should only be utilized to maintain harmony after all hiring and performance decisions have been made.

For example, a team may have established that unless otherwise arranged with management, all developers should be present for the daily scrum at 9:00 AM and are expected to work 40 hours per work week even though they are salaried exempt employees. Lets say that all of the team members except for Joe show up around 8:30 AM, take a 1 hour lunch, and leave between 5:30 PM and 6:00 PM. Joe regularly shows up at 9:35 AM, takes a 1 hour lunch, and leaves around 4:00 PM daily.

In this scenario, the organization’s leadership has to determine whether Joe’s work habits are causing issues within the development team or not. For some teams, if Joe is producing as much output or more than the other members of the team while working fewer hours, it is understood that Joe is so good that he gets a bit of a pass on some rules.

However, if Joe is not the superstar performer, the question gets tricker. Many times it seems that this pattern erodes the morale of the other developers on the team that put in more effort than Joe and produce better results than Joe. When the morale of the team begins to decline, organization leadership has to determine whether to attempt to correct Joe’s habits or to attempt to replace Joe with another developer that is willing to adhere to the 9:00 AM start time and 40 hour work week that the organization has determined is the way they will conduct business.

Once you get to that first decision point and decide to attempt to work with Joe to adjust his behavior to adhere to the rules of the organization, the waiting begins. Over the next several work days afterwards, everyone on the team pays special attention to Joe’s behaviors to see whether or not he shows up on time and stays later into the day. If he never makes a change, then it should be obvious it is time for Joe to move to an organization that better accommodates his normal work schedule. However, if Joe adjusts his behaviors slightly for a while, and then relapses for a period of time, you are back to the decision point again.

At this point, it has already been determined that Joe’s behavior has negatively impacted the work output of the rest of the team, and Joe is not a superstar performer that is able to make up for the work output deficiency. This is the time to ask yourself how many times you are willing to go through this cycle with Joe before enough is enough. Will it be 1 time, 3, or 5? What precedent does this set with the rest of your development team, and when they see your reaction to Joe, will they start taking the same liberties with the rules that Joe did, since he has repeatedly failed to adhere to the organization’s rules, but still has a place on the team? Do you decide that Joe’s way of working is actually better and decide to change the rules so that Joe’s way is the standard?

How do you want to handle things when members of your team challenge the rules? Adhere to the rules, or change the rules?