This website is currently dormant!

API Definitions News

These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is defining not just their APIs, but their schema, and other moving parts of their API operations.

Who Are The Most Influential People And Companies To Keep An Eye On In API Space

I am spending two days this week with the Capital One DevExchange team outside of Washington DC, and they’ve provided me with a list of questions for one of our sessions, which they will be recording for internal use. To prepare, I wanted to work through my thoughts, and make sure each of these answers were on the tip of my tongue–here is one of those questions, along with my thoughts.

When it comes to the most influential people and companies in the API space that I am keeping an eye on, it always starts with the API pioneers. This begins with SalesForce, eBay, and Amazon. Then it moves into the social realm with Twitter and Facebook. All of these providers are still moving and shaking the space when it comes to APIs, and operating viable API platforms that dominate in their sector. While I do not always agree with the direction these platforms are taking, they continue to provide a wealth of healthy, and bad practices we should all be considering as part of our own API operations, even if we aren’t doing it at a similar scale.

Secondarily, I always recommend studying the cloud giants. Amazon is definitely the leader in this space, with their pioneering, first mover status, but Google is in a close second, and enjoys some API pioneering credentials with Google Maps, and other services in their stack. Even though Microsoft waiting so long to jump into the game I wouldn’t discount them from being an API mover and shaker with their Azure platform making all the right moves in the last couple of years as they played catch up. These three API providers are dictating much of what we know as being APIs in 2017, and will continue to do so in coming years. They will be leading the conversation, as well as sucking the oxygen out of other conversations they do not think are worthy. If you aren’t paying attention to the cloud APIs, you won’t remain competitive, no matter how well you do APIs.

Next, I always recommend you study the cool kids of APIs. Learning about how Twilio, Stripe, SendGrid, Keen, Stripe, and the other API-first movers and shakers are doing what they do. These platforms are the gold standard when it comes to how you handle the technical, business, and politics of API operations. You can spend weeks in their platforms learning from how they craft their APIs, and operate their communities. These companies are all offering viable resources using web APIs, that developers need. They are offering these resources up in a way that is useful, inviting, and supportive of their consumers. They are actively investing in their API community, keeping in sync with what they are needing to be successful. It doesn’t matter which industry you are operating in, you should be paying attention to these companies, and learning from them on a regular basis.

What Is The Role Of An Influencer In The API Industry?

I am spending two days this week with the Capital One DevExchange team outside of Washington DC, and they’ve provided me with a list of questions for one of our sessions, which they will be recording for internal use. To prepare, I wanted to work through my thoughts, and make sure each of these answers were on the tip of my tongue–here is one of those questions, along with my thoughts.

The idea of an influencer in the API space will mean many things to many different people. I have pretty strong opinions about what an influencer should do, and it is always something that should be as free of product pitches as it possibly can. Influencing someone in the API space should mean that you are just influencing their decision to buy your product or service. That is sales, which has it’s place, but we are talking about influencing. I would also add that influencing SHOULD NOT be steeped in convincing folks regarding what they should invest in, at the technology purchasing level, all the way up to the venture capital level. The role of an influencer in the API industry should always be about education, awareness, and helping influence how average flks get everyday problems solved.

Being an influencer always begins with listening and learning. We are not broadcasting or pitching, we want to influence, so we need to have an idea about who we are influencing, and what will resonate and help them solve the problems they face. I do a significant portion of this by reading blogs, tuning into Twitter, and spending time on Github understanding what folks are building. Next, I engage in conversations with folks who are doing APIs, looking to understand APIs, and listening to what their challenges are, and what matters to them. At this stage I am not influencing anyone. I am being influenced. I’m absorbing what is going on, educating myself about what the problem set looks like, and better understanding my potential audience, when and if I get around to doing some of that influencing.

With a better understanding of an industry, a specific audience, and potentially the problems and challenges faced with doing APIs, I will usually step back from APIs entirely. I want to better understand the industry outside of just doing APIs. I want to understand the companies, organizations, instutions, and potentially government influence on what is happening. Everything that is already going on often weighs on doing APIs way more than the technology will ever by itself. I’m looking to understand the business and politics of operating in any sector before I will ever begin doing any sort of influencing within an industry, and to any specific audience. In technology circles, I find that many of us operate within silos, with our blinders on, and don’t always understand the scope of the problem we are looking to provide API solutions for. Stepping back is always healthy.

Once I’ve done my research, engaged in conversations with folks in an area I’m looking to influence, I’ll begin to write stories on the blog. This is all just exercising and training for the white papers, guides, workshops and talks I will be giving in any area I’m trying to influence. I will do this for months, repeating, reworking my ideas, and developing my understanding. The process usually brings more people out of the woodworks, opening up even more conversations, and influencing my industry, but also potentially adding to the number of folks I will be influencing. Slowly I will build the knowledge and awarness needed to truly be able to influence people in any industry, ensuring I have the platform of knowledge I will need, and grasp the scope of the challenges and problems we will be looking to deliver API solutions for.

The role of an API influencer is always a two-way street. You should be influenced just as much, or more than you are influencing. You should be working with influencers to understand your challenges. Tell us your stories, even if they are confidental. Help us understand your industries, and the unique problems and challenges that exist in there. Invest in us listening to your stories, and us telling your story on our blogs, and other longer form content. This is how we’ll help work through what is going on, and find the right path for your API journey. We can bring a lot of value to your API operations, and help you work through the challenges you face. This isn’t about content creation, or simply workshops, training, white papers, and public speaking. This is about influencing, and making an impact. You can’t do this without truly knowing what is going on, and being able to intelligently speak what is going on. This takes time, practice, investment, and actually giving a shit. It is something not everyone can pull off.

What It Was About Web APIs That First Captured My Attention

<img src="" align="right" width="40%" style"padding: 15px;" />

I am spending two days this week with the Capital One DevExchange team outside of Washington DC, and they’ve provided me with a list of questions for one of our sessions, which they will be recording for internal use. To prepare, I wanted to work through my thoughts, and make sure each of these answers were on the tip of my tongue–here is one of those questions, along with my thoughts.

In the spring of 2010 I was ready for a career shift. I was running North American event for SAP, and had also taken up running events for Google, which included Google I/O and Developer Days. I was the VP of Technology, and made all the decisions around usage of tech, from email blasts, to registration, session scanning, and follow-up reporting. When I took over the role I was dealing with a literal hostage colocation facility for server infrastructure, and massive hardware expenditure on servers that I didn’t need most of the year. Then in 2007 I began using the Amazon Cloud, and got to work re-engineering systems to be more API-centric, leverage AWS APIs to orchestrate my operations.

By 2007 I had been playing around with web APIs for some time. I had incorporated payment and shipping APIs into commerce systems, and integrated Flickr, Delicious, Twitter, Facebook and other APIs into applications. I had plenty of SOAP web service experience when it came to enterprise infrastructure, but this was the first time I was deploying global infrastructure at scale using web APIs. I realized that web APIs weren’t just hobby toys, as my SAP IT director in Germany called them, they were an actual a tool I could use to operate a business at scale. My success resulted in more work, taking on more events, and scaling operations, which didn’t always pencil out to me actually being happier, even though the events scaled more efficiently, and out-performed what had come before.

The two Google I/O events where I managed the technology were the first ones where Google gave away their new Android mobile phones. I saw first hand what was happening in the mobile market, with the growth of the iPhone, and everyone scrambling to deploy APIs to support the new applications their were developing. Now, I was also beginning to develop new APIs to support what was possible via Android devices. It was clear that web APIs were going to be the preferred way to deliver the resources needed on mobile phones, and by 2010 there was no doubt that this mobile thing was going to be around for a while. Both SAP and Google were pushing on us to deliver resources that could be used on mobile platforms across all the events we were managing, and I saw that web APIs were how we would do this at scale.

I was using web APIs to deliver compute, storage, and other essential infrastructure to support global events. I was also using web APis to deliver resources to iPhone applications, and now Android applications. I wanted to better understand how this was being done, so in 2010 I began studying the world of APIs, looking at the common approaches to delivering APIs. I quickly saw there were plenty of pundits discussing the technical details of doing APIs, and I decided that I would focus on the business of doing APIs, and specifically how I can help convince business leaders to understand the potential. By summer of 2010 I had settled in on the name of my research blog, and by October I was beginning to publish my research on the blog. Seven years later, 3,000 blog posts later, I’m still doing it, and enjoy the focus on this important layer of not just the web, cloud, and mobile, but how APIs are being used in devices, on the network, and for bots, voices, and other conversational applications.

Azure Matching AWS When It Comes To Serverless Storytelling

I consume a huge amount of blog and Twitter feeds each week. I evaluate the stories published by major tech blogs, cloud providers, and individual API providers. In my work there is a significant amount of duplicity in stories, mostly because of press release regurgitation, but one area I watch closely is the volume of stories coming out of major cloud computing providers around specific topics that are relevant to APIs. One of these topics I’m watching closely is the new area of serverless, and what type of stories each providers are putting out there.

Amazon has long held the front runner position because AWS Lambda was the first major cloud provider to do serverless, coining the term, and dominating the conversation with their brand of API evangelism. However, in the last couple months I have to say that Microsoft is matching AWS when it comes to the storytelling coming out of Azure in the area of serverless and function as a service (FaaS). Amazon definitely has an organic lead in the conversation, but when it comes to the shear volume, and regular drumbeat of serverless stories Microsoft is keeping pace. After watching several months of sustained storytelling, it looks like they could even pass up Amazon in the near future.

When you are down in the weeds you tend to not see how narratives spread across the space, and the power of this type of storytelling, but from my vantage point, it is how all the stories we tell at the ground level get seeded, and become reality. It isn’t something you can do overnight, and very few organizations have the resources, and staying power to make this type of storytelling a sustainable thing. I know that many startups and enterprise groups simply see this as content creation and syndication, but that is the quickest way to make your operations unsustainable. Nobody enjoys operating a content farm, and if nobody cares about the content when it is being made, then nobody will care about the content when it is syndicated and consumed–this is why I tell stories, and you should to.

Stories are how all of this works. It is stories that developers tell within their circles that influence what tools they will adopt. It is stories at the VC level that determine which industries, trends, and startups they’ll invest in. Think about the now infamous Jeff Bezos mandate, which has been elevated to mythical status, and contributed to much of the cloud adoption we have seen to date. It is this kind of storytelling that will determine each winner of the current and future battles between cloud giants. Whether it is serverless, devops, microservices, machine learning, artificial intelligence, internet of things, and any other scifi, API-driven topic we can come up with in the coming years. I have to admit, it is interesting to see Microsoft do so well in the area of storytelling after many years of sucking at it.

API Evangelist Is A Performance

I think I freaked a couple of folks out last week, so I wanted to take a moment and remind folks that API Evangelist is a performance. Sure, it is rooted in my personality, and I keep it as true to my view of the world of APIs as I can, but it is just a performance I do daily. When I sit down at the keyboard and research the world of APIs I am truly (mostly) interested in the technology, but when I craft the words you read here on the blog I am performing a dance that is meant to be interesting to the technology community in a way that draws them in, but then also gives them a swift kick in the pants when it comes to ethics of the technology, business, and politics of doing all of this.

Sure, my personality shines through all of this, and I’m being genuine when I talk about my own battles with mental illness, and other things, but please remember API Evangelist is a performance. It is a performance that is meant to counteract the regular stream of fake news that comes out of the Silicon Valley funded technology machine. API Evangelist is a Contrabulist production, pushing back on the often exploitative nature of APIs. Not that APIs are exploitative, it is the people who are doing APIs are exploitative. Back in 2010, I saw that APIs were providing a peek behind the increasingly black box nature of web technology that was invading our lives through our mobile devices, and jumped at the opportunity to jam my foot in the door, even as the VC power brokers continue to look to look for ways to close this door.

In 2011, I found my voice as the API Evangelist explaining APIs to the normals, making these often abstract things more accessible. Along the way, I also developed the tone of this voice pushing back on the politics of doing APIs, calling out the illnesses I see in the space. These are the two areas I hear the most praise from my readers, something that has significantly shaped my performance over the last seven years. I have a pantheon of API characters in my head when I tell stories on API Evangelist, speaking to specific groups, while showcasing as many of the best practices from the space as I possibly can. I’m looking to shine a light on the good, first and foremost, but I’m also never going to shy away from showcasing the illnesses in the space as I have nothing to lose. I’m never looking to get VC funding, or do any technology startup, so throwing myself against the machine doesn’t ever worry me–I will keep doing it until I grow weary of this production.

I just wanted to take the time to help folks understand that all of this is a show. Sure, my rant last week was rooted in my own dark personal thoughts, but it was meant to be a reflection of the space (your darkness). I’m touched at the folks who reached out to me with concern, but I’m fine. If I am ranting on the Internet you can always be sure I’m fine. It is when I go silent for any sustained amount of time is when you should have concern. When I’m in my dark place I have NO interest in performing as API Evangelist, and increasingly I have little interest in Internet technology when I feel this way. If you are reading this, thank you for tuning into my little production. I enjoy doing it because it keeps me learning each day. It keeps me writing and telling stories each day. Hopefully along the way some of you also get some value from the stories I tell, whether their are positive, or a little dark like they were last week.

The Fact That You Do Not Know Who I Am Shows You Live In A Silo

Don’t who know who I am? I am the API Evangelist. Ok, I know this post is dripping with ego. However, it is the last post in my week of API rants, and I’m just pumped from writing all of these. These types of posts are so easy to write because I don’t have to do any research, and real work, I just write, putting my mad skills at whitesplaining and mansplaining to work–tapping into my privilege. So I’m going to end the week with a bang, and fully channel the ego that has developed along with the persona that is API Evangelist.

However, there is a touch of truth to this. If you are operating an API today, and you do not know who I am, I’m just going to put it out there–you live in a silo. I have published around 3,000 blog posts since 2010 on APIs. I’m publishing 3-5 posts a day, and have consistently done so for seven years. There are definitely some major gaps in that, but my SEO placement is pretty damn good. You type API or APIs, and I’m in the top 30 usually, with the occasional popping up on home page. The number thing I get from folks who message me is that they can’t search for anything API without coming across one of my posts, so they want to talk to me. So why is it that you do not know who I am? I have some ideas on that.

It is because you do not read much outside your silo. When you do, you don’t give any credit to authorship. So when you have read any of my posts you didn’t associate them with a person named Kin Lane. You operate within your silo 98% of the time, and the 2% you get out, you really don’t read much, or learn from others. I on the other hand spend 98% of my time studying what others are doing, and 2% hiding away. My goal is to share this with you. I’d say 75% of my work is just referencing and building on the work of others, only 25% is of my own creation. I’m putting all of this out there for you, and you don’t even know it exists. What does that tell you about your information diet? It tells me that you probably aren’t getting enough exercise and nutrients as part of your regular daily intake, that will make your API operations be less healthy and strong–reading is good for healthy bones girls and boys!

Kin Lane doesn’t have this much ego, but API Evangelist does. The fact that you don’t know who I am shows you aren’t spending enough time studying the API space before launching an API. I’m hoping that you in your API journey you learn more about the importance of coming out of your bubble, and learning from your community, and the wider API community. It is why we do APIs, and why APIs work (when they do). I wrote this title to be provocative and part of my week of rants, but honestly it is true. If you haven’t come across one of my API posts, and stumbled on my blog at some point you should probably think about why this is. The most successful API providers and evangelists I know are tuned into their communities, industries, and wider API space, and are familiar with my work–even if they don’t all like me. ;-)

Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.

You Have No API Imagination, Creativity, Or Sensibility

I know you are used to people telling you that you are creative, and your ideas are great, but I’m here to tell you they aren’t. You lack any imagination, creativity, or sensibility when it comes to your APIs. Some of it is because you are personally lacking in these areas, part of it is because you have no diversity on your team, but it is mostly because you all are just doing this to make money. As creative as you think doing a startups is, they are really just about making money for your bosses, and investors–not a lot of imagination, creativity, or sensibility is required.

You could invest the time to come up with good ideas for applications and stories on your blog, but you really don’t want to do the work, or even stand out in the group. It is much easier to just phone it in, follow the group, and let your bosses and the existing industry trends dictate what you do each day. If the business sector you operate within is doing it, you are doing it. If you see something funny online or at a conference you will do it. You have a handful of blogs you read each weekend, that you will rewrite the best posts from and publish on your own blog. Your Twitter account is just retweeting what you find, and you don’t even push out your own stories, because you have already tweeted out the story you copied in the first place.

Don’t beat yourself up about this, you come by it honestly. Your privilege affords you never really getting out of your comfort zone, and the people around you make you feel good enough. Everyone on your team is the same, and your bosses really don’t care, as long as you are just creating content, and sending out all the required signals. Just make it look like you are always busy, and keep all the channels active. You don’t actually have to support your API consumers, just make sure you are having conversations with them on forums, and the channels your boss can keep an eye on. Doing too much will make you a target. Keep an eye on your coworkers and never do anymore than they are, establishing a kind of solidarity of mediocrity. This isn’t rocket surgery, its API theater.

You know deep down that you have some creativity in there, but it is something that has never been encouraged. This is the damaging effects of your privileged world. Your parents, teachers, bosses, and friends never push you, and neither do you. You don’t have to. If this story pisses you off, you really have nobody to blame. You’ve never had to work hard. You have never pushed yourself to do any of the hard work required to fail, on the path to becoming creative, developing your sensibility, and honing your imagination. How are you ever going to know what you are capable of if you do not put yourself out there. Creativity isn’t created in a silo. People aren’t just born with sensibility. And API aren’t lacking in imagination by default. There are many APIs operating out there that possess all these characteristics, and are leading the conversation–why aren’t you one of them?

Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.

Holding Little Guys More Accountable Than We Do VCs And Bigcos

I spend a lot of time defending my space as the API Evangelist. I’ve had lengthy battles with folks in the comments of my blog for defending women, charging for my services, being pay for play, having secret agendas, and much more. I’ve had my site taken down a handful of times (before I made static on Github Pages), because I stood up for my girlfriend, or just joined in on the wrong (right) cause. When you have been doing this as long as you have, you see the size of the armies of tech bros that are out there, waiting to pounce. It is why I don’t share links to Reddit or Hacker News anymore. I stopped sharing to DZone for same reason, but they’ve since cleaned up their community, brought in some great talent (including women), and I’ve started syndicating there again.

Most recently I had someone accuse me of pay for play, even though there was no disclosure statement present, and I have had two other folks accuse me of having an agenda set forth by my partners. If you know me, you understand how ridiculous this is, but this never stops the waves of young men finding their way to my site, and pointing the finger. What I find fascinating about this is these men never point the finger at Techcrunch, or call out API startups (and bigcos) for colluding, sponsoring, pay for play, and the other bullshittery that goes on. They go after folks who are outspoken against the machine, and never after the machine itself. If people don’t like something I said, or what someone I’m writing about is up to, they tend to go after me, without spending any time getting to know me, looking at my background, or looking at the seven years of storytelling on my site–there is a single page to do it!

The majority of these folks rarely ever have their own blog, name and pictures on their Twitter or Github accounts, and have a minimum digital footprint. They don’t understand what it is like to be out in the public sphere sharing their ideas on a daily basis, and prefer hiding behind anonymity while they go after the little guy. Again, rarely do you see them going after the Silicon Valley, or larger corporate machine–too big of target. I have special Twitter lists I add these folks too, and usually when one of them pisses in my Cheerios I’ll spend some time seeing what the others are up to, and most times it is more of the same. Trolls. It is easy to dismiss these folks as part of the wider illness we see infecting the Internet, but much like sexism and racism, the real damage is done by the waves of complicit individuals and platforms who support them, chime in, pile on, and maintain an environment where this type of behavior is normalized.

For the most part I’m a diplomat. I tend to perform API Evangelist in a supportive, friendly tone. I started API Evangelist on this tone with intent. I saw the meanness in the space, fully grasped my assholeness as a VP of technology within an enterprise group, and wanted to do something different, and help people feel like APIs were approachable and friendly. I still support this tone, but this week, I’m performing a more offensive version of API Evangelist. One that is calling y’all out for the bullshit that you do each day online in this business, or condone and support daily in your complacency. I’m not really as unhinged as these posts make me out to be (close), I’m just exploring the illness that is rampant in the space, and pushing back a little. There is a significant amount of cover afforded to VCs, bigcos, and the startups who support their message, and for the handful of us out in the open, we often become a much easier target, when in reality there should be much more accountability for those that are responsible for the illnesses in the tech sector, ad are often out of site, but actually have their hands on the puppet strings that make things go around.

Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.

Extract As Much Value As You Can From Your API Community And Give Nothing Back

You are in a sweet spot. You got a fat six figure job in the coolest department of your company, building out your API platform. You have a decent budget (never as much as you want) to throw hackathons, run Google and Twitter ads, and you can buy schwag to give away at your events. Sure there is a lot of pressure to deliver, but you are doing pretty well. All you gotta do is convince 3rd party developers to do thing with your companies APIs, develop web, mobile, voice, and other applications that generate buzz and deliver the return on investment your bosses are looking for.

It is all about you and your team. Let’s get to work growth hacking! Attract as may new users as we can, and convince them to build as much as we possibly can. Let’s get them to develop SDKs, write articles for us on their blog, speak at our events, favorite things on hacker news, and whatever activities that we can. Your objective is to extract as much value from your API operations as you possibly can, and give nothing back. Expect developers to work for free. Expect your hackathons attendees to come up with the next great idea, build it, and hand it over to you for very little in return. This isn’t a partnership, this is an API ecosystem, and your team is determined to win at all costs.

Your API isn’t a two-way street. All roads lead to your success, and your bosses getting what they want. You don’t care that 3rd party developers should be compensated, or that they have any rights to their intellectual property. The 5% of them that successfully build applications, we will offer them a job in exchange for it, or we’ll just replicate it internally, decrease their rate limits, and increase their error rates so that they can’t compete. Sure you want people to still feel inspired, but not enough so that they’ll ever be able to sustain their applications–the only sustainable application around here will be owned by the platform. After all, this is all just business–it is nothing personal.

Note: If my writing is a little dark this week, here is a little explainer–don’t worry, things will back to normal at API Evangelist soon.

The Yes I Would Like To Talk Button When Signing Up For An API Platform

There are never enough hours in the day. I have an ever growing queue of APIs and API related services that I need to play with for the first time, or just make sure and take another look at. I was FINALLY making time to take another look at the RepreZen API Studio again when I saw that they were now supporting OpenAPI 3.0.

I am still driving it around the block, but I thought the second email I got from them when I was signing up was worth writing about. I had received a pretty standard getting started email from them, but then I got a second email from Miles Daffin, their product manager, reminding me that I can reach out, and providing me with a “Yes I Would Like To Talk Button”. I know, another pretty obvious thing, but you’d be surprised how a little thing like this can actually break us from our regular isolated workspace, and make the people behind an API, or API related service more accessible. The email was pretty concise and simple, but what caught my eye when I scanned was the button.

Anyways, just a small potential building block for your API communication strategy. I’ll be adding the list I am cultivating. I’m not a big hard sell kind of guy, and I appreciate soft outreach like this–leaving it up to me when I want to connect. I’ll keep playing with RepreZen API Studio and report back when I have anything worth sharing. I just wanted to make sure this type of signup email was included in my API communication research.

The Successes And (Mostly) Failures Of A Developer Evangelist

I am a big fan of companies who share their API journey publicly. The comment I hear from readers, as well as attendees of @APIStrat often, is that they want to hear more honest stories from API practitioners regarding every stop along the API lifecycle from defining to deprecation. I encourage API providers to actively share their stories publicly on their blog, and even semi-privately via email newsletters.

Ash Hathaway (@ash_hathaway) over at Stich Data asked me what I thought about her doing an evangelism email newsletter based on her experiences–to which I responded with, “hell yeah, it is a great idea!”. So she has launched The Evangelism Compendium, the successes and (mostly) failures of a developer evangelist email newsletter. She will be sharing her regular thoughts from the trenches, as she is evangelizing for the data integration platform.

Sharing stories from the API trenches like this is a great way to generate content for your operations, while also working through your thoughts on what is working (or not), when it comes to evangelism and outreach for your platform. I think the email newsletter has two audiences 1) data stewards looking to learn more about managing your data in today’s online cloud environment, and 2) other data and API service providers who are looking to learn, and hopefully share thoughts on evangelizing your platform. Many folks think I’m crazy for encouraging this type of real-time transparency into your operations, something that can make some feel vulnerability and exposed, but I find it to the best way to generate honest and compelling content.

API Evangelist is the result of me doing this for the last seven years. Sharing my thoughts as I do my work. I find it is a helpful part of my regular workflow to tell stories in this way, as it helps me refine and articulate my approach. It also generates valuable SEO and SMM exhaust for my platform, while also hopefully helping educate others along the way–even stimulating conversation. I encourage all API providers, and service providers to tune into what Ash is doing over at Stitch Data, and make sure you are telling your story via your blog and/or email newsletter–no matter which stops along the API lifecycle you are looking share with the community.

More Evangelism Will Be Needed To Move Banking API Conversation Forward

I was reading what’s behind the hold up of API adoption at credit unions and I’m reminded (again) of the critical need for API evangelists in the space. I am not talking about advocates for a single API, but more evangelists that reflect my mission as the API Evangelist, but dialed in for specific industries.

To set the stage for you, let me share why I started API Evangelist seven years ago. I began writing about the business, and eventually the politics of APIs because I saw the potential with APIs, but I also saw that things were not evolving as fast as they could because technologists were dominating the API conversation. We needed more discussion around the business of doing APIs, and many of the finer political details like security, terms of service, branding, and other concerns of the business leaders who actually controlled the purse strings that would move the space forward at the speed and scale everyone desired.

To help break the log jam within the federal government, healthcare, and other industries someone needed to help assure business and technical stakeholders of the benefits of doing APIs, with sensible discussion regarding how they could mitigate the risk involved. The problem in the banking space is that you only have the vendors and hype pundits dominating the conversation, and much-needed trust is never established. Banks are extremely risk adverse because of money, but also because of regulations, and when you have just technologist, vendors, and hype analysts stirring the pot, nobody ever really helps alleviate bank’s actual concerns around security, privacy, and other areas that keep them up at night.

I remember sitting down at a table in Vegas with Anthem, Kaiser Permanente, and other health insurance providers who were all about business when I sat down, but after an hour or so I convinced them they weren’t in my sales pipeline, and the tone changed completely. They are so used to be sold to and pushed vendor solutions to their problems, they were just seeing APIs as the next vendor product. I help show them I didn’t have a product to sell, and genuinely wanted to help them understand the API potential, and break down the security, business, and other concerns they faced as major players in the space. I have seen this play out over and over, across many different industries over the last seven years, and is something that the waves of enterprise sales teams, vendors, and analysts never fully grasp is actually gumming up the gears of their progress–a bi-product being so narrowly focused.

For the last five years, I have been trying to groom up evangelists who could tackle specific industries like finance, healthcare, education, and others, but it is really, really difficult to patch together a consistent paycheck to keep anyone engaged. Plus, it seems to take a certain type of obsessive-compulsive personality to stay dedicated to what is going on. If folks are really interested in clearing some of the gunk that is slowing the progress in the banking and credit union API space, you all should get together and establish some sort of vendor-neutral group to help fund and provide a platform for financial sector API evangelist(s) to work independently with banks to help alleviate their concerns, and help showcase the positive motion forward when it comes to banking APIs–otherwise things are going to continue to sputter and jerk forward at an uncomfortable pace.

P.S. The evangelists have to actually give a shit about what is going on and be personally invested, otherwise it won’t be sustainable.

More API Evangelists And Storytellers Please

Everyone once in a while I get a comment from someone regarding competition in the API storytelling space, alluding to someone getting the page views, or audience when it comes to APIs. I rarely worry about these things, and in reality, I want to see way more competition and outlets when it comes to short and long form API storytelling--the API space needs as many voices as it possibly can.

I'd like to see domain specific evangelists emerge, beyond individual API advocates. Someone covering industrial, machine learning, healthcare, and other significant verticals. We need to begin to cultivate domain expertise, and preferably vendor-agnostic, and tooling-comprehensive knowledge and accompanying storytelling. Some of these verticals are in desperate need of leadership, and I just don't have the time to focus in on any single area for too long.

We need more practical, and hands-on API storytelling like we are seeing from the Nordic APIs. They are rocking the storytelling lately, exceeding the quality I can achieve on API Evangelist. They are hitting all the important areas of the API life cycle, and their storytelling is genuine, useful, and not pushing any single product or service. The Nordic APIs is invested in educating the community, something that makes their work stand out--emulate what they are up to if you need a model to follow, don't follow mine. #seriously

If you are an API provider or possibly aggregator and marketplace, consider following the lead of BBVAOpen4U API Market, they produce some interesting content, as well as also have a good way of sharing and syndicating quality content from across the API space. I've seen a lot of companies come and go when it comes to aggregation and syndication of API stories. I like BBVA's open approach, because they have skin in the game, and seem to genuinely want to highlight other interesting things going on in the space--something more API providers should be doing.

If you want to get started in the space, all you need is a blog, a Github, and Twitter account. Come up with a name, and begin learning and writing. Don't worry about page views, or having a voice when you first start, just write. Then as you feel comfortable, and find your voice, begin sharing your work more, as well as highlight the work of other storytellers in the space you are learning from. If you keep at it for a while, you never know, you might actually build a following, and be able to influence the world of APIs through the stories you tell--give it a shot.

All API Startups Should Be More Like Glitch

I was playing around with, and better understanding the new collaborative developer community that is Glitch, and I saw they had published a blog post about how they won't screw up Glitch. The topic was in alignment with another post I was working on regarding what I'd like to see fro API startups, but I think Anil articulates it better than even I could, and I think folks are going to respect it a lot more when it comes from a seasoned veteran like him, over an opinionated evangelist like me.

In hist post, Anil shares five key points I think every startup should be thinking about from day one:

  • No lock-in. We use totally standard infrastructure for Glitch, including regular old Node.js, and normal JavaScript for your code. You can export all of your code to GitHub with a click, or download a zip file of your code instantly at any time. And it’s gonna stay that way. The key thing that we think will keep you using Glitch is by your deep emotional connection to your fellow members of the community. And that’s not lock-in, that’s love! Aww. ❤️
  • We’re not gonna take features away from you and then start charging for them. This is one of those tricky things that a lot of companies do when they start building a business model for their product — they ask, “what would people pay for?” And then they realize… oh crap, the stuff people want to pay for is already offered for free. We’ve thought about this pretty carefully so we’ll be able to support our current features going forward. (It doesn’t cost much for us to run your Glitch app, and that cost is going down each month. No biggie.)
  • When we do start charging for stuff, we’ll check with you firstWe imagine we’ll add some paid features on top of what Glitch has now (maybe domain names? Everybody loves mapping domain names!) and when we do, we’ll let you know they’re coming, plus get your feedback on what you think is fair and reasonable pricing. Because we want you to be happy to pay for these valuable features!
  • We won’t let a bunch of jerks take over the community. Ugh, this one is so annoying. Usually, when a company is trying to grow a community, they’ll let just about anybody in because they’re desperate to show growth, and that inevitably means opening the door to some small number of jerks, who then ruin the whole site for everybody. Instead of doing that foolish thing, we’re going to grow Glitch steadily and deliberately, with tons of room for new folks, but a lot of thought put into preventing abuse and harassment. I can’t guarantee we’ll get it perfect, but honestly the thought of working every day to build something that’s mostly used by jerks would be awful, so we’re not gonna do it. And honestly, Glitch is growing pretty quickly because it’s friendly, so hooray for nice people.
  • We want your fun and weird and “not serious” stuff on Glitch, too. While we’re ecstatic to feature Serious Tools from incredible companies like Slack on Glitch, we think your artsy or silly or deeply personal projects are vital to the community, too. The same people who spend their day building a complex API integration on top of Glitch’s tools will come home and collaborate on a generative poetry project at night, and that’s exactly what we’re designing for. So don’t feel embarrassed to show all your many facets here; that’s what our own team does, too.

There are other things I'd like to see other startups focus on like privacy and security, but Anil really get's at athe heart of much of the illness we see regarding API startups. For me, it really comes down to communication and honesty about the business model, which Anil talks about in a very approachable way. I don't expect companies who are doing startups to do everything that us developers want, but I do want you to be open, honest, and communicative with us about what is going on--that is all.

I fully grasp that startups are in the business of making money, and often have different motivations than many (some) of us developers who are consuming their API focused resources. I do not expect these things to always be in perfect balance, but I do expect startups to be honest with developers from day one, and not bullshit us about their business model, changes and the long term road map. I appreciate that Anil and the Glitch team has started things off on this foot, hopefully providing the rest of us with a model to follow when it comes to not screwing over your developer community, and building more trust when it comes to depending on APIs across the sector.

I am looking forwarding to learning more about Glitch, and the potential for the community.

The Relationship Between Dev Relations And Support

I saw an interesting chasm emerge while at a Google Community Summit this last week, while I heard their support team talk, as well as their developer relations team discuss what they were up to. During the discussion, one of the companies presents discussed how their overall experience with the developer relations team has been amazing, their experience with support has widely been a pretty bad experience--revealing a potential gap between the two teams.

This is a pretty common gap I've seen with many other API platforms. The developer relations team is all about getting the word out, and encouraging platform usage and support teams are there to be the front line for support and being the buffer between integration, and platform engineering teams. I've been the person in the role as the evangelist when there is a bug in an API, and I'm at the mercy of an already overloaded engineering team, and QA staff, before anything gets resolved--this is a difficult position to be in.

How wide this chasm becomes ultimately depends on how much of a priority the API is for an engineering team, and how overloaded they are. I've worked on projects where this chasm is pretty wide, taking days, even weeks to get bugs fixed. I'm guessing this is something a more DevOps focused approach to the API life cycle might help with, where an API developer relations and support team have more access to making changes and fixing bugs--something that has to be pretty difficult to deal with at Google scale.

Anyways, I thought the potential chasm between developer relations and support was worthy enough to discuss and include in my research. It is something we all should be considering no matter how big or small our operations are. There is no quicker way to kill the morale of your API developer relations and support teams by allowing a canyon like this to persist. What challenges have you experienced when it comes to getting support from your API provider? Or inversely, what challenges have you faced supporting your APIs or executing on your developer outreach strategy? I'm curious if other folks are feeling this same pain.

How Do We Keep The Fire Alive In API Space?

It is tough to keep a sustained fire burning in the world of technology, at the individual, organizational, and community level. I have been doing API Evangelist full time for six years, and it is no secret that I have had several moments where I've experienced a crisis of faith, and I do not doubt that there will be many more of these in my future--there is no perfect solution. It takes hard work, creativity, and a myriad of other considerations to keep going, stay energized, and keep other folks doing the same.

I have spent a great deal of time this fall thinking about all of the factors that influence me, and contribute to the fire burning, or acting as a flame retardant to me and the API space. When exploring these contributing factors, it is only logical we start with the external forces right? Because this all sucks because of everything external, aka all of you! Couldn't possibly be me?

So what are some of the external forces out there that contribute to the fire burning brightly, or possibly being dampened across API space are?

  • People Aren't Always Nice - For some reason, the Internet has brought the worst out in many of us. I personally feel this is the nature of technology -- it isn't human, and the more time you spend with it, the less human we are, and less empathy we will have for other people.
  • Everyone Takes A Little - Until you've spent a great deal of time in the spotlight writing, speaking, or otherwise you don't fully grasp this one. Every person you talk to, every hand you shake, takes a little bit from you -- making it super critical for people to give back -- it all takes a toll, whether we acknowledge it or not.
  • Few Ever Give Back - The general tone set by startup culture and VC investment is to take, take, take, and rarely give back. The number of people who want to pick your brain, take your open work, and not ever give anything in return is far greater than the people openly giving back, or acknowledging they should pay you for your time.
  • Use & Subscribe To Open Channels - Follow me on Twitter, and Medium. Subscribe to the Atom Feed and email newsletter. Support those people in the space who provide open channels of information by tuning in and engaging.
  • Fork, Contribute & Build Upon - When you fork someone's work plan on how you will contribute back, build upon, and cite their work. Don't just use open source, contribute back to it, and augment it with the value you bring to the table.
  • Events Are Exhausting - Producing, organizing, and pulling of valuable events that focus on ideas over products are fucking hard, and you should support the open tech events you think contribute most to the tech space. Invest time, money, and your energy wherever you can afford it. I know your company demands you get the most out of your sponsorships, but step back and consider how you can give the most as part of your sponsorship as well.
  • Where We Invest - 95% of the investment in the APi space is into proprietary products, services, and technology. The other 10% is an equal investment in ideas, open concepts, specifications, definitions, and software. If companies do invest in "open" it is in name only, and not a true invest. Everyone suffers from this behavior, making the space pretty fucking business as usual--which is a fire that nobody wants to tend to for very long.
  • Intellectual Property - Unhealthy views on IP lock up ideas. I'm not saying copyright, patents, and licensing shouldn't exist. I am saying that aggressive, greedy views will continue to act as a wet blanket when it comes APIs making a meaningful impact, and making the game pretty untenable for individuals.

Next, up, what are some of the internal forces (aka my responsibility) that can contribute to the fire burning more brightly in the API space?

  • Going To Burning Man - Yes burning man will reinvigorate you each year, but we have to find a way to establish a regular alter that we can burn on a regular basis, finding renewal on a regular basis without so much fucking dust involved.
  • Eat Well - If we've learned anything over the last six years it is that man cannot live on pizza alone. Words of caution for you youngsters--eventually you will start falling apart, and this shit will break if you do not eat well.
  • Alcohol - Drinking is fun and an important social lubricant, but it can also lead to some very bad behavior in real-time, as well as contributing to a multitude of other issues in life ranging from health to relationships. 
  • Exercise - We just can't sit on our ass all the time, as much as we'd like to think we can. Again, this isn't a problem for the youngsters, but as we get on in life, it will catch up with you, and we are better off finding a way to work it in regularly.
  • Family Time - Spending time with family is important. Too much travel, screen time and work all hurt this. Regularly check in on what is important when it comes to family. Even if it is just working on API integrations with your kids (did I tell you I'm doing a project with my daughter) -- woohoo!
  • Creativity - Take time to invest in and move forward creative projects. All work and no play makes us all very fucking boring, and are not conducive to any flame burning. The less I invest in my creative side, the less productive I am in my regular work. As an individual and a business make sure there is the investment in creative projects and space.
  • Money - Money is not everything, but making some is required. I've had several waves of $$ making good in my career, and it rarely ever brought me more happiness, and always brought me more concern. There is a lot of focus on VC investment, and showcasing the successful founders in the space. To keep a sustained fire burning we have to realize there is a lot more to all of this than just making money.

These are just some of the key external and internal forces contributing to the fire burning within me individually when it comes to APIs, and I also feel contribute the fire burning also across the community (which I am part of). Startup and VC investment success do not equal community and individual success. Rarely does a startup winning contribute to any single individual success, or the wider community being more vibrant, creative, and rich? You have a rare rock star founder, and always the wealth of corporate and brand success, but these do not make a fire burn brighter in the community. It might attract a few moths to the flame along the way but doesn't truly enrich everyone, and provide fuel for a sustained burn--it is about burning bright, fast, and hard, which aren't good for most of us humans.

I keep going as the API Evangelist because I'm interested in what I'm doing. I'm fulfilled by learning, writing, sharing, and building. I will keep going for another 10, 20, hopefully until the end of my life, because a real fire is truly burning--not because I met my sales goals, sold my startup, or reached API economy nirvana (that is API singularity). Most of the time I'm learning, I am being creative, and I've made more money than was required to pay my rent, my bills, and could eat well. More meetings. More projects. More handshakes. More money does not always nurture me, and keep the fire alive personally, or within the wider API community.

Learning About APIs Has To Be Relevant And Interesting

I am working on a project with a 16-year-old young lady to extract and tell a story using the YouTube API. I'm pretty excited about the project because the young lady happens to be my daughter Kaia Lane. If you've ever seen my API Blah Blah Blah t-shirt, you've seen her work. Historically she could care less about APIs, until recently when pulling data about one of her favorite YouTube stars came up--suddenly she is interested in learning more about APIs.

During regular chatting with my daughter, I shared a story on the entire history of Kickstarter projects broken down by a city. She is a little geeky and likes Kickstarter, so I figured I'd share the approach to telling stories with data, and said that if she ever wanted help telling a story like this using YouTube, Instagram, or another platform, that she should let me know. She came back to me a couple days later asking to learn more about how she could tell a story like this using data pulled from one of the YouTube stars she follows.  

Ok. I have to stop there for a moment. My 16-year-old daughter just asked me to learn more about APIs. :-) As an old goofy dad who happens to be the API Evangelist, I am beside myself.

I'm not 100% sure where this project will go. Right now I'm just seeing what data I can pull on Dan & Phil's video game YouTube channel, and from there we'll talk more about what type of story we want to tell about their followers and get to work pulling and organizing the data we need. I couldn't think of a tougher audience to be trying to get her interested in APIs. She isn't going to care about APIs, wants to learn about APIs, let alone become proficient with APIs unless they are relevant and interesting to her world. 

I do not think this lesson is exclusive to teaching 16-year-olds about API. I think this applies to ANYONE potentially learning about APIs. I am a big fan of EVERONE learning about APIs because they are the plumbing that moves our bits and bytes around in our personal and professional worlds. The more we are aware and the more we know we can put APIs to work, the more successful we are going to be in our lives. I want EVERYONE to open up and learn about APIs for this reason, but I REALLY REALLY want my daughter to find success in this way.

Just something to consider, as we are trying to help key internal, essential partner and other public stakeholders understand the API potential. How can we present APIs in a way that is relevant and interesting? Otherwise, most people probably aren't going to care, and it will all just be API Blah Blah Blah!

We Focus On Interacting With The API Developer Community Where They Live

Another story I harvested fro a story by Gordon Wintrob (@gwintrob) about how Twilio's distributed team solves developer evangelism, was about how they invest in having a distributed team, providing an on the ground presence in the top cities they are looking to reach. I know this isn't something all API providers can afford, but I still think it was still an important approach worth noting.

Like with many other aspects of Twilio's approach, they are pretty genuine about why they invest in a distributed API evangelism team:

We also focus on interacting with the developer community where we actually live. We don’t think it’s valuable to parachute into a tech community, do an event, and then leave. We need to participate in that community and make a real impact. 

I wish there was a way that smaller API providers could deliver like this. I wish we all had the resources of Twilio, but in reality, most API providers won't even be able to "parachute into a tech community", let alone have a dedicated presence there. I've seen several attempts like this fail before, so I am hesitant to say it, but I can't help but think there is an opportunity for evangelists in certain cities.

There isn't any startup potential here (let me make that clear), but I think there is an opportunity for developer advocates, evangelists, and would-be evangelists to band together, network, and offer up services to API providers. All you'd have to do is take the page from the Twilio playbook and execute in a decentralized way--where multiple evangelists could work together as a co-op. The trick is to bring together evangelists who actually give a shit about the space--something that would be very difficult to accomplish.

Anyways, just some more thoughts from my API notebook, inspired by Gordon's post. If nothing else, Twilio's approach should help guide other larger API providers, showing how important it is to invest in developers, in-person at the local level. The value brought to the table via Twilio's APIs has been key to their success, but I can't help but think a significant portion of their success has been the result of their investment at the local level.

Working Tips and Tricks Into Your Regular API Evangelism Efforts

I usually don't have to look very far to find good examples of API evangelism in the field, because the best technology providers are usually pretty consistent and vocal about their practices--allowing me to just pluck from my feeds, and rework as a story for my API provider readership. One of the consistent sources for me out there is from the Docker community, and from what they like to call Docker Captains.

One of the things I see regularly from this Docker community leadership is the sharing of their platform tips and tricks and in-person and online meetups. This is definitely something I recommend other API providers do when possible, but I would also recommend working to integrate the concept into your regular evangelism activities like blogging, weekly newsletter, and Tweeting.

Maybe it is something you could also open up to the rest of the community. Allowing your trusted partners, and your favorite developers to share what their tips & tricks are around API integration and usage are. The idea of tips and tricks is a pretty basic thing, but if you are working to stay creative in producing content, while also keeping things in the realm of actually helping your API developers be successful--it is one that can go a long way each week at meetups, on your blog, newsletter, Twitter, and across all the other channels you are already using to reach developers.

Be Straight Up About Internal Challenges When Hiring Your API Talent

I see an increasing number of job postings on LinkedIn and other job websites from companies who are actively seeking an API rockstar, ninja, lead, owner, or product manager, and because of my connections in the space I know that some of the intent behind them are less than sincere. Don't get me wrong, I think ALL companies should be embarking on their API journey, and if that means bringing in outside talent--get it done!

My motivation in writing this post is to help companies be more realistic during their talent search, and hiring process, as well as internally with their teams. As an IT and lead developer veteran, I have been brought in to take the reins on a number of teams and I have seen a wide range of toxic situations. I understand the internal struggles exist in all companies, but the companies that were the worst for me, were the ones where I was blindsided by the depth of the entrenchment and struggle with leadership and internal teams, either because they were in denial or were straight up bullshitting me--in hopes I might be able to wave my magic wand and just fix everything.

I've confidentially heard many stories from API product leads, and evangelists after exiting a company, or sometimes while they are still in their positions, about how entrenched internal leadership is when it comes to "innovation" and "change"--all while putting on a good show that APIs are truly the priority. I understand that companies want to look innovative, hip, agile, flexible, and all the things often associated with APIs, but bringing in API talent, only to let them hit a brick wall because they were unprepared just isn't good business.

If you are going to say that you are doing APIs, and issuing press releases, and promising your customers, partners, and internal stakeholders that you are going to do APIs, make sure you properly prepare any talent you are looking to lead the charge. I'm not saying the API journey will be easy, and you shouldn't be embarking on this journey. I am just recommending that do not go around hiring API talent, only to blindside them upon entry with entrenched, unwilling to evolve internal actors...or if this is the case just make sure you set the stage properly during the hiring process.

The Expanding World of Technology Evangelism

Technology evangelists are nothing new, but are something I think is continuing to expand as the Internet continues to crack open more of the core areas of the tech sector. I specifically chose the term API Evangelist to define what I did evangelizing for all APIs, but all I was really doing is following the lead of evangelism pioneers like Amazon, Google, and even Microsoft. 

There has long been discussion around evangelism vs advocates, and I've seen companies also choose to adopt an ambassador format. I have also been interested to see the evolution of Docker's Captain's program--who are "Docker experts and leaders in their communities who demonstrate a commitment to sharing their Docker knowledge with others". 

I also stumbled across a post out of the MongoDB as a service provider Compose showcasing what they call the database advocate, whose "job is not to guard the database from the world but to advocate the best ways to use it and offering the tools to optimize that usage". In their view, the outdated DBA is going away, with the database advocate emerging as a much more friendly, outward facing, pragmatic gatekeeper for databases within the enterprise.

It makes me happy to see the open ethos brought to the table by web APIs spreading to all the layers of the tech stack, making the world of virtualization and containers more accessible. As an old database guy, it makes me really, really happy to see it also spread to the world of databases--I am hoping that it is something that continues to spread to all layers.

Looking For Partners At Every Turn When Planning Your API Evangelism

One reason for having a well thought out, comprehensive API strategy, is that you are thinking about all the moving parts, and at ever turn you can weave things together, and potentially amplify the forward motion of your API operations. With every new release you should be considering all other areas of your API strategy, how you can include your API consumers, your partners, and where all of the opportunities lie when it comes to evangelism, and storytelling.

This approach was present in the latest release from Postman, with the release of their Run in Postman, embeddable button. As part of the release of the new embeddable button for their API client tooling, Postman also made a call for partners. It was a savvy marketing technique to reach out to partners like this, something that will not just generate implementations in the wild, but will also establish new partnerships, strengthen existing ones, while also generating new blog posts, and press releases around API platform operations.

When it comes to the API Evangelist operations, the approach by Postman is gold--when I consider across many areas of my own strategy. Postman is showcased as part of my API client research, their product release exists within my embeddable API research, and also lives within my API evangelism and API partners research. The moral of this story is Postman thought across their strategy when crafting the release strategy for their new feature, and I also put in similiar thoughts across my own strategy while reading their blog post, giving us both an opportunity for establishing biggest bang possible, around a single API platform release.

API Evangelism Sometimes Seems Similar To The Environmental Discussion - What We Would Like, Does Not Reflect What Actually Happens On The Ground

I was just listening to segment on NPR, All Things Considered, about educating students around the environment. Throughout the program I couldn’t help be reminded of a similar imbalance in the world of APIs. Throughout my API experience I’m constantly faced with a separation between what I hear is possible, what I would like to see, and what actually occurs on the ground in startups, small businesses, and within enterprise organizations, and government agencies.

You might have to listen to the segment to fully grasp what I mean, but essentially it comes down to this: we’d like a perfect world where we do not negatively impact the environment, and everyone understands the urgency, but in reality there are a lot of real world constraints that prevent us from truly realizing this vision. In the world of APIs, these same constraints exist. We’d like to achieve API harmony in everything we do, but in reality there are a lot of real world constraints we have to navigate, from knowledge and education, to the time and resources needed to implement.

This chasm reflects the challenge in my API Evangelist mission. How do steer clear of selling people a single product, platform, or holistic vision of an API strategy, and break things into small, bite-size chunks of information that anyone can use (or not use) as they see fit, in the environments they operate within. I don’t believe there is a silver bullet, or single religion to follow here, it is all about staying in tune with what is working, and what is not—then making your own decisions about what is appropriate on the ground.

API Evangelist was born out of my success and failures working at SAP—which was all about striking a balance between what I knew was possible, what I wanted, and what was really possible in the environment I operated in. Alright, enough pontificating, and back to understanding all of this. I guess my point is, that this isn’t just about understanding where are going, where we’ve been or where we are currently—it is also about actually making meaningful connections that guide us, incrementally, in the right direction.

An API Evangelism Strategy To Map The Global Family Tree

In my work everyday as the API Evangelist, I get to have some very interesting conversations, with a wide variety of folks, about how they are using APIs, as well as brainstorming other ways they can approach their API strategy allowing them to be more effective. One of the things that keep me going in this space is this diversity. One day I’m looking at Developer.Trade.Gov for the Department of Commerce, the next talking to WordPress about APIs for 60 million websites, and then I’m talking with the The Church of Jesus Christ of Latter-day Saints about the Family Search API, which is actively gathering, preserving, and sharing genealogical records from around the world.

I’m so lucky I get to speak with all of these folks about the benefits, and perils of APIs, helping them think through their approach to opening up their valuable resources using APIs. The process is nourishing for me because I get to speak to such a diverse number of implementations, push my understanding of what is possible with APIs, while also sharpening my critical eye, understanding of where APIs can help, or where they can possibly go wrong. Personally, I find a couple of things very intriguing about the Family Search API story:

  1. Mapping the worlds genealogical history using a publicly available API — Going Big!!
  2. Potential from participation by not just big partners, but the long tail of genealogical geeks
  3. Transparency, openness, and collaboration shining through as the solution beyond just the technology
  4. The mission driven focus of the API overlapping with my obsession for API evangelism intrigues and scares me
  5. Have existing developer area, APIs, and seemingly necessary building blocks but failed to achieve a platform level

I’m open to talking with anyone about their startup, SMB, enterprise, organizational, institutional, or government API, always leaving open a 15 minute slot to hear a good story, which turned into more than an hour of discussion with the Family Search team. See, Family Search already has an API, they have the technology in order, and they even have many of the essential business building blocks as well, but where they are falling short is when it comes to dialing in both the business and politics of their developer ecosystem to discover the right balance that will help them truly become a platform—which is my specialty. ;-)

This brings us to the million dollar question: How does one become a platform?

All of this makes Family Search an interesting API story. The scope of the API, and to take something this big to the next level, Family Search has to become a platform, and not a superficial “platform” where they are just catering to three partners, but nourishing a vibrant long tail ecosystem of website, web application, single page application, mobile applications, and widget developers. Family Search is at an important reflection point, they have all the parts and pieces of a platform, they just have to figure out exactly what changes need to be made to open up, and take things to the next level.

First, let’s quantify the company, what is FamilySearch? “ For over 100 years, FamilySearch has been actively gathering, preserving, and sharing genealogical records worldwide”, believing that “learning about our ancestors helps us better understand who we are—creating a family bond, linking the present to the past, and building a bridge to the future”.

FamilySearch is 1.2 billion total records, with 108 million completed in 2014 so far, with 24 million awaiting, as well as 386 active genealogical projects going on. Family Search provides the ability to manage photos, stories, documents, people, and albums—allowing people to be organized into a tree, knowing the branch everyone belongs to in the global family tree.

FamilySearch, started out as the Genealogical Society of Utah, which was founded in 1894, and dedicate preserving the records of the family of mankind, looking to "help people connect with their ancestors through easy access to historical records”. FamilySearch is a mission-driven, non-profit organization, ran by the The Church of Jesus Christ of Latter-day Saints. All of this comes together to define an entity, that possesses an image that will appeal to some, while leave concern for others—making for a pretty unique formula for an API driven platform, that doesn’t quite have a model anywhere else.

FamilySearch consider what they deliver as as a set of record custodian services:

  • Image Capture - Obtaining a preservation quality image is often the most costly and time-consuming step for records custodians. Microfilm has been the standard, but digital is emerging. Whether you opt to do it yourself or use one of our worldwide camera teams, we can help.
  • Online Indexing - Once an image is digitized, key data needs to be transcribed in order to produce a searchable index that patrons around the world can access. Our online indexing application harnesses volunteers from around the world to quickly and accurately create indexes.
  • Digital Conversion - For those records custodians who already have a substantial collection of microfilm, we can help digitize those images and even provide digital image storage.
  • Online Access - Whether your goal is to make your records freely available to the public or to help supplement your budget needs, we can help you get your records online. To minimize your costs and increase access for your users, we can host your indexes and records on, or we can provide tools and expertise that enable you to create your own hosted access.
  • Preservation - Preservation copies of microfilm, microfiche, and digital records from over 100 countries and spanning hundreds of years are safely stored in the Granite Mountain Records Vault—a long-term storage facility designed for preservation.

FamilySearch provides a proven set of services that users can take advantage of via a web applications, as well as iPhone and Android mobile apps, resulting in the online community they have built today. FamilySearch also goes beyond their basic web and mobile application services, and is elevated to software as a service (SaaS) level by having a pretty robust developer center and API stack.

Developer Center
FamilySearch provides the required first impression when you land in the FamilySearch developer center, quickly explaining what you can do with the API, "FamilySearch offers developers a way to integrate web, desktop, and mobile apps with its collaborative Family Tree and vast digital archive of records”, and immediately provides you with a getting started guide, and other supporting tutorials.

FamilySearch provides access to over 100 API resources in the twenty separate groups: Authorities, Change History, Discovery, Discussions, Memories, Notes, Ordinances, Parents and Children, Pedigree, Person, Places, Records, Search and Match, Source Box, Sources, Spouses, User, Utilities, Vocabularies, connecting you to the core FamilySearch genealogical engine.

The FamilySearch developer area provides all the common, and even some forward leaning technical building blocks:

To support developers, FamilySearch provides a fairly standard support setup:

To augment support efforts there are also some other interesting building blocks:

Setting the stage for FamilySearch evolving to being a platform, they even posses some necessary partner level building blocks:

There is even an application gallery showcasing what web, mac & windows desktop, and mobile applications developers have built. FamilySearch even encourages developers to “donate your software skills by participating in community projects and collaborating through the FamilySearch Developer Network”.

Many of the ingredients of a platform exist within the current FamilySearch developer hub, at least the technical elements, and some of the common business, and political building blocks of a platform, but what is missing? This is what makes FamilySearch a compelling story, because it emphasizes one of the core elements of API Evangelist—that all of this API stuff only works when the right blend of technical, business, and politics exists.

Establishing A Rich Partnership Environment

FamilySearch has some strong partnerships, that have helped establish FamilySearch as the genealogy service it is today. FamilySearch knows they wouldn’t exist without the partnerships they’ve established, but how do you take it to the next and grow to a much larger, organic API driven ecosystem where a long tail of genealogy businesses, professionals, and enthusiasts can build on, and contribute to, the FamilySearch platform.

FamilySearch knows the time has come to make a shift to being an open platform, but is not entirely sure what needs to happen to actually stimulate not just the core FamilySearch partners, but also establish a vibrant long tail of developers. A developer portal is not just a place where geeky coders come to find what they need, it is a hub where business development occurs at all levels, in both synchronous, and asynchronous ways, in a 24/7 global environment.

FamilySearch acknowledge they have some issues when it comes investing in API driven partnerships:

  • “Platform” means their core set of large partners
  • Not treating all partners like first class citizens
  • Competing with some of their partners
  • Don’t use their own API, creating a gap in perspective

FamilySearch knows if they can work out the right configuration, they can evolve FamilySearch from a digital genealogical web and mobile service to a genealogical platform. If they do this they can scale beyond what they’ve been able to do with a core set of partners, and crowdsource the mapping of the global family tree, allowing individuals to map their own family trees, while also contributing to the larger global tree. With a proper API driven platform this process doesn’t have to occur via the FamiliySearch website and mobile app, it can happen in any web, desktop, or mobile application anywhere.

FamilySearch already has a pretty solid development team taking care of the tech of the FamilySearch API, and they have 20 people working internally to support partners. They have a handle on the tech of their API, they just need to get a handle on the business and politics of their API, and invest in the resources that needed to help scale the FamilySearch API being just a developer area, to being a growing genealogical developer community, to a full blow ecosystem that span not just the FamilySearch developer portal, but thousands of other sites and applications around the globe.

A Good Dose Of API Evangelism To Shift Culture A Bit

A healthy API evangelism strategy brings together a mix of business, marketing, sales and technology disciplines into a new approach to doing business for FamilySearch, something that if done right, can open up FamilySearch to outside ideas, and with the right framework manage to allow the platform to move beyond just certification, and partnering to also investment, and acquisition of data, content, talent, applications, and partners via the FamilySearch developer platform.

Think of evangelism as the grease in the gears of the platform allowing it to grow, expand, and handle a larger volume, of outreach, and support. API evangelism works to lubricate all aspects of platform operation.

First, lets kick off with setting some objectives for why we are doing this, what are we trying to accomplish:

  • Increase Number of Records - Increase the number of overall records in the FamilySearch database, contributing the larger goals of mapping the global family tree.
  • Growth in New Users - Growing the number of new users who are building on the FamilySearch API, increase the overall headcount fro the platform.
  • Growth In Active Apps - Increase not just new users but the number of actual apps being built and used, not just counting people kicking the tires.
  • Growth in Existing User API Usage - Increase how existing users are putting the FamilySearch APIs. Educate about new features, increase adoption.
  • Brand Awareness - One of the top reasons for designing, deploying and managing an active APIs is increase awareness of the FamilySearch brand.
  • What else?

What does developer engagement look like for the FamilySearch platform?

  • Active User Engagement - How do we reach out to existing, active users and find out what they need, and how do we profile them and continue to understand who they are and what they need. Is there a direct line to the CRM?
  • Fresh Engagement - How is FamilySearch contacting new developers who have registered weekly to see what their immediate needs are, while their registration is fresh in their minds.
  • Historical Engagement - How are historical active and / or inactive developers being engaged to better understand what their needs are and would make them active or increase activity.
  • Social Engagement - Is FamilySearch profiling the URL, Twitter, Facebook LinkedIn, and Github profiles, and then actively engage via these active channels?

Establish a Developer Focused Blog For Storytelling

  • Projects - There are over 390 active projects on the FamilySearch platform, plus any number of active web, desktop, and mobile applications. All of this activity should be regularly profiled as part of platform evangelism. An editorial assembly line of technical projects that can feed blog stories, how-tos, samples and Github code libraries should be taking place, establishing a large volume of exhaust via the FamlySearch platform.
  • Stories - FamilySearch is great at writing public, and partner facing content, but there is a need to be writing, editing and posting of stories derived from the technically focused projects, with SEO and API support by design.
  • Syndication - Syndication to Tumblr, Blogger, Medium and other relevant blogging sites on regular basis with the best of the content.

Mapping Out The Geneology Landscape

  • Competition Monitoring - Evaluation of regular activity of competitors via their blog, Twitter, Github and beyond.
  • Alpha Players - Who are the vocal people in the genealogy space with active Twitter, blogs, and Github accounts.
  • Top Apps - What are the top applications in the space, whether built on the FamilySearch platform or not, and what do they do?
  • Social - Mapping the social landscape for genealogy, who is who, and who should the platform be working with.
  • Keywords - Established a list of keywords to use when searching for topics at search engines, QA, forums, social bookmarking and social networks. (should already be done by marketing folks)
  • Cities & Regions - Target specific markets in cities that make sense to your evangelism strategy, what are local tech meet ups, what are the local organizations, schools, and other gatherings. Who are the tech ambassadors for FamilySearch in these spaces?

Adding To Feedback Loop From Forum Operations

  • Stories - Deriving of stories for blog derived from forum activity, and the actual needs of developers.
  • FAQ Feed - Is this being updated regularly with stuff?
  • Streams - other stream giving the platform a heartbeat?

Being Social About Platform Code and Operations With Github

  • Setup Github Account - Setup FamilySearch platform developer account and bring internal development team into a team umbrella as part of.
  • Github Relationships - Managing of followers, forks, downloads and other potential relationships via Github, which has grown beyond just code, and is social.
  • Github Repositories - Managing of code sample Gists, official code libraries and any samples, starter kits or other code samples generated through projects.

Adding To The Feedback Loop From The Bigger FAQ Picture

  • Quora - Regular trolling of Quora and responding to relevant [Client Name] or industry related questions.
  • Stack Exchange - Regular trolling of Stack Exchange / Stack Overflow and responding to relevant FamilySearch or industry related questions.
  • FAQ - Add questions from the bigger FAQ picture to the local FamilySearch FAQ for referencing locally.

Leverage Social Engagement And Bring In Developers Too

  • Facebook - Consider setting up of new API specific Facebook company. Posting of all API evangelism activities and management of friends.
  • Google Plus - Consider setting up of new API specific Google+ company. Posting of all API evangelism activities and management of friends.
  • LinkedIn - Consider setting up of new API specific LinkedIn profile page who will follow developers and other relevant users for engagement. Posting of all API evangelism activities.
  • Twitter - Consider setting up of new API specific Twitter account. Tweeting of all API evangelism activity, relevant industry landscape activity, discover new followers and engage with followers.

Sharing Bookmarks With the Social Space

  • Hacker News - Social bookmarking of all relevant API evangelism activities as well as relevant industry landscape topics to Hacker News, to keep a fair and balanced profile, as well as network and user engagement.
  • Product Hunt - Product Hunt is a place to share the latest tech creations, providing an excellent format for API providers to share details about their new API offerings.
  • Reddit - Social bookmarking of all relevant API evangelism activities as well as relevant industry landscape topics to Reddit, to keep a fair and balanced profile, as well as network and user engagement.

Communicate Where The Roadmap Is Going

  • Roadmap - Provide regular roadmap feedback based upon developer outreach and feedback.
  • Changelog - Make sure the change log always reflects the roadmap communication or there could be backlash.

Establish A Presence At Events

  • Conferences - What are the top conferences occurring that we can participate in or attend--pay attention to call for papers of relevant industry events.
  • Hackathons - What hackathons are coming up in 30, 90, 120 days? Which would should be sponsored, attended, etc.
  • Meetups - What are the best meetups in target cities? Are there different formats that would best meet our goals? Are there any sponsorship or speaking opportunities?
  • Family History Centers - Are there local opportunities for the platform to hold training, workshops and other events at Family History Centers?
  • Learning Centers - Are there local opportunities for the platform to hold training, workshops and other events at Learning Centers?

Measuring All Platform Efforts

  • Activity By Group - Summary and highlights from weekly activity within the each area of API evangelism strategy.
  • New Registrations - Historical and weekly accounting of new developer registrations across APis.
  • Volume of Calls - Historical and weekly accounting of API calls per API.
  • Number of Apps - How many applications are there.

Essential Internal Evangelism Activities

  • Storytelling - Telling stories of an API isn’t just something you do externally, what stories need to be told internally to make sure an API initiative is successful.
  • Conversations - Incite internal conversations about the FamilySearch platform. Hold brown bag lunches if you need to, or internal hackathons to get them involved.
  • Participation - It is very healthy to include other people from across the company in API operations. How can we include people from other teams in API evangelism efforts. Bring them to events, conferences and potentially expose them to local, platform focused events.
  • Reporting - Sometimes providing regular numbers and reports to key players internally can help keep operations running smooth. What reports can we produce? Make them meaningful.

All of this evangelism starts with a very external focus, which is a hallmark of API and developer evangelism efforts, but if you notice by the end we are bringing it home to the most important aspect of platform evangelism, the internal outreach. This is the number one reason APIs fail, is due to a lack of internal evangelism, educating top and mid-level management, as well as lower level staff, getting buy-in and direct hands-on involvement with the platform, and failing to justify budget costs for the resources needed to make a platform successful.

Top-Down Change At FamilySearch

The change FamilySearch is looking for already has top level management buy-in, the problem is that the vision is not in lock step sync with actual platform operations. When regular projects developed via the FamilySearch platform are regularly showcased to top level executives, and stories consistent with platform operations are told, management will echo what is actually happening via the FamilySearch. This will provide a much more ongoing, deeper message for the rest of the company, and partners around what the priorities of the platform are, making it not just a meaningless top down mandate.

An example of this in action is with the recent mandate from President Obama, that all federal agencies should go “machine readable by default”, which includes using APIs and open data outputs like JSON, instead of document formats like PDF. This top down mandate makes for a good PR soundbite, but in reality has little affect on the ground at federal agencies. In reality it has taken two years of hard work on the ground, at each agency, between agencies, and with the public to even begin to make this mandate a truth at over 20 of the federal government agencies.

Top down change is a piece of the overall platform evolution at FamilySearch, but is only a piece. Without proper bottom-up, and outside-in change, FamilySearch will never evolve beyond just being a genealogical software as a service with an interesting API. It takes much more than leadership to make a platform.

Bottom-Up Change At FamilySearch

One of the most influential aspects of APIs I have seen at companies, institutions, and agencies is the change of culture brought when APIs move beyond just a technical IT effort, and become about making resources available across an organization, and enabling people to do their job better. Without an awareness, buy-in, and in some cases evangelist conversion, a large organization will not be able to move from a service orientation to a platform way of thinking.

If a company as a whole is unaware of APIs, either at the company or organization, as well as out in the larger world with popular platforms like Twitter, Instagram, and others—it is extremely unlikely they will endorse, let alone participate in moving from being a digital service to platform. Employees need to see the benefits of a platform to their everyday job, and their involvement cannot require what they would perceive as extra work to accomplish platform related duties. FamilySearch employees need to see the benefits the platform brings to the overall mission, and play a role in this happening—even if it originates from a top-down mandate.

Top bookseller Amazon was already on the path to being a platform with their set of commerce APIs, when after a top down mandate from CEO Jeff Bezos, Amazon internalized APIs in such a way, that the entire company interacted, and exchange resources using web APIs, resulting in one of the most successful API platforms—Amazon Web Services (AWS). Bezos mandated that if an Amazon department needed to procure a resource from another department, like server or storage space from IT, it need to happen via APIs. This wasn’t a meaningless top-down mandate, it made employees life easier, and ultimately made the entire company more nimble, and agile, while also saving time and money. Without buy-in, and execution from Amazon employees, what we know as the cloud would never have occurred.

Change at large enterprises, organizations, institutions and agencies, can be expedited with the right top-down leadership, but without the right platform evangelism strategy, that includes internal stakeholders as not just targets of outreach efforts, but also inclusion in operations, it can result in sweeping, transformational changes. This type of change at a single organization can effect how an entire industry operates, similar to what we’ve seen from the ultimate API platform pioneer, Amazon.

Outside-In Change At FamilySearch

The final layer of change that needs to occur to bring FamilySearch from being just a service to a true platform, is opening up the channels to outside influence when it comes not just to platform operations, but organizational operations as well. The bar is high at FamilySearch. The quality of services, and expectation of the process, and adherence to the mission is strong, but if you are truly dedicated to providing a database of all mankind, you are going to have to let mankind in a little bit.

FamilySearch is still the keeper of knowledge, but to become a platform you have to let in the possibility that outside ideas, process, and applications can bring value to the organization, as well as to the wider genealogical community. You have to evolve beyond notions that the best ideas from inside the organization, and just from the leading partners in the space. There are opportunities for innovation and transformation in the long-tail stream, but you have to have a platform setup to encourage, participate in, and be able to identify value in the long-tail stream of an API platform.

Twitter is one of the best examples of how any platform will have to let in outside ideas, applications, companies, and individuals. Much of what we consider as Twitter today was built in the platform ecosystem from the iPhone and Android apps, to the desktop app TweetDeck, to terminology like the #hashtag. Over the last 5 years, Twitter has worked hard to find the optimal platform balance, regarding how they educate, communicate, invest, acquire, and incentives their platform ecosystem. Listening to outside ideas goes well beyond the fact that Twitter is a publicly available social platform, it is about having such a large platform of API developers, and it is impossible to let in all ideas, but through a sophisticated evangelism strategy of in-person, and online channels, in 2014 Twitter has managed to find a balance that is working well.

Having a public facing platform doesn’t mean the flood gates are open for ideas, and thoughts to just flow in, this is where service composition, and the certification and partner framework for FamilySearch will come in. Through clear, transparent partners tiers, open and transparent operations and communications, an optimal flow of outside ideas, applications, companies and individuals can be established—enabling a healthy, sustainable amount of change from the outside world.

Knowing All Of Your Platform Partners

The hallmark of any mature online platform is a well established partner ecosystem. If you’ve made the transition from service to platform, you’ve established a pretty robust approach to not just certifying, and on boarding your partners, you also have stepped it up in knowing and understanding who they are, what their needs are, and investing in them throughout the lifecycle.

First off, profile everyone who comes through the front door of the platform. If they sign up for a public API key, who are they, and where do they potentially fit into your overall strategy. Don’t be pushy, but understanding who they are and what they might be looking for, and make sure you have a track for this type of user well defined.

Next, quality, and certify as you have been doing. Make sure the process is well documented, but also transparent, allowing companies and individuals to quickly understand what it will take to certified, what the benefits are, and examples of other partners who have achieved this status. As a developer, building a genealogical mobile app, I need to know what I can expect, and have some incentive for investing in the certification process.

Keep your friends close, and your competition closer. Open the door wide for your competition to become a platform user, and potentially partner. 100+ year old technology company Johnson Controls (JCI) was concerned about what the competition might do it they opened up their building efficient data resources to the public via the Panoptix API platform, when after it was launched, they realized their competition were now their customer, and a partner in this new approach to doing business online for JCI.

When Department of Energy decides what data and other resource it makes available via or the agencies developer program it has to deeply consider how this could affect U.S. industries. The resources the federal agency possesses can be pretty high value, and huge benefits for the private sector, but in some cases how might opening up APIs, or limiting access to APIs help or hurt the larger economy, as well as the Department of Energy developer ecosystem—there are lots of considerations when opening up API resources, that vary from industry to industry.

There are no silver bullets when it comes to API design, deployment, management, and evangelism. It takes a lot of hard work, communication, and iterating before you strike the right balance of operations, and every business sector will be different. Without knowing who your platform users are, and being able to establish a clear and transparent road for them to follow to achieve partner status, FamilySearch will never elevate to a true platform. How can you scale the trusted layers of your platform, if your partner framework isn’t well documented, open, transparent, and well executed? It just can’t be done.

Meaningful Monetization For Platform

All of this will take money to make happen. Designing, and executing on the technical, and the evangelism aspects I’m laying out will cost a lot of money, and on the consumers side, it will take money to design, develop, and manage desktop, web, and mobile applications build around the FamilySearch platform. How will both the FamilySearch platform, and its participants make ends meet?

This conversation is a hard one for startups, and established businesses, let alone when you are a non-profit, mission driven organization. Internal developers cost money, server and bandwidth are getting cheaper but still are a significant platform cost--sustaining a sale, bizdev, and evangelism also will not be cheap. It takes money to properly deliver resources via APIs, and even if the lowest tiers of access are free, at some point consumers are going to have to pay for access, resources, and advanced features.

The conversation around how do you monetize API driven resources is going on across government, from cities up to the federal government. Where the thought of charging for access to public data is unheard of. These are public assets, and they should be freely available. While this is true, think of the same situation, but when it comes to physical public assets that are owned by the government, like parks. You can freely enjoy many city, county, and federal parks, there are sometimes small fees for usage, but if you want to actually sell something in a public park, you will need to buy permits, and often share revenue with the managing agency. We have to think critically about how we fund the publishing, and refinement of publicly owned digital assets, as with physical assets there will be much debate in coming years, around what is acceptable, and what is not.

Woven into the tiers of partner access, there should always be provisions for applying costs, overhead, and even generation of a little revenue to be applied in other ways. With great power, comes great responsibility, and along with great access for FamilySearch partners, many will also be required to cover costs of compute capacity, storage costs, and other hard facts of delivering a scalable platform around any valuable digital assets, whether its privately or publicly held.

Platform monetization doesn’t end with covering the costs of platform operation. Consumers of FamilySearch APIs will need assistance in identify the best ways to cover their own costs as well. Running a successful desktop, web or mobile application will take discipline, structure, and the ability to manage overhead costs, while also being able to generate some revenue through a clear business model. As a platform, FamilySearch will have to bring to the table some monetization opportunities for consumers, providing guidance as part of the certification process regarding what are best practices for monetization, and even some direct opportunities for advertising, in-app purchases and other common approaches to application monetization and sustainment.

Without revenue greasing the gears, no service can achieve platform status. As with all other aspects of platform operations the conversation around monetization cannot be on-sided, and just about the needs of the platform providers. Pro-active steps need to be taken to ensure both the platform provider, and its consumers are being monetized in the healthiest way possible, bringing as much benefit to the overall platform community as possible.

Open & Transparent Operations & Communications

How does all of this talk of platform and evangelism actually happen? It takes a whole lot of open, transparent communication across the board. Right now the only active part of the platform is the FamilySearch Developer Google Group, beyond that you don’t see any activity that is platform specific. There are active Twitter, Facebook, Google+, and mainstream and affiliate focused blogs, but nothing that serves the platform, contributed to the feedback loop that will be necessary to take the service to the next level.

On a public platform, communications cannot all be private emails, phone calls, or face to face meetings. One of the things that allows an online service to expand to become a platform, then scale and grow into robust, vibrant, and active community is a stream of public communications, which include blogs, forums, social streams, images, and video content. These communication channels cannot all be one way, meaning they need to include forum and social conversations, as well as showcase platform activity by API consumers.

Platform communications isn’t just about getting direct messages answered, it is about public conversation so everyone shares in the answer, and public storytelling to help guide and lead the platform, that together with support via multiple channels, establishes a feedback loop, that when done right will keep growing, expanding and driving healthy growth. The transparent nature of platform feedback loops are essential to providing everything the consumers will need, while also bringing a fresh flow of ideas, and insight within the FamilySearch firewall.

Truly Shifting FamilySearch The Culture

Top-down, bottom-up, outside-in, with constantly flow of oxygen via vibrant, flowing feedback loop, and the nourishing, and sanitizing sunlight of platform transparency, where week by week, month by month someone change can occur. It won’t all be good, there are plenty of problems that arise in ecosystem operations, but all of this has the potential to slowly shift culture when done right.

One thing that shows me the team over at FamilySearch has what it takes, is when I asked if I could write this up a story, rather than just a proposal I email them, they said yes. This is a true test of whether or not an organization might have what it takes. If you are unwilling to be transparent about the problems you have currently, and the work that goes into your strategy, it is unlikely you will have what it takes to establish the amount of transparency required for a platform to be successful.

When internal staff, large external partners, and long tail genealogical app developers and enthusiasts are in sync via a FamilySearch platform driven ecosystem, I think we can consider a shift to platform has occurred for FamilySearch. The real question is how do we get there?

Executing On Evangelism

This is not a definitive proposal for executing on an API evangelism strategy, merely a blueprint for the seed that can be used to start a slow, seismic shift in how FamilySearch engages its API area, in a way that will slowly evolve it into a community, one that includes internal, partner, and public developers, and some day, with the right set of circumstances, FamilySearch could grow into robust, social, genealogical ecosystem where everyone comes to access, and participate in the mapping of mankind.

  • Defining Current Platform - Where are we now? In detail.
  • Mapping the Landscape - What does the world of genealogy look like?
  • Identifying Projects - What are the existing projects being developed via the platform?
  • Define an API Evangelist Strategy - Actually flushing out of a detailed strategy.
    • Projects
    • Storytelling
    • Syndication
    • Social
    • Channels
      • External Public
      • External Partner
      • Internal Stakeholder
      • Internal Company-Wide
  • Identify Resources - What resource currently exist? What are needed?
    • Evangelist
    • Content / Storytelling
    • Development
  • Execute - What does execution of an API evangelist strategy look like?
  • Iterate - What does iteration look like for an API evangelism strategy.
    • Weekly
    • Review
    • Repeat

AS with many providers, you don’t want to this to take 5 years, so how do you take a 3-5 year cycle, and execute in 12-18 months?

  • Invest In Evangelist Resources - It takes a team of evangelists to build a platform
    • External Facing
    • Partner Facing
    • Internal Facing
  • Development Resources - We need to step up the number of resources available for platform integration.
    • Code Samples & SDKs
    • Embeddable Tools
  • Content Resources - A steady stream of content should be flowing out of the platform, and syndicated everywhere.
    • Short Form (Blog)
    • Long Form (White Paper & Case Study)
  • Event Budget - FamilySearch needs to be everywhere, so people know that it exists. It can’t just be online.
    • Meetups
    • Hackathons
    • Conferences

There is nothing easy about this. It takes time, and resources, and there are only so many elements you can automate when it comes to API evangelism. For something that is very programmatic, it takes more of the human variable to make the API driven platform algorithm work. With that said it is possible to scale some aspects, and increase the awareness, presence, and effectiveness of FamilySearch platform efforts, which is really what is currently missing.

While as the API Evangelist, I cannot personally execute on every aspect of an API evangelism strategy for FamilySearch, I can provide essential planning expertise for the overall FamilySearch API strategy, as well as provide regular checkin with the team on how things are going, and help plan the roadmap. The two things I can bring to the table that are reflected in this proposal, is the understanding of where the FamilySearch API effort currently is, and what is missing to help get FamilySearch to the next stage of its platform evolution.

When operating within the corporate or organizational silo, it can be very easy to lose site of how other organizations, and companies, are approach their API strategy, and miss important pieces of how you need to shift your strategy. This is one of the biggest inhibitors of API efforts at large organizations, and is one of the biggest imperatives for companies to invest in their API strategy, and begin the process of breaking operations out of their silo.

What FamilySearch is facing demonstrates that APIs are much more than the technical endpoint that most believe, it takes many other business, and political building blocks to truly go from API to platform.

Financial Data Aggregator Yodlee Looking For A Director of Developer Evangelism

I spoke with the leading financial data API aggregation providers Yodlee last week, regarding their hunt for a director of developer evangelism. Yodlee provides an aggregation API that is designed for developers who need secure access to their users’ bank, credit card, investment, and loan accounts—if you think about it, this is a pretty critical API, in what we are all calling the “API Economy”.

Yodlee isn’t just looking for a junior evangelist, they are looking for a director—someone to lead the charge, when it comes to evangelizing Yodlee to potential API consumers, while also supporting the community and applications that are already integrated with the financial data aggregation platform. While there are well published job descriptions for the API evangelist role, there are no universities training up, cranking out the next generation of evangelism leaders—they are a unique breed, leaving a major hurdle for API providers like Yodlee to jump.

Evangelists are equal parts engineer, business development, product development, sales, and marketing—a combination that is not easy to find. Yodlee and I discussed the difficulties of finding the right candidates for the role, and whether or not you emphasize the technical or the marketing skills? There are extremely few candidates who know they are evangelist material, you often have to sculpt one out of many different personality traits, and both technical and business skils.

Evangelism talent, at both junior, and leadership levels is going to continue to be a major stumbling block for the expanding API economy. Even with some movement in the world of API discovery in 2014, we will never be able to fully automate API discovery, let alone evangelism, management and support. At some point we are going to need more agencies, and institutions focusing on training up the next generation of evangelists, similar to social media marketing did in the last 5 years—of course, hopefully we can scale a little more sensibly, than the social media marketing world did.

If you are interested in the developer evangelist position at Yodlee, head over to the recruiters site, and let them know I sent you.

If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.