ITO. AUM. Gigantor. Every company’s got ’em. Acronyms, internal terms, or code names that are specific to your company or perhaps your industry. For most employees, the sheer quantity of TLAs (three-letter acronyms) is overwhelming.

Here at Salesforce, we’ve been swimming in them.

It’s not that the terms weren’t defined anywhere. In fact, we had dozens of separate glossaries throughout the company in varying formats.

However, this didn’t help the problem. The existence of multiple glossaries and the number of unfamiliar terms was a pain point for employees. They were frustrated because they didn’t know where to find the answers, and which glossary had the most current and accurate terms.

I’m a writer on the Documentation Team at Salesforce, and this is the story of how we solved this problem.

The process and the principles behind the solution are universal, so my hope is that what we learned might help you in your projects. They might also inspire you to come up with a creative solution for your acronym overload.

Prioritize and Get Support

Here at Salesforce, we have something called PTOn which stands for “paid time on.” For employees in a technical role, this is time allocated to work on something that you’re passionate about that may be outside your regular work.

I proposed solving the problem of the wild acronyms as a PTOn project. I received my manager’s full support. This was key because it gave me the time and mental space to think about the problem.

When I considered the glossary problem, my first thought was that the solution had to be convenient for end users – otherwise, no one would use it. We live in Internet time now, so people give up after a few seconds of searching and remain frustrated.

We had lots of glossaries, but in spite of this, employees still had trouble resolving new terms. A new user wouldn’t know where to find a separate glossary: It may have been in a spreadsheet or part of a website.

As I pondered the problem, the idea of a tool that you could use from your browser seemed like the ideal solution.

Salesforce is a cloud company. So where are employees when they come across new terms? Typically in a browser.

Therefore, I started investigating browser extensions. I came across a Dictionary.com browser extension (for Chrome or Firefox). This extension allows you to look up terms in their dictionary from any web page. You just double-click the term and it pops up the definition from their dictionary, if there is one.

This seemed like the perfect paradigm for the glossary extension.

Collaborate to Get Expertise

I started to put together a simple document with requirements on how the glossary extension should work. I wanted to get feedback on what technologies were available to create this new tool so I asked Babu Naidu, a developer here at Salesforce that I had previously worked with.

He not only gave me the information, but offered to code it using his PTOn time! This was awesome news. On the graphics side, one of our experts on the Documentation Team provided the icons that show up in the browser and the menu.

This collaboration turned out to be invaluable. We were able to split the responsibilities and each focused on what we’re good at.

Iterate Towards Greatness

Salesforce is also an Agile company. This is our development methodology and it informs the entire culture of the company. We’re used to working in sprints and building discrete pieces of functionality to arrive at a final product; and this is how we approached this project.

Babu and I decided to start with a Chrome extension since that’s a commonly-used browser here at Salesforce. Then he went to work on coding it up. We felt that double-clicking the term wasn’t the best workflow; instead, the user would highlight a term on a page, right click and then select a menu item to look up the term. The definition is displayed in a pop-up window. Our goal was to get a working prototype and go from there.

We tried a few different implementation designs. Due to the way our internal systems are set up, we settled on a design in which the glossary terms are stored in a Google spreadsheet. When the user selects to look up the term from the right-click menu, the definition is displayed in a pop-up window.

For any geeks reading this, the pop-up window is rendered using AJAX. When the browser first opens, the spreadsheet is returned to the browsers in a CSV format, and this is then used to return the definition in the pop-up window. As we tested out new versions of the extension, we got ideas for refining the user interface and adding some new features.

Using this approach enabled us to take on pieces of functionality and complete them before moving on. For example, instead of rolling out the extension for multiple browsers, we prioritized the Chrome extension based on our knowledge of the users.

Roll Out Incrementally

After we had a working version, we did some QA on it and then had a small group of people install and use it. This was the equivalent of piloting a feature. We also had a security review and our internal security team gave us good suggestions.

My manager is a big believer in branding and she came up with the GlossaryHub name. I wrote up some installation instructions, and after it was tested and approved, we rolled GlossaryHub out to everyone in the company.

GlossaryHub was a big hit with everyone. The installation page received over 1,000 hits in the first two months. And the positive feedback was awesome. We received a range of comments from “Cool!” and “Amazing! Thank you.” to ”This is awesome. I’ve been here over 5 years and still run into acronyms I don’t know.”

The success of GlossaryHub was due, I think, to its simplicity. It’s just a few easy steps to look up an unfamiliar term and users can do it right from where they encounter the term: in their browser. Since the glossary was rolled out about six months ago, about 1,100 new terms have been added to it. Of those terms, about 150 were requested by users.

Rolling GlossaryHub out in stages meant we could troubleshoot any installation problems and also get feedback from users. We were able to incorporate these changes as we rolled it out company-wide.

We started with support for GlossaryHub on Chrome only. After we had success with that, we then rolled out a Firefox version and are considering a Safari version.

Maintain Your Project

Because GlossaryHub attained such wide adoption, it’s become the glossary “source of truth.” We’ve incorporated content from all the other glossaries into this one, and there’s now someone from the Documentation Team dedicated to maintaining the glossary and responding to requests for new terms.

It’s fun to start a new project and get a proof-of-concept done. This can be the most exciting phase. But always keep an eye to the future and plan for how your project will be maintained. Perhaps you’ll continue to maintain and evolve it. Or it may be a perfect opportunity for another team to move it forward.

In Summary

If you’re in the early stages of a project or you’re driving a problem-solving project – which most projects are – these principles may help you “get to done.”

  1. Prioritize and Get Support – Get support for your project from both upper management and cross functional teams. Garnering support is something you can do throughout the life of your project, not just at the beginning.
  2. Collaborate to Get Expertise – Avoid taking on all the work yourself and seek out other people that have the skills that you need.
  3. Iterate Towards Greatness – Instead of solving a problem all at once, take the Agile approach and break it down into achievable chunks. Delivering incrementally can make a project much more manageable.
  4. Roll Out Incrementally – In the same way that you develop incrementally, rolling out your solution in this manner can be more efficient. Particularly with large implementations, think about how you can break that phase into small pieces.
  5. Maintain Your Project – Count on the success of your project and the fact that it’ll need to be maintained going forward. This is where getting support and collaborating come into play because other people or teams may have the expertise to help you support your project.

If you’re wondering what those terms from the beginning of this post mean, here they are: ITO=in the office, AUM=available by usual means, and Gigantor=the name of one of our internal projects.

If you’d like to work on innovative projects like this, Salesforce is hiring! Visit http://www.salesforce.com/tech to find your #dreamjob.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS