--- layout: handbook-page-toc title: Plan:Project Management Backend Team --- ## On this page {:.no_toc .hidden-md .hidden-lg} - TOC {:toc .hidden-md .hidden-lg} ## Plan:Project Management backend team The Plan:Project Management backend team works on the backend part of GitLab's [Project Management category] in the [Plan stage]. For more details about the vision for this area of the product, see the [Plan stage] page. From an engineering perspective, we are also responsible for the [code backing our GraphQL API][graphql]. This does not mean we own everything about the API - each team is responsible for implementing its own resources in GraphQL - but we are responsible for the overall stewardship of this API. [Project Management category]: /handbook/product/categories/#project-management-group [Plan stage]: /direction/plan/ [graphql]: https://gitlab.com/groups/gitlab-org/-/epics/711 ### Team members <%= direct_team(manager_role: 'Engineering Manager, Plan:Project Management') %> ### Stable counterparts <%= stable_counterparts(role_regexp: /[,&] (Plan(?!:)|Plan:Project Management)/, direct_manager_role: 'Engineering Manager, Plan:Project Management') %> ### Hiring chart This chart shows the progress we're making on hiring. Check out our [jobs page](/jobs/) for current openings. <%= hiring_chart(department: 'Plan:Project Management BE Team') %> ### Team metrics dashboard We have a [metrics dashboard for the Plan:Project Management backend team][dashboard]. This is intended to track against some of the [Development Department KPIs][kpis], particularly those around merge request creation and acceptance. Below is a single metric from that dashboard: [MR Rate][mrs-per-engineer], scoped to this team.

[dashboard]: https://app.periscopedata.com/app/gitlab/570334/Universal-Engineering-Team-Metrics-Dashboard [kpis]: /handbook/business-ops/data-team/metrics/#development-department-kpis [mrs-per-engineer]: /handbook/engineering/development/performance-indicators/#mr-rate ## Work You can see how we work as a stage at the [Plan stage page]. For the backend team specifically, we use the standard GitLab [engineering workflow]. To get in touch with the Plan:Project Management backend team, it's best to create an issue in the relevant project (typically [GitLab CE]) and add the ~"group::project management" label, along with any other appropriate labels. Then, feel free to ping the relevant Product Manager and/or Engineering Manager as listed above. For more urgent items, feel free to use [#s_plan] on Slack. [Plan stage page]: /handbook/product/categories/plan/ [engineering workflow]: /handbook/engineering/workflow/ [GitLab CE]: https://gitlab.com/gitlab-org/gitlab-ce ### Capacity planning <%= partial("handbook/engineering/development/dev/plan/capacity_planning") %> #### Planning rotation <%= partial("handbook/engineering/development/dev/plan/planning_rotation") %> #### Historical Capacity <%= partial("handbook/engineering/development/dev/plan/historical_capacity", locals: { chart_ids: [7693808] }) %> ### Picking something to work on The [Plan:Project Management Build board] always shows work in the current release, with [workflow columns] relevant to implementation. There is an additional column to show in-progress community contributions. Filtering it by ~backend shows issues for backend engineers to work on. It's OK to not take the top item if you are not confident you can solve it, but please post in [#s_plan] if that's the case, as this probably means the issue should be better specified. [workflow columns]: /handbook/product-development-flow/ ### Working on unscheduled issues Everyone at GitLab has the freedom to manage their work as they see fit, because [we measure results, not hours][results]. Part of this is the opportunity to work on items that aren't scheduled as part of the regular monthly release. This is mostly a reiteration of items elsewhere in the handbook, and it is here to make those explicit: 1. We expect people to be [managers of one][efficiency], and we [use GitLab ourselves][collaboration]. If you see something that you think is important, you can [request for it to be scheduled], or you can [work on a proposal yourself][iteration], as long as you keep your other tasks in mind. 2. From time to time, there are events that GitLab team-members can participate in, like the [issue bash] and [content hack days]. Anyone is welcome to participate in these. 3. If you feel like you want to have some specific time set aside, but aren't interested in the topics of an existing event, feel free to label issues with "For Scheduling" and copy your manager for visibility. When you pick something to work on, please: 1. Follow the standard workflow and assign it to yourself. 2. Share it in [#s_plan] - if not even more widely (like in #development or #backend). [collaboration]: /handbook/values/#collaboration [results]: /handbook/values/#results [efficiency]: /handbook/values/#efficiency [iteration]: /handbook/values/#iteration [request for it to be scheduled]: /handbook/engineering/workflow/#requesting-something-to-be-scheduled [issue bash]: /community/issue-bash/ [content hack days]: /handbook/marketing/corporate-marketing/content/content-hack-day/ ## Useful links * [Plan:Project Management Build board] - this shows work in the current release * [#s_plan] in Slack * [Recorded meetings][youtube] * [Retrospectives][retros] * [Group Conversations] (archive; group conversations now happen at a the [section level]) [Plan:Project Management Build board]: https://gitlab.com/groups/gitlab-org/-/boards/1285239?label_name[]=backend [#s_plan]: https://gitlab.slack.com/archives/s_plan [youtube]: https://www.youtube.com/playlist?list=PL05JrBw4t0KoceqcTneOVmAzhEp6NinY0 [retros]: https://gitlab.com/gl-retrospectives/plan/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=retrospective [Group Conversations]: http://gitlab-org.gitlab.io/group-conversations/plan/ [section level]: /company/team/structure/#organizational-structure