Disclaimer: I witnessed this first hand as a junior software engineer several years ago. This is a stark reminder of how a neglected team member can suffer both professionally and personally. The names have been changed for privacy, and this person did not report to me.
It was early 2001, when Ben walked into the interview with a jovial personality. Ben’s resume was impressive with a laundry list of accomplishments as a Senior Software Engineer. We grilled him in a series of 2-on-1 interview sessions and at no point did he raise any red flags. Ben’s answers were articulate, and he was hired shortly thereafter.
Once Ben had joined the company, the IT Director placed him on production support for our evolving trade platform.
He did this (I believe) for 2 reasons:
- Since we had no training material, it was an easy way to have Ben learn the platform.
- It would place another set of eyes on our critical bug stream.
Ben sliced through malformed XML with the speed and precision of a Japanese master chef. One misplaced decimal point or node could result in thousands of dollars in gain loss, yet none of which happened on Ben’s watch.
As our start up matured, we adopted an agile framework to help quickly meet the needs of our clients. Our core offerings flourished and our teams gelled. This was great news except for Ben, who was still on production support after more than a year. The IT Director had either completely forgotten about Ben, or was unwilling to let him work on new functionality. I imagine if Ben had participated in our shiny new agile team we’d have to actually address our sustained engineering problems.
Ben’s personality slowly deteriorated over time as he watched his coworkers continuously roll out new functionality. One afternoon we found him underneath his desk, sobbing in a fetal position. Needless to say Ben wasn’t with the company for much longer.
What lessons can we learn from this tragedy?
- Good developers want to create code, not continuously patch it.
- Do not leave a team member isolated on a project with no end in sight.
- Training new team members should be mandatory.
- Single points of failure do not save you money in the long run.
#1 by Brian Wawryk on October 22, 2010 - 4:23 pm
I experienced this when I first was hired coming out of university. However, I recognized it within a few months of starting and immediately began applying elsewhere. Five months after I started in a prod support role I had found another job that gave me that “new development” opportunity I was looking for.
#2 by Sameer Bendre on October 22, 2010 - 4:34 pm
There are very few who get or grab the chance to get out of such lingering mess. Lot of factors go in between “get” and “grab” and your supervisor can play a BIG role in it. I believe Ben took a little longer as it was 2001 the bad patch. But, it’s sad, de-motivating and shaking for a coworker to witness this. What Ben has been through? No one can ever imagine.
(On a side note: reminded me of the “stapler guy” from office space who is always ignored!)
#3 by Derek Huether on October 25, 2010 - 1:41 pm
This brought back memories of my last company, where I was Manager of Software Engineering. We also put new developers in Production Support. It was baptism by fire. One difference from poor Ben and his situation was I would make sure, after each release, there was an exit strategy for anyone asked to serve. Though it was a little disruptive, all developers expected a tour of duty in Production Support. It acted as a good reminder that bugs may come back to haunt them. They just couldn’t throw things over the fence.
Alas, after I left, the rotation stopped. I just received a call last week from one of the developers. He gave his notice. Why? He wanted to create code, not just fix it. He didn’t see an end in site for his tour on Production Support.
#4 by Agile Scout on October 25, 2010 - 2:34 pm
wow. Thats epic. I’m glad I never got to that point as a developer!
#5 by Billy Kirsch on December 15, 2010 - 7:17 pm
Great reminder of how important it is to support and celebrate staff, co-workers and take time to build a team environment.
#6 by David J Bland (@davidjbland) (@davidjbland) (@davidjbland) on August 5, 2011 - 10:36 am
Why is that Programmer Crying? http://bit.ly/qcUS3V