Prerequisites for staffing new projects

In order for a new project in the TTS Staffing repo to be staffable, it must:

• Have identified a single point of contact (from the partner agency if there is a partner external to TTS) that is empowered to make decisions.
• Include a summary of the core problem this effort is meant to solve (not assigning solutions: that’s the team’s work).

Opening an issue

Required labels These should be added by the issue author.

• MULTIPLE blue skillsets labels
  • UX / Service design
  • CX + Customer Success
  • Engineering
  • Product
  • Content
  • Change strategy / Org design
  • Internal Comms
  • Product design/Visual design
  • Project management / Account management
• MULTIPLE (color) on-call-SME labels
  • On-call SME’s can be called upon to share their technical expertise and/or their lived expertise in a specific space - such as working with SSA, working on disaster assistance projects, etc.
  • Some areas of technical expertise that are typically on-call SME’s, rather than fully staffed:
    • Acquisition
    • Accessibility
    • Cultural competency/language
    • Security/compliance
    • Data & analytics
    • Financial Mgmt
• Purple phase labels as appropriate:
  • Work in Progress—Issue is not yet ready for Staffing consideration and should be ignored.
  • Staffing Request—An issue that is ready for TTS Staffing leads to actually assign staff. This should be applied to all projects with a current staffing need. See (PREREQUISITES).
  • Inflight—A project that is already underway and has a new or changed staffing need.
  • Waiting Room—A project that is not ready to close but does not need action at this time.

Staffing requests

Once a staffing issue has been opened in the TTS Staffing Repo, the Staffing representatives from the Five Families look internally for folks who would be good fits for the project. Each unit has its own internal process for identifying individuals for projects. The reps then convene once a week to build teams.

Onboarding discussions should not start until two things have happened:

• The staffing rep lists the person's Github handle next to the role in the issue with the box checked.
• The staffing rep mentions the person's Github handle in the comments along with their role. For example, "Adding @tweetybird to the cat-herding role".

Once the issue is fully staffed and a start date has been assigned, the issue should be closed.

PLEASE DO NOT add or remove names in the original project issue unless you are a TTS staffing rep who knows you are authorized to do so.

For new requests on existing projects:

If someone needs to move off of a project but can be replaced 1-1 on the spot, reopen the original issue, note the change, get the appropriate parties to acknowledge, and close it back up. (This should only be done by the TTS staffing rep. Example: “Bugs is going on extended leave starting on September 1. Daffy will backfill for Bugs starting on August 26.”)

If a person leaves a project unexpectedly (medical leave, role change, leaving TTS, etc.) and a replacement is needed but not immediately available, an team member should reopen original issue, add the "Inflight" and “Staffing Request” labels, and note the need in a comment. (“Reopening to request backfill for Porky following his acceptance of a new role.”)

If a project needs to add additional staff that were not originally requested, reopen the original issue and proceed with the request. Apply the "Inflight" and "Staffing Request" labels.

On the subject of inflight staffing changes:

There are many reasons why a change in staffing might be warranted, and changing the team make-up is a tool in our toolbox. You can change staffing to bring in different skills or a fresh perspective. You can also change the make-up of a team if folks have conflicting work styles, or if someone is challenged by working with a particular partner. People may also have personal reasons for wanting to leave a project. To help navigate these situations, and to ensure no one is being treated unfairly or discriminated against, please make use of the following resources:

If you’d like to leave a project: Please do not unilaterally depart a project. You will never be compelled to stay on a project with which you do not feel comfortable, but we have a process to handle this sort of thing designed to prevent the many downstream problems caused by leaving. See Rule #10 below.

If you think your team needs a staffing change, please discuss it with your team, and then the TTS Chief of Projects. If you don’t feel comfortable doing this, or if conversations have been ineffective, consider approaching the Staffing lead or your supervisor.

If you aren’t comfortable with any other choices for communicating distress, ping the TTS Chief of Projects. That’s what they’re here for.

And finally

TTS’ effort to reconcile many competing priorities and areas of expertise in an equitable way has led to an amazingly complex and chaotic system. It takes magic, luck, and a lot of supremely talented, dedicated, hard-working, way underappreciated people to make it work. Drop into #tts-staffing occasionally and distribute hugs and high fives and thanks; making a system like this work at all is a small miracle.

Staffing rules

1. A problem needs to be defined and prioritized in order to apply the “Staffing request” label to an open issue, and thereby initiate a request for staffing.
2. Requests for project staff should arrive in GitHub unstaffed, except when putting a pre-existing team on the record.
3. Each TTS Unit will establish one single point of contact to address chapter members’ questions about the staffing process.
4. TTS Units are responsible for negotiating mutually acceptable project roles & skill sets for each staffing request.
5. Projects that do not have a defined endpoint will be staffed in 6-month increments.
6. When team members must be allocated to multiple projects, the projects will establish a clear priority order of those projects for that team member before the team member begins the assignment(s).
7. An individual team member can neither leave nor be removed from a project without the consent of their staffing rep and the project team. (This is intended to be a deterrent to “recruiting”.)
8. In the unlikely event that one of these rules must be circumvented, the conflict will be mediated by the Staffing Director and approved by the TTS Chief of Projects.

A list of rules without the context behind them will lead an org in circles. The Original 18F Rules of Staffing, Annotated tells some of the tale of how we got here, in hopes of avoiding redundant work in the future by capturing experiences from the past.

These rules will evolve and change and be adjusted, sometimes a lot, as the staffing team learns and iterates. They’re guidelines supporting a process to let the Staffing Team get where we need to go, not commandments prescribing how we do what we do forever and ever.