Justin Carmony | Director of Engineering, DeseretNews.com, DDM | @JustinCarmony | October 2, 2015
When the DDM Publisher Solutions team asked me to write a piece for the Innovation Wire, I said I would have to think about it. After hours of contemplation and deep meditation I only had one crucial question to ask:
Excellent. Let's begin. (Wait, whose idea was it to let the engineer write a post?)
In all seriousness, as the director for our CMS team it can feel like I'm light-years away from the newsroom and our journalists. My day consists of building new features, upgrading servers and making sure the correct 1's and 0's go through the correct pipes. My only previous experience in journalism was as a paperboy growing up. It was intimidating learning how to work in our industry. Deadlines, embargos, bylines, revisions, AP style, etc. You name it, it was all new to me. At times, it felt like software development and journalism were two separate worlds. However, how I build and maintain our CMS tools and websites can drastically impact our content team's ability to do its job.
This is why we love collaboration tools, and why we've been so happy moving to Slack. Any tool that helps break down barriers and lets the right people communicate and work together, regardless of team or role, is a game-changer. My co-worker Matt Montgomery wrote earlier this year about how our journalists and developers worked together to produce some amazing long-form pieces. When you work together, you can produce some pretty spectacular results.
We're not the first media company using Slack. Quartz, Vox Media and others have shared their experiences on how they use Slack. The New York Times built Blossom, a slack bot that successfully helps editors decide which stories to best promote on which social channels. While attending SRCCON, a conference centered around designers, developers and journalists, there was an entire session (transcripts) dedicated on how newsrooms could use bots in their respective workflows.
But Justin, isn't Slack just another chat service? We have tools to send IMs already.
While we have used other chat services in the past, there are three crucial differences that take Slack from being another messaging services to being a driver for innovation at DDM.
Reason No. 1: People will use it. This may sound silly and straightforward, but this is where many of our past attempts to unify a chat service have failed. We would try different services and only get 10 percent of the company on it. Other times, we were able to get about 50 percent of the company on a particular service in six months.
We moved about 70 percent of our company to Slack with people using it in three days. This is incredible for us on how quickly this transition happened. Journalists, developers, designers, sales, customer support, you name it, they love using it. The interface feels fresh, the mobile apps are top-notch, and you can fine-tune your notification settings level so you see the messages you need without all the noise.
And there are gifs. You may think that is silly, but between gifs, emojis, reactions and other subtle features, it allows a company to foster a culture instead of just sterile text communication. Heck, we have the channel #gifs for just gifs:
So why is this important? You can't use Slack as a tool to help you innovate if your team isn't there. So having such a high adoption and retention rate was crucial for us.
So the next question is, how do you innovate?
Reason No 2: One click integrations. There are so many tools and services we use that integrate seamlessly into Slack. As a development team, we use GitHub, Travis CI and Pivotal Tracker to manage our process. We have channels in Slack that receive notifications from these tools, allowing our team members to stay up to date on what's going on. An example is our CMS project's activity room:
Anyone can add these integrations, not just developers. Spencer Hall, our content director for KSL.com, wanted to keep an eye on the headlines for KSL.com over time. Using the online service If This Then That aka IFTT he was able to have new entries in the KSL RSS feed posted to his team's Slack channel:
Without the help of a single developer, a content director implemented a solution to a problem he was trying to solve. This is just one example out of many, and we're always looking for ways to "slackify" our workflows.
Many one-click integrations work and solve all of the problems for a particular need. However, there are times where a little additional work from the dev team can take an idea and make it magical.
Reason No. 3: Fail fast and quickly iterate on what works. Slack is an excellent place to experiment with new features, workflows, processes, etc. If my team spends weeks or months in a feature that doesn't solve our users' needs, it becomes a huge waste of time and effort. We don't like that; we like to make things that are useful.
So Slack is a great place to test ideas and see if and how people use them. Slack has several powerful, robust ways to interact with your team. From simple webhooks to a robust real-time messaging API, there are easy-to-use technical solutions for any development team — large or small.
Going back to Hall's RSS feed channel, he was happy with it, but it wasn't solving all of his needs. There could be up to a 15-minute delay with new items being posted, and it could look a little nicer.
Because people were already using the channel, we knew spending a little more time would be a wise investment. We set up a bot called "newsie" that crawls an RSS feed every 15 seconds and post a nicer formated message in a channel we call #our-news. We also added some of our other sites like Deseret News. The result turned out nice and was worth the few hours of additional effort from the dev team.
If there is anything that has me sold on building tools into Slack, it has been these last two weeks.
Case Study - The Deseret News Bot
For the month of September, the Deseret News content team set a goal: double the number of video views we serve. It was a lofty goal, but members of the team felt we could hit it. Every day, Matt Hartvigsen, the content director, would manually send out an email with the following information: yesterday's video views, top videos and how many video views we had for the month. The content team felt the emails were super helpful, but they couldn't do a lot about yesterday if they had a slow day.
So our dev team thought, "why don't we make a bot in Slack that can tell them the stats in real time?" So we created DN Bot. We based it off of "hubot" from GitHub, and had an initial version working in about two hours. DN Bot was simple and polite.
You could ask it to tell you what commands it could do:
But the most important part is asking it "@dnbot: stats videos for today":
Our content team got hooked. Our team went from checking daily to checking hourly. In the afternoon if it had been a slow day they would go out and turn it around. And guess what? We totally hit our goal! Our dev team can't take the credit, our amazing content team deserves that, but we were glad to help out.
Now that we know people will use DN Bot we've added more features. You can now check many types of stats for any type of date range. We're now looking to expand it to let other teams like KSL.com and Utah.com use it. It has been a huge success, especially given that only one developer spent a few days working on it.
That's the beauty of Slack. We can try, experiment, tweak, adapt and innovate. We can spend just a few hours on an idea, and if it is a total flop, that's wonderful. We learned something new at a very small cost. I don't have to worry about putting weeks (or months) into a project hoping I'm building the right thing. Then if something becomes so successful it outgrows Slack's interface or features, we can move that successful project into a full-blown product.
If you're not using some sort of communication tool like Slack, I highly recommend it. If you're successfully using another tool like HipChat or Campfire, wonderful. Look for ways to experiment with it. It is extremely cost-effective and a lot of fun. When your developers and journalists start to enjoy working together and trying new things, you'll start to do awesome things.
P.S. If your developers want some more technical insight into how we built the things we did, feel free to let them contact me directly (firstname.lastname@example.org).