Dealing with Unaccountable Developers

Déjà vu. It was the same response to a different request. Looking back on it, I can’t believe I didn’t see the pattern.

John was an above average developer on my team. He was the type of guy who everyone liked to be around. He was totally easy going and had great sense of humor. But John was not accountable.

As a manager, it is much easier to implement consequences for a bad job if the person responsible is someone that isn’t such a nice person.

It’s the manager’s job to treat everyone fairly. In my experience, this isn’t usually the case. It’s just more palatable to punish someone who is a jerk.

John was not a jerk. Not even close. And his code deliverables were all well tested and conformed to standards. His code worked as expected.

The problem wasn’t the quality of his work; it was that he was consistently late with his deliverables. And I am here to say that John was an expert at finding excuses.

He was likely the kid at school whose dog ate his homework. And I’m betting he got away with it. He’d probably smile at his teacher, give her a compliment – “Say, did you do something different with your hair today, because it looks spectacular?" And then lay on the sad story of his dog’s subsequent digestive problems.

The key to his successful procrastinations was that his work wasn’t abhorrently tardy. He would just turn work in a day late here and there. And as I mentioned, his code passed peer reviews and was always perfectly in sync with requirements.

The problem was that over the course of a project his disregard for deliverable dates would add up just enough to impact the overall schedule, causing problems with integration coordination and production implementation.

As a manager, if you don’t deal with these types of nagging issues, they will eventually be dealt with by someone else. That someone else in my case was my boss.

Because as a manager, it was my responsibility to ensure the project work was done on time. My manager didn’t care about John’s excuses. And evidently I wasn’t nearly as clever as John with great excuses.

We were working on a project for a Fortune 500 company to completely redo their billing system. This was before ERPs were popular and when the big companies wrote this code from scratch. You know, the good ole’ days when developers could reinvent the wheel in their own unique way.

John’s assignment was the dunning module, or more simplistically referred to as the bill collections module. It wasn’t rocket science, but it wasn’t all that easy either because the system was being written in Cobol II.

His code had to use reference modification (i.e. string manipulation) to create an automated word processor that resulted in a perfectly formatted dunning notice based on varying text lengths. Today, this would just be a module in the ERP system that was written one time with a more advanced language. John had to write it from scratch.

My point is that it wasn’t a simple assignment. However, everyone on the team knew he was most capable of creating some pretty cool logic that was quite innovative. Everyone also knew that he would likely be late. And everyone overlooked this fact because, well, they just liked being around John.

Each deliverable was clearly communicated to each team member. Each of them received a copy of the project plan with their timeline highlighted. Yet, this is how it played out.

1. Deliverable – Unit Testing and Peer Review

John shared an office with Sara. They were great friends. And it showed. They were constantly chatting it up while they worked. They’d go out to lunch and come back late. They’d go out on smoke breaks and be gone for longer than a smoke should take. (Turned out they were more than friends, but I was oblivious.)

Next Page: "John had a great idea. He organized a mid-week happy hour..."

Regardless, the difference was that Sara would work late and her deliverables were on time. John would rarely work late and when he did, he wasn’t usually working. He’d be playing games over the network – I think it was the first release of Doom.

When it came time for his peer review, John called in sick. He sent an email explaining his throat hurt too badly to talk. He did attach his unit test plan, but his code was not checked in for review.

The unit test plan looked good, so we just rescheduled his peer review for later in the week and sure enough his code passed with flying colors.

Schedule impact = 2 days

2. Deliverable – Integration Testing

When it came time to work with other teams on integration, John had a great idea. He organized a mid-week happy hour for all the teams auspiciously claiming everyone could form better working relationships and blow off some steam over halfway through the project.

Okay, fine, he was promoting inter-team cohesiveness and relieving stress, so why not? Except it was the day before his code was to be checked in for integration testing.

Happy hour turned into happy hours and everyone was dragging when they came in the next day, me included. Some didn’t show, including John. He sent an email (funny, he never called) bemoaning that his car wouldn’t start.

If I were the suspicious type, I’d bet he was hoping many of his peers would also skip the day with hangovers, diverting attention from him missing another deadline. After all, he was buying rounds of shots for everyone. What a great guy!

Schedule impact = 1 day

3. Deliverable – Production

This is when I went to John and asked if he thought he could make up the three days before his code was checked in to be packaged for production. “Not a problem,” was the response.

But accountability to schedules was always a problem for John. This was his third project in two years where he was consistently late.

On the day his final changes were to have been ready, I had a sinking feeling when I saw his email pop into my inbox, with the subject “Small problem.” His excuse was something about his sister needing someone to watch her kids because she was subpoenaed as a witness and had to be in court.

Schedule impact = 2 days

His “not a problem” had turned in to a BIG problem for the team and me.

We had to delay go-live for production due to his “small” delays that added up to a full week. I was reprimanded by my manager, which finally spurred me to confront this ongoing problem with John.

Confrontation…Kind Of

He was incredulous (in his nice kind of way). “Hey, you have to agree that I had legitimate reasons every time.” He went on, “I had the most difficult assignment on the team and I did the best I could under the circumstances.”

I explained that it wasn’t like he struggled with the technical challenge. And individually, each of his excuses was reasonable. The bigger problem was the continuous pattern. He was put on a performance improvement plan that required he make deadlines regardless of circumstances.

John resigned before his next deliverable. We lost a very good developer, but we regained our team accountability. And I realized that just because someone is a nice person, a manager can’t let things slide.

I did hear his going away happy hour was a blast. Not surprising - I wasn’t invited this time around.

ALSO SEE: Why Developers Get Fired

AND: When Developers Work Late, Should Manager Stay or Go?

AND: Are Quirky Developers Brilliant or Dangerous?

Eric Spiegel is CEO and co-founder of XTS, which provides software for planning, managing and auditing Citrix and other virtualization platforms.