DevOps enablement is key to growing your business

Let’s say you own a fish market in a small town in Alaska.  You do pretty well supporting your local village of about 500 people.  Each day you sell around 40 fish.  You employ a couple of local fishermen who can support the demand.  Everyone makes a living, and everyone gets to eat fish when they want.

Then something happens.  Your village gets featured in a travel magazine as a beautiful destination for vacationing and whale watching.  Suddenly you have lots of people coming to visit, and even moving there permanently.  The population of your village doubles and demand for your service skyrockets.

People waste food, so they always buy more than they really need.  This means that when the population doubles, your demand actually goes up by 125%.  Now you have to supply 90 fish per day.  Your existing fishermen can’t scale up to meet that demand, so you have to hire extra fishermen.  Additionally, these vacationers have different tastes, and they want you to get new kinds of fish.  That means your crew needs different bait and tackle, different rods and reels.  You have to learn all about that new gear and make sure your fishermen know how to use it.  You have to learn how to clean these new kinds of fish and prepare them for your customers.

Then oil is discovered nearby and the population increases by another 4x.  Because waste scales as well, you now need to supply enough to sell over 450 fish per day.  This means lots of new fishermen, and lots more supplies for them.  The overhead of managing that process is crushing, and you are actually making less money now than you were before all this growth.  At this point, you just want to close up shop and go do something else.

Now… let’s imagine that instead of a fish market you owned a bait and tackle shop.  You sell rods and reels to the locals, along with tackle and other supplies.  Play that same series of events out.  This time, the growth is helpful and you are able to benefit from it.  It’s relatively easy for you to scale up shipments and supplies.  Adding new types of products to your shelves is simpler to account for since you profit directly from their sales.    

Traditional engineering works like the fish market example.  Development teams have needs, experience waste (bad/failed deployments, bugs and downtime...etc) and as the business scales up through acquisition (the travel magazine) or by adding new products to meet new market opportunities (the oil discovery) the demands on engineering skyrocket.  Your business will collapse under this model, because the overhead is so high that eventually you will not be able to make changes fast enough to meet demand.  

DevOps is the tackle shop example.  In that model, instead of giving people fish you are teaching and equipping them to fish for themselves.  While it still has to scale up as your business grows, the overhead in that model is dramatically lower, and accounting is much easier.  A relatively small team can support a huge diversity in technologies.  

If you want your engineering function to scale efficiently with the rest of your business, make sure you are not building a dependency that can’t scale.  The DevOps model of enablement will help you avoid that.

Note: I fully agree that analogy is the weakest form of argument and that this story is pretty simplified.  I had this idea a while back when thinking about teaching to fish VS giving fish and it’s served me well in explaining DevOps to non-technical folks.  Just sharing here in case someone else finds it a helpful way to talk about how DevOps is different than traditional engineering.