At Slack, we’re focused on delivering big, impactful features, but we’re also dedicated to improving our users’ day-to-day experience of our product. In fact, every engineer spends at least an hour per week supporting users alongside our Customer Experience team, as part of our Everyone Does Support program. When we receive actionable feedback from our users, we share it into a channel where anyone at the company can see the pain our users are feeling.

If the issue at hand is easy to fix, we do so right away. If the problem is more complicated or requires a more involved solution, we’ll post the feedback in the appropriate team or product channel, where the right people can discuss it in more detail. This process has remained central to our team. Even as we’ve grown, we’re still committed to shipping features quickly and iterating rapidly with the help of new employees. (Read more about what we’ve launched recently on our main blog.)

One improvement we launched recently was our inline media player, which enables users to play audio and video files that have been uploaded to Slack right within their channels and DMs. Previously, users would have had to download these files to play them. For most teams, this new feature was pleasant but minor, but for teams that work with audio and video files everyday, this saved both time and hassle.

Determined to ship this feature quickly, we knew we had to keep the scope manageable and that meant prioritizing and gaining efficiencies where we could. We started by looking at the native capabilities of the HTML5 audio and video player. Then, we worked with our Analytics team to figure out which file types were most commonly uploaded.

Since the HTML5 player would allow us to immediately support .mp4, .mp3, and .wav (72% of all video and 81% of all audio), we decided to move forward. Although this wouldn’t cover all media files, we knew this could help us get the feature out the door more quickly and deliver a better experience for the majority of our users.

When a new engineer — Jason Norris — joined the team, we used the opportunity to add support for another commonly-requested file type: .mov files. This iteration was a great on-boarding project for Jason as it was both well-defined and provided hands-on experience with various parts of our codebase. Within his first month, he was able to take on, build, and deliver the feature to our customers. With this update, we were able to cover 98% of all video files.

Another feature we rolled out more recently is the ability to view PDF files directly in Slack. As with embedded media files, this allows people to view PDFs right in Slack without needing to download them. While this may also seem minor, PDFs are our third most popular type of uploaded files (after images and snippets) and we knew making them easier to view would make a big difference to our users.

View PDFs in Slack

PDFs are complex documents — structured into different layers of information, data, and objects, and containing different languages, images, and graphics. To simplify this project, we looked into using external libraries and settled on using PDF.js. This library provided basic capabilities, including security and reliability, and helped us abstract away the complexities of the project. For our first pass at inline PDF viewing, we intentionally kept our scope narrow: display and text selection support for small PDF files. This clear, achievable set of product requirements allowed one of our new engineers, Xi Ji Guo, to start working on the project within his first few weeks on the team.

Every new engineer at Slack is assigned a mentor to help with their first few months. When Xi Ji faced technical challenges, his mentor, Patrick Kane, was able to guide him in the right direction with frequent code and architecture reviews. Patrick helped get the PDF viewer integrated into the Slack client and into our build system. He was also available whenever Xi Ji hit a snag, and pointed Xi Ji to the right people and in the right direction when he was stumped.

Xi Ji and his Slack engineering mentor, Patrick

Through both of these features, Jason and Xi Ji learned the full product development process at Slack within their first few months, setting them up for their next projects. They worked with their product manager (that’s me!) to develop the features, debugged issues with our Manual QA team, and helped our Automated QA team set up tests. When we released the feature internally (something we do with all features), they wrote their first internal product announcement in our #released-internal channel. When we were ready to launch, they staged a gradual rollout and worked closely with our Customer Experience team to address any questions that came up.

We focus on the small things because they matter to our customers. Being an engineer at Slack means more than just submitting pull requests or making changes because someone told you to. We’ve created a process and a culture that encourages engineers to stay in touch with our customers and empathize with their problems. We like to say that nothing is someone else’s problem and we expect our engineers to take the attention and care that our Customer Experience team does everyday. What matters to you, matters to us. And we mean it.

[hiring text=”If you want to help us make Slack a little better each day, check out our job openings and apply today.” url=”https://slack.com/jobs” /]