General evangelism around what APIs are, as well as more precise advocacy around specific APIs or groups of API resources takes a lot of work, and repetition. Even as a seasoned API evangelist I can never assume my audience will receive and understand what it is that I am evangelizing, and I regularly find myself having to reassess the impact (or lack of) that I’m making, retool, refresh, and repeat my messaging to get the coverage and saturation I’m looking for. After a decade of doing this, I cannot tell which is more difficult, internal or external public evangelism, but I do find that after almost 10 years, I’m still learning from each audience I engage with—-proving to me that no single evangelism strategy will ever reliably work, and I need a robust, constantly evolving toolbox if I am going to be successful.
I have many different tools in my internal evangelism toolbox, but I find that the most important aspect of what I do is repetition. I never assume that my audience understand what I’m saying after a single session, or simply by reading one wiki page, blog post, or white paper. Quality internal evangelism requires regular delivery and enforcement, and an acknowledgement that my first engagements with teams will not have the impact I desire. When it comes to internal evangelism, I tend to encounter the following phases when engaging with internal teams:
- Silence - The first time I present material to internal teams I almost always encounter silence. Teams will often listen dutifully, but rarely will engage with me, ask questions, and want to get to the details of what is going on. I can rarely assess the state of things, and find that the silence stems from a range of emotions, ranging from not caring at all, to being very distrustful of what I am presenting. I can never assume that teams will care, trust me, and that silence is always a sign of the work that lies ahead of me, and I immediately get to work scheduling additional sessions with each team I’m trying to reach.
- Challenges - Usually by our second or third encounter with internal teams I will begin to get a little more than just silence, however it almost always comes in some aggressive form. Developers love to challenge what you are proposing, tearing things down before they ever understand what is happening. It is actually part of the natural cycle for them. Technical folks are used to taking things apart, ripping them into pieces, to see what they are all about, and what they are made of. It is easy to take this type of response in a negative and personal way, but it is the way technical minded folks see the world, especially when faced with something they do not understand, and are uncomfortable with. To survive this phase you have to have a lot of self-confidence and know your stuff, otherwise you will be eaten alive.
- Questions - After surviving the aggressive challenges about what APIs are all about and what they mean to a company, organization, institution, or government agency, I usually begin getting some more constructive questions. Moving beyond the desire to rip you to pieces, and actually start the process of actually understanding what is happening when it comes to providing and consuming of APIs. Again, you have to really know your stuff to be able to survive this line of questioning from often very smart, very technical, and inquisitive folks. However, if you come prepared, this is where you start seeing the ROI on your internal evangelism efforts.
- Engagement - I usually do not see real engagement from teams for at least 1-6 sessions. Depending on the team, they’ll take more or less time to get through the painful aspects of understanding what is going on. Depending on the type of development team, what their experience levels are, and the environments they’ve been working in, they will respond very differently. You will have to be patient to be able to reach the phase where teams actually become engaged, are able to contribute to the conversation, and take what you’ve presented and apply it to their daily work. Moving beyond just evangelism, and actually beginning to see real business value from sharing of API knowledge.
Depending on the organization culture, these four phases could take days, weeks, or months. Not all teams will be ready for what you are evangelizing. You cannot assume that teams understand what you are talking about, and that they see you as a messenger of a positive future. I’d say about 70% of the time I am seen as a hostile actor, coming in to disrupt, change ,and mess with people’s world. I don’t care how well honed my message, materials, and vision is, if I cannot connect with teams on a human and professional level–I will fail. I’ve been practicing my delivery of 101, intermediate, and advanced API material for a decade, and I still get eaten alive on a regular basis within startups, the enterprise, government agencies, and at conferences. There is no amount of preparation that will shield you from the intensity that internal development teams can bring to the table–this game isn’t for rookies.
Internal API evangelism and advocacy within the enterprise is not something you can do from high up on the mountain. You have to be able to come down from your management, architect, and executive horse, and be able to see things from the view of those in the trenches trying to get work done on a daily basis. If you can’t be seen as someone looking to build bridges between management and development ranks, your information will never be received. No amount of evangelism will cross the Grand Canyon that exists between business and technical groups in some organizations, if you aren’t willing to build bridges. Something that will take some serious planning, repetition, and tactical agility when it comes to the delivery of relevant information that is tailored for your intended audience. Internal evangelism is hard work, and something that will take regular auditing and retooling before you will ever see the impact you desire.
