The Misappropriation of Terms: Andon Cord

Posted by Howard on Friday, October 28, 2016

Software developers tend to be a bit hipsterish in that we seem to have an inherent attraction to novel things - especially when those novel things are lifted from the old things of other disciplines. The Andon Cord is one of those nuggets lifted from the same corpus that brought us much of what is now termed “agile”: Automobile manufacturing - specifically, the manufacturing practices of Toyota.

While more thoroughly described by others, the Andon Cord was a physical cord that ran along side Toyota’s entire production line and when pulled, stopped the assembly line. The culture that it yielded was one where every employee, no matter their role within the organization, was empowered to “pull the cord” when he or she saw a problem and bring production to a stop until the problem could be resolved.

Empowering employees? Sign me up! Why wouldn’t we want to apply this to building software???

Well, I’m glad you asked. I’ll take a stab at it.

Because software is not a manufacturing endeavor.

We should absolutely be empowering employees - no question. Especially employees who tend to be driven by principles such as impact, autonomy, and mastery. However, we should be empowering them to build - not stop building from happening. In my opinion, empowering people to “pull the cord” will ultimately create a culture of passive aggressive bullying at the level of ideas (since it doesn’t make sense to pull the cord once software has been built). In fact, I recently heard a VP threaten a team by saying, “I’m going to have to pull the Andon Cord on you.”

Sorry, but I don’t think that the thinkers and planners at Toyota ever had that scenario in mind when they built their manufacturing culture.

Software development should be fundamentally different than manufacturing in a few major ways:

  • It should be inherently parallel
  • Conclusions around success or failure should be made based on measuring real things (see Lean Startup)
  • If something is determined to be a failure (again, as a result of measuring) - or if a better idea comes along - there’s no assembly line to stop. Rather, something else should be built that will obsolete the first thing.

This is the general approach used by companies such as Google and EBay, and I think that most of us would agree that they have been pretty successful at building innovative software. So why do we have such a fascination with applying practices from manufacturing disciplines? I suspect that it’s because at the end of the day, software developers are human beings, meaning that all of the principles of human nature apply equally to them as they do to those in the manufacturing industry. Some people want to be line workers and not have to think deeply beyond the task that they have been given; some people crave power and the ability to tell other people want to do; and some fall into myriad other points along the spectrum of identity and motivation.

“Well we’re not Google”, you may say. And I get it - I really do. However, I’ll argue that if this is the justification for employing a serial, assembly line-style approach to software development, I will predict that you will be out-innovated and disrupted at some point in the future by a company (or an individual) who is more comfortable living in the uncomfortable.

Why do I assert this? Because it’s already happening in industries like manufacturing and retail.