Eating your own dog food?

Someone said to me yesterday “we need to eat our own dog food.”  I’ve heard the phrase a hundred times before, but for some reason this time I thought to myself “Ew.  I don’t like the smell of dog food; I’m sure not going to like the taste.”  The origins of “eat your own dog food” are pretty well known.  Alpo food company once advertised that their food was, logically, the food they fed to their own beloved pets.  Somehow that has translated into using our own product or service, while a more appropriate translation might be that we apply our product or service on those close to us.

Symantics you say?  I think not.  Would you crack open a can of dog food and actually (be honest now) eat it yourself?  No, of course not.  It really isn’t human food, but it’s certainly of good enough quality to feed to our pets.  It’s not a bad product, for its purpose.  But software process isn’t something we do to our employees like we serve dog food to our pets.  Or, at least, it shouldn’t be.

A process can’t be just good enough for those who work for us, even if they are the only ones who would use it.  Would we, as leaders of the organization, do it ourselves?  If the answer isn’t resoundingly yes, then the process is just that – dog food.  Meant to be served to someone who we care about, but not quite enough to serve them the exact same thing we want for ourselves.

I understand the sentiment of using the tools and processes that we propose others use.  After all, do as I do is great leadership by example.  But serving your own employees a process you wouldn’t reasonably do yourself day in and day out is not good enough.

Respect for People

John Hunter’s post at Curious Cat Management is a great reminder of what respect for people means.  Having respect for your employees, and the work they do, means being able to look someone in the eye and say “that didn’t work so well, did it?” and then to use that experience to help everyone to avoid making the same mistake.

In Agile software development, the manifesto refers to “People over Processes” but, at least in my opinion, I don’t believe that’s necessarily equal to “Respect for People.”  People are a critical part of the equation, but understanding that people are fallible, to respect that reality and use process to compensate for it is a better translation of Respect for People than “whatever the team wants to do is the right choice.” 

In fact, many Agile implementations, are among the most rigorous development methodologies of all.  However, many implementations are not, and in those cases “people over process” is translated as “to heck with the process.”  In one way, it shows enormous trust in your folks, by allowing them to use their best judgement.  In another way, it’s letting them pack their own parachute before jumping out of a plane.  How respectful is it to your folks to allow them to take a known bad path?