There is an incredible analysis of Amazon authored by investors Social Capital making the rounds on Twitter lately (hat tip to Blake Robbins, another great investor). The deck makes some big predictions about Amazon’s future growth. (We made a lot of money with AMZN already, but have no position in it currently.) And while we cannot vouch for Social’s recommendation, a lot of their points resonate with reasons we owned the stock in the past. That being said, we want to play contrarian here and think about how Amazon is organized and what that means for its future.

What really caught our eye was this slide:

The graphic shows the way in which Amazon has converted each of the cost items in its income statement into a revenue stream. This reminded of us a post from ten years ago, by a former Amazon employee. The central point of that piece is that Amazon learned a long time ago that the best way for its constituent parts to interact as it grew was to essentially treat each business unit, or product, as something akin to an API, a standard software interface. That is to say the company applied a software concept to its corporate organization.

If you need to interface with a particular software tool, you feed it a set of inputs and can expect certain outputs from in return. This is the basic programming concept of abstraction. From an organizational perspective, this allowed every part of Amazon to act independently but still be able to rely on other parts of the sprawling organization. There would be one person, or a team, clearly responsible for every function inside the company.

You can trace that Social Capital slide directly back to this Org Chart-as-API structure. We think a huge amount of Amazon’s success can be attributed to this incredibly flexible structure. Anyone who has ever worked at a large corporation can likely relate to the problem that this structure solves. You are in the sales team, and your biggest customers’ order is lost in the shipping department. The operations team needs manufacturing specifications from the engineering team but never get their emails returned. The finance team wants any accurate information it can get its hands on. The innovation here is that it pushes responsibility as far out to the edges of the organization as possible.

In software, the idea of abstraction means that if you control one element of an application you can make your code call a function created by someone else. You do not need to know how that function works. If something underneath breaks, it can be isolated and repaired. So long as the basic interface (the inputs and outputs) are constant, the internal workings of that other function do not matter to you.

For an organization this means that if the shipping department is losing packages, management can focus on fixing or boosting that team. As with software, all this API discussion is true in theory, there are countless areas where it does not work out quite this way, but the theory does hold a pretty good model to live up to.

This has allowed Amazon to expand into every business under the sun. Need to add a new business? From day one the entire infrastructure is already in place. This is more than just converting costs into revenue streams, it is the ultimate form of flexibility for growth.

However, it is worth considering how this could affect Amazon over the long term. One of our core principles of analysis is that every company contains the seed’s of its own demise. Amazon is very far from that stage, but it is worth considering, especially when they have had the same CEO for close 30 years.

Big companies have problems organizing and communicating internally. Amazon’s API model solves this but there must be trade-offs.

A few come to mind. First, there has to be additional cost inside each unit. Maintaining a software API is expensive and time-consuming. Someone has to document and communicate all the features and inputs, and then someone has to monitor and make sure they are all working. If the shipping department is now a revenue line, then the company is going to need more accountants (or at least more accounting software) to keep track of it all.

A second problem is that it can blind the company to superior outside alternatives. Outside vendors may be able to greatly outperform or underprice pieces of the organization, but the cost of switching, of even evaluating the alternative, is a powerful disincentive. To be clear, Amazon does not suffer from this problem (as far as we know), but the risk is there.

A third issue is that it enables massive sprawl. Someone with a good idea can quickly spin up a new unit. That can lead to misfires like the Fire Phone. This is one of those things that cuts both ways. Currently, it means that Amazon can experiment in ways that no other large company can. As much as Amazon was derided for the Fire Phone, the idea had merit, but execution was just a bridge too far.

The unifying theme of all these is that Amazon’s structure creates a heavy burden on management to enforce the discipline of that structure. Someone has to make sure that everyone is abiding by the terms of every organizational API. And then they have to monitor everyone, and benchmark them. We wrote a few months back about Amazon’s first CFO, and we can see how her attention to detail would work so well with Amazon’s model. Amazon is obviously in great shape today, but as the company matures, it will be interesting to see how it contends with these problems.