Adaptive Enterprise Manifesto

Following on from the Enterprise DevOps manifesto I present another iteration that highlights the technological, organisational and cultural paradigms necessary for Enterprise adaptation.

Adaptive Enterprise Manifesto

Businesses must adopt a radical operating model to address existential threats including market and regulatory pressures, the march of technology, changing customer need and climate change. We are uncovering better ways of responding to these VUCA challenges by doing it and helping others do it. Through this work we have come to value:

Autonomy over control over chaos

Automation over manual work

Networked community over organisation and process

Agility over stability of methods

That is, while there is value in the items on the right, we value the items on the left more.

Principles

Autonomy over control over chaos

1. Create autonomous teams that own end-to-end outcomes. Empower them to get their job done while minimising their dependencies on others. Avoid new cliques and silos being created by encouraging communities of practice and guilds
2. If you are a service provider, enable self-service by providing the tools needed to allow your customers to work autonomously. Give them freedom within a gilded cage enabled by guard rails so they can employ this autonomy safely
3. Embrace E2E ownership and accountability models like DevOps. This leads onto favouring vertical over horizontal organisation models the closer to the customer you are
4. Decouple independent areas of business/IT operation and specialise to solve undifferentiated heavy lifting and cross-cutting concerns
5. Favour course-grained APIs and microservices and share these for external consumption
6. Embrace Decentralised decision-making but make it bounded

Automation over manual work

1. Embrace AI and machine learning to make sense of your data
2. Build all your technology stack using code (including Infrastructure as Code and Software Defined Networking) and use CI/CD pipelines as unit of change and approval
3. Favour configuration over customisation
4. Shift left, addressing problems as early in the life-cycle as possible

Networked community over organisation and process

1. Build a robust culture reinforced by a shared set of values and principles that emphasise psychological safety, transparency and trust
2. Embrace diversity and inclusion (including of stakeholder groups)
3. Learn from failure and adapt, employing double-loop learning-- and reject blame culture
4. Develop communities of practice like Guilds and use these are centres of value creation, knowledge dissemination and reuse
5. As Microsoft do, incentivise employees to help another team, build on the work of others

Agility over stability over chaos

1. Customer (and internal customer) obsession
2. Adopt an Agile mindset and employ the use of minimum viable product (MVP). This does not however mean dogmatic adherence to Kanban, Scrum
3. Continuously roll out incremental improvements to products, platforms, methods, processes
4. Have a fix-forward mindset
5. Disintermediate your value chain
6. Measurement (particularly of sentiment around empowerment)
7. Take advantage of all your talents by embracing multi-disciplinary teams (MDT)
8. Move people around to avoid getting stuck in ruts

"It is not the most intellectual or the strongest of species that survives, but the species that survives is the one that is able to adapt to and adjust best to the changing environment in which it finds itself". -- Charles Darwin

{Postscript}

Some great questions by Rui Vale I thought I would answer in the body of the article:

Q: aren't most end-to-end outcomes too boundary-crossing to be delivered solely by autonomous teams?

A: yes and no. Funnily enough I have been ruminating on the fact that this is not covered sufficiently in the article. It has also come up in conversation with Ed Morrison. Principles are heuristics and may be over-ridden by others so it is OK for them to conflict. What is not OK is if important concepts are missing. Some of the concepts that come to mind when reading your question are:

• Cross-cutting concerns--if everyone needs a database or a billing engine or a debt recovery or marketing team do we all build our own or use a central service? What happens if these cross-cutting concerns are complex and it is not efficient for us all to have our own version cf. undifferentiated heavy lifting, a term Werner Vogels, Amazon CTO introduced. The inevitable sharing of e.g. large scale systems like CRM and ERP are as a result of this. We also get into complex areas including SOA and easier to understand concept like preferring high cohesion and loose coupling
• The evolutionary path for methods and technology from Genesis, through Custom Build, Product and finally Commodity. This is the x-axis of the Wardley Map
• The building of hybrid products and services including e.g. products with modular components built by suppliers

So are these missing? Let's take the first value statement:

Autonomy over control

Some of these topics are to do with control, and in some cases we should indeed prefer control over autonomy. Letting every team manage their own cyber security sounds like a bad idea. But then again, the principle of enable self-service covers aspects of control within an autonomous setting. Firms like Netflix with their anti-fragility ethos do exactly this.

I will therefore replace the value statement with:

Autonomy over control over chaos

Q: is freedom within a gilded cage really a good thing, I mean from the customer's perspective?

A: freedom within a gilded cage means freedom within boundaries. This is civics. We are accorded rights to live in a free society subjects to being bound by responsibilities enshrined in covenants like the Law. It is gilded because life in the cage is pretty good. I wrote this primarily from the perspective of product teams who are then freed up to innovate on behalf of the customer.

Q: what do you mean by decoupling independent areas?

A: probably covered by my answer to the first question about autonomy.

Q: what is bounded decentralised decision-making?

A: decision-making devolved outwards to operating units closer to the effects of the decision e.g. closer to the customer impact. Bounded because it is informed by a set of principles or creed. See:

Q: what do you mean by favouring configuration over customisation?

A: a common engineering principle aligned to the comment about Wardley Mapping. With the right technical solution variability can be described in a language that is input into the service and changes its behaviour. Think placing your restaurant order rather than cooking your own food.

Q: are the Guilds Spotify-like or twelfth century Florence-like?

A: whatever works. I see them as communities of practice aligned to Neils Pfleiging's concept of Value Creation structures. Twelfth century Florence-like had the better costumes.

Q: what's a fix-forward mindset?

A: see this article.

Q: what do you mean by "Disintermediate your value chain"?

A: remove unnecessary intermediaries by:

• Dealing direct
• Enabling self-service
• Solving a cross-cutting concern or undifferentiated heavy lifting problem
• Moving from customisation to configuration
• Automating a manual step

References:

https://www.interana.com/blog/future-adaptive

Another view: