Skip to content

Rants of a Madman – When Job Descriptions Attack

September 15, 2012

What’s your job description?  I can tell you mine off the top of my head without thinking:  Deliver high quality solutions on time and under budget that delight my customers.  In fact, I would contend that should be the job description for any Agile Team member regardless of department, title, HR filed job description.

In my many years I cannot tell you how many developers that I’ve met who thought their job description was simply to “pump code”.  These folks viewed themselves as artists on top of the technological food chain.  If they were doing anything other than writing code then their precious time was being wasted.  I know, I was one of these folks and that’s what I mistakenly thought early in my career.  That said reality kicked in and I soon realized that writing code was simply a component of the job.  I learned that to be successful that I had to pay equal attention to defect tracking and management, source code control, build management, release management, unit testing, and many other disciplines that actually helped me become a much better developer and allowed me to pump my own better code even faster.

I also witnessed something early in my career that made a huge impact on me that I thought I’d share.  We had a developer on one of the teams who walked on water.  He had the Midas Touch and could pump code like no other, making things work after many others had given up.  When it came to critical path tasks he was always one of the guys always brought in to save the day by management.

He was also, pardon my French, an ass.  He believed there was a caste system between developers, QA, support and other groups and that by sitting at the top of the food chain that all he had to do was pump code and everybody else could kiss his ring.

One day there was a huge yelling match out in the halls and I stepped out of my office to see what was going on (now I date myself…all developers at the time had individual offices so they could close the door and managers could shove pizza in the gap under the door; crazy, no?).  A QA specialist had found a defect in this developer’s code and filled out an incident ticket and presented it to the developer.  The developer was furious and was shouting in the hallways.  He ranted and raved how stupid QA and others were for not finding the bug sooner.  He wondered out loud how was he supposed to build great code if others who had job descriptions for testing that code were so bad at their jobs? In fact, he even bragged that he knew about the bug and was simply waiting to see how long it would take QA to find it.  Since it had been there for months he stated that he was surrounded by idiots.

Finally a manager left her office, walked up, asked what was going on.  She listened to the entire tirade again.  Without blinking she asked one question very calmly:  “So you knew about this defect and failed to enter it in to our defect tracking system as a test to see how good or bad our QA group is?”  The rockstar senior developer gleamed with pride and replied “Yes.”  Her reply was simple, short, and to the point:  “You’re fired.”

Afterwards she pulled some rather dazed and confused folks together.  Many were shell shocked as nobody had ever been fired like that before.  Also, nobody ever thought that golden boy could be touched as he was one of the best coders out there and schedules were sure to be impacted as a result of his abrupt termination.  She kept her words few, but on point when she explained what had happened and why she did it:  “Our jobs are to delight customers with high quality products that are delivered in accordance with the commitments we’ve made; from this day forward throw your job descriptions in the trash.  We are all on the same team.  We all pull on the same rope together.  If you agree you are welcome to stay; otherwise I’ll arrange for boxes.”

In the many years since, I’ve seen various versions of this job description log jam.  On the other end of the spectrum I’ve even had QA leaders and staff who believed their jobs were to “stop products from shipping that had material defects that would greatly impact customers.”  Sounds nice at first until you realize that what they are really doing is saving up some of the hardest tests until last such that they could hit the stop button a day or so before a release…  As opposed to running those tests early and often and allowing those final days of testing to simply be smoke tests of what was already tested to ensure something materially didn’t break, they took pride in hitting the stop button and causing the entire team to have to retrench for days or even weeks.  Instead of working proactively with the teams to ensure the gnarliest issues and gaps would be considered and covered by the teams early in the cycle they simply had a test plan in their folder for exposing the gap.

Although not as drastic and without a hallway of spectators I had to have the same discussion with them as a newly minted manager:  “Your job is to ship high quality products on time that delight customers; testing something for the first time the day before release to prove a point in no way aligns with that job description.”

This is one of the reasons I love Agile.  Job descriptions be damned.  There are roles to play and if the role needs to be covered then somebody steps in to cover that role.  Grab the story, move it to the in-progress column, and work it.  Of course we try to cover what we know best, but we also jump in and cover what we don’t know or lend a hand to others when we have to.

We also don’t stay silo-ed within our own definitions while playing these roles.  If you are a developer you can code until your heart’s content, but your job isn’t done until you know that code works before you check it in; if that means building test harnesses first, then so be it.  Stories need acceptance criteria?  Add them first and validate with the Product Owner.  UAT test cases need to be checked out before UAT, then do them vs. waiting for UAT.  Not written yet, help write them…

So, now that you’ve read this, regardless of your title or level, what is your job description?


From → Agile, Quality, Software

One Comment
  1. What’s up i am kavin, its my first time to commenting anyplace, when i read this post i thought i could also create comment due to this sensible post.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: