Home — Helping Patreon Employees find things
During my time at Patreon, we’ve been in a rapid growth stage, with new teammates joining every week. This can be a very exciting time for a company, however this transitory time period brings its own challenges. As a company grows, finding documents, files or relevant information becomes more difficult. Our documentation was spread across multiple resources and teammates were having trouble figuring out where to find the answers to their questions. This issue particularly affected new hires because they are unfamiliar with the organization of the company. This growth really solidified the need for a centralized place to locate information. We had already created Go: a service that creates easy quick links like go/food or go/mobile. However there couldn’t be a go link for everything and there wasn’t a good way to search through these links. This need for quick access to information led to a hack day project called Find, a service that consolidated search across documents from Paper, Asana, Slack, GitHub, Confluence and Go links. Find’s search was originally powered by Algolia; it searched both documents and employees at Patreon. Here is what Find looked like when I joined.
The major issue with Find was that most people didn’t know about the service and there weren’t any dedicated engineers that had time to make the project more useful. With the rapid growth that Patreon was experiencing and the start of my internship in May, it was the perfect time to pick the project back up. My ultimate objective for this project was to build a system that requires little maintenance, that made it easier for Patreon employees to be more effective, and helped Patreon employees find the information they need. With these objectives, I spent the next three months building out Find (which was renamed to Home during my time on the project).
Since search is the most critical part of Home, I started there. Home is powered by several commands that run every hour, gathering documents from various sources like Paper or Asana and then adding these documents to the Home index. The Home index is a collection of documents that the search engine queries. When I started, Home was running on Algolia’s search service. The goal was to migrate away from Algolia to reduce our dependency on third-party services for internal data and build operational knowledge around Elasticsearch. This migration involved modifying the index commands to build the Elasticsearch document and add them to the index. An Elasticsearch document is a key-value mapping, where a key is the name of a field or property, and a value can be a string, a number, a Boolean, or some other specialized type. The original Algolia search (shown below) was very basic; we didn’t provide many query options to improve search results.
In switching over to Elasticsearch we wanted to add result boosting and control the ordering of results. Below is a sample query and search command for Elasticsearch.
I wrote this query to prioritize matches on the title of documents but also provide results from matches in the body of the text. Users also have the option to filter by different different sources; ie, only querying paper docs. Lastly, I added some shortcuts for internal lookups such as users or campaigns.
With Home’s search improved and in a good state, it was time to move on to other feature work. The next thing I focused on building was an improved employee page. This was a frequent ask because employee information was spread across multiple platforms, if it was even available at all. My goal with Home was to pull as much information possible about a single employee and make it all accessible on a single page. Below is the before and after of the employee pages.
The new employee page now features any information someone fills out on Slack, including pronouns or any custom fields we add as a company. Home matches against JumpCloud, which is our internal IT system that tracks employees, to get their legal names and emails. New on the employee page are documents that this person has authored. The major difference between this query and the generic search query is that it attempts to match the employee’s name or email on the document owner attribute.
If this query returns no results, such as when this employee hasn’t authored any public documents, I do a fuzzy search on the person’s name and email in documents and return those results.
As part of the work for the employee profile pages, I added a command to index the Patreon Vacation calendar on Google Calendar. Now if an employee has any upcoming vacation or are out of the office that will appear below their name in their profile card. Lastly, I added a command to pull birthdays and Patreon anniversaries from the Patreon All Team calendar, such that those dates also populated the employee profile. Below is all the information someone will now see when they look up another coworker on Home, all of which does not require any manual entry into Home.
Another feature I personally really wanted to see on Home were team pages. Any Patreon employee can create a team, and then update, delete or add team members to that team. This flexibility was intentional. Making it simpler for anyone to add a team would increase the chance that these pages would be maintained. I kept the underlying data model simple, so people can see all of the teams at Patreon and see who are on those teams without having to spend a lot of time updating the pages.
One nice side-effect of having employee data in one place is that tools can be built on top of that data to help strengthen ties across our team. Often a Patreon employee may find themselves walking through the halls of Patreon wondering whom they just passed by due to the many new faces at the company. This issue has been solved in the past with the creation of a game called who-dat, where people would try and match faces of employees to their names. This was an awesome example of the kinds of tools you can build on top of employee data, however in the original version the main data source for the images stopped being updated. So I ported the name game to Home. I wrote another job to pull images from a company Dropbox folder that we populate with profile pictures taken on the employee’s first day. That job then crops and resizes the photos and uploads them to S3. If an employee’s image for some reason is not in that folder the name game will default to their slack photo, guaranteeing that an image will always appear.
The last feature that really rounded off Home was an announcements bar on the main page. It was common for events, like departmental office hours, to be forgotten even if they were on the Patreon All Team calendar. Indexing the Patreon All Team calendar allowed Home to easily surface all of the upcoming events for the week so team members could get a high level overview of what was happening at Patreon. Once the announcements bar was complete Home was ready to be shared with the rest of the company!
Now with Home, Patreon employees have a way to search for coworkers, teams and documents across multiple platforms. They no longer need to cross reference the vacation calendar to see if the person they are looking for has upcoming leave. Important events and anniversaries are surfaced right on the front page so there is no more confusion about when or where an event is happening. Best of all, this system does not need a full time engineer to stay relevant.
Now that Patreon employees have a way of finding important information, one might wonder what’s next for Home? The future I imagine for Home is one where Patreon employees have a more personalized experience on the platform. To achieve that outcome the next major step for Home would be allowing Patreon employees to login and edit their own profiles. This would allow for people to update any incorrect information and potentially add more custom information; like a fun fact or hello video. In addition to logging in, Home should allow for people to have the ability to connect additional apps enabling search across private documents. Home could also be a place for team members to schedule their vacation time. Below I have some mocks of this login and edit profile flow.
The last major task on Home’s road map would be to switch the frontend to React. Home would then match Patreon’s own frontend stack, enabling us to use our own design elements and branding. While all of these features would be very nice to have, Home in its current state is already allowing for new and old Patreon folks to work more effectively in funding the creative class.
To learn more about working with the Patreon team, head to patreon.com/careers.
