Every time I walked through the GlueCon 2014 lobby, I couldn’t help but look up at the “API Challenge” leaderboard. Mashery’s booth at the conference for API thinkers included a real-time ranking of competitors. I watched as attendees whipped open their laptops and puzzled away at the digital scavenger hunt from the API management vendor. In the sea of event sponsors, Mashery’s booth stood out as the busiest and it was all down to how they had managed to engage the technical audience’s curiosity and sense of competition.
As you choose which developer events to attend or sponsor, you’ll also be looking for a way to stand out. I like this example from Mashery so much that I hopped on a call with one of its creators, Neil Mansilla.
He walked me through Mashery’s approach to engagement activities at events and how his thinking has progressed over the years. More than 10 years after the API Challenge series (they put it on at several other conferences), he still sees the power of puzzles to engage a developer audience. And I found his ideas compelling enough to share here.
Align Your Objectives With Your Puzzles
Even before Neil set up the API Challenge leaderboard at the particular booth I visited, he knew the idea would deliver on his company’s primary goal of raising brand awareness. While that may seem hand-wavy, getting their name out during this rise of APIs was most important. With a puzzle that collects unique entries, they also had something much more meaningful than “number of shirts shot from a cannon.”
There were three goals for Mashery’s event sponsorship, driven by the API Challenge:
- Make developers aware of Mashery’s API platform
- Show off how easy it is to get started with Mashery APIs
- Provide visibility to Mashery customer APIs
To complete each step of the challenge, developers had to make API calls, inspect the results, and figure out the next step. As part of the rules, Mashery pointed to a list of APIs​​ that would help solve each step. These APIs happened to belong to Mashery’s customers and run on Mashery’s platform.
When we chatted, Neil admitted that Mashery’s definition of event success was more easily attainable than it might be for other companies. As part of the developer relations team, he didn’t need to generate leads from this conference. He couldn’t even expect signups directly from the event, since API management was typically an exec-level purchase. However, he suspects many developers tried out their platform afterward. Developers often champion great products and could put Mashery in the conversation.
Many conference booths give away T-shirts and other branded merchandise. That’s certainly a route to awareness, but will a developer remember you and associate you with anything other than a freebie? Probably not.
Mashery’s API Challenge had all the attraction qualities of swag, with the stickiness that comes with giving developers a fun problem to solve. In addition, the leaderboard grabbed attention and made people want to see their names (ideally, near the top). Attendees stopped to ask about the challenge and participants would return for hints from the Mashery team. And that gave them a chance to point out, for example, that Mashery’s software was driving the breezy API Key process. And it certainly didn’t hurt that Mashery had brand-name APIs for developers to try as they competed.
With good conversations and healthy competition going, the API Challenge became a go-to engagement tool for Mashery. Neil was quick to point out that the sophisticated leaderboard and automation came after they’d already proven the concept. If you’d like to engage developers similarly, don’t try to build it all at once.
Start Small and Iterate on Developer Puzzles
The Mashery team used to attend 60 or more conferences annually. Over the years, they ran the API Challenge at many of these events. They had a chance to see developer reactions to the puzzles, make adjustments, and improve the overall infrastructure. The leaderboard, for example, was an entire software application itself! But they didn’t start there and you shouldn’t, either.
All you need to begin is an idea or even a single question. Put that together with simple form software attached to a spreadsheet. That’s enough to be more engaging than the standard conference booth.
If you’re already giving out swag, make your simple puzzle the way to unlock the prize. Mashery gave every entrant in the API Challenge a bottle-opener thumb drive — trust me, these were cool.
Similarly, Keen IO would give away shirts to anyone who used the “Wardrobe Resource” API. Hidden in its documentation was an endpoint that accepted a name, address, and shirt size. Make the right request-which was built atop Keen’s existing data platform—and some swag might arrive in the mail. While the company could use this as a mini-puzzle at conferences, they also left it public as an easter egg. I tried it and it worked (and sorry to say it’s gone from their docs today).
Even though puzzles could be done remotely or even asynchronously, Neil says they work best in finite time and physical space. That’s also good advice for starting small. If it works well, you can always expand it later.
Make your puzzle related to something within your product. Give them a reason to explore to find an answer, but make that first one easy enough that it doesn’t take much searching.
For your initial version, you don’t even have to worry about automated “grading.” Any team member at the booth can look for the person’s name in a spreadsheet of entries and confirm they put the right answer.
Once you confirm developers are taking an interest, you can iterate and expand your puzzle. Perhaps create more elaborate questions or activities. Or build out the way you collect the answers. Whatever you do, don’t do it alone. At Mashery, successfully engaging developers at events was the definition of a team effort.
Make It a Fun Internal Collaboration
The API Challenge was bigger than a single event and its reach went beyond conference audiences. Everyone I’ve talked to who worked at Mashery still remembers these challenges. More than that, they seem proud of the way their former employer reached technical audiences at events. After talking with Neil, I can see it’s because many of these people were themselves involved in the API Challenge iteration.
While Developer Relations was the team delivering the API Challenge at events, many others at Mashery pitched in with their ideas. Neil would broadly share their goals and examples of existing questions. Other coworkers would chime in with ideas — often diabolical twists to increase the difficulty.
As you put together your puzzles for developers, it’s a good idea to have different stages to the challenge. The initial ones should be solvable in just a few minutes. You want to provide some early success to maximize developer interest. Then, make the puzzles progressively harder. Neil recommends three levels of difficulty. You can categorize input from other teams as easy, tough, or somewhere in between.
In addition to ideas, you can trial your challenge internally. You can even give the same prizes out and share top results to encourage participation. To my surprise, Mashery varied the API Challenge with each event. While audience overlap is rare, answers could slip out online. Plus, I think the Mashery team enjoyed the iteration process.
Among the teams to consider for input and to test your puzzles:
- Developer Relations: They understand what engages the audience
- Marketing: They know entertainment and can connect to the product
- Engineering: They may be the audience you want to reach
- Support: They talk to customers and know the product well
Keep all the feedback you receive, especially ideas to improve the system. Anything you don’t use for your first conference you can put into practice at the next.
As for Neil, he left Mashery later in 2014 but brought his developer engagement skills to multiple companies in the last decade. Since 2017, he’s worked on developer tools and practices at Atlassian, known for its now-departed Dragon Slayer Quests… and a suite of collaboration tools for software teams. With Neil on the team, you have to wonder what new puzzles await at the next Atlassian event.
Engage Developers with All Your Content
What Mashery did was take the typical conference booth — free T-shirts and sales pitches — and make it something a developer wants to engage with. The truth is that to reach more of the right developers, all your content needs to resonate with them. Technical content is far too often shouting and touting like an overeager carnival barker.
Instead, you want to connect the developers’ problems to your product with content that teaches and builds trust. This will engage the audience you want to reach.
To start, avoid these super-common technical content mistakes. The first alone could save thousands of hours spinning your wheels on content that’s unlikely to resonate with your audience.