“Wow, you’ve run an ultramarathon. That must have been hard.”

“Kinda, I guess.”

That’s often how the conversation goes when someone finds out I’ve run an ultramarathon (any race over 26.2 miles). It’s an interesting conversation because people are often fixated on the execution of a single event in my life. An event that lasts 7.5 hours over the course of one day. What people don’t say is, “Wow, you trained for six months, five days a week, in the cold and snow, spending 7-8 hours a week running, cross training a fewtimes a week in order to run that far at one time?”

Progress comes to those who train and train; reliance on secret techniques will get you nowhere. – Morihei Ueshiba on enterprise devops — Andrew Clay Shafer (@littleidea) October 12, 2014

People are often focused on the event, and not what it takes to get to the event. Society focuses on the next great shortcut to achieve something better, cheaper, faster. The thing many of us don’t want to recognize is that the tried and true method of achieving something is hard work and perseverance. You can’t effectively run a marathon or ultra without putting in the hard work of training. You must spend hours a week training. You must slowly build up your miles. You must not over train or else you will get hurt. Sure, there are different methods of training, such as Crossfit Endurance which focuses less on running and more on building endurance, but you still have to train. Anything else will result in failure.

I’m reminded of The Karate Kid (the 1984 original). Daniel was bullied and felt he needed to learn karate. He found Mr. Miyagi, who was willing to teach him. Mr. Miyagi sets Daniel to work painting his house, waxing his car, and staining his deck. Daniel doesn’t want to be a servant; he wants to learn karate! In his overanxiousness to learn, he confronts Mr Miyagi about doing all these chores. We end up finding out that Daniel was learning karate all along.

@jtroyer @mccrory @mfdii @mthiele10 people want to hear a devops secret and get disappointed when you tell them to chop wood and carry water — Andrew Clay Shafer (@littleidea) July 15, 2014

And now, like with everything, people want the shortcut to DevOps. They want the secret sauce that they need in order to transform their business and IT. They want the certification they can earn in a few hours of work to prove they can DevOps. They get frustrated when we tell them there is no easy path. They get frustrated when we tell them that they need to just start doing something, anything to start improving their work. As with the runner, you just have to start running to start training for a marathon.



We now have over five years of history in the DevOps movement. There is plenty of information available for “how to get started”, but the single most important thing a newcomer needs to realize is that it takes a curiosity, a desire to learn, and a willingness to listen to other people that might be different than you. As Aneel Lakhani said in his below ignite talk, “…the single strongest signal that we have something to learn is the fact that a difference exists.”

And there’s the rub with the “classification of DevOps” that people are undertaking. This classification seeks to alienate groups because differences exist, not unite them because they have something to learn from each other. After reading the latest post on the subject, a friend tweeted about going through those exact same things in a 100 person company right now. If enterprises solve problems in their own little world of DevOps, how do we ensure that this knowledge flows down to the “non-enterprise” DevOps practitioner? This stratification divides us rather than unites us.

When we willfully disregard core tenets of the movement, such as Collaboration and Sharing, we are essentially back to where we’ve always been, and no one moves forward. That is why hearing the stories coming out of the DevOps Enterprise Summit is encouraging. Large companies are opening up and telling their stories of transformation. Large companies are proving that the ideas of DevOps work, no matter your size.