This is the final part of our series on How Enterprises Foster Innovation and Grow Developer Communities. In part 2, we looked at how developers can move innovative ideas forward within an enterprise.
In the previous parts of this ongoing series focusing on developer experience, we talked about how an enterprise is surprisingly well-suited to embracing the agility that is often expected of good developers. In fact, balancing the ideas of other parts of the business and developer know-how with an enterprise-sense of planning and risk aversion can actually mix as the right recipe for success.
As SOA Software’s Andy Jones continued his APIcon talk “How Enterprises Can Build a Mobile Developer Community” (see the video below), he dove into now, once you’ve built something, how do you take it out to market.
How a Developer Portal Draws Them In
So how do you get external developers to interact with your application programming interface or API? Of course, the first step is for marketing and PR to reel them in. But then what? How many developers sign up for your product, service or app and then just ignore it after initial enrollment? As with all software or technology, the most important part of the sale tends to be onboarding. Jones went on to talk about developer engagement via a developer portal that provides easy-to-find and easy-to-understand resource catalogs, great customer support, and other ways to connect channels of communication as efficiently as possible.
Of course having a developer portal also works as a great way to manage usage control and permissions which will probably need to vary between your internal API users and your external partners. This is also where that flexibility comes in because not all users will have the same needs.
A developer portal, fundamentally, “is just a way of simplifying that engagement process. I think for people who are experienced in integration are wondering why enterprise-level integration has been difficult, I think this whole idea of making consumption easy and engaging with the consumers of service is perhaps the part that’s been missed from those conversations over the years,” Jones said. “Integrations work fantastically well between integration experts but if you’ve got app-type developers using an ESB, then watch out.”
Now, on the other side, how should onboarding work from the enterprise standpoint? Jones outlines a series of questions that every enterprise must answer in order to properly expose their API to developers:
- Access for API Owners
- Who controls the API documentation?
- Who is in charge of access control?
- Who needs to be approved?
- Who needs API access?
- Are there developer IDs? Organizational IDs?
- Who needs to approve everything?
- Is there one product owner?
- Or is there a workflow shared across a group of stakeholders?
“For the enterprise, it comes back to this idea of governance. You want people to contribute, but there’s certain parameters within which you have to operate for your own safety and security and for the welfare of your shareholders. And it often comes down to ownership of assets and the control of assets,” Jones said. By making sure of the answers to the questions above, your enterprise can more easily get people engaged with your product.
Branding: Shed The Old-School Image
A lot of time in innovation incubators and startup hubs, there’s such a rush of innovation followed by a plummet. Why? Because they don’t take the time to measure. Enterprises’ sense of restraint means that they are often better suited to measuring the success of any efforts to create a developer community.
As you go through the entire process from idea iteration to final customer, it’s important to measure the new roles to discover what so-called best practices actually work for your team and your developer audience. This includes measuring:
- The total number of ideas brought to the table
- The proportion of good ideas
- The value accrued from shared ideas
- Successful conversion from shared ideas
But then again, these are just best practices which vary by company. It’s up to you to find the best practices that suit both your enterprise’s goals and your external developer community’s goals.
Role Of The API Evangelist
This is a term thrown around a lot lately, but that doesn’t mean it’s clearly defined. In fact, since API developer roles vary, the person or persons given the task of engaging that community should vary. Here are certain types of potential API evangelists:
- technical API evangelist — This is the one that knows your API inside and out and all the quirky and special things it can do. This very well could be an internal employee, perhaps a tester or developer, who is available to help the über users of your API do what they want to do.
- user API evangelist — This tends to be someone that was an early adopter of your API or is just blown away by the problem it solved. Don’t necessarily look for them in places where you think your intended audience or target sectors are found. Ask sales or support for recommendations here because you may not only find a great brand advocate, you may find a whole new target area.
- creative API evangelist — Maybe you need someone completely outside your company and perhaps completely outside your field doing crazy creative stuff with similar APIs. That’s someone you want to bring on to try out your service and to see what she or he can do with your API.
- internal API evangelist — This is not someone on your team. This is someone found somewhere else within your company that has an innovative mindset and can understand the benefits of your API within the vision of your entire business. This is the one that can help get you funding.
Of course, these API evangelists aren’t going to just trip upon your booth at the next API conference or come up in a search on LinkedIn. As Jones pointed out,“You don’t have to leave it to chance. You don’t have to hope that the really bright spot in the garage decides to work on your API. There are things that the enterprise can do that can make it [the API] so easy to work with and then be proactive with the community to create an environment for success.”
There’s this common misconception that building an API community must come from the bottom up at hackathons and MeetUps. Yes, that helps, but building a community of API evangelists and enthusiasts has to be a top-down initiative as well.
“I think there are ways beyond simple technology to really get the organization behind creating value for everybody,” Jones said.