Fulfillment frontend team and the Fulfillment groups
What's the problem?
The Fulfillment Purchase Frontend team isn't really the Purchase Frontend team as it's handling Frontend work for the Purchase, License, and Utilization groups.
Project work by groups is sporadic. This is further exacerbated because we're often working on revenue impacting changes. This means that between milestones the group with the highest priority project gets the majority share of the Frontend team allocation. This means that some milestones the other groups can be neglected.
Pros of current situation
- The frontend team is working on the most important project for the Fulfillment department
- Increases the ability to execute on larger projects
- The frontend engineers in Fulfillment are in the same team. Makes it easier to communicate and collaborate as we work closely
Cons of current situation
- Always working on the highest priority leaves little downtime for technical debt, non-critical features, and developer experience improvements
- Groups in Fulfillment can't reasonably estimate how much frontend allocation they have in the future
- Alignment between the Frontend team and the various groups suffers - creates distance between frontend and backend
Prior related discussions
- https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/163
- https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/198
- gitlab-com/www-gitlab-com#10558 (closed)
How are other departments handling this
The Fulfillment Purchase Frontend team isn't the only frontend team in GitLab that's in this position.
Discussion during Frontend Managers Office hours
Video - discussion on this topic starts at 13:19 ends at 24:58 Meeting agenda
Secure
Similar to what Fulfillment is doing except the groups each have a separate backlog and the frontend teams pick from them
- 4 groups, turning into 3 soon as 2 are merging
- Good projects with tech leads has helped a lot
- To combat siloing - pairing sessions and rotate through every few milestones
Plan
1 frontend team and 2 groups.
- Engineers are dedicated to groups
- Encourage engineers not to do a formal swap, but make it so they can pick up work from each group
Verify
Several engineers in FE: Verify but they're all dedicated to their respective groups.
- 4 groups
- If the EM can't make a meeting it's clear which engineer should cover in that case
- Moving from one group to the other means a formal move
Solutions (very much WIP)
Some factors to keep in mind
- How many backlogs, location, and ownership of backlog is a big factor
- Where we split increases (and decreases) distance - splitting between frontend and backend (our current setup) makes frontend engineers work more closely together but alignment between frontend and backend suffers. Splitting across groups means that shared frontend technical debt and frontend infrastructure comes with more overhead. Splitting across groups also creates distance between frontend EM and engineer
- Which piece of work belongs to which group in Fulfillment is pretty blurred
Keep things as is
- 1 Frontend team
- 3 Backend teams
- PMs agree on ranking priorities across the stage and where frontend is mainly focused
We're feeling the pain of the current setup, but it's got the upswing that high priority projects get a lot of attention. The other solutions might seem better but there's no silver bullet here, there will be some trade-offs no matter what we do.
Rotate frontend engineers across groups on a X milestone basis
- 1 Frontend team
- 3 Backend teams
- Groups own their own backlog and know how many frontend engineers they have allocated each milestone
Rotating engineers to combat creating silos or some part of the codebase to slowly evolve into a completely different thing.
Each group gets a dedicated frontend engineer
- 1 Frontend team
- 3 Backend teams
- PMs agree on ranking priorities across the stage and where frontend is mainly focused
1 frontend engineer dedicated to each group. The 3 frontend engineers will put a high priority on their groups work and advocate for frontend direction for their group. The non-dedicated engineers would then rotate their work between groups depending on the highest priority in Fulfillment
Split the frontend team across the groups
- 3 frontend + backend teams
- Groups own their own backlog
Ala Verify. Frontend engineers report to the same frontend EM, but they are dedicated to a group.
Dissolve the frontend team
- 3 cross-functional (?) teams
- No frontend team
- Groups own their own backlog
Same as above but engineers will start reporting to the EM of that team. This is a step towards cross-functional teams.
Trade-offs table
type | BE <> FE alignment | own backlog | capacity balance | knowledge expertise | FEM | avoid silos |
---|---|---|---|---|---|---|
Dedicated FE | - | - | - | - | - | |
X-functional | - | - | ||||
Split teams | - | |||||
Rotation | - |
Note: capacity balance means that each group would be able to plan a fair shared amount of weight each milestone.