Back to Flutter Inner Source homepage
inner source

Capability Owners

The Flutter inner source model promotes re-use and cross-team contribution to each capability. Each capability is shared, and you may hear the terms shared codebase or shared development to describe them. However, our experience is that almost all successful capabilities in stage 3 have clear ownership with a named individual as a capability owner.


A capability owner has 3 key objectives:

  1. Use community leadership, process design and automation to improve the quality & efficiency of maintainer collaboration.
  2. Define, agree, communicate and action the capability’s technical and functional strategic path.
  3. Promote and action the tasks and projects required to optimise the capability sustainability and success in the longer-term.

The need for an owner can also be understood by considering the risks of their absence:

Capability, Individual & Role

We know that all capabilities, individuals and roles are different:

Capability An Individual Divisional Role
Complexity of a capability is how difficult it is to understand and change. Expertise of an individual is what they know and can do. Competencies of a role is the expertise that is expected from an individual in this role.
Demand of a capability is the expected effort required for an owner to achieve his or her objectives. Allocation of an individual is the amount of time they can actually spend being an owner. Affinity of a role is the similarity between the divisional role and a cross-divisional capability owner.
Evolution of a capability is the level of change that is required to ensure its future success. Impact of an individual is their ability to drive different sizes of change. Level of a role is the impact that is expected from an individual in this role.

The measures in each row can be matched between capability, role and individual to identify the optimum owner for a capability.

Complexity, Expertise, Competencies

Capability complexity, individual expertise and divisional role competencies can be expressed by what it relates to:

A good foundation of people skills (leadership, facilitating collaboration and consensus) is required in all cases.

Demand, Allocation & Affinity

Capability demand, individual allocation and role affinity can be expressed as the level of effort dedicated to being an owner:

Evolution, Impact & Level

Capability evolution, individual impact and divisional role levels can be expressed as:

Divisional Roles

To match divisional roles against the needs of a capability we need to know their competency, affinity and level:

Division Role Affinity Competency Level
FDG, ISP Senior Engineer full-time engineering optimise
PPB Senior Engineer part-time engineering change
FDG Lead Engineer part-time engineering change
PPB, ISP Principal Engineer full-time engineering change
PPB, FT, ISP Architect part-time architecture transform
ISP Senior Principal Engineer part-time architecture transform
ISP (Senior) Engineering Manager reactive engineering (transform) change
FDG Senior Devops Engineer full-time operational optimise
ISP Senior Devops Engineer part-time operational optimise
ISP Principal DevOps Engineer full-time operational change
PPB, FT, ISP Product Owner part-time product optimise
FT Inner Source Manager part-time - change
ISP Distinguished Engineer full-time - transform
FDG Tech Programme Manager full-time - change


Usage Examples

Due to the high value to an owner of knowledge and existing experience within a capability, most capability owner appointments are internally recruited. This section describes typical examples of this process to illustrate how the model described in this document is used.

Requesting a New Owner

A capability has no owner and its parent product maintainers want to recruit one. A group who know the capability well are gathered to agree the needs of the capability:

This group classifies the capability with engineering complexity, full-time demand and its evolution requires significant change.

The product maintainers review this against divisional roles:

The product maintainers document the need for a capability owner including suggested divisional roles. They use this document to justify and request candidate proposals from divisional leaders. They use the document to discuss with their teams and any interested candidates. The product maintainers use the expected divisional role costs to secure budget in advance for divisional backfill or direct recruitment (in the case of no divisional proposals).

Assessing Proposed Owners

Two owner candidates are proposed by different divisions.

Further discussion between product maintainers, divisions and the candidates themselves results in Emily appointed as the new capability owner.

Owner Performance Reflection

Over the last year Emily has proven herself a valuable and highly effective capability owner. In performance reviews with her manager they discuss how she has done so:

This forms a key part of her manager’s justification to recognise her recent achievements with a promotion to Principal Engineer.

Maintainers in Multiple Teams
← Previous
Divisional Independence