By tech standards, Twitter is approaching middle-age. For many people, middle age brings a change in perspective; an opportunity to reflect, re-evaluate, and make changes. If life has gone well, middle age can lead to a renewed confidence.
Today, Twitter has an established role in how politicians, corporations, celebrities, and individuals communicate. Its reach stretches beyond what might have been expected at its launch 14 years ago.
Twitter’s confidence in its platform and its data are reflected in its newly revitalised developer programme. After some years focusing on partner success, Twitter’s outward-facing developer relations programme is back.
Twitter’s first API came about shortly after the main product’s launch. In those early years, the API was remarkably open. Then, perhaps as the company recognized the vast range of potential use cases of its data and API, it introduced rate limits and other restrictions that were common amongst its peers.
For the past few years, the focus of Twitter’s developer programme has been on enabling partners rather than the general developer population. However, that has now changed. According to Stephen Compston, Twitter’s Senior Manager for Developer Relations, there’s a renewed outreach and adoption effort:
“We know that a broad set of developers, such as academic researchers, hobbyists, and professional devs, bring a lot of value to Twitter and help make Twitter, Twitter. So that’s why we’re developing our efforts in driving growth on the front end.”
Here “front end” means developers improving how people consume Twitter, as opposed to the partners that integrate with Twitter’s back end for large scale data purposes. That’s not to say, though, that this is a replacement of the previous partner-focused strategy. Instead, Twitter is expanding its developer programme to continue supporting partner success while also enabling bottom-up developer adoption.
More dev rel means more dev rel practitioners. Sitting in Twitter’s Platform department, the developer relations team had largely been made-up of generalists but now is moving towards hiring some specialists to help the expansion of their outreach activities. Today, that means a team of partner engineers and advocates but it looks likely that they might specialise further in future.
This is part of a broader trend in larger developer relations teams. Arguably, the days of the generalist developer advocate are numbered in all but the smallest teams. Not only is it increasingly hard to hire people who tick every box, and anecdotes suggest that frequent context switching is one reason so many dev rel practitioners burn out, but true generalists are rare; better to hire a team of people each of whom is really good at one or two aspects of dev rel.
One outcome of shifting Twitter’s developer strategy is the change in what they measure. When the programme’s sole focus was on partner enablement, the team prioritised metrics that showed how well partner tools were integrating with the platform. Now the programme is expanding to do more outreach, so they’re adding more metrics.
“Our goals and metrics now focus on high level growth metrics for the platform overall. So, we look at how fast it is for someone to get in and start using the platform. We’re also measuring customer satisfaction scores for the resources.”
There’s an important illustration in Twitter’s story of how a programme focused on one thing can have positive knock-on effects elsewhere. A common strategic question in dev rel is, “Should we go after adoption or should we improve things for our existing developers?” Arguably, Twitter’s focus on partners fell into the latter. However, work to improve the lot of existing developers can also help adoption by improving the overall developer experience.
Dev rel at Twitter is proof that successful developer relations programmes naturally shift focus in line with broader changes in company strategy. Just as with other parts of the business, there are natural ebbs and flows for dev rel.
For Twitter dev rel, 2020 is all about staffing a larger team to go out and build adoption of their newly revamped API. You can view their open vacancies here.
Indeed has seen a huge uptick in Hacktoberfest participation from their engineering team. Hear how they did it.
People were organising communities long before developer relations. So what can we learn from those that went before?