The Three Economies an Introduction

The Three Economies an Introduction

March 4, 2020·Jabe Bloom
Jabe Bloom

For the last few years, during conversations with teams and executives across the globe, I’ve drawn a simple graphic on whiteboards, notepads and giant stickies, one that has led to many great conversations. It looks like this.

A Simple Graphic illustrating three economies: Differentiation, Scope, and Scale, with two red dashed lines that start far apart in the Differentiation phase, converge in the Scope phase, and run parallel in the Scale phase. Above the transitions between phases are two curved arrows labeled ‘Accelerate Differentiation’ and ‘Create Resilience.’

I think there is a book in that graphic and in those conversations… an exploration of Ashby’s Law, complexity theory, constraints (enabling/governing, top-down and bottom-up), reliability and emergent resilience, diffusion theory, the Commons and the enclosure movement (and recommoning), pluralistic logics and in the end more successful IT organizations.

So, this is the first in what I hope to be a series of posts (and maybe even a book) about rethinking how we conceive of the economics of software engineering and IT.

I call this graphic “the Three Economies,” because, of course, three is the magic number, but also because economic logics drive decision making in organizations, and the attempt to shoehorn IT into a single economic logic is not only misguided, but it does damage to the very organizations that need to transform the most. I want to think more deeply and publicly about the Three Economies, because I believe the software development industry is moving rapidly towards a platform thinking based paradigm, one that requires a new understanding.

To start with, let’s explore the concept of an economy. Simply, it is just the idea that an organization has a limited set of resources and they need to use some form of logic to apply those resources towards better outcomes for whoever is involved (themselves and their customers). Economics are logics that maximize the conversion of (constrained) resources into value. Even here the definition tempts us into a simplistic understanding that we should resist. What is value? Who defines value? How are resources constrained? When are they constrained? What is the process of conversion? How can that process be reproduced? What happens when constraints are removed, or changed? We’ll need to explore these ideas in more depth.

Current ways of thinking about software development tend to suggest a (false) dichotomy between Development and Operations. An understanding of The Three Economies requires an exploration of these conceptions of software engineering — not to devalue or falsify them, but to bound them within their particular relational contexts. Many organizations I speak with are trapped in a paradigm that imagines you can either be efficient or effective. Michael Porter, a key figure in strategy for a long time, had this idea that you needed to choose between operational excellence or a unique competitive position.

In order to create a unique competitive advantage, what you needed to do in Porter’s mind, was to create a clear trade-off between yourself and your competitors — differentiation.

Operational excellence, meanwhile, is the ability to deliver on that differentiated promise, efficiently and consistently. Porter argues that the source of value created here is Cost-based. But, Porter also argues that operational excellence isn’t itself a strategy — according to him, you can’t just do operations well and be strategically successful. You can create a competitive advantage through a focus on Cost, but there is a floor, once you get to $0 per widget, you’ve successfully completed a race to the bottom, congratulations. Differentiation has fewer limits… it would seem.

This is an argument that’s been driving IT for years: You can either be a value center, “Software is Eating the World” or a cost center “Deliver the same value for less cost at greater scale.” IT needs to transform from a cost center to a force multiplier… etc.

A value center is organized around maximizing the value of the competitive advantage of differentiation, it is organized around the logic (and context (or ecology)) of an Economy of Differentiation. A cost center provides, operational excellence that enables efficiency, it is organized around the logic (and context (or ecology) of and Economy of Scale.

While the logic of an economy of difference creates a unique and defendable position in the market, the logic of an economy of scale takes a value feedback loop — one in which we know that people will purchase something at a certain price point — and tries to create as much value as possible by squeezing all the waste out of the loop. As a result, the difference between the selling price point and the delivery price point gets bigger — in other words, in economies of scale, we move the bottom line down without changing the top line — and therefore we’ll make more money.

Economies of Scale also create situations in which people around us eventually notice that we’ve identified market conditions in which we can deliver some well-defined thing at well-defined price, this creates competition and eventually, there will be a price war, and only people who have operational excellence (disciplined execution in the reproduction of a specific process and outcome) AT SCALE will be able to continue to operate profitably. A really simple and common example of this is, if I wanted to personally administer machines (a thing I actually used to do once in my life), I could maybe administer 10 machines a day, constrained by the rate of change involved in maintaining those machines. Maybe I get really good and I’m managing 20, or whatever. But what I can’t personally do is what AWS does, which is to highly leverage servers administered per human. What’s being scaled at that point is the efficiency of having a defined output, a known state that you need to create, and the ability to reproduce that state.

Many organizations mistakenly think that there’s this choice between an economy of difference and an economy of scale. You need to focus on one or the other. You can either drive costs out of it or you can create value. There’s no in-between.

This is partially driven by the fact that these first two economies when they directly touch each other, are like grinding gears, the two logics don’t mesh. The math of differentiation and the math of efficiency don’t work together, instead, they oppose each other.

Illustration of a ‘Wall of Confusion’ between Development and Operations teams. The Development side, represented by an angry stick figure, is throwing boxes over a brick wall to the Operations side, also represented by an angry stick figure. The wall symbolizes the communication and collaboration barrier between the two teams.

In DevOps, Andrew Clay Shafer coined the term “the wall of confusion” — a wall of policy, and intermediation that goes up between operations and development, to prevent the grinding of gears, but at a great cost, to describe this strategy.

This false dichotomy between Differentiation and Scale, value and efficiency, is revealed for what it is by the introduction of a third economic logic. The problem isn’t choosing between these initial logics, but instead expanding the way we understand IT works with a third economy.

This third economy acts as a clutch. It’s a way of translating efficiency into difference. This third economy is the Economy of Scope.

We need to clarify the difference between the economy of scope the economy of scale right away as they are often confused. The economy of scale is driven by things that can be consumed. In IT, this means things like network, CPU, storage, etc. These are things you can use up. If you use your network, you can saturate the limited amount of bandwidth available. So you need to manage in order to be able to (re)produce the network, the capacity, the compute, the writes per minute, etc. All these things are consumables. If you use them, they “go away”. Scale economies require managing how people get access and how much access they receive to these consumables. Scale Economies limit variability (of consumption) by CONTROLLing access.

A scope economy is different because the value produced in it is based on things that gain value in great (re)use. For instance, if we have a customer record that’s really nicely well-formed, it becomes more valuable if lots and lots of people use it (compared to lots of people having lots of different models of the customer). Same thing with well-formed functions. If we have a login function, and we share that same login function among many, many applications so it gets reused a lot, the value of that function or that service goes up, not down.

Scope economies (platforms) are made up of things that are found in scale economies. A platform is made up of network, compute, storage, etc., but what’s added to it is the reuse of functionality and data. It’s also made up of predefined configurations (patterns of configuration) of what I’m going to call primitives — network, storage, database, compute. A platform configures those primitives in a certain way to make them more easily accessible by developers. But it also limits the amounts of variation in those configurations, so it makes it more stable and reduces the combinatorial complexity of the system, creating resilience out of mere reliability. Well-formed functions, reusable data, and predefined or standardized configurations. These three things create a platform, which performs the logic of an Economy of Scope, which allows you to have a clutch between the logics of differentiation and scale.

Therefore, scope economies should not be measured by how efficient they are and shouldn’t be measured at all by how much differentiation they create. They should be measured by how quickly they’re adopted and how effectively they isolate efficiency from differentiation.

When a platform isolates efficiency from differentiation, the differentiation gets thinner, but also faster. As an example in a recent article, Facebook rewrote the Messenger app, and they took 1.7 million lines of code and reduced it by 84% to 360,000 lines of code, just by leveraging the preexisting framework inside of iOS. They basically leveraged the iOS platform to make the messenger app, the differentiated edge system, as small as possible. This means it goes faster, it’s easier to maintain, and it’s easier to dispose of.

So, Three Economies. You’ve got an economy of difference, an economy of scope, and an economy of scale. You have to learn to manage all three economies, all three different kinds of logic, and you have to not mis-apply the logics to the wrong parts of the system.

I’m looking forward to exploring these ideas with you. Please ping me on twitter with questions and thoughts.

Hat Tips

(h/t to Ben Mosior @hiredthought for his contributions in bringing you this writing)

(h/t to Cat Swetel @catswetel & Ben Mosior for exploring these ideas with me for the last few years through patient questioning, explorational conversations, and a nearly endless reading list)

Legacy Comments

Chris D, March 12, 2020
I wrote about how I understand the three economies in the light of Wardley Mapping
Dotglum, June 9, 2020
2 Questions; 1. Is ‘economies of differentiation’ same as ‘economies of variety’? reference to ‘economies of variety’ > 2. is this ‘economies of scale’ or ‘differentiation’ > without changing/reducing the cost or w/ minor increase in cost if more value is generated out of that component? reply
Dotglum, replied: June 9, 2020
without changing/reducing the cost or w/ minor increase in cost if more value is generated out of that component? > probably this is ‘economies of scope’ because value has increased with reuse reply
Julian Everett, June 11, 2020

Some comment on this post, recent Redhat talk and the twitter thread with swardley.

  1. I believe that you and he are possibly talking about different things. As I read you both, he is talking about how technology evolves over time whereas you are talking about how to integrate technology at different stages of evolution at a single point in time. If that reading is correct then I think these are different questions.

  2. Whether or not any phase is a transition doesn’t really matter, as all stages are really transition stages. In community ecology, the stages of forestry succession are known as pioneer, seral and climax. However the point when pioneer trees become established is actually stage 4 on the wider plant succession scale. So all stages are both transitions and relative. I think this also points to the scale-invariance at play here too.

  3. I suspect the notion of property ownership is orthogonal to this (although I applaud your efforts on recommoning). There is obviously a frequent correlation between differentiation and private ownership due to the revenue streams it enables, but I don’t think it is a necessary link. I really like Wardley Mapping, but as a previous user of Nickolaisen’s Purpose Alignment model ( one area where I find that stronger is on core competences. It seems to me that quite a lot of software is still differentiating (e.g. from Rails to Airflow) at the point when it gets opensourced, but the driver for this is that it does not align with the intentional core competences of the committing organisation i.e. it is a market-differentiating, non-core competence hence the decision to “partner” with the open source community. I think the orthogonality of this relationship is also demonstrated by the fact that your examples of traditional commons seem to contradict your definition of “gets more valuable with increased usage”, e.g. that doesn’t seem true of common land pasture?

  4. I’d argue that in many organisations there is a scale-invariant split between differentiation and scale everywhere, from cutting edge R&D where 3 UX devs might collaborate on a code extension to React that speeds up their productivity, all the way to the Ops engineers who are writing a Helm chart code generator util. The problems of cost centres and value centres in Enterprise IT is only incidentally related to this. The underlying problem is that their failure escalation boundaries (e.g. project/product portfolios or P&L reporting lines) are not aligned to their actual organisational value streams. Thinking about this using a visual metaphor, the boundaries need to follow the seams of the scale-invariance/fractals whereas all too often those boundaries are created by someone blindly axing into the middle of the value streams. For example, in the video media sector the rich metadata on which personalisation, contextualisation, targeted ad delivery, etc depends is often just seen as a back office librarianship cost centre. This drives a race to the bottom on cost and quality, and then suddenly everyone is wondering why revenues are being impacted.

  5. One further still-brewing thought. Your definition of the economy of scope as concerning those things which get “more valuable with increased usage” sounds very much like a definition of information as opposed to a physical or virtual resource, and the “differentiated edge” made me think interface, i.e. is this thing in fact an informational interface? If so I think perhaps it is the informational interface of the economy of scope rather than the economy of differentiation, which then reveals the gap in the value stream which need to be filled by dev teams in order to ship those differentiating features on which the revenue streams depend. Wardley Settlers then mine that gap for emerging services which can then be pushed down into the economy of scope and emerging patterns which can enrich its informational interface. I think you can view those informational interfaces as the things which enable the conversion of potential value in the economy of scope into actual value (a bit like informational data about financial assets)?…

Devilish QuestionsSlick Rock Creek, September