Improving Service Engineer onboarding period

After nearly one month as a new Service Engineer, I feel obliged to share my experiences with the current onboarding process. I understand that the Service Engineering team is only just experiencing growth and this is new for everyone, so this will be a gradual and somewhat experimental process.

As Service Engineers, we need to know a lot about the product. On customer calls (especially) and tickets, we can be asked anything and everything about the product and we should be prepared. No-one can know all of the answers and we should feel that we are able to say "No" or "I can find out the answer" to certain queries, but that's a lot harder when on the phone to someone demanding Support, right now.

I want to make the learning experience for those Service Engineers coming after me as enriching as possible, to empower them with all of the information that they need to provide our customers and users with the Support experience that they deserve. The current GitLab University syllabus goes some of the way towards helping with this, but falls short with the assumption of a firm grounding in both Systems Engineering and Ruby on Rails development experience.

Right now, I feel that Service Engineers are asked to know too much, too soon. The documentation is a really great resource, but we are not asked questions relating to the answers found in the documentation. In my experience, tickets are extremely varied and rarely relate directly to the product, rather the Customer's underlying infrastructure, answers that can't be found in code. I also found that the Service Engineer onboarding process was largely not followed and needs to be reworked. As my background is largely in Web Development and Web Application Support, my personal struggle is of a System Engineering theme. Such as dealing with topics like external databases, SSL and firewall configuration and customer's wanting to deviate from the suggested installation recommendations along with High Availability topics. None of which are prerequisites for the role, or can be found in the documentation, or will be taught in the current onboarding phase.

To improve the process, I propose that there be a ramp up period in which "Starter Service Engineers" will primarily field User (Community Edition and GitLab.com) Support Requests via tickets relating to all current SLA3 and SLA4 levels during their onboarding phase. This will provide ample time to ask questions whilst they learn, and to understand the intricacies of the product and the many platforms upon which it can be deployed. All the while, learning from and contributing to plugging the holes in the relevant Product documentation as they go. This should remove the need for more experienced Service Engineers to be concerned with the lower priority channels and focus only on Customer tickets and aiding the transition for newer members of the team. In this stage, Service Engineers should begin to be present on calls with Customers for training and upgrades to learn even more to ready them for the next stage.

After graduating this phase, I propose that Medium level Service Engineers begin to triage Customer tickets with the ability to escalate difficult ticket to their more experienced peers via suitable groups in Zendesk. Providing yet another learning platform to gain more knowledge of the product. These Service Engineers will be able to deal with most customer requests, the number of escalations required decreasing with knowledge acquired. Service Engineers at this level should be comfortable with the training regime, carrying out upgrade calls and answering tickets as a Dedicated Service Engineer.

Graduation from this stage will allow the Engineer to work on Security and Emergency tickets dealt with by the Senior and Lead Service Engineers and escalations from less experienced team members.

Something similar to this is touched upon in the Service Engineer onboarding handbook pages. I found myself working on SLA2 level tickets at the end of my first week. I don't feel that this is the right time scale for graduation to responding to Customer level tickets. I feel that the timeframe for graduation to the different stages will differ for each Engineer, based on their familiarity with GitLab and their experience in the above domains.

@MrChrisW @cabargas: Please could you also add comments with your experiences in your initial phase, and where you agree and disagree @balameb @dblessing @patricio @kelvinmutuma @ernstvn: I'd also really welcome your feedback here

Thanks @markglenfletcher for this candid review; it is very helpful, and it is also in line with the conversations I recall having with the team not so long ago.

In particular, you recommend:

To improve the process, I propose that there be a ramp up period in which "Starter Service Engineers" will primarily field User (Community Edition and GitLab.com) Support Requests via tickets relating to all current SLA3 and SLA4 levels during their onboarding phase. This will provide ample time to ask questions whilst they learn, and to understand the intricacies of the product and the many platforms upon which it can be deployed. All the while, learning from and contributing to plugging the holes in the relevant Product documentation as they go.

That was indeed the intent. So if we need to improve the syllabus / documentation on where one is expected to start to reflect this, then hopefully that is straightforward to do. Indeed, you also write that the syllabus was largely not followed in your ramping up... I'd welcome @balameb 's view on whether that was due to special circumstances or because the syllabus does not feel right yet, or some combination of the above.

You also write that you found yourself working on SLA 2 tickets at the end of your first week: perhaps that was a little too ambitious on our part :-) Is this graduation timeline something that can be codified in the form of a knowledge based test?

Finally, you raise a key issue:

The documentation is a really great resource, but we are not asked questions relating to the answers found in the documentation. In my experience, tickets are extremely varied and rarely relate directly to the product, rather the Customer's underlying infrastructure, answers that can't be found in code.

(emphasis added)
That's a bigger deal IMO. Is this observation borne out by the ZenDesk tag statistics on the nature of questions? Can we attempt to cover more infrastructure questions in our documentation, or is it a never-ending rabbit-hole? I'm not sure what the best approach is here; but do feel that we should always strive to make the answers widely available beyond the brains of our most experienced Service Engineers.

\cc @stanhu

By the way... any particular reason you chose to make this issue confidential @markglenfletcher ?

Made the issue visible

I actually meant to remove that. Now visible

@markglenfletcher thank you very much for sharing your thoughts. I'm glad you feel comfortable sharing them and being so candid with them. This is exactly the kind of interaction we want from the new Team Members.

I very much agree with you on all your points. The GLU training path just got added a few months ago, right before you, @MrChrisW and @cabargas joined. So there is still a lot we can improve there. I like what you describe about a more clearer path for ticket escalation. With a system like that in place, we can make sure that all customers get a timely answer with less back and forth.

@ernstvn You mention:

Can we attempt to cover more infrastructure questions in our documentation, or is it a never-ending rabbit-hole?

We can certainly add more infrastructure documentation on the most common setups, but given all the possibilities on how you set up and configure GitLab, it can certainly become a rabbit-hole.

@markglenfletcher I agree with all the points you've raised. - Excuse the copy/paste and please let me know if anything is missed. The main changes revolve around updating the support structure and documentation/training improvements.

The following are the main points I'm getting out of this.

• Service Engineers are asked to know too much, too soon.

• Service Engineer onboarding process was largely not followed and needs to be reworked.

• Support structure needs to be implemented, consisting of

  • Starter level: Primarily field User (Community Edition and GitLab.com) Support Requests via tickets relating to all current SLA3 and SLA4 levels.

    • Service Engineers should begin to be present on calls with Customers for training and upgrades to learn even more to ready them for the next stage.

  • Medium level: begin to triage Customer tickets with the ability to escalate difficult ticket to their more experienced peers via suitable groups in Zendesk. - These Service Engineers will be able to deal with most customer requests, the number of escalations required decreasing with knowledge acquired

  • Senior level: Graduation from this stage will allow the Engineer to work on Security and Emergency tickets dealt with by the Senior and Lead Service Engineers and escalations from less experienced team members.

---

Are we able to build a list of tasks/actions around improving these items? I've got something started in #35 - Ideally it would be good to see people responsible for each item and milestones as suggested by @balameb

@markglenfletcher Thanks for bringing this up. Also, what other training would be useful aside from trial-by-fire? Can we use include materials in GLU that would help? Would some sort of FAQ/knowledge base or quiz of commonly-asked questions help?

We also need more materials like this: https://delftswa.gitbooks.io/desosa2016/content/gitlab/chapter.html

mentioned in issue gitlab-org/University#17 (closed)

Milestone changed to %Onboarding and decreased demand

mentioned in merge request gitlab-org/University!28 (merged)

Status changed to closed by merge request gitlab-org/University!28 (merged)