The Clutch

The Catalyst

We are in an intense recruiting round here and are looking for genuine cream-of-the-crop
developers and QA people.  We have had surprisingly good luck with finding some
genuinely passionate and talented people out there.

During one interview, though, I asked the question of a developer, “What is the thing
that enjoy most in your work?”

His answer was, “I like coming through in clutch situations.”

Hmm…

Not Good

I appreciate his feeling.  I worked for years in a mode where I was constantly
seen as someone who would get the job done via heroic efforts.    Late
nights, early mornings, new and weird ideas were common.  I remember saying,
“Put me on the plane to that client and I will get our product working just fine.” 
It worked.  I was the hero.

If this is happening to you or another “super star” in your shop, you have a big problem.

Who is responsible for bringing order to your chaos?  Your manager? You? 
If I had never needed to get onto that plane to fix that problem, then the client
would have never been angry.  If the time lines of the original project plan
were realistic, I would never have worked late nights and would have seen my first
boy take his first steps ( 8 p.m. on a Wednesday).

“Well, sure,” you say, “but that will never happen.  Those things are outside
of my control.” Wrong.

Use the methodologies that you are reading about.  Scrum, Agile, Continuous Integration and
TDD are not just buzz words.  When applied appropriately, they can actually get
you home for dinner and get your software to your client in a way that you know will
work. 

All you have to do is do it.  You can only change your own behavior, but the
good news is that you can change your own behavior.  The next
time someone asks you how long something will take, don’t answer them for at least
10 minutes.  Consider what it will mean to bring up that server, put that new
project in source control, create that build script, write those tests, and automate
that build.  Then, because developers are eternal optimists, increase your
estimate by 50%.

Under Promise, Over Deliver

While “Under Promise and Over Deliver” sounds like a real drag, it works. 
While you may begin to sound like a broken record to some, you will begin to accomplish
what you have said you will.  This is particularly important in small development
shops where you are the goto guy for everything else that is going on.

Balancing the inverse relationship between flexibility and dependability is a hard
thing to do and your greatest chance of success is to build in the time you need to
keep dependability on top.  Your boss will be ticked that the new app isn’t ready,
but will be furious when the exchange server goes down.

Clients will rarely remember that you delivered late.  They will always remember
that you delivered poorly.