---
title: T-compiler Leadership and Succession
breaks: false
tags: steering, rustc
---

:::info
This document was originally distributed amongst the T-compiler members, and then to the compiler-contributors and to leadership elsewhere in the Rust project.

It is going to be effectively "open to the world" once Felix posts it to the Zulip stream for the [Leadership and Succession steering meeting](https://github.com/rust-lang/compiler-team/issues/506).

The aim for the document itself:
* Establish shared goals/aspirations: what we want to get from our leadership.
* Establish baseline expectations: the minimum we expect from our leaders
* Outline the effort required today from our leaders to meet the above
* Specify a *succession plan*: How leadership should rotate over time, in order to ensure the health of the team and the success of the Rust compiler.

The aim for the steering meeting:
* Get everyone aligned on the items above, and get feedback from you all about what's right or wrong in the document.
* Identify volunteers to help with converting this document into a structure appropriate for the project at large (presumably an RFC).
* Felix is currently assuming such volunteers would likely be helping with cutting out text and with review; we shouldn't need to start over from scratch.

As usual, we will drive the meeting by inviting the readers to provide feedback, either by adding comments via hackmd's annotation system (highlight the text in a View pane and then add the comment), or by adding questions/discussion topics to the discussion [topic queue][] at the bottom of the document (by adding the item itself in the Edit pane). Unfortunately the [topic queue] hyperlink seems to sometimes fight with hackmd's autoscrolling when the Edit pane is visible.
:::

[topic queue]: #Discussion-Topic-Queue

# T-compiler Leadership and Succession

:::info
tl;dr: If being a compiler-lead is something you are interested in doing, you should read this document. If you care about what leadership of the compiler team means, you also should read this document.

Leadership of the Compiler Team, and selection of new leads, has been performed in an ad-hoc manner. This document tries to fix this by writing down 1. what the leads do today, 2. the minimum we expect from future leads, and 3. what process we should use for selecting new leads.

The motivation for writing this document: Felix believes a team like ours benefits from rotating leadership, both to prevent burnout for the leads themselves, and to encourage new leaders to step up and push the team towards new unexpected directions. But, to enable rotating leadership, we need to establish a shared vision for what our expectations are for our leaders, as well as the vision for what succession planning looks like.

If you, as a team member, want to give us feedback or talk about it 1:1, please let Felix/Wesley/both know by Thursday 2022-04-07, and we will schedule a follow-up meeting with you. If no one has any concerns, then Felix plans to propose a steering meeting on this topic at the 2022-04-08 planning meeting.
:::

Let us, the compiler team, talk about how we manage ourselves today and our plans for how to do so in the future.

The compiler, as the development tool that is the literal embodiment of the language definition, is arguably the most important component of the Rust project.
Of the [teams](https://www.rust-lang.org/governance#teams) that make up the Rust Project, the compiler team is easily the largest. T-compiler currently has 14 official members and an additional 23 "compiler contributors" who have many of the same privileges as full team members (such as r+ rights on the rust-lang/rust github repository).

Leadership of the compiler team matters: While a small co-located team can often operate without much structure, a large distributed team like T-compiler benefits from higher level coordination. Today, that coordination is mostly provided via 1. the T-compiler co-leads, and 2. the various subteams, working groups and project groups that members of our team contribute to, or lead outright.

This raises natural questions, such as:

* What *does* a team lead do?
* What are the expectations we have for a lead? What competencies should they have? What time commitment does the role demand?
* How should future leaders be chosen?

This document is going to try to tackle those questions.

:::info
There are other questions you might have asked as well, such as:
* What kind of person is most useful in the role of lead?
* What structure does the current team actually follow, in practice? Would the team benefit from more structure? (Or from less?)
* The text mentioned expectations/competencies/time-commitment for a lead. Well, what about that same question for a T-compiler *member*, as opposed to lead?

This document is *not* going to try to answer those questions directly (though it might allude to them needing answers in the future). Some of those questions don't have one-size-fits-all answers. Others represent bigger issues that we do not want to try to tackle right now.
:::

## What is the role of a lead?

Wesley and Felix both see compiler team leadership as ["servant leadership"](https://en.wikipedia.org/wiki/Servant_leadership).
We are not trying to push everyone to go do our thing. Instead, much of the role, as we see it, is just getting obstacles out of the way of the rest of the team. But (and this is an important "but"): Servant leadership is but *one philosophy* of leadership; Felix is not sure it is built into the role of T-compiler lead *per se*.

Felix's expectation is that the work performed by a T-compiler lead will naturally vary between different leads. Some leads will be heavily technical and want to focus their time on specific initiatives of interest to them, and will inspire their teammates to join them there. Other leads may invest the bulk of their time into project management as a whole. Still other leads may be most interested in building community and making the team itself more cohesive. Variation here is to be expected.

At the same time, it is important that the basic needs of the project are met. The compiler team leads are, in part, meant to be safeguards ensuring that each release of the Rust compiler meets a high bar for quality, while also continuing to progress forward in terms of the features it provides.

## What a Lead Does

Let us first discuss the *bare minimum* that a team lead should provide.

Felix thinks the bare minimum can be described via two roles: 1. Team Representative, and 2. Decision Owner.

### Minimum: Represent the Team

A team lead needs to be able to represent the compiler team, specifically when engaging with stakeholders.

* "stakeholders" can mean any of: Rust users, other teams on the Rust project, developers contributing code to the Rust project, or even organizations seeking to support development of Rust by contributing money or human resources.
* A team lead must have a rough understanding (at least) of what tasks fall under the remit of the compiler team, and which are better suited for another one of the Rust teams.
* A team lead should be aware of what painpoints that the compiler team is suffering from most.
* The painpoints can be technical. They can also be social.
* The co-leads have had to manage personality conflicts involving contributors to the compiler on multiple occasions.[^changes-to-conflict-resolution]
* A team lead should be aware of what large scale initiatives are happening within the compiler, so that they can speak in an informed manner about what issues in the compiler are being addressed, and which issues are not likely to be addressed in the near term.
* Felix thinks that T-compiler has a significant gap in this kind of project management. We may want to look into adopting practices being used by the [Lang team][lang project board], or by [wg-async][async polish board], to drive initiatives forward and track their progress.
* Ideally, the leads' representation of the team would manifest itself via structured communication. For example, the [2022 Ambitions Blog Post][2022 Ambitions] was one example of how we, as team leads, communicated our team's plans to the broader community and world at large.
* Today, this aspect of the role means that Felix and Wesley both participate in project leadership discussions.
* We have been asked for advice, both technical and non-technical, about topics ranging from: "How should the Rust Foundation provide support for the compiler team?", "What should the rules be about code-reviews when PR author and reviewer both share the same employer?", "Where can I hire contractors to improve rustc performance?", "What criteria should be used to determine success of a contributor's project?"
* We also have reached out on behalf of the team, when it seems like an issue is not being resolved, to try to identify stakeholders external to the team who could drive progress forward on resolving that issue.

[^changes-to-conflict-resolution]: The social/conflict resolution aspect of the role may lessen in the future, depending on whether the project decides to take a more holistic approach to this problem, since it is a concern that cuts across many teams.

[2022 Ambitions]: https://blog.rust-lang.org/inside-rust/2022/02/22/compiler-team-ambitions-2022.html

[lang project board]: https://github.com/rust-lang/lang-team/projects/2
[async polish board]: https://github.com/orgs/rust-lang/projects/2

### Minimum: Own Decisions

A team lead needs to own decisions on behalf of the compiler team.

* Some choices made by the team can be consensus driven, e.g. driven by the usual "FCP all-but-two with no concerns" process.
* But some issues need a decision with high urgency, or even a specific deadline.
* Deciding what to do about a critical release-blocking bug should happen before the release, preferably long before.
* Beta-backport decisions need to be made in time for the backport to happen before the beta is lifted to stable.
* When adverse events happen, true ownership means also recognizing what decisions led to the event, and taking action to prevent future occurrences of the same event.
* Examples of this include the incr-comp bug that plagued the 1.52.0 release, which led to a 1.52.1 release [four days later][1.52.1] and [three][2021-06-25] [steering][2021-07-02] [meetings][2021-07-09] as follow-up.

[1.52.1]: https://blog.rust-lang.org/2021/05/10/Rust-1.52.1.html

[2021-06-25]: https://zulip-archive.rust-lang.org/stream/238009-t-compiler/meetings/topic/.5Bsteering.20meeting.5D.202021-06-25.201.2E52.20retro.20compiler-team.23435.html
[2021-07-02]: https://zulip-archive.rust-lang.org/stream/238009-t-compiler/meetings/topic/.5Bsteering.20meeting.5D.202021-07-02.3A.20fingerprints.20.2B.20planning.html
[2021-07-09]: https://zulip-archive.rust-lang.org/stream/238009-t-compiler/meetings/topic/.5Bsteering.20meeting.5D.202021-07-09.3A.20f's.20part.203.20compiler-team.23435.html

## What does the bare minimum look like?
[core items]: #What-does-the-bare-minimum-look-like

Today, Felix and Wesley try to manage covering the items above by:

1. issuing "unilateral approval" for decisions (such as beta backports) that are either urgent or are trivial enough to not require team discussion
2. driving the two weekly meetings (Thursday triage, and Friday steering),
* This is not a passive activity: good meeting facilitation requires both encouraging dialogue (e.g. by seeking disconfirmation, or by taking a contrary position), and cutting dialogue off (by noting when conversation is no longer productive, or would be better suited for an asynchronous forum)
* (Also, the meetings have sometimes been driven by a non-lead team member. This is rare today, especially since we started having co-leads; but maybe in a future era it need not be rare?)
4. engaging in asynchronous zulip conversations amongst leadership
5. authoring communication on behalf of the team (such as the [1.52.1 blog post][1.52.1] and the [2022 ambitions blog post][2022 Ambitions])
6. coordinating with each other as co-leads, either in an on-demand manner, or via periodic "sync-up" meetings.

In addition to the above, Felix and Wesley have each chosen at various times to:

6. drive progress on backlogged work,
7. draft steering meeting proposals, and often write the associated steering meeting document to drive the meetings,
8. solicit individuals to form working groups to address important problems,
9. take on the resolution of unassigned or abandoned P-critical or P-high issues,
10. drive larger initiatives related to the language.

However, we think it is important to note two things:
* any contributor can do any of the latter items, and
* it need not fall on the T-compiler leadership to fill all gaps in these spaces.

## Expectations, Competencies

The common technical activities of a T-compiler lead are not glamorous: you need to be able to build the compiler and run its test suite. <!-- Reducing bugs is useful at times, but not a strict prerequisite. --> You should be able to bisect the git history. And you should be able to post pull requests, especially ones that revert existing changes.

To put it simply: We expect that any member of the T-compiler already has the *technical competencies* necessary to be a lead for the team.

One interesting aspect of the Rust compiler is that we actively encourage people to contribute to our code even if they have no background in compiler technology.

Similarly, Felix and Wesley do not believe someone needs to have expertise with every facet of the Rust compiler to be a compiler team lead. Simply put: It is too big a code base for anyone person to actually hold in their brain at any one time. (Of course we have proposals for things like "librarification" that might help with this, through the magic of ["abstraction via specification"](https://en.wikipedia.org/wiki/Information_hiding); but our code base does not fit that mold today, and we have no short-term plans for getting there.)

This is all a way of saying: We don't know about everything in the compiler, and we don't expect future leads to know everything either.

What a person who leads the team *does* need is enough social connection with the other T-compiler team members to feel comfortable reaching out for one-on-one communication when necessary.

Under our current model, the leads also need to be able to drive the Thursday and Friday team meetings.

For these reasons, we will use "membership in the T-compiler team" and "regularly attends the Thursday and Friday T-compiler meetings" as the main prerequisite to be a candidate for T-compiler leadership. (A record of leadership on one or more project groups or working groups is probably a good thing to have as well, but is not a strict requirement.)

## Time Commitment

Felix is not great at teasing apart how much time he has spent on the [core items][] listed above. But, let us take a shot at it, since it seems important to set expectations for our leadership going forward. (Having said that, Wesley wants to stress that the real requirement is not a fixed amount of time each week, but rather *flexbility* in how you can spend your time.)

Issuing unilateral approval is done on a "as needed" basis. Likewise, engaging in asynchronous zulip conversations amongst leadership is done on an "as needed" basis. Let us assume one should set aside 2 hours a week for these activities, as well as addressing various "fires" that arise.

Driving the two weekly meetings takes at minimum 2 hours a week (for the meetings themselves). But there is some extra time to account for on top of that:
* The Thursday meeting itself needs no preparation anymore, thanks to the ongoing efforts of wg-prioritization.
* The Friday meeting benefits from preparation in the form of aiding the meeting proposer with authorship of their steering meeting document. On weeks when Felix has invested time in steering meeting document authorship, it has occupied 2-4 hours of their time.
* Overall then, we might say that you should plan to spent 4 hours per week on preparing for meetings, running them, and dealing with post-meeting activities (such as blog posts or follow-up discussions).

Wesley and Felix have a standing bi-weekly 30 minute sync-up meeting. They also communicate asynchronously on Zulip as needed. Let us say there's 1 hour a week on average for that.

Finally, authoring communications on behalf of the team has been done on both an as-needed basis (such as for the [1.52.1 blog post][1.52.1]) and as part of a preplanned deliverable on the behalf of the team (such as for the [2022 ambitions post][2022 Ambitions]). Each such document represented a fairly significant amount of effort, though it was only required on an infrequent basis. Let us assume that activity like this requires 6 hours of effort once every six weeks; thus, 1 hour per week on average.

Overall then, we might say that T-compiler leadership should be expected to consume 8 hours per week, *at minimum*. That's in addition to whatever time you might spend on actual development work on Rust itself.

However, we emphasize again that this number is an average, and the variance is high: some weeks you might only spend an hour or two on T-compiler leadership duties. But then there will be rare weeks where you will spend 15 hours or more on these duties. In some ways, the most important attribute of a T-compiler lead today is *flexibility* with respect to how they can spend their time.

## Leader Selection Procedure

### History of Leader Selection

So far, T-compiler leadership has been a largely ad-hoc process. We have only had three eras:
* Niko as sole lead (since the T-compiler team's inception, pre-1.0 in 2015),
* Niko and Felix as co-leads (formally starting in October 2019), and
* Felix and Wesley as co-leads (starting in December 2020).

Felix's memory is that their [promotion to co-lead][felix-co-lead] was a decision Niko made after recognizing that Felix's efforts in meeting management and issue triage effectively showed Felix was already acting as a co-lead, in terms of sharing team leadership responsibilities, since at least 2018.

[felix-co-lead]: https://blog.rust-lang.org/inside-rust/2019/10/24/pnkfelix-compiler-team-co-lead.html

Sometime in 2020, Niko decided they needed to step back from their T-compiler leadership duty in order to focus more effectively. Felix and Niko together felt shared leadership was healthier than relying on one sole leader at all times. Thus, they asked the team to nominate members whom the team thought would be good candidates to lead the team. Then, after reviewing the list of nominated members and speaking with each of the nominees, Felix and Niko [selected Wesley][wesley-co-lead] to be the next T-compiler co-lead with Felix.

[wesley-co-lead]: https://blog.rust-lang.org/inside-rust/2020/12/14/changes-to-compiler-team.html

The main notable difference between these two events was that Felix organically stepped up to take on co-leadership duties without being named co-lead, while Wesley was selected by a slightly more formal process. (Of course, Wesley had already proven themselves as a capable leader based on their history leading a number of working groups, as discussed in the blog post announcing their new role.)

### Time Commitment, Part II: How long to lead?

Niko served in their T-compiler leadership role for over five years. Felix plans to serve as co-lead through (at least) the remainder of 2022. Depending on how you count, that's a precedent of expecting a commitment of 4-5 years, at minimum, if someone signs up for T-compiler leadership.

However, we **should not** treat that precedent as established law. Four years is a long time.

Felix thinks it would be healthier to revise our expectations here: Team leadership terms should aim to cover two to four years, where that term covers *both* the time spent as a junior lead, *and* the time spent as a senior lead.

(If we can work through transitions in leadership successfully, then maybe we can push for even more frequent turnover in leadership. The stated two-year minimum was based on an expectation that we should allow for the junior co-lead at least one year to "learn the ropes" of leadership duties, and that implies an overall two-year cadence for team leadership duty. It is possible that a shorter period might suffice, especially as the team evolves.)

### A "New" Process

We think the co-leadership process we have used so far has worked pretty well. In particular: Having a pair of leaders, one "senior" and one "junior", where the last era's junior lead is the subsequent era's senior lead, works well in terms of transferring knowledge between eras. It also aids for *calibrating* leadership activity: A senior lead is meant to provide help the junior lead fine-tune their sense of how to prioritize issues that arise, and how to make decisions about things like beta backports.

One thing that is important when it comes to co-leadership is that the two leaders need to be able to work together effectively. We do not want to end up with a pair of leaders who cannot talk to each other.

Also, our expectations is that past leaders will remain available, at least for the short term. Niko is still a compiler team member, is active in the project, and has been available to consult when needed. We think that is a good model to follow: after each roll-over in leadership, the former senior leads should strive to be available for limited consultation when necessary.

Therefore, Felix proposes that going forward, we reuse the process that Niko and Felix adopted back in 2020: when the senior co-lead decides that they are ready to step down, and have confirmed that the junior co-lead feels ready to take on the senior co-lead role, then the two tell the T-compiler team privately about the intention to have a rollover in leadership.

Then the T-compiler team members can nominate their teammates to serve as the new junior co-lead. (In 2020, we allowed five days for nominations to roll in. Felix is inclined to deviate from that precedent, and follow the model of our FCP process: The leads should provide a ten-day window for nominations to come in, unless they get confirmation that the set of nominations is complete.)

After nomination is completed, the outgoing senior and junior co-leads discuss the set of nominees, and also, if desired, have short discussions with the nominnees. Then, the senior and junior co-leads select the new co-lead from the set of nominees. And that's it! Then they just need to publish a blog post saying that the leadership is rolling over, and say when it will happen.

### Why nominate?

One might wonder: If the two co-leads are going to select the new lead, why go through a nomination process? Shoudn't the co-leads just skip the nomination and select someone?

Here's why: it is important to give the team a chance to speak up in support of their candidates. It gives the leads a chance to see which other team members would be likely to get support during *future* rounds of succession planning. It also provides evidence that the nominee has a healthy relationship with the other members of the team, which we argued above is a defining attribute for a lead of this team.

## Failure Modes

This document isn't going to try to predict every bad thing that might happen. But there is one failure mode that is worth noting: What if a junior co-lead changes their mind, and decides they want to step down?

For now, Felix recommends that in this scenario, some previous senior co-lead steps into the vacant junior co-lead position (on a temporary basis) while a new junior co-lead is selected (presumably by reusing the previous set of co-lead nominees, or going through a new round of nominations if necessary).

This stepping into temporary co-lead position is just to allow proper sharing of workload, so that the current senior co-lead isn't suddenly facing twice the amount of work that they had before.

## Conclusion

Right now, this version of the document is being shared privately between members of T-compiler.[^reshared] Basically, Felix did not want to make any big statements about their plans or about how leadership is handled without first giving every member of the team a chance to weigh in with their own thoughts.

[^reshared]: Since the above was written, the document was subsequently shared with the compiler-contributors and with the other project leaders. And as of 2022-04-22, it is being shared with the world at large as part of the compiler team's open steering meetings.

The next steps are: Felix and Wesley are both available to talk with any of you one-on-one. We want your feedback on this document!

:::info
If you, as a team member, want to give us feedback or talk about it 1:1, please let Felix/Wesley/both know by Thursday 2022-04-07, and we will schedule a follow-up meeting with you.
:::

If no one has any concerns, then Felix plans to propose a steering meeting at the 2022-04-08 planning meeting
to discuss this document (or the next iteration of it) with the broader T-compiler + compiler-contributor community. After that, there will probably be a T-compiler RFC to codify the ideas here as official policy for the team.

Thanks to you all for taking the time to read this, and for all the work you do on Rust itself.

Cheers,<br/> Felix and Wesley

# Discussion Topic Queue

Add your question/discussion topic below, with its own `##` header so that we can identify them easily.

## Sample Topic

pnkfelix: Is this what a question looks like? (Yes, it is!)