* The Principal Engineer role acts as the individual equivalent of a Senior Engineering Manager, Development.
* Extends that of the [Staff Frontend Engineer](https://handbook.gitlab.com/job-families/engineering/development/frontend#staff-frontend-engineer) or the [Staff Backend Engineer](https://handbook.gitlab.com/job-families/engineering/development/backend/#staff-backend-engineer) responsibilities
* Extends that of the [Staff Frontend Engineer](/job-families/engineering/development/frontend#staff-frontend-engineer) or the [Staff Backend Engineer](/job-families/engineering/development/backend/#staff-backend-engineer) responsibilities
* Collaborates and makes proposals across several teams on their engineering work, and helps their team members make informed decisions in alignment with the sub-department strategic plans.
* Exposes technology and organizational needs across their sub-department.
* Teach, mentor, grow, and provide advice to other domain experts, individual contributors, across several teams in their sub-department.
@@ -56,7 +56,7 @@ During the FCL, the team(s) exclusive focus is around [reliability work](#scope-
- Hold a synchronous `closing ceremony` upon completing the FCL to review the retrospectives and celebrate the learnings.
- All FCL stakeholders and participants shall attend or participate async. Managers of the groups participating in the FCL, including Sr. EMs and Directors should be invited.
- Agenda includes reviewing FCL retrospective notes and sharing learnings about improving code change quality and reducing risk of availability.
- Outcome includes [handbook](https://handbook.gitlab.com/handbook/) and [GitLab Docs](https://docs.gitlab.com/ee/) updates where applicable.
- Outcome includes [handbook](/handbook/) and [GitLab Docs](https://docs.gitlab.com/ee/) updates where applicable.
@@ -96,7 +85,7 @@ Every MR follows the applicable MR template. When a MR is ready for review, assi
#### Merge Request approval requirements
Because of quality and [security](https://handbook.gitlab.com/handbook/security/gitlab_projects_baseline_requirements/#mr-approval-rule-configurations) we require every MR to be approved before merged with multiple Team Members involved. By default the CODEOWNER file sets that an approval is needed and by who. But if a file or folder is not present in the CODEOWNER file a MR still can be merged without approval or without other Team Members involvement. To enforce the following 2 settings must be applied on each project within the [GitLab-Data Group](https://gitlab.com/gitlab-data/).
Because of quality and [security](/handbook/security/gitlab_projects_baseline_requirements/#mr-approval-rule-configurations) we require every MR to be approved before merged with multiple Team Members involved. By default the CODEOWNER file sets that an approval is needed and by who. But if a file or folder is not present in the CODEOWNER file a MR still can be merged without approval or without other Team Members involvement. To enforce the following 2 settings must be applied on each project within the [GitLab-Data Group](https://gitlab.com/gitlab-data/).
