How do you build trust before you ever interact with others? A public handbook! Having a handbook publicly available provides lots of benefits including consistency for the team, being literally on the same page as a customer, and providing the opportunity to collaborate with others, such as the Support community.
Presented at Support Driven Expo 2023.
Note: Links are in the slides.
Intro
Hi Everyone, thanks for joining. My name is Cynthia Ng, although most people know me and you’ll find me on the Support Driven Slack 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 also have to thank the community for asking about public handbooks, which prompted me to think about proposing this talk. Thanks to Lizzie for encouraging me to submit the proposal, and to the events team for accepting.
As a quick note, I have a lot of links in the presentation for reference and examples. I’ll be making the slides available, so you’ll be able to get them afterwards.
GitLab
As I’ll be talking primarily about the public handbook at GitLab, I want to provide a little bit of context on the company.
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 mid-September this year, has over 2000 team members spread across over 65 countries and regions, and all work fully remote.
The Support team has over 130 team members globally including Support Operations and Managers.
Our Support team covers all of the different platforms that we have:
- Self-managed, which you might think of as the self-install or self-hosted version, where a customer downloads and installs GitLab on their own infrastructure.
- GitLab Dedicated, single-tenant SaaS, which basically means GitLab hosts an install for each customer
- SaaS which is GitLab.com
Normally, I don’t cover our offerings, but it’ll help for context.
And of course, no presentation of mine is complete without a cute animal picture, so here’s a tanuki, also known as a Japanese racoon dog, which is the basis for GitLab’s logo.
About me
Now a little about me. I’ll not bore you with a long bio, but for the context of this presentation, there are a few things I want to mention.
Everywhere I’ve worked, I advocated for good documentation. When I can’t get that documentation public, I’ve often blogged about the parts of my work that I could. I did it for many reasons, though primarily to record what work I had done, and to “pay it forward” by sharing my knowledge with others.
I started at GitLab over 5 years ago, and was hired specifically for the SaaS team. We don’t have separate teams for the different platforms anymore. However, this separation in my first 1.5 years did influence my work, especially around the handbook.
A handbook
Some questions to start
- Do you find yourself wanting to write things down?
- Do you have processes that need to be followed?
- Do you have workflows that are shared with another team?
- Do you have information that needs to be consistently shared?
These are of course very general questions, but hopefully they get you thinking.
What is and why a handbook
To make sure we’re on the “same page”, let’s define what we mean by handbook.
Wikipedia says:
“A handbook is a type of reference work, or other collection of instructions, that is intended to provide ready reference.”
Which is fairly general.
At GitLab, we define it using different words, but has the same basic idea:
“The handbook is the central repository for how we run the company.”
Honestly, to me that sounds like it could be almost any information that people need to refer to.
Why a handbook
If you can put anything in a handbook, why would you do it? What purpose would it serve?
Probably the most common reason is to have what we call a “shared reality”, where all team members have the same defined objectives and consume the same information to bring those objectives to reality. To store and maintain that shared information, you need a “single source of truth” (SSoT). Depending on the type of information and its permanence, that’s not always going to be a handbook, but you should consider it the default. We’ll get into that a little more later.
Often when writing in long form, because we’re not sure who might end up reading it, we’re more likely to write with lower context.
“Low-context communication assumes that the person you’re communicating with has little or no context about the topic at hand.” – TeamOps
The lower context information allows for greater understanding for anyone who doesn’t already have in-depth knowledge of a particular topic, whether that’s a new team member, a team member who has never worked on the specific topic, or someone outside of the team.
Building on these, documented workflows enable a lot of other benefits.
- measurement clarity: allows a shared understanding of what you’re measuring.
- results standardization: allows for an agreement on how you’re measuring whether you’re achieving results.
- worker autonomy: means that team members are empowered to make decisions without permission or approval for things already in the handbook.
- efficient onboarding: is possible since you don’t need someone to walk through every new team member what to do in every case. There will always be some edge cases or things you hadn’t thought of, but for the most part, a new team member can learn and start working on things based on what’s documented.
- inclusivity: Having information written down allows a team member to work more at their own pace, and not feel like they need to note everything down for themselves. If there’s a video version of the information, then team members can also choose which way to absorb that information.
- continuous improvement: It’s easier to see and understand what might be missing, and needs to be updated.
- operational scalability: The more team members you have, the more important it is to have things written down to make things scalable.
“By providing a common reference point, these documented workflows enhance efficiency and consistency, ultimately leading to improved team productivity and outcomes.” – TeamOps
Why a public handbook
I doubt there would be much disagreement that there are a lot of benefits to having a handbook, and most likely, you already have something similar even if you call it something else.
So why a public one?
The reasons you would have a public handbook actually apply to why you would have an internal one as well, but I pulled out a few points that I believe are more salient to making it public.
Efficiency
Okay, I already mentioned efficiency, but remember at the beginning how I asked you whether you’ve ever had to frequently share something?
We often want to share with other organizations, and having a public handbook is a great way to do that.
Take this example from the Support Driven Slack #leadership channel where Mariana asked about creating a liaison role between support and product:
Mariana: Hey all! Any recommendations or best tips on how to create a role as a liaison between Support and Product? This would be someone on the Support team who meets with a product lead or manager to discuss any upcoming changes to our product, prepare support documentation to reflect these changes, and be the voice of the customer
[…]
Arty-chan: I’m not sure how much reading you want, but here’s the description on what we expect support team members that are product counterparts to do: https://about.gitlab.com/handbook/support/support-stable-counterparts.html
There is so much information and nuance to building a relationship with another department, but I could link Mariana to our public handbook page and let her know to ask any follow up questions she might have. This saves me time, and lets Mariana decide how much or little information she wants to take from it. If she did have follow up questions, I could also look at adding it to the handbook page to improve it and potentially answer those questions for anyone else in the future that might have them.
Having the handbook public means that you can also use search engines to look up content, which might help if the tool you’re using doesn’t have a good search. Of course, it means it’s searchable by others too.
Consistency
While a handbook provides consistency for the team, making things public means that you can literally be on the same page as a customer. Even if a customer might disagree with a process, they can see that it’s being consistently handled.
Transparent measurements
Transparent measurements: When your Key Performance Indicators (KPIs) and Objective and Key Results (OKRs) are public, you provide insight into what your organization cares about. You can make better connections when priorities and values align with others. Even better if you can not only describe the measurement, but also show how you’re doing. Especially if your team is meeting KPIs and OKRs, it can be a great selling point.
Operational transparency
While there are limits on the level of operational transparency that support can have outside of the company, with the handbook, if you can publish a list of changes or have those public in some other way, you can show how the team is constantly improving. For example, if a customer writes in about a process, and you make an improvement as a result, you can show the customer the direct impact they’re having.
In an article on Operational Transparency for the Harvard Business Review, Ryan Buell found that
“when people see the work going on behind the scenes, they value the service more.”
Collaboration
Naturally, collaboration improves within the team and your organization when you have things written down, but it can improve from public input as well. At GitLab, we have had community contributors submit improvements to our handbook numerous times over the years, and it’s always great to see.
Community Resource
Most of all, having a public handbook can be a great way to give to the community. A number of companies have a handbook, but it’s rare for information on how a Support team is run to be public.
Lizzie, our very own Support Driven Director of Events, mentioned in a comment that she’s found the public handbook helpful when working in Support.
I am SO EXCITED for your session!!! 🎉 🎉 🎉 I remember our convo when you mentioned it last year, and I am so glad you’re doing the thing. I know I’ve personally found the public handbook so helpful over the years when working in Support. <3
By the way, if you know of any other public handbooks, please let me know. I’m putting together a list.
Creating a handbook
Are you convinced yet? I think most people will agree that writing things down is ideal.
And, we now come to the all important question of: how do we create a handbook? Even if you already have one, depending on how well or consistently it’s used, some of these tips should still be helpful.
What you need
There are a few basic things that you need:
- Buy-in: You want buy in from as many people as possible, but at least the team that will be documenting things in it.
- Location / Version controlled tool: Obviously, you need to decide on what tool you’re going to use and where it will live. You want an easy to find place, and preferably use something your organization already has so it’s easier to expand. Ideally, whatever you use is version controlled, so it’s simple to compare and see changes: the author, the date/time, and the reason. The specific tooling doesn’t necessarily matter. At GitLab, our old handbook went from Middleman (Ruby based Static Site Generator) to Netlify (CMS), and our new handbook uses Hugo (Go based Static Site Generator).
- Easy (enough) to use: The easier something is to use, the more likely people will use it.
- Reinforcement: Putting things in a handbook needs to become a habit. For it to become a habit, you’ll need to reinforce the action by prompting when something should be added to the handbook. [Slide] One of our Senior Support Engineers says “If it’s not in the handbook, then it’s not part of the process.”
- Public by default (separate internal only): The handbook should start public, and be kept public. You’ll want to have something separate that is internal only for the rare cases that something really can’t be public. I can proudly say our Support team has only 1 page on our internal handbook, so it’s possible to keep most of the information public. We’ll come back to this.
- Start small and iterate: Last but not least: start small and iterate. If you’re making a new one, just start jotting things down. If you’re moving content, you can move one page or section at a time as you use it, and consider it an opportunity to review whether the content is up to date.
Just before I started at GitLab, we only had 25 Support workflow pages, 7 or 28% of which were SaaS specific. At last count, 5.5 years later, they have more than quadrupled to 109 Support workflows, with 37 or 34% of them being SaaS specific. Of course, the handbook as a whole has grown more than 10 times based on the number of pages.
The idea is that you grow the handbook over time. It doesn’t start completed, and really, it’s never complete.
Set expectations
To grow a handbook, you want to set clear expectations. We’ve covered some things, but let’s expand on them.
Encouraging contributions
We want to encourage contributions.
- Doesn’t need to be perfect: While it may be public, the audience of the handbook is still the team or company. The focus is to make sure other team members understand it, so it doesn’t need to be perfect, and we can always improve it with further edits.
- Invite collaboration on changes. Aside from version control, ideally the tool you use has a way for people to suggest changes and provide feedback before it makes it into the handbook. Especially if the tool doesn’t allow for that, you want to have some documented way for others to provide feedback.
- Have guidelines on what level of review is required: Related to that, one recommendation is to have guidelines on when a review is required. Fixing a typo shouldn’t need review. A small change might just need a peer review. More substantial changes might need a manager.
- Mark which pages are “controlled”: Similarly, there may be some controlled pages that require specific departments or individuals for approval to make changes.
- Have clear guidelines on what should be internal-only information, and in an internal handbook. At GitLab, we use what we call the “SAFE framework”. The framework outlines what we need to ask ourselves to determine if it’s shareable: S stands for sensitive, meaning if there’s material non-public information, A for accurate and verifiable information, F for whether there’s financial data, and E for whether sharing could have a harmful Effect. It might seem like having all these guidelines would hinder contributions, but we want to provide guidance so people know that it’s okay not to always need a manager’s permission, and that it’s okay to make things public.
- Not “set in stone”: It’s also important to encourage people to update the handbook, and make suggestions; that the handbook is not set in stone.
One of my teammates, Kenneth, explains:
It’s not “just a rulebook” that you follow blindly. Sometimes it might be wrong (because it was written by humans), but being able to see the discussions behind why something was added helps us to work out a way forward when we come to undocumented edge cases. (Of which there are many in the land of Support). – Kenneth Chu (Senior Support Engineer)
Build it into Support
Aside from reinforcing adding or updating the handbook when it comes up, and having guidelines on how to use it, realistically, the best way to signal that the handbook is important is to build it into the work.
- Provide & budget time: for people to contribute to the handbook.
- Onboarding: should include training on how to make changes to the handbook.
- Job responsibility and
- Performance review: should include keeping the handbook and other internal documentation updated.
- A Key Performance Indicator (KPI): for the team on handbook contributions is a great indicator of its importance.
Here’s a quick example of the KPI we have at GitLab, where we track the number of submitted changes by Support team members that make it into the handbook divided by the number of Support team members. You can see it varies month over month, but on average, we’re generally fairly close to target.
Take away
I know that was fairly general, so I’m happy to answer any questions about any specific aspect you’re interested in, or point you to a handbook page that already answers it! 😉
Personally, I have found it amazing what a public handbook can do. It’s normal to think about the internal benefits, but I’ve heard stories about how we’ve had companies that wanted to become customers because of our handbook. I didn’t talk about the impact a public handbook can have on recruiting, but our CEO once shared:
“Someone said I feel like I found my corporate soul mate after reading our handbook.” – Sid Sijbrandij
When talking about customers, another finding from the Ryan Buelle article is that:
“Transparency increases not only sales but also people’s trust and satisfaction.”
So, if I have only one take away for you, it’s that:
A public handbook builds trust
Thank you
Thanks for reading to the end!
Appendix: List of public Customer Support handbooks
Let me know if you’ve found one to add!
- GitLab: https://handbook.gitlab.com/handbook/support
- Sourcegraph: https://handbook.sourcegraph.com/departments/technical-success/support/
- Posthog: https://posthog.com/handbook/growth/customer-support