The AREA Model of Ownership

Accountability, Responsibility, Expertise and Authorization for code, data and other stuff

Photo by SIMON LEE on Unsplash

“We have a strong community-based ownership model for our code”

Ownership is a compelling, but ambiguous term used in the context of code, data, models, or other technical concepts in software. There’s a big difference between shared responsibility and accountability for a given artifact, and the term ownership can mask those details.

Sometimes an engineering team or organization reinforces principles around community-based ownership of things. This tends to mean something like “everyone contributes to all other teams’ code”. These principles can sometimes produce a culture where engineers feel welcome, or even compelled, to proactively and opportunistically improve the quality of someone else’s codebase.

At its most extreme, everybody “owns” all code, data, and everything else in a communal way; this can become impractical and runs into scaling challenges once the team grows.

“Only Mike is in the CODEOWNERS for that directory; he’s pretty particular”

The other end of the spectrum is an individualistic or defensive ownership model which centers the owning individual or team. While the code may be open to others to read, browse and sometimes use directly, external contributions are not encouraged or welcomed. This is often accompanied by a rationale related to code complexity, sensitivity, or maintenance cost.

At its most extreme, an important codebase or dataset relies on a single individual caretaker and contributor and no others; it is their castle.

I’ve found that something the middle tends to work best. But it requires a more nuanced understanding of what constitutes ownership.

“Does anybody know who owns <X>?”

This kind of question is asked all the time. It tends to be a convenient and contextual shorthand for a few different, but often conflated concepts. These work out to the convenient acronym AREA:

• Accountability: Who must ensure that the work on X gets completed, and done so correctly and safely
• Responsibility: People who should be tasked with doing the actual work on X
• Expertise: People who best understand X (or some relevant component of it), often because they’ve built it, and can inform how work should be done
• Authorization: People who are able to commit or approve changes to code, data or other assets associated with X

If X is small, the same people might fill all four buckets. If it’s large, that may not be the case. For example, if X is a codebase, ownership might look like:

Accountability: Team A's manager
Responsibility: The entire Team A
Expertise:      Team A's tech lead and another old-timer on the team
Authorization:  A subset of team A with commit privileges to the codebase

In this case, the entire team A is responsible for the codebase (I think the best default scenario, discussed later), and the manager is accountable for it. However, only a couple people on the team really know the codebase, and a subset of the team have repository approval privileges. That could be the two people above, or all engineers on A except the manager.

“Our team owns <X>, but only a couple people really know how it works”

In a different example, imagine a database X which is “owned” by Team A and gated by their service A-DB-Service. The database is required for a project being run by Team B. In addition, Team A is large so it is split into a couple of sub-team squads:

Authorization:  All members of Team A and A-DB-Service
Responsibility: Squad Z from Team A in partnership with Team B
Expertise:      Squad Z from Team A
Accountability: Squad Z tech lead

Although the database as a whole is owned by A, perhaps there are tables or columns which were added by, or for, team B . Now there’s some shared responsibility across both teams for the database, even though accountability for the database hasn't changed. The fact that A-DB-Service has privileges for reading and writing to the database can inform us who owns the table X if that information is not directly available.

The answer to “who owns this thing” is context-dependent, but should be known, well-defined, and stable over time. All owners should understand in what context they, and all other owners, own the artifact in question and how best to support it.

Accountability within ownership is a prerequisite; if the other attributes are unbalanced it can lead to problems developing or modifying the artifact in question

If being asked about ownership by an incident management team, the askers likely want to know who is accountable for recovery and followup tasks. If being asked by a collaborating project team, they’re probably looking for expertise for consulting on their project.

Ownership policy and clarity are key

I have worked on teams where the set of owned artifacts were defined by the set of targets in PagerDuty, things enumerated in a wiki page, or things under a directory in a code repository. I have been on teams which have “co-owned” code and data with other individuals or teams, been listed as owners of artifacts or services while having never touched the code, and been handed totally unrelated datasets for stewardship.

In these cases my teams owned things on paper, but not in reality, and that was bad for the company when we wanted to fix or complete Big Things which affected many, or all, assets across Engineering. That kind of cognitive dissonance delegitimized our alleged ownership of those artifacts.

An articulation of ownership policy for the broader organization helps avoid these traps, and helps teams plan longer-term for their own asset portfolios.

The attributes of ownership overlap, but are not the same

For small teams, or small codebases, an entire team might share AREA attributes for the code. But for complex codebases, datasets, or large teams, they necessarily need to split. Not every member of the team can be an expert in every codebase the team manages, nor can you have twelve people on a team accountable for a codebase’s upkeep or safety.

While the entire team might have approval or authorization privileges for the codebase, for a variety of reasons spanning from code review turnaround time to incident management, it’s likely that different subsets of the team are responsible for different components as a matter of course.

Accountability is the single most important ownership attribute

If only one unit of ownership is defined, it should be the single accountable person for the asset, because everything else follows from there. This person tends to be a team manager because they have some capacity to allocate resources against things within their scope.

A person accountable for outcomes based on X is going to ensure expertise is developed, people are responsible for the upkeep of X, and there’s clarity on who can and cannot modify it. If they don’t, then they are clearly on the hook for eventual negative outcomes, and there’s a clear escalation path.

Conversely, it's difficult to assign accountability for something if we have, for example, experts familiar with the asset who aren’t responsible for it in any way as part of their day job. This is often how large, communal codebases or datasets fall into disrepair (tragedy of the commons), even if they are being actively used.

A team can be the de-facto “owner” for any given asset by default

It’s often sufficient to define a “team” as the owner for a codebase or anything else, as long as that team has an understanding and opinion of how that thing is owned and map into a common manager.

For example, if a privacy-related data retention change to a dataset owned by Team A is necessary, it should be sufficient to leave the work item to Team A and assume they’ll figure out who will be responsible for the work. This kind of group-assignment works as long as the working expectation is that Team A’s manager is accountable for the work getting completed as discussed above).

Ownership of systems versus ownership of projects

There’s a difference between the ownership of existing systems and data, and the ownership structure associated with project and project management creating or modifying those systems.

Most of what is discussed in this post is related to ownership of stable systems. Transient projects or programs can also have an ownership structure, though it’s usually structured in a project-specific way.

An ongoing project P could have dependencies entirely captured within system S , but with those two having distinct AREA ownership definitions. The ownership and accountability of the delivery of P is related, but separate, from the stability, operation, quality and ease-of-use of S.

Least-privilege versus execution speed and practicality

Following the principle of least privilege, the only people authorized to make changes to an artifact should be as small as possible, and in an ideal world, 1:1 with the system experts.

The reality is that authorized commiters tend to be larger than the group of experts, because of the need to support development against a particular codebase or dataset, even if the committer has less-than-expert knowledge of the system in question.

As long as all authorized people map upwards to the same accountable individual, this can work fine if the right sets of standards around code or data health, quality and risk are established within the team. Without these standards, permissions can degrade into a huge list of contributors who don’t fall into any reasonable accountability chain.

Resolving abandonment

Ownership over abandoned entities, code, systems, datasets, or other assets needs to be established, if they are still in active use. This is for a variety of reasons from codebase health, to enabling company-wide platform upgrades (for example, a language version upgrade), to compliance or information security.

As mentioned above, the first step is identifying the right accountable owner for the artifact. Then they can sort out the other aspects of the AREA ownership model.

Determining that accountable party isn’t easy, especially if we’re talking about some kind of legacy artifact which hasn’t had active owners for some time. Considerations could include:

• Strategic alignment of the artifact with an existing teams’ strategy or plans, to the extent they exist
• Location of relevant technical domain expertise within the organization
• Who-touched-it-last or you-found-it-you-own-it
• Where the previous set of known “owners” went within the org and whether they’re capable of re-assuming ownership
• Relative workloads and capability of teams to assume a greater ownership portfolio

Resolving ownership conflicts

Ownership conflicts arise in two situations:

1. A team doesn’t want to own (/maintain/pay for/operate) an artifact and thinks another team should (common)
2. Two teams want to own the same artifact (rare)

In both cases, the considerations under the resolving abandonment section above still apply. In general, it’s desirable to have owners responsible for strategically-alined artifacts, for which they have relevant domain expertise, and historical familiarity.

Ownership is a useful and intuitive shorthand term for a collection of nuanced concepts. Failing to dig into these underlying attributes makes ownership resolution or assignment difficult or all kinds of artifacts. Organizations which define a consistent ownership policy that articulates and rationalizes these roles as they relate to their code, data, models, and other assets create clarity for their teams, informs them how to manage their portfolios, and prevents disputes with their peers.