Coté Memo #16 - Outsourcing & DevOps, Lovecraft, 38% DevOps penetration
Fall is finally coming to Austin, which means it’s nice and cool. With a long lull in travel, I’ve been working on a second edition of my “cloud native journey” PDF. See a fragment of it below, on outsourcing. Meanwhile, I’m reading through the DevOps Handbook to write a review.
Outsourcing and DevOps, it's a problem
An excerpt from the second edition of my cloud native journey booklet. This is from the second section where I cover the common questions and “barriers” to doing DevOps/Agile/cloud native/whatever you want to call it. As I get more of the text done, I’ll post more, if not the whole document for review
One of the most common cloud native inhibitors I hear people complain about in large organizations (esp. government and Western European organizations) is outsourcing. We all know the story: around five or ten years ago, a new CIO came to the organization and achieved huge cost savings by outsourcing much of IT, including developers. It was great for several years, so great that the CIO got an even better job at a new company. In the present day, these organizations find themselves with a huge bill and results they usually don’t like. And in the present, in the era of transient advantage, when creating custom written software is mission critical, these organizations have little to no ability to do produce high quality software.
“Government contractors” often are mythologized to be the worse of all outsourcers. This mini-story from Steven Levy is good example of what typically goes wrong with large outsourcing deals. The US Federal government had been trying to digitize the process for green card renewals, but it wasn’t going well:
While the scale of this project may not exactly fit what you’ve experienced, the general shape and pattern of this story matches what many large organizations tell me is wrong with contractors…which they’re forced to rely on because of past outsourcing decisions that no longer seem like good ideas. It’s little wonder that in a recent study, over 75% of senior executives said they want to replace their “legacy” outsourcers because those providers are so unwilling to change to new models.
Among many others, Citi provides one example of addressing this need to change how outsourcing and offshoring is done in large organizations. Currently 80% of Citi’s developers are contractors, while 20% are employees. Citi wants to invert this model by the end of 2017 and are shooting for 80% of developers being employees with only 20% remaining contractors.Their hope is to drive a culture of ownership, leading to better product level thinking, creating greater alignment to the business’s needs. That is: to become more innovative.
Further, while remote work is possible, Citi has found that having co-located workers pays off: They’re reducing 26 different development locations down to just 4. Going through the process of co-locating team and working with stakeholders is driving a 57% increase in the speed of delivering their software.
Again, what color badge someone wears won’t prevent them from becoming cloud native, but the traditional relationships with outsourcers will probably be an inhibitor. There’s no way around it: you have to start insourcing more, or have such a special relationship with your “outsourcer” that it’s virtually insourcing.
That special relationship essentially means having outsourcers follow the core principals of your cloud native approach. For example, one of the most useful requirements you should have is that the outsourcers work on the same code base, use the same build pipeline, and follow the same integration requirements that your insourced teams use. As Gary Gruver puts it:
Arguably, the “lower levels” of your cloud platform could be outsourced since there are clearly defined contracts between the application and platform layers. However, care must be taken to avoid introducing scarcity into the system. At The Home Depot, for example, after several rounds of trying to speed up the release cycle, managers found that product teams were still not doing releases frequently. Upon investigating why, they found that teams were charged in internal money for each release, making teams leery of blowing out budgets when they released frequently. This sort of a la carte fee schedule occurs in outsourcing arrangements and create negative incentives that will inhibit the rapid release cycles, slowing down the innovation engine for your business.
Coté Content
Links
