A few weeks ago, Terry Crowley, former manager of Microsoft’s Office team, wrote a great post about essential complexity in systems.

In it Crowley discusses essential complexity, the cost of adding a new feature to a large system, and how the team at Microsoft embraced essential complexity to build a cloud Office suite that could compete with Google Apps on previously asymmetrical features (like concurrency,) while maintaining the robust feature set (and file format) that enabled Microsoft to keep business from Google Apps’s collaborative cloud in the first place.

Much of the response I read concerning the post treated it in a triumphant light (likely influenced by good news re: Office 360 v. Google Apps market share)---the words of a man who had wrested complexity to the ground.

But any who cite victory against complexity should be taken with a grain of salt. Complexity is the emergent behavior that arises from the interaction of lower-level primitives. It is, by many accounts, unpredictable. A complex system can’t be controlled or used to elicit a specific result, it can only be loosely guided towards an objective from the bottom-up. (If you’re looking for a good primer on the science of complexity, check out Mitchell Waldrop’s Complexity.)

When Crowley talks about taking on the “essential complexity” inherent in a large system, and reducing the “accidental complexity” or “unnecessary complexity” introduced to it via a new feature, it’s important to note that he isn’t conquering complexity so much as embracing it (and accepting that his users will, to a certain extent, have to embrace it as well. More on this later.)

In reading Crowley’s discussion of the essential complexity within a given system, I was reminded of two other complexity concepts I’ve been reading about lately. In this post, I’ll explore those different types of complexity, their relation to essential complexity, and how all of this introduces a host of questions that product management (and company leadership) need to consider.

I’ll start with essential complexity and then look at what happens when we abstract it to a higher order of behavior. The first abstraction lands us at what I call “stack complexity”, or the behavior that emerges when different systems interact. The second abstraction moves to “enterprise complexity”, or the behavior that emerges when that stack of systems and vendors interact with the scale and process of an enterprise organization.

Essential complexity

First, let’s look at what Crowley means when he says “essential complexity.”

He starts with the function-cost curve, a way to ascribe the functionality a team develops within a system, and the marginal cost of adding each new feature to that system as more and more functionality gets built in. The general position is that in large systems, the cost of adding a new feature to the system is higher because it needs to consider its interaction with more total product.

In product strategy, you’re always thinking about essential complexity within the context of new features. Crowley explains how at Microsoft they often had to decide whether or not to take on essential complexity. Either make a new product completely compatible with the other feature sets in the suite, thereby increasing its essential complexity (as they attempted with the co-editing features in Office 360,) or cast aside that essential complexity and start the new feature in isolation (as they did with OneNote.)

In the case of Office 360’s Word app, Crowley+co decided to “embrace essential complexity” and build co-editing features on top of the existing Office feature set, rather than build a new, simpler version of Office designed for in-browser collaboration.

This decision gave Microsoft a cloud word processor app compatible with Word formats, “a critical competitive moat with immensely strong network effects.” This led to Microsoft stealing a lot of productivity software market share back from Google Apps.

But the decision also led to a lot of new complexity within Office360. For any user looking for an easy way to collaborate on a document online, the simplest solution still sits within Google Docs. And this is the grain of salt I mentioned earlier. Crowley’s post is fantastic, but we should be careful to read it not as a triumph over complexity, but as an acquiescence to it. The Office team decided to lump co-editing in with their existing feature set and the result is a more complex product than Google Apps---one that’s more difficult to use but offers the range of functionality certain enterprise users need.

So this is essential complexity. Weighing the decision to introduce a new feature into the existing context of the system. Considering that decision within the light of the features your competitors in that space offer. But, in most cases, the decisions around essential complexity are inward ones. Decisions about how things interact within your product suite.

When you move to a higher order of complexity and start thinking about how a system interacts with other systems, you get stack complexity.

Stack complexity

Stack complexity is interesting in that it poses an entirely different set of questions to product management. A set of questions that exist on a different plane than those in essential complexity, and likely exist outside of the scope of what those essential complexity systems are able to do. (I.e. for a long time systems like Microsoft have natively integrated within their suite, and relied on SIs to integrate them within their larger stack.)

Ben Thompson addressed the idea of stack complexity on his blog a few weeks ago:

“When enterprise software first came to be it was primarily focused on automating routine business processes like accounting and enterprise resource planning. At first these solutions were self-contained, but over time, particularly as companies sought to gain usable insights from the data they were collecting, it became necessary for these monolithic software installations to talk to each other.

At the beginning nearly all of these integrations were custom-built and maintained by system integrators; this was manageable as long as the number of integrations were small, but as the number of applications increased the number of potential integrations increased exponentially (integrations = n(n-1)/2 in which n is the number of apps). This not only made it difficult to connect applications, it made even updating a single application a very dicey proposition — what if the custom integrations stopped working?”

With the cloud and its proliferation of services all touting integration-friendly, API-first applications, stack complexity abounds. There are a few different approaches vendors have taken to this problem. Like essential complexity, one approach is to embrace stack complexity, the other is to bow out if it.

Companies embrace stack complexity in different ways. On one hand you have vendors like Slack who want to be the interface on top of everything. Their message to IT buyers is “purchase whatever you want, you can rest assured it’s in the Slack app directory so you can tie it all together.” But being the interface to all systems doesn’t necessarily mean handling the regular and systematic flow of data between those systems. For that use case there are vendors like Mulesoft, seeking to be the common layer between everything. In either case, these vendors are similar in that they’re betting on customers embracing complexity, building a stack out of multiple point solutions and then trying to piece it all together into something that works.

Then there are those companies attempting to eliminate stack complexity for their customers. This is the path for Microsoft and the other full suite providers---in the process of taking on essential complexity, they bow out of stack complexity. For while Microsoft’s Office suite (and other suites like it) provide plenty of integration solutions, they’re not differentiating on them. What they’re differentiating on is the ease of the native integrations within their system; Outlook working with Word working with OneDrive and so on. It’s an interoperability that 1) with a strong enough network effect creates the aforementioned moat of file formats and 2) helps to win out against point solutions. In a late 2015 CIO article on Microsoft’s winning of market share against Google, Outlook was actually cited by IT consultants as the primary driver behind customers switching from Google Apps to Office365. I was stunned when I read that. Outlook over the ease and simplicity of Gmail? But that’s the power of a system that takes on its own essential complexity (and to Crowley’s point, I think Microsoft has done a better job of acquiescing to their own complexity than Google Apps has) so that its customers can opt out of some stack complexity.

On top of this, Microsoft makes it easy for an organization to opt into their entire suite. Not just through their software, or their product strategy, but through an enterprise culture that embraces the organizational complexity of the enterprise. This brings us to our last abstraction of complexity.

Enterprise complexity

If essential complexity is the complexity within a single system, and stack complexity is that within a collection of systems, then enterprise complexity is the loose term I use for what happens when you move to yet a higher order behavior and start to look at how the users (and buyers) within an organization interact with that collection of systems.

Like stack complexity, enterprise complexity asks a completely different set of questions than essential complexity, this time not just of product management, but of the entire vendor as a whole. How is implementation run? Are customers expected to learn how to use the product on their own, or are you putting people on the ground to help them? Do you offer dedicated support teams for your biggest customers? How does your product’s system administration scale to a true enterprise organization? These are the types of questions posed by enterprise complexity. And what’s more, since it’s a higher-level of complexity involving the lower-level elements already discussed---each feature, each system, the interaction of all of those systems and features, the people that use them, etc---it gets even harder to predict what emergent behavior will come out of it.

This means that when it comes to enterprise complexity, there is no single product management strategy that makes it all better. Instead, a vendor embraces enterprise complexity from the bottom-up by making sure every lower-level element within their own business (just one part of which is product) drives towards the emergent behavior of enterprise success. A lot of people call this bottom-up structuring “enterprise ready”. Whatever we call it, the takeaway is this: you only survive in the enterprise by embracing it everywhere in your business. Sales. Services. Marketing. It doesn’t just come from product.

A great example of this is Charles Fitzgerald’s recent post Google’s Scalability Day. In a fun twist, it starts with the example of Microsoft in the late 90s, a giant who, by many measures, hadn’t yet become “enterprise ready.”

“Microsoft at the time was an extremely engineering-centric company, so it processed all the criticisms through a technical lens. Soft, cultural, customer, and go-to-market issues were discarded as they did not readily compute and the broader case against Microsoft’s enterprise maturity was distilled down to the concrete and measurable issue of scalability. The company assumed some benchmarks plus updated product roadmaps would clear up any remaining “misunderstandings” about Microsoft and the enterprise.

The event was a disaster and served to underscore that all the criticism was true. It was a technical response to non-technical issues and showed that the company didn’t even know what it didn’t know about serving enterprise customers. Internally, the event served as a painful wake-up call that helped the company realize that going after the enterprise was going to be a long slog and would require lots of hard and not very exciting work.”

Fitzgerald then brings the thread back to where we started: Microsoft Office v. Google Apps, and the latter’s push into the enterprise through an asymmetrical product strategy focusing on collaboration and co-editing.

“I couldn’t help but think about Scalability Day while watching Google’s #GCPNext event today. After telling us for months that this event would demonstrate a step function in their ability to compete for the enterprise, it was a technology fest oblivious to the elephant in the room: does Google have any interest in or actual focus on addressing all the boring and non-product issues required to level up and serve enterprise customers?”

This is the importance of enterprise complexity. Even if you’re the vendor with the simpler, easier-to-use solution---in this case, Google---if you haven’t embraced the complexity of the enterprise and “all the boring...non-product issues” required to succeed within it, you might actually be the more difficult solution for enterprise buyers to purchase and scale across their organization.

For product and non-product managers alike, it’s important to consider the essential complexity within their own solution, as well as how it plays with their customers’ stacks and organizations. The simplest product isn’t always the one that wins in the enterprise.