Dealing with Unaccountable Developers: Page 2

Posted February 15, 2010
By

Eric Spiegel

Eric Spiegel


(Page 2 of 2)

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.


Page 2 of 2

Previous Page
1 2
 



Tags: Project management, development, developers, IT management, IT management job


0 Comments (click to add your comment)
Comment and Contribute

 


(Maximum characters: 1200). You have characters left.