jmunroe
commented
1 year ago I agree with all of the goals that need to be accomplished, so this proposal is definitely forward looking!
Is this too fine-grained for where we are now? (7 functional 'teams' for ~8 people). Unless we are going to be doing some significant hiring, shouldn't we be rolling up some of these areas into a smaller number of teams? Or is the point to make it explicit the full extent of all the work we are trying to do across the team?
choldgraf
damianavila
Context
Currently, we describe 2i2c as an organization with several functional areas, and one big team. In practice our organization performs a variety of actions, and is probably best-described as a collection of teams with different responsibilities and focus areas. Because we are a small group, many people are on multiple teams at once.
I think there is value in defining them separately so that we understand when a person is wearing the hat of one team or another. So my goal below is to:
So that we can:
It should not be proposing anything radically new, so everything below should feel familiar. Its goal is to make explicit our current roles that we are implicitly filling.
Plan for this proposal
If there are no objections to the framing below (I am happy to iterate if people have recommended improvements!) then I plan to integrate these ideas into our team compass by:
I'll plan to leave this open for at least a week so that others have time to think about it.
Proposal
I propose that we describe 2i2c's group as a combination of the following teams and roles:
Within 2i2c there are a number of sub-teams that all coordinate with one another. They roughly map onto the major functional areas of 2i2c. These teams are below, broken down by major area. Note that many of these roles may be unfilled, and one person may be split between many roles. That's OK - the goal is to identify potential places for growth, and to make it more explicit when somebody is serving in one role or another.
Diagram of our structure
Here's an Excalidraw diagram with a draft structure for 2i2c. It represents our current thinking about how 2i2c is structured and where our team members interact with one another.
Site Reliability Engineering
Ensures that our cloud infrastructure is resilient, reliable, scalable, and that we have a fast velocity of deploying new changes into production for all of our communities. Our PagerDuty workflow is a part of this team.
For example, here's GitLab's description of an SRE engineer, and here's the Google SRE description of SRE teams and their SRE engagement model.
Goals:
Roles:
Systems they oversee:
Current people:
Software Development
Implements user-facing enhancements to technology via software engineering. They do their work either in upstream repositories, in our infrastructure repository, or in dedicated repositories. This work is then deployed into production for all of our communities via our SRE team. For example, the development work around "launch user sessions in multiple clouds" or "binder functionality in JupyterHub".
Goals:
Roles:
Systems they oversee:
Current people:
Product Management
Guides the direction of our service and development by understanding the perspective of the communities that use our service and how their needs fit into the impact we wish to have. This team is responsible for communicating with and understanding the perspectives of stakeholders, and synthesizing new ideas. Examples of this work are the interviews that @jmunroe has had with groups like Toronto, or the UX research around Binder-in-JupyterHub that @consideRatio and @sgibson91 are doing.
Goals:
Roles:
Systems they oversee:
Current people:
Community Guidance
Assists communities in using our infrastructure in order to accomplish their goals. They must understand the kinds of problems that our users are trying to solve, and must know how cloud infrastructure could be leveraged to help them. They should focus their efforts on "training the trainers" and guiding community leaders to learn and share best practices. They also make connections between communities to grow networks.
Goals:
Roles:
Systems they oversee:
Current people:
Partnerships
Identifies and grows new partnerships for our organization in order to both increase our impact as well as increase our sustainability. They identify opportunities for impact and sustainable growth, implement systems and practices that take advantage of those opportunities, and oversee the operations of those systems once they are in motion. Their job is to consider the financial sustainability of our organization and how it relates to our impact.
Goals:
Roles:
Systems they oversee:
Current people:
Team Operations
Oversees our system of work and collaboration, our processes for planning and coordination, and the connections between all of our other teams. Its goal is to ensure that 2i2c has a healthy and efficient asynchronous work culture, and that we are reliable and consistent in our planning and progress. This team works cross-functionally and should have visibility into many parts of the organization as part of its work. It should identify opportunities to improve our cross-team processes and facilitate the flow of information and work within and between teams, if needed.
Goals:
Roles:
Systems they oversee:
Current people:
Upstream Support
The job of this team is to provide upstream support of various kinds to the open source communities that we depend on. This work is driven by the needs of those communities, not by the needs of 2i2c or any of its teams. If you are working with a support team hat on, you are working for the open source community, on 2i2c's time. Examples of this are @sgibson91's time working as strategic lead in JupyterHub, or @GeorgianaElena's time mentoring Outreachy interns. Generally speaking, we use this team to note when team members will have reduced capacity for direct 2i2c work so they can focus part of their time elsewhere. We don't use this team for small upstream improvements and interactions here and there - we assume everybody is participating in upstream work as a part of their 2i2c jobs. But anything exceptional (e.g. dedicating an extra day a week to a specific upstream need) we do as a part of this team.
Goals:
Roles:
Systems they oversee:
Current people:
who knows probably too much%)References
Relevant Pull Requests