# Code Ownership

## The What

Code ownership is **NOT** one person who owns a codebase. Instead, it refers to how we **collaborate** on a shared codebase.

## The How

### Prerequisites

* The team owns the codebase
* The team works in an agile way
* The team embraces risk and learns from failure
* The team doesn’t have a heavy and prescriptive process

### Create a supportive environment

* Recognise the assistance of other team members in achieving their goals
* Recognise the contributions to improve Dev Experience, even though it isn't visible 
* Recognise the patience to tackle tech debt
* An appropriate level of autonomy

### Narrow the ownership **when appropriate**

* In many cases, splitting ownership is not ideal, but it can help you tackle small, maintenance & repeated tasks. e.g.,
* Upgrade dependencies
* Approve PRs generated by [Renovate](https://github.com/renovatebot/renovate)
* Bake the duties in the development workflow 
* Keep track of who owns what in a shared document

## :white\_check\_mark: Exceptions

* It only works on the known challenge with a certain solution

## :red\_circle: Red Flags

* Don’t go too far down the track
* Code ownership may demotivate the team

## :scroll: Tips

* Recognise desirable behaviours, e.g., refactoring, patching, improving dev experience, tidying up, improving CI/CD pipelines, etc
* It's quite OK for product managers or stakeholders to be outcome-driven
* The tech lead should recognise the contributions made on the journey to their goal

## :hole: Pitfalls

* Simply establishing clear ownership will not help you build a high-performing team