Rocket.Build 2020: Building Products to Improve Efficiencies
This is my first Rocket.Build as a participant. In previous Rocket.Build events, I’ve attended the awards evening and had a chance to meet fellow Rocketeers from different offices. It’s always been a great opportunity to find out what people are working on across the company and to meet people in different roles at Rocket. I get a kick out of seeing the outside-the-box thinking in the projects from teams around the world, but the most important thing is to get outside my own “box” and to meet Rocketeers with different skills, cultural backgrounds, and career paths.
I’ve had a great time this year working on a couple of simple tools that will make certain painful aspects of my job as a content designer a lot easier. The other goal we set to achieve was to get more closely involved with people in other roles within my product team—specifically, development and QA. I work on several products at the same time, mostly IBM products, but I occasionally help out with a few tasks on Rocket products as well. I find that when I get past just “closing tickets” and get more actively involved with other people in my product teams, we all understand each other’s jobs better. This may sound like a cliché, but the more you communicate with your product team, the better everyone gets along.
My Rocket.Build team is made up of three people: Martee Lew and I from Content Design (ID), and Jason Fakour from QA. We’re developing a couple of tools that will automate the process of building and testing online help for several products. They’re strictly internal tools; customers will never see them, but they’ll benefit from them because these tools will save time spent by developers, QA, and ID. Every hour we save on building, sending, testing, and revising the online help is time we can spend doing the other things we do to make the products better and more reliable.
This project isn’t glitzy, but it’s going to be time well spent. I started with the idea of converting ODI files to the DITA format we use to create help topics. When I mentioned it to Jason, he immediately sounded interested and said that he already had some related tools he had developed to improve test automation. I sent him the DITA help source for one of the products we work on, and he started coding. Meanwhile, I thought I’d write a couple of batch scripts to automate the process of building and packaging help plugins. This process has always involved a number of manual steps that give me plenty of chances to make errors—not what you want to do when there’s a fix pack to release on time!
The third member of our team, Martee, is taking on another important role: documenting the tools and updating the ID wiki with information other writers will need in order to use the tools for their own help updates. The problem with homegrown tools is that they tend to be poorly documented and don’t get maintained. We’re going to make sure to avoid that pitfall and keep these new tools where everyone can find them.
Collaboration has been easy. With WebEx and Slack, we communicate easily during Rocket.Build, just as in a normal day’s work. I think we’ve all been pleased with how well the whole company has been able to communicate during these pandemic months when we can’t get together in person. Rocket.Build 2020 has been a great experience. Even if our project doesn’t win the cup, it’ll have been well worth the time, because we’ve made tools we can use every day.