Slow Down to Go Faster

How Leaders Must Learn to Pull the Andon Cord

In the early days at Wealthfront, we took the “build the plane as you’re falling off the cliff” model to a whole new level. We had inherited a very popular Facebook game whose backend was falling appart: data was getting lost, accounting records were corrupted, site wide game rankings flawed... Our users were leaving en masse, and we literally could count the Days Until Death.

We transplanted in a new system, grafted it on the old UI and started the slow process or stopping the user hemorrhage. The team worked day and night. I remember sleeping under my desk to maintain my 20hr/day rhythm. It was rough.

My time was devoted to keeping the lights on, but part of the team was getting ready to work on a new shiny UI. Which framework we’d use wasn’t clear. Django? Rails? GWT? Everybody had some opinion, but the final call was mine to make. Pressure was building up.

One of the engineers — very passionate about GWT — showed up one morning and announced “I’m now blocked on the final call. What should I do? Go to the beach?” I pushed back, saying there were production issues that needed immediate attention. Second day, same story. “So, beach day for me?”

The third day, I caved, put aside my urgent work, took a few hours to code examples in each framework, and hastily agreed to go the GWT route.

From there on, things went downhill very fast. Suffice it to say that developing using GWT was unnatural and slow, the application we ended up with was fine as a Facebook app, but inappropriate otherwise, tensions arose in the team ultimately leading to a departure… And icing on the cake, we had to do a complete rewrite 6 months down the road.

This easily ranks as one of my biggest professional mistakes. It still haunts me.

This isn’t a technical post, and it would be too simplistic too look at this as a bad framework choice. The mistake was my failure to realize the broad set of constraints to consider and improperly assessing the lasting impact it would have on the team (tensions, rewrite & lost engineer). It was allowing myself to optimize for what was in front of me (an idle engineer) and failing to recognize the big picture.

In retrospect, I would have needed to pull the Andon cord. Alert everybody that there is a problem, slow down production to the pace of my station, ask for help. As a company, we would have been better off taking extra time to reflect on the decision, at the cost of someone being idle for some time, rather than rush into making everybody “busy.”

The Andon cord and its concept comes from Kaizen, the continuous improvement mentality which started in manufacturing. Slow production down to the pace of the weakest link to maintain high quality standards.

During the accelerated recalls that Toyota suffered in 2010, Akio Toyota wrote in an op-ed:

Two weeks ago, I pulled the andon cord for our company. I ordered production of eight models in five plants across North America temporarily stopped […]

Everything stops (temporarily). We all focus on a particular problem. We keep calm and carry on.

Now, we all feel overwhelmed at times. Why not just say so and slow things down? Let’s learn to pull the Andon cord — we’ll go faster in the end.