Scaling the Delivery team
Background
As the Delivery team grows and the variety of projects increases it makes sense to split the team to reduce communication channels and domain responsibility. To maintain the strengths of the team we will continue to have a mix of SRE and BE skillsets in each team.
A proposed split
After considering several options we're proposing two teams; one focused on creating deployment and release capabilities, and the other focused on providing a deployment platform for the application.
Team names to be decided. Please add suggestions!
Deployment System team
This team would be responsible for providing a deployment platform onto which the application can be effectively deployed.
Opportunities include:
- Application rollout management lifecycle on Kubernetes (Support for Blue/green deploys, deployment tooling)
- Cluster observability to support deployments
- Efficient cluster organization to allow for growth and efficient resource usage
Deployment & Release Orchestration team
This team would continue our deployment and release work with the goal of enabling stage groups to adopt self-serve deployments and releases.
Opportunities include:
- Support stage groups in moving to self-serve deployments.
- Fully automated processes for deployments and self-managed releases, including backport processes for patching to earlier versions
- Moving away from custom tooling to GitLab features
This split maintains interactions and strategy between the two teams but still gives each team a clear focus. As an example, observability is owned by the Foundations team but leveraged by the Orchestration team to handle automated deployments, automated rollbacks, and deployment self-healing. On the other side, stage groups’ self-service deployments are owned by the Orchestration team but they provide better observability and new data points to allow the Foundations team to improve resource efficiency.
Other options considered
- Self-Managed team & GitLab.com team - Teams focused on the needs of different groups of users. Creates a strong boundary between teams with little opportunity for vision sharing between the two.
- Squad-based teams - Changing groups of people formed to solve the highest priority projects. Creates short-lived teams and splits reporting lines from project groups.
- Timezone-based - Grouping teams based on current timezones. This creates an assumption that you need to be online when your teammates are.
What about Release Management?
To continue to meet the required levels of release management support with multiple, smaller teams we'll continue with a single release management rotation with people from both teams. Where possible we'll pair people from different teams to help with bonding and knowledge sharing.
Who will be in each team?
This is a suggestion of how we could work. We can adjust this, now, or in the future if needed. Please let your manager know if you have any concerns about the team split options.
|
Orchestration | Staff (Working with both teams) | |
---|---|---|---|
EM | Michele | Amy | |
SRE | Skarbek, Ahmad, "New Hire" | Graeme, Henri | |
BE | Reuben, "New Hire (Q3)" | Mayra, Robert, "New Hire (Q4)" | Alessio |
When will the split happen?
A rough order of tasks and timeframes for completing the team split:
- April 22 - Discuss proposed split and team names
- May 22 - Reporting lines updated + team structure (labels, issues, handbook) in place
- June 22 - Future project & issue organization completed
- July 22 - Individual team goals & direction finalized ready for Q3
Through Q2 we'll continue to work on the same projects as we have previously discussed (OKRs still to be finalized) and in the same groups as before. Q3 will be the goal for shifting to working in 2 distinct teams.
@gitlab-org/delivery for visibility and any comments you have