Autonomy is the ability of a product, team, or organizational unit to make decisions and operate independently. In socio-technical architecture, it means distributing responsibility so teams can decide, deliver software, and reduce coordination with other parts of the organization. section 1.1
Treat autonomy as a design trade-off rather than an absolute condition:
- Balance autonomy with standardization: excessive freedom can create technology sprawl, while excessive standardization can constrain teams and add workflow friction. section 6.2.4
- Explore multiple domain and subdomain models, comparing autonomy and product optimization against duplication, inconsistent user experience, and added dependencies. section 9.2.4
- Assess decision authority explicitly through mandate levels, from building to an exact specification through pursuing a long-term business outcome. section 11.3.2
Autonomy in practice
The marketing cloud at Salesforce operated as a highly autonomous product portfolio, with product groups designing and evolving their taxonomy while dedicated product and technology leaders helped prevent silos. OpenTable eventually reached a state where highly autonomous teams worked independently and deployed multiple times per day, following an intensive modernization effort. section 6.2.4 section 3.1.1
Use the mandate-level visual to compare how independently different value streams can decide what work to perform, while remembering that mandate level does not eliminate cross-stream dependencies. section 11.3.2








