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.

I know. It shouldn’t make a difference.

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..."