Propose Core Platform internal opportunities pilot process
Why is this change being made?
We don't have a well-defined process to connect interested team members with available opportunities. For example, sometimes we execute borrow requests where specific engineers are targeted for assignment and there is no opportunity for other engineers to express interest. We can encourage engineers interested in a move to look at job postings. But there could be other opportunities for temporary assignments or exchanges if we had an overview of interest across the organization. This MR proposes a lightweight process for connecting team members to opportunities for us to pilot in Core Platform.
Author and Reviewer Checklist
Please verify the check list and ensure to tick them off before the MR is merged.
-
Provided a concise title for this Merge Request (MR) -
Added a description to this MR explaining the reasons for the proposed change, per say why, not just what - Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
-
Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI) - If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the
Maintained by
section on the page being edited - If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
- The when to get approval handbook section explains the workflow in more detail
- If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the
-
For transparency, share this MR with the audience that will be impacted. -
Team: For changes that affect your direct team, share in your group Slack channel -
Department: If the update affects your department, share the MR in your department Slack channel -
Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR - For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter
-
Merge request reports
Activity
assigned to @nhxnguyen
@DylanGriffith I drafted this MR based on our conversations about helping team members find other opportunities within the organization. Would love your feedback before passing along to others.
requested review from @DylanGriffith
- Resolved by Nick Nguyen
- Resolved by Nick Nguyen
@nhxnguyen this seems like a great lightweight process to start with. I'd love to see this implemented and then I guess the managers involved might have some ideas about how to improve the process over time.
removed review request for @DylanGriffith
requested review from @cdu1
- Resolved by Nick Nguyen
- Resolved by Nick Nguyen
@nhxnguyen I like that we're formalizing the process here! This may be for a later iteration on this doc, but I'm wondering if we would want to add some more specifics for the different types of internal transfers like a borrow vs. permanent change of team as the process and expectations may be different depending on the type. Also, some team members might be interested in a temporary change to learn some new domain, but would not want it to become permanent, while others may be interested in checking another team and open to it eventually becoming a permanent change.
- Resolved by Nick Nguyen
@nhxnguyen I think it's great we are trying to pilot a program that gives people an opportunity to develop and grow. Lack of career and learning opportunities can exacerbate attrition of talent. Some general question I have though ...
- What criteria would the individual have to have in order to participate in this pilot?
- Performance rating, i.e. would lower performers be allowed to participate?
- Length of time in current role, i.e. how long would one need to be in their current role before they can try a stretch assignment?
- Suitability of skills, experience, team fit, for the new role; would this be a conversation between old mgr, new mgr?
- What happens to the work the individual was doing on the lending / sending team? Does others need to absorb the work they are leaving behind, or is the participant expected to do two jobs during the Stretch assignment?
- What happens after the Stretch assignment is over? Do they just go back to their old team? If they permanently stay in the new team, does the old team get a backfill headcount?
Edited by Rick Mar - What criteria would the individual have to have in order to participate in this pilot?
- Resolved by Nick Nguyen
@nhxnguyen I think the question about interviewing is an interesting one. It might be something where people feel that things are arbitrary or unfair if we just leave this up to managers to decide if and when an interview would be necessary for a transfer.
But from a different perspective I feel like requiring people have multiple interviews to change roles is pretty intimidating and somewhat in conflict with "generally support moves between teams". From my experience at GitLab I've moved teams multiple times and I only ever once had to do an interview because I was moving from a manager role to Staff engineer. The interview as only for levelling purposes but it was assumed I could move over at least as Senior in any case. But outside that I've moved teams a few times without interviewing. I also think that other companies where they have a culture of internal mobility there wouldn't likely be such a formal process for moving teams.
I can appreciate though from a manager perspective it might not sound great to hear that they'll just be given new team members to fill an open position and can't even interview them to see if they're a good fit.
Edited by Dylan Griffith
- Resolved by Nick Nguyen
Thanks for sharing this and solicit feedback @nhxnguyen and @cdu1. Here are my two cents:
It seems like the objective is to increase awareness of opportunities to those who might be interested and otherwise would lose on the opportunity. The proposal seems to place the initial action on those interested to explore new areas, and then for their managers to share this and ask if those teams have any opportunities or are interested int getting this person involved.
I personally feel that this way is backwards. I would propose that instead, when opportunities emerge, these are posted (by the manager that owns the opportunity and is in need of help) on a visible board where all interested parties can see them . During the staff meeting, we could review together those emerging opportunities and share them with our respective teams. Then, those people who have an interest could have a conversation with their manager to see if it is the right time and if they are able to seek the opportunity based on that conversation.
This would ensure we only move people around when there is a true need and when the interested party is in the right place for them to leave their team. I suspect that asking any team's manager if they would like to have an extra pair of hands, the answer more likely would be yes, even if the need was not initially there.
I suggest we also separate the mechanism to increase awareness of opportunities from the process to apply, review and approve the transfer. The transfer itself should follow a specific process depending on the type of opportunity. These processes are already defined; e.g. Borrow request, Internship or permanent transfer.
- Resolved by Nick Nguyen
- Resolved by Nick Nguyen
- Resolved by Nick Nguyen
- Resolved by Nick Nguyen
mentioned in commit d53f2f58