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.
- The definition, design and implementation of a single requirement spans several teams or departments, possibly including asynchronous handovers
- Developers talk about ‘the system’ instead of calling it their own solution.
- Teams need to be pushed to show acceptable results. Without explicitly appointing responsible persons, problems are not addressed
- Product Owners have a strong focus on features, not really representing the diverse needs of different stakeholders
- Developers and teams influence the whole lifecycle of the product, from feature inception to deployment and maintenance.
- Teams relate to the prosperity of their product (part), having little other measures of success
- Dependencies between teams are identified regularly and managed actively
- Teams use techniques to work on strategic and architectural aspects of a solution (e.g. quality scenarios as backlog items)
- Teams constantly identify weaknesses and uncover innovation potential, having a pragmatic eye for trends
Focus on products
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.
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.
Reducing dependencies between 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
|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|
- 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.
- Anti-Viscosity: Leave responsibility inside teams by implementing proposal-based governance instead of hard rules.
- Technical Excellence: Minimize risk while handing over product responsibility to teams.