---
# System prepended metadata

title: Answers to Sarah's Questions about Flexible Squads

---

# Answers to Sarah's Questions about Flexible Squads
## Questions
Thank you for sharing this! I'm excited to work on Sponsors with y'all. 😄 

I have a few questions:

- Does # of people per squad reflect amount of work we expect is necessary? I notice Sponsors has 6 devs while the other squads have 4.
- I notice 3 of the 4 squads have a name that's not a specific product, I assume to define a general focus for that squad beyond the product if new work in that focus comes along. Why is the Sponsors squad named after a particular product while Contributions isn't called Discussions? I feel like I'm going to get this confused and just call that squad the Discussions squad. I similarly think I'm going to think of/call Connections the Profile squad.
- How were EPD leads determined? I figure familiarity with the area, what they were working on before Wall-E. Just noticing that Derek is on both Contributions and Connections, and Contributions has more EPD leads than other squads. Both Contributions and Sponsors have more leads than "EPD" has letters in the acronym, too. 😅 Are we concerned about increased confusion about roles, considering we'll already have some of that with "the EM I report to" versus "the EM for the product I'm on"?

## Answer (DRAFT)

Hi Sarah, these are fantastic questions and thank you for asking them! Here's my best shot at answering them:

**Sponsors Eng IC Staffing**
> Does # of people per squad reflect amount of work we expect is necessary? I notice Sponsors has 6 devs while the other squads have 4.

Yes, absolutely. Sponsors has 6 devs because we're having that squad work on both the _Corporate Sponsors_ project and the _Automation around fraud mitigation_ project. I had kind of hinted at it in my Announcements for the [Week of Aug 10](https://github.com/github/communities/discussions/112) but I wasn't super explicit about it. 

**Contributions naming**
> I notice 3 of the 4 squads have a name that's not a specific product, I assume to define a general focus for that squad beyond the product if new work in that focus comes along. Why is the Sponsors squad named after a particular product while Contributions isn't called Discussions? I feel like I'm going to get this confused and just call that squad the Discussions squad.

Across the board, we wanted the projects being shipped to be paired to the initiative they are building towards. We almost named the Sponsors initiative something broader and ambitious like "Open source careers" but chose Sponsors because the projects within the initiative were corporate sponsors and automation around fraud mitigation. Accordingly, since Discussions isn't in public beta yet, we didn't want the initiative name to anchor us to the product as we see it today; we still need to ship a public beta and see how the public responds to it! Accordingly, we saw Discussions as a project that's allowing people to contribute in a new way and expand what it means to contribute altogether. This is a part/whole relationship. 
 * We want to ship Discussions to enable more types of impactful Contributions on GitHub
 * We want to ship corporate sponsors and automation to make more types of Sponsorships successful on GitHub

**Connections naming**
> I similarly think I'm going to think of/call Connections the Profile squad.

For using the name Connections versus Profiles, I don't think that Profiles fully captures the work that the Connections initiative plans to do. The first project they plan on shipping is [Sparkles](https://docs.google.com/document/d/114ax5HuoBhbw1kvZb347RNM8RRyLCLCtwJ07UBgcbP8/edit) and it shows a world where you could sparkle someone in the comments of an Issue, Pull Request, or Discussion; none of this is in the profile area. They're also exploring ways to improve Discovery on GitHub, which may include creating a new content type called Posts.

Choosing names for initiatives that aren't anchored on a single feature or product implicitly gives us permission to design features for a future state instead of figuring out what we can do within a certain area.

**Derek Staffing**
> How were EPD leads determined? I figure familiarity with the area, what they were working on before Wall-E. Just noticing that Derek is on both Contributions and Connections

We're staffing projects to give them the greatest chance of success as possible. EPD leads are determined by looking at the work to be done and then talking to the EPD leads on what they need to be successful. With these two pieces of information, we try to make the best decision we can considering the constraints we have to work with. Every EM, PM, and Designer's input has been taken into consideration for the leads assignments and that input has been received over the last 3 weeks.

Zooming out, for the Communities department, we have 5 PMs, 6 people in product, 4 designers, and 3 EMs, so no matter what, we're not going to have a 1:1 matching for an EPD squad. Given that we've settled on 4 initiatives, Derek is the most qualified to handle two projects since he's been doing that off and on for his entire duration at GitHub and he's expected to be able to handle more responsibility!

**Contributions Staffing**
> Contributions has more EPD leads than other squads. Both Contributions and Sponsors have more leads than "EPD" has letters in the acronym, too. 

As far as Contributions having more EPD leads than other squads, we originally had only 3 leads for the project and as we started to look at the work and account for the well-articulated points by the EPD leads, we chose to fortify the initiative so it has what it needs to launch a successful beta and ship to get to a GA. There's always a tradeoff between "we need more than one person" and "now we're going to have to be more intentional about our roles in the project" and I can assure you that the EPD squad is thinking carefully about how to make the split (but I'll let Becca, Evi, Bryn, and Anthony speak for themselves! I'm only sharing my thoughts based on the conversations I've seen). 

Also, as a Staff PM, part of Becca's time will be spent in "synthesis mode", where she acts as a sounding board for the PMs/designers across all of Communities. Her primary focus will be to ship the Discussions public beta, but she'll also spend many cycles ensuring that our product strategy is cohesive across the department.

There's also a precedent for doing this! Sponsors had 2 senior designers on it for > 1 year in order to launch the product and get it off the ground successfully and I think that went pretty well, no? We're doing something similar with Contributions; giving the initiative what it needs to be successful given the current vision for bringing Discussions to Enterprises and to communities beyond the repository structure on GitHub. 

**EMs Staffing**
> Are we concerned about increased confusion about roles, considering we'll already have some of that with "the EM I report to" versus "the EM for the product I'm on"?

I don't think the EMs are concerned but I'd love to understand what we can do to gain the trust of our Eng ICs on this. We optimized for Eng IC mobility and growth opportunity chances instead of optimizing for ICs to be on teams with their manager and, accordingly, the EMs have all agreed to work harder to keep each other in the loop and share feedback. Yes, there have been some instances of trying to process the "EM I report to" versus the "EM for the product I'm on" and that confusion has encouraged the EMs to become even more explicit about the role split, which is a good thing! Unless the feedback isn't bubbling up, I'm under the impression that it's getting better. If it's getting worse, please let me find out so we can figure out what to do. 
