This post was co-authored by Mike Loukides and Bill Higgins.
Bill Higgins of IBM and I have been working on an article about DevOps in the enterprise. DevOps is mostly closely associated with Internet giants and web startups, but increasingly we are observing companies we lump under the banner of “enterprises” trying — and often struggling — to adopt the sorts of DevOps culture and practices we see at places like Etsy. As we tried to catalog the success and failure patterns of DevOps adoption in the enterprise, we ran into an interesting problem: we couldn’t precisely define what makes a company an enterprise. Without a well understood context, it was hard to diagnose inhibitors or to prescribe any particular advice.
So, we decided to pause our article and turn our minds to the question “What is an enterprise, anyway?” We first tried to define an enterprise based on its attributes, but as you’ll see, these are problematic:
- More then N employees
- Definitions like this don’t interest us. What changes magically when you cross the line between 999 and 1,000 employees? Or 9,999 and 10,000? Wherever you put the line, it’s arbitrary. I’ll grant that 30-person companies work differently from 10,000 person companies, and that 100-person companies have often adopted the overhead and bureaucracy of 10,000 person companies (not a pretty sight). But drawing an arbitrary line in the sand isn’t helpful.
- Not “born on the web”
- So, Google isn’t an enterprise? Any definition of enterprise that omits some of the largest and richest companies in the world can’t be right. The contrast between web-native companies and companies that predate the web is interesting and important, but that hardly seems like the right way to define “enterprise.”
- Dull, hierarchical, stuck in the past
- The company your father (or grandfather, maybe) worked for? Sure, there are companies that fit this description, both large and small. These types of companies are not our audience. A company that is stuck in the past isn’t likely to adopt DevOps practices in any meaningful way. Enterprises are not monoliths, and we have found many cases of thoughtful, forward-looking individuals who are members of the DevOps community, learning from the Etsys and Netflixes of the world about how to adapt their cultures and practices to improve their delivery and operations.
- Multiple lines of business
- As companies grow beyond a single product line or market, they often form semi-autonomous divisions and centralize common functions like IT. However, certain companies — Apple is the exemplar — organize functionally rather than divisionally. Microsoft is following Apple’s lead to adopt a functional org structure. Does this mean Microsoft will soon cease be be an enterprise? Of course not.
What is an enterprise and why does it seemingly present unique challenges to adopting DevOps? After discussing this question with some industry colleagues, we realized our problem was that we were asking the wrong question. Horace Dediu of Asymco provided the key insight by suggesting that whether or not something is an “enterprise” is irrelevant. The key success criterion is an organization’s ability to learn and its willingness to change based on what it learns.
This struck home. Is an organization sufficiently agile to change its practices when the landscape changes? John Allspaw writes about corporate culture and the need to adapt in his article Blameless PostMortems and a Just Culture. The point of doing a post-mortem after a failure is to learn about what went wrong and figure out how to adapt in the future, not to establish blame. Corporations that need to establish blame never learn; they only put in place increasingly inflexible firewalls trying to make sure the same mistakes don’t happen again. The firewalls can’t prevent the next incident (because no two disasters are the same), but they limit the flexibility and freedom the organization needs to improve its operations. Allspaw concludes that you can only learn from your mistakes in a blame-free environment. Corporations can learn when they don’t behave as if everything is a zero-sum game where there are winners and losers.
Art Kleiner struck a similar theme at O’Reilly’s Foo Camp: companies that are successful over the long term need both cultural exceptionalism (we’re different; the rules don’t apply to us), and humility. Sometimes the rules do apply, and we have to go back to the drawing board and redesign our strategies to face the new situations. The ability to build distinctive capabilities is the key to long-term survival, but the distinctive capabilities can become traps unless they are linked to a culture with a discipline of challenging itself. And with this context, whether a corporation is an “enterprise” is surely much less important than whether it can learn. 30-person startups can learn, but they can also be as hidebound and traditionalistic as the largest corporate megalith.
Our original article talked about DevOps as a framework of cultural characteristics, supporting practices, and supporting tools. While this is technically correct, it obscures a key point: culture is the high-order bit — specifically, an organization’s culture as it affects its ability to learn and change. However one defines “enterprise,” what really matters is an organization’s culture — its values, norms of behavior, and reward systems determine whether or not it will be able to evolve, whether the challenge is adopting DevOps, or anything else. This is as true for massive international conglomerates as it is for small startups.