# Motivation

The Rust Project is composed of hundreds of globally distributed individuals each of whom have very different motivations for working on Rust. Rust's open culture allows for these individuals to collaborate in a productive manner where complex technical and organizational decisions are made through consensus building and stakeholder feedback.

Rust's model for project management and decision-making delegates most decisions to the appropriate team. Teams are ultimately accountable for their purview. While teams' decision-making processes do not strictly need to be consensus based, stakeholder feedback is repeatedly solicited to ensure a plethora of opinions on each matter are considered and factored in.

However, at times this leads to issues. These issues can be summarized by the following questions which do not have clear answers in Rust's current governance model:
- What happens when it is unclear which teams' purviews a certain decision falls under?
- Who is in charge of important but non-urgent work that is not clearly owned by an existing team?
- Who is accountable when that work does not happen and organizational debt accrues?
- How are teams in the Project held accountable to each other and to the wider Project?

Examples of the type of work in question include the following. Please note that this list is far from exhaustive and is merely meant to give an impression of the type of work in question:
- Helping identify gaps where existing teams are struggling to accomplish work or grow to meet challenges.
- Establishing large structural changes such as the Rust Foundation or new top-level teams.
- Project self-reflection. What aspects of Project operations are less than ideal? What do we do to change course?
- Project-wide community management. While individual teams can ensure that their teams are welcoming places, how do we ensure that the Project as a whole is?
- Policy work, for policies that have ramifications across the Project or even legal ramifications.
- Ensuring teams coordinate their work so that the Rust Project produces results greater than the sum of the output of the individual teams.

While the current system does at times lead to positive outcomes in the above scenarios, it often does not. Some examples of failure mode categories include:
- No one is accountable for a decision and so the decision goes unmade, leaving it undefined. This requires solutions to repeatedly be developed either "off the cuff" or from first principles. This requires enormous amounts of energy and often leads to work not being done well or at all. In some cases it can even lead to burning out Project participants.
- Much Project work that is non-urgent often does not get done. This can lead to processes and procedures that are done not because they are the best way to handle a situation but simply because they are the easiest. This can lead to outcomes that are unfair or even actively harmful to individuals. In general, working this way leads to a culture of "putting out fires" instead of actively fostering improvements.
- The solutions to many of the issues facing the Rust Project require coordinated action across many different teams. Finding solutions for these issues requires investment at the organizational level, and it is often very difficult for individuals to coordinate and implement such structural investment.
- Still, such Project work is often taken up by motivated individuals who then lack structural support for accomplishing goals leading to frustration and at times conflict and burnout.

Historically, the core team delegated authority to "top-level" teams who have further delegated authority to subteams or other governance structures. However, since the work outlined above is often Project-wide and outside the purview of individual teams, delegation was sometimes difficult. As a result, the core team assumed the following two responsibilities:
- Identifying, prioritizing, and advertising that certain important work needs to get done and does not fall under the purview of an existing team
- Attempting to do that work

Through experience by the core team, it has become clear that both the identification of problems *and* the actual work itself is far too much for a single team. This has led to less than ideal results and in some cases, burnout. While a small amount of work requires urgent and immediate action, the vast majority of work would benefit from being tracked and handled by dedicated governance structures.
