Presentation: Everyone Can Contribute: Making Support Effective Through Contributions

Everyone dreams of talking to someone who can solve their problem. Opening up ways for Support team members to contribute to documentation and code will improve the customer experience and the company’s efficiency and we can prove it!.

Presented at Support Driven Expo 2022.

Hi Everyone, thanks for joining. My name is Cynthia Ng, although most people know me as Arty. I currently work at GitLab as a Staff Support Engineer.

Before I get into the presentation itself, I want to quickly thank everyone involved in organizing Support Driven Expo. I was excited for my talk to be accepted, and happy to be here presenting for the first time at Support Driven Expo.

About me

Anyone who has looked at my resume might wonder why I’m here talking to you, and on a management topic at that, so I wanted to give a brief introduction about myself.

While this is the first role where I’ve had the word “Support” in my title, I’ve worked in numerous customer service related positions. I started originally in retail, worked at the government tax benefits call centre (which was probably some of the hardest customer service work I’ve ever had to do), got my degree and became a teacher, got my master’s and became a technology librarian, before most recently becoming a Support Engineer.

While I’m not currently a manager, I do have management experience from previous roles. I’ve been at GitLab for a little over 4 years, and my current role as Staff Support Engineer is the same level as a Manager, meaning I help lead the team but don’t have direct reports.

I’ve also contributed to many open-source projects over the years, especially in documentation, being a long time Documentarian.

Fun fact: I like cute animals, and I clearly can’t do a presentation or blog post without inserting at least one cute animal picture. So have a red panda, one of my favourites!

GitLab

As well, I want to provide just a little bit of context on GitLab.

GitLab, itself, is a comprehensive platform that helps people collaborate and develop software faster. Think of it as a single platform to code, test, package, and release software.

The company, as of Oct 2022, is comprised of over 2000 team members spread across over 60 countries and regions, and all work fully remote.

The Support team has a handful of Support Operations team members, and globally over 130 team members in Support Engineering including both Engineers and Managers.

Making Support (more) effective

So you came here because you want to learn more about making Support more effective.

Let’s start with some questions:

[in-person: ask for hands]
* Do you work in Engineering?
* Do you have a Support team?
* Do you have a backlog?
* Do you want to increase your velocity?

If you said yes to any of these, then to make Support more effective, one answer is to:

Have your Support team contribute docs & code!

Common blockers

It seems like there are two common blockers:

The first is that:

Support teams don’t have write access to docs.

And the second is that:

Support teams don’t have read or write access to code.

So if…

Everyone dreams of Support fixing their problems

Where do we start?

Part 1: Give your team access

No surprise that the first step is to get Support access.

Clearly, you’ll need to talk to your Development or Product team, or both. Try to get as much access to as many projects as possible for Support to contribute changes.

Support Engineers want to find out why things don’t work, and if they can see it, they may be able to fix it.

In a lot of organizations, getting access will likely be half the battle, but not always.

In one organization I worked in, the only reason no one outside of the small Development team we had could see the code was that there was no way to do it. The code base was stored on a server that a developer’s code editor would connect to. All it took was setting up our project and issue tracking system to load a copy of the code for everyone else to at least be able to see the code.

Part 2: A well-defined review workflow

This second part, which may not happen after the first as it’s likely part of the resistance for opening up access, is building a system and workflow that Development can trust in.

You’ll need to design or ensure there’s a process where anyone can propose a change, and have it reviewed. Most likely, the Development team, or Technical Writing team in the case of documentation, would be the primary reviewers, and be the ones to accept or reject changes.

The main thing is making it easy for Support to contribute.

At GitLab, we’re lucky to have a well defined merge request and review workflow, which applies to both internal and community contributions, and both code and documentation contributions. The text may look lengthy, but if you look at the basic process and especially once you get used to it, it’s not complicated, as it boils down to submitting the changes, having the relevant people review it, applying changes based on their feedback, getting it reviewed again until the reviewers are satisfied. We also have ways for contributors to get help if they need it. For internal contributors, there isn’t a formal coaching system, but that’s something you might want to consider.

To make it easier, Support created self-paced training modules to provide a slightly more guided experience for those wanting to make contributions.

Part 3: Avoid the small things ending up in your backlog

Once such a system is in place, hopefully it means you skip the process of having Support file the bug, have product and engineering schedule it (at the expense of other work, usually feature work), fix it, and for Support to find out later; and instead, have Support submit the fix (and even send a link to the customer if you have a public code base), it gets review, and merged.

As a result, the number of issues that Support submits will shrink, and you avoid having those issues ending up in an ever growing backlog.

Admittedly, we could be doing a better job ourselves, but right now, our team for example, submits anywhere from 50-80 merge requests a month to the main GitLab project. We have some other projects which are not included here, so the number is a little lower than the reality.

If you want a trendy buzzword to go with it, this means you can “InnerSource”.

Focus

With any product or platform, bugs slow down feature development, and decrease shipping velocity.
So, why not outsource some of your bugs to the Support Engineering team?

Have:

Support focus on bugs.
Development focus on features.

That’s not to say the Development team would never fix bugs, but the more issues the Support team fixes, the more the Development team can focus on features.

Alright, so we have an idea of how it might look, but how do we get Support team members to work on these issues?

Build it into Support

It may seem obvious, but you’ll need to provide and budget for the time and space for Support to take on the responsibility of doing fixes, whether that’s code or documentation. I know that’s not always easy to do.

You may need to start with a small number of team members and gather data to convince Support higher ups that it’s effective. As you explore contributions, your data might include customer satisfaction, average time to fix compared to similar issues, the number or weight of fixes, and how much time or effort that’s saving in product planning and development time. You can also include select customer quotes from tickets where they were happy about getting a quick fix.

There is a chance that the people you have hired are not interested in doing contributions, but I actually suspect most would be. People tend to join Support to help people fix problems!

Likely the most obvious way to build contributions into a Support team is to make it part of the role. Both the list of job responsibilities and an individual’s performance review should include contributions.

The majority of Support folks that I’ve spoken to say that documentation updates are a part of their role, so it may not be a big stretch for them to make code contributions.

You can also include training on making contributions in your onboarding. Almost 2 years ago, at GitLab, we created some self-guided training on how to make documentation contributions and added it to Support’s onboarding. We also have separate training available for those wanting to start doing code contributions, but it’s not required as part of onboarding.

One way to make it clear that contributions from the Support team are key to the company’s success and to provide visibility into Support contributions, is to have a contribution measurement as a Key Performance Indicator (KPI).

At GitLab, we measure the number of merge requests per Support team member. As you can see, we tend to be somewhere between half and just under 1. The number fluctuates and tends not to increase, because as we add more team members, we need to make more merge requests to keep the number the same, though we’re targeting a higher number, so we have some work to do ourselves.

We have also been reviewing other numbers, such as the percentage of total merge requests made in GitLab platform related projects, but we haven’t decided on what the value of tracking other metrics might be, so for now, this is the only one we have as a KPI.

Examples

Making code contributions often sounds “scary” for those without a development background, but those less experienced with programming could start with simple fixes.

In this first example, you can see it was just updating an incorrect link.

This second one involves updating a text string to better explain a particular option when creating a specific type of token.

Getting into the code itself a bit more, this third example updates when new lines are added to a specific error message banner.

And this last example, I have here, involves passing an issue number to a code change request (or merge request as we call it) so that the description will automatically include the issue number. It’s actually the behaviour we expect, but a bug surfaced where that stopped happening, so one of our Support Engineers fixed it.

Of course, those with more experience can contribute more complex changes, especially if someone has development experience.

So, depending on the role and your organization, you may want to make contributions required, but not necessarily make code contributions required, meaning Support team members would at least be doing documentation contributions. Code contributions could also be required at a higher level of the role, such as a Senior level.

If that’s not enough for you, here’s what some of our Support team members had to say:

From Greg:

I’ve seen minor contributions to the documentation directly deflect tickets, make answers frequently asked support questions publicly available/discoverable, and even mitigate or avoid customer emergencies. […] I estimate each time the upgrade docs are updated by a Support team member, at least a dozen future support emergencies are mitigated.

I think that last part speaks for itself.

From Anton:

If a docs or code contribution I write helps a customer or another team member troubleshoot a problem in a more efficient manner on their own or it resolves their problem completely, that’s a win for me. It’s a very satisfying feeling knowing that something you did is improving the efficiency and user experience for everyone else.

From Łukasz:

Having your code or docs update reviewed is an excellent learning experience that leads to a much greater, low-level understanding of the product and its components. If this doesn’t make us more effective Support Engineers, I don’t know what does.

How do we make Support more effective?

We started with asking: how do we make Support more effective?

And my one take away for you is the simple answer of: