Complexity, interchangeability, and partnership in outsourcing

In this post, John Naylon draws an interesting connection between multi-cloud strategies and outsourcing. I won’t steal his thunder by saying any more!

Mark

Complexity, interchangeability, and partnership in outsourcing

 What do emptying the office wastepaper baskets and manufacturing iPhones have in common? Perhaps not much on first inspection. However, these are both tasks which are outsourced by organizations to external suppliers. Clearly, though, there is some kind of qualitative difference, and it is instructive to examine this difference in more detail.

Clayton Christensen, in The Innovator’s Solution, refers to the exercise of deciding which business processes an organization undertakes itself, and which it outsources, as getting the scope of the business right. This is a sophisticated development of classic “core competency” theory, which proposes that an organization should decide what it is fundamentally good at—and outsource everything else.

For the process of emptying wastepaper baskets and other office cleaning, it is a simple—even default—decision for the vast majority of organizations to outsource it. That is because it is a simple, easily defined task for which there are likely to be many competitive suppliers in any given location. Since the task is easily defined, and performance can be easily measured (were the bins emptied and the floor cleaned?), the choice between suppliers will typically be made on a price comparison. In the event of poor performance, an unsatisfactory supplier can trivially be substituted by an alternate supplier.

Manufacturing an iPhone, needless to say, is a far more complex task to define in sufficient detail for an external supplier to successfully undertake it. For a task like this, the outsourcing organization must invest significantly in creating technical materials, drafting contracts, setting up governance structures and accounting procedures, et cetera. This investment is mirrored by the supplier who must fully understand the complexity of the process they are tasked with, the risks they are assuming, and so on. This can be conceived as a process of mutual education, and, in common with learning a new language, it takes time to become fluent—i.e., operationally efficient.

These investments of time and resources constitute a real barrier to the trivial substitution of suppliers that we described above: the mutual education process has to restart; a new language must be learnt. For this reason, arrangements of this nature tend to have greater closeness and longevity, and it is common to reflect this by describing them as partnerships between the two organizations.

We see, therefore, that there is a continuum between simple, transactional “work for hire” and more complex, long-lived partnerships. Certainly, it is not the case, as is sometimes wrongly assumed, that because I outsource something then by definition it is a commoditized and substitutable function. Obviously, this continuum exists when I use the cloud too: if my needs are simply defined and measured—perhaps I just need to store some files—then I can take a very transactional approach to my choice of supplier. On the other hand, the greater the complexity of the task, the more of a partnership the supplier relationship will naturally become.

Sometimes, it is the case that an organization culturally favours a transactional approach to its outsourcing, perhaps motivated by a perception of cost or the desire to avoid “vendor lock-in.” Challenges can arise when the organization tries to apply this approach regardless of the complexity of the task being outsourced.

Previously on this blog, Bill Salak, CTO of Brainly, described how his company invested time and effort in building abstraction layers to make applications agnostic to the underlying cloud supplier. On closer inspection, as he writes, the costs were significant and the hypothesised benefits weren’t tangible—in his words, “The avoidance of vendor lock-in resulted in avoidance of vendor partnership.” If vendor abstraction is an approach you are considering, I highly recommend the original article, which is a great read. To revisit it through the lens of outsourcing, ask yourself: Is writing, supporting, and maintaining middleware a core competency of my organization? Am I prepared to invest in it becoming one? I suggest you stress test your initial answer further—if middleware is a core competency, then am I monetising it, perhaps by selling it to customers in its own right? If the answer to these questions is no, then be cautious: you could end up with critical dependencies on an aging layer of software that nobody wishes to maintain, and that has become constraining, instead of liberating.

Two of Clayton Christensen’s subtle observations, which take the notion of outsourcing beyond core competency theory, are as follows: first, that customers are motivated by their own needs and that these become more sophisticated over time; second, that they are not correlated with an organization’s own assessment of its core competencies. Thus, even if an organization’s core competencies have a close fit with customer’s needs today, they may become irrelevant to the customers tomorrow. If everything except the now-irrelevant core competencies has been outsourced, competitive advantage will be lost at this point, with very little chance of recovery. One way to guard against this is a more nuanced view of competencies, which recognizes that they have a lifecycle, and that there is uncertainty in the early part of that lifecycle. I previously wrote about some techniques for mitigating the risk of disruptive innovation here, and it is the major topic of The Innovator’s Solution.

Does it then follow that increased outsourcing places a company at more risk of being disrupted by a competitor? It depends on the nature of the outsourcing. In the case of emptying wastepaper baskets, almost certainly not. But if the outsourcing is an intrinsic part of the company’s own product architecture, then potentially yes. When this kind of outsourcing is transactional, with little investment towards building a partnership, and the arrangement is not carefully re-evaluated over time as customer demands change—these are the precise conditions that lead to successful companies being disrupted. Almost by definition in this case, the most innovative services of the supplier are not being exploited by the organization; they may very well be being exploited by a disruptive entrant. Indeed, as Christensen describes in detail, the supplier may itself be the disruptor.

On the other hand, where outsourcing is in the partnership mould, this can defend an organization against disruption. Good partnerships are bilateral, and by fostering close collaboration, the supplier is empowered to innovate on behalf of the client. At AWS, as we’ve said before, around 90% of our roadmap originates from dialog with customers and is designed to meet specific needs and requirements. Furthermore, in partnership, the supplier can act as a trusted advisor to the client: highlighting best practice, challenging complacency, and promoting excellence in product architecture. A great example of this is AWS’s Well-Architected Framework. This distils AWS’s experience in working with millions of customers into a highly actionable tool that customers can use to enhance their workloads along the dimensions of security, cost optimization, operational excellence, reliability, performance and sustainability. Well-Architected Framework Reviews (WAFRs) are explicitly intended to be repeated over time, with the intention of detecting changes in assumptions and stimulating remediation of risks.

I will conclude by coming to the matter of business value: it is tolerably obvious that manufacturing iPhones is a higher value activity than emptying the wastepaper baskets. As you consider your own migrations to the cloud, you can ask yourself—is this a low or a high value activity? Is it low complexity or high complexity? The higher the value, and the higher the complexity, the more I believe you should invest in creating a strong partnership for the long term.

Postscript: like all the writing of Clayton Christensen, The Innovator’s Solution remains rewarding to read. Published in 2003, fully predating the existence of AWS, it devotes just eight words to Amazon.com! However, it is gratifying to note that, taking AWS into account, Amazon would join the very select group of companies who have been disruptive innovators more than once.

About our Guest

John Naylon is a Principal Solutions Architect at AWS, in the Telecom IBU. Before joining AWS, John founded two disruptive startups in the fixed wireless access (FWA) space. This blog was written using a QWERTY keyboard, iconic emblem of the power of path dependence.