Responsibility
Accepting responsibility needs motivated people and a sense of ownership. This includes the process and tools used as well as the product created. Motivation needs several factors, feeling ownership for something is one of them.
Core Ideas
Embracing developer freedom
Developing and creating new products is creative work. And creative people need freedom to control the solution as well as their tools and practices. This means they have influence on these aspects of product development. Developers will feel responsible for something they can influence.
Focus on end-to-end ownership
Many organizations use specialized technical silos in which one specific aspect of a product is being developed, like master data or service integration. This limits our view and leads to a weak sense of responsibility for the overall product, or none at all. Instead of segmenting our product into technical aspects or small business functions that only have value within a bigger context, we try to find meaningful products (or product parts) that have value and are directly associated to goals.
Create cross-functional teams
If I am dependent on someone or something outside my range of influence this reduces my feeling of responsibility. To prevent this we need to reduce dependencies, which nicely ties back to our first idea of focusing on the product. When I am part of and have influence on the bigger picture I feel empowered and capable. Small teams that are able to create value on their own can and will accept responsibility more eagerly.
Sector Rating Aspects
These are aspects that can be used to assess your performance and maturity in this sector. For a detailed explanation please have a look at our how to page.
| Aspect | Adoption Lifecycle |
|---|---|
| Teams have collective code ownership | Late majority |
| Teams are included in recruitment decisions | Early majority |
| Management uses an adaptive and flexible management style (situational leadership) to meet the changing needs of their organization | Early majority |
| The organization focuses on products, not projects | Early adopters |
| Teams choose their tools, practices and processes | Early adopters |
| Teams actively reduce dependencies on various levels (between people, work, technology) | Early adopters |
| Innovation is driven by teams, not hierarchy | Early adopters |
| Teams are included in delegation decisions (e.g. Delegation Poker; see also Management 3.0) | Early adopters |
| Levels of delegation are discussed and agreed upon by management and employees (e.g. Delegation Board; see also Management 3.0) | Early adopters |
| Make the boundaries of self-organization explicit to increase responsibility inside the constraints set by the environment and organization | Early adopters |
| Sociocratic organization structures and workflows are used (e.g. Governance meeting; see also Sociocracy 3.0) | Innovators |
| The strategic direction is actively supported bottom-up | Innovators |
| Teams are responsible for their members’ professional development | Innovators |
| Teams are included in salary and bonus decisions | Innovators |
| Teams who build something, run and fix it | Innovators |
Connections
- Feedback & Transparency: Offer fast and detailed feedback to increase the willingness to take on responsibility.
- Verticality: Increase the willingness to take on responsibility by creating decoupled systems with clear system boundaries that can be individually designed and shaped.
- (Guided) Architectural Emergence: Leave responsibility inside teams by implementing proposal-based governance instead of hard rules.
- Technical Excellence: Minimize risk while handing over product responsibility to teams.
