You sell products to developers. By now, you should be acutely aware of the fact that those very developers are increasingly, if not directly, influencing decisions related to purchasing of software technology, such as cloud platforms, frameworks, and tools. Engaging with developers, and the developer community, is not a nice to have, it is a necessity for survival. Per RedMonk cofounder Stephen O'Grady, author of “The New Kingmakers”, developers are the most important, most valuable, constituency in business today, regardless of industry. Technologists are no longer content to be mere stage players. They are taking an active hand at direction.
With developers’ increased power over what technologies a company will be deploying, your business needs to position itself as a respected and trusted adviser to these developers.
Microsoft, Oracle, and SAP among others have been wrestling with these types of issues for years. Microsoft has done a phenomenal job rebooting itself in the image of the modern, millennial, developer with aggressive investments in the developer ecosystem targeting the source of influence for these communities. Knowing full and well that this is a long term commitment that will not change its quarterly results in the short term, but position the company for growth in the long run.
For any organization approaching a developer relations mission, you must understand that this is a long term commitment measured in years not quarters.
When it comes to developer relations, people often bring varying mental models. This variation can lead to initial agreement on a course of action that goes terribly wrong upon execution. Since you rarely get a second chance in developer relations, it is important to carefully define and consider the various aspects of each program.
To better understand what is needed and what to avoid it is imperative that we have an understanding of common definitions in the modern developer ecosystem.
A developer is an individual that builds and creates software and applications. They are no longer content to be mere stage players, and are taking an active hand at direction.
Developers are generally immune to traditional marketing tactics:
- Print ad placement is ineffective because they consume online
- Online ad placement is ineffective because they use ad blockers
- Forced registration is ineffective because they do not care about white papers
- Media is ineffective because they generally feel they know more
- Analyst webinars are ignored because they are seen as lagging in new technology
- Ignores conferences featuring company executives
A person who seeks to convert others to the faith, especially by public preaching. This is the genesis of what most people refer to as "advocate" in today's business. The term was largely dumped due to the religious connotation, though it still accurately sums up the dominant means of communication. This is generally a company-outward communication effort. The mindset is useful in establishing a presence in a market that does not yet exist, or that is under-represented. Also useful for maintaining customer excitement in well established markets.
A person who publicly supports or recommends a specific cause or policy. This is generally a developer-in activity. It excels at providing guidance through extensive developer contact in the trenches of a mature technology. Advocates are for developers, not technologies, nor products. That is to say that an advocate should act as the voice of the customer inside the company, not the voice of the technology or product outside of the company.
A feeling of ownership with others, as a result of the sharing of common attitudes, interests, and goals. Technology stacks can have communities, but companies can have communities as well. The body of a corporate community should consist predominantly of customers. Well run communities can greatly amplify marketing efforts.
Developer relations is a long-term, strategic, investment. An operational charter of advocates and evangelists should be to plot where technologies will be in one year, and to seeding those concepts in the market in the present. Without a long-term investment, relationships cannot be established. Worse is when a long-term investment is one only long enough to gain developer attention, and then is cancelled. The sudden lack of support creates a vast audience of developers that will never recommend your product again.
Do you know your top 100 developers? Do you listen to what they say? Do you take action? What are their kids’ names? All parties in a developer relations effort must build relationships first, not customers. Relationships build trust. Once developers trust your company, only then will they make recommendations in your favor.
To explore this further, it is likely that you have neighbors where you live. You smile at one another when mowing the lawn. You wave as you pull out of the driveway on the way to work in the morning. All is well, but there is nothing more than a passing acquaintance. If your neighbor came over and asked to borrow a large sum of money, you would most likely not be investing in their cause. Unless however you had a deeper relationship with the neighbor. Your kids played together regularly. You have eaten at each other’s house many times before. You know that your neighbor is a successful investment banker. You are going to think twice about making an investment because you trust that neighbor.
Developers are probably already aware of your company and/or products on some level. This may be only a passing acquaintance, but they do not trust your product automatically. If we get to know them, and they get to know us, and a relationship is established, developers will be more likely to at the very least take a look at software we provide. Thus is the function of developer relations.
WHAT IT IS NOT: Developer relations cannot fix poor products. If the product is half-baked when the developer relations team gets to a point where they can recommend software, the result will be damaging to both the company and the advocate. The product must shine. No amount of developer relations can fix crappy products.
WHAT IT IS NOT: While marketing and sales are functions of developer relations, they are not the primary driver. This concept does not often sit well with executive management. Sales "pushes" products. Marketing "pushes" products. Developer relations is a function of engineering, and as such, it should work feverishly to enable "pull" for your product vertical (or horizontal) as a concept.
Developers are intrinsically curious by nature and establishing a developer relationship based on trust, authenticity, honesty, and focus on offering solutions to problems will enable your business to awaken the curiosity in your technologies e.g. creating “pull”. Along the path to building trust is attendance and participation in communities and events. Developer relations team members should attend events regularly, simply to attend, participate, and be involved in the discussion. Attempt to be everywhere your key concepts are being discussed. Talk to developers, not at them. Listen. Attendance and participation are key characteristics of being actively involved in a community.
The ultimate goal of an advocate is to create a community of evangelists beyond the corporate walls - effectively putting themselves out of a job.
An acronym commonly used by sales is "IHAC" which stands for "I have a customer". You might start an email exchange with your inside sales team using "IHAC" and then listing out special circumstances. For developer relations, that term should shift to become "IHAF" – “I have a friend”.
It is not uncommon for developer relations to encounter first-of-kind projects by way of friends bouncing ideas off of one another. These types of projects should be expected, welcomed, and funded. An advocate, sitting side-by-side with a developer helping them bring a concept to life, far outweighs the cost of their presence.
There are generally two types of advocates. Clearly, not every advocate is going to be up to the task of sitting with a developer through initial brainstorming of a concept. That advocate must have deep knowledge of that specific domain. Likewise, it is important to inspire developers to be more - to challenge them to try new techniques, approaches, and technologies that they may not have previously found interesting.
- Describes solving real-world problems with existing technology
- Focused on helping customers in production scenarios
- Help the developer bridge the gap between demo and production
- Describes new and potential technology scenarios
- Focused on the cool, new, bleeding edge
- Helps developers visualize the potential of a given technology or concept
WHAT IT IS: What can I do to make any given developer the hero for what they are trying to accomplish.
IBM Founder, Thomas Watson, famously laid out three core directives for employees at IBM. These directives “Trust and personal responsibility in all relationships”, “Dedication to every client's success”, and “Innovation that matters” align perfectly with the goal of developer relations. We would like to change “Dedication to every client’s success” to "Dedication to every developer's success" because developers are our clients.
WHAT IT IS NOT: A developer advocate is NOT a replacement for sales, sales engineering, sales-support, or product marketing. It is NOT a staffing service to be called upon to close deals or market a product. A developer advocate always strives to ensure your company’s success, and one way of doing this is to enable sales and sales-support staff to be great at their jobs by training them on how to engage with the modern, millennial, developer.
When a developer asks for help, telling them that they can find the answers in the documentation, is not an example of personal responsibility. Personal responsibility would be getting direct links to the answers needed by the developer, at the very least.
Showing dedication to the cause of the developer, to make them a success (hero), would be taking the next step, and scheduling an online meeting for hands-on knowledge transfer.
WHAT IT IS NOT: Looking closely at these two directives should make it instantly clear as to why developers relations metrics need to be carefully considered. Advocates will not be inclined to help a developer be a hero if they are motivated by bulk numbers.
The importance of solid products cannot be understated. The best products enable you to do something you could not do five minutes before you discovered the product. If it does not enable you to be successful, it is not innovation that matters. Focus all your effort on making sure you have a good product first and foremost.
Listening and hearing are two different things. Listening takes energy. If you are hearing your developers, but not listening, then you do not have a relationship with them. No relationship, means no trust. No trust means no product usage. Feedback must be taken to heart, and acted upon.
Developers deal in true and false all day long. The moment anything deviates from that; it raises a red flag. Developer relations should not give solutions to problems that do not exist. Presenting solutions (e.g. developer scenarios) is sure to be communicated to the developer as a sales and/or marketing pitch. To think that you know the struggles that a developer is facing, specific to their industry, lacks the interest necessary to build a relationship.
You should understand the complete context of where the developer is coming from. The quicker you can connect them with somebody that knows the answer, the faster they will trust you - and contact you again. Developers should feel as though the advocate would be capable of doing their job.
WHAT IT IS: Developer relations should genuinely care about developers and their success. You can copy competitors all day long, but it is the heart of the organization that makes the difference.
Further directives to consider might be around the concept of “being essential.” Do not be a “money machine.” Do not be “driving developers.” Be essential.
- Put the developer first
- Listen for need and envision the future
- Share expertise
- Relentlessly reinvent
- Dare to create original ideas
- Treasure wild ducks
- Think, prepare, rehearse
- Unite to get it done now
- Show personal interest
Involvement in standards and open source bodies is important. It is simply not feasible for contributors to be at every event, nor have the time (and/or patience) to help developers be heroes. Advocates bring scale to this equation. Advocates should strive to be extremely active in these communities; in addition to organizing and hosting local user groups, when possible they should hold positions on boards or committees, become active organizers for conferences (nearly all conferences will gladly accept help from well-organized technologists when it comes to putting together events), and of course be developers (commit code, fix bugs, help maintain a positive and constructive tone in these communities). Without active involvement like this, developer advocates risk losing their hard-earned legitimacy in these communities. This aspect of the job may consume as much as 50% of their time.
WHAT IT IS: Advocates should be skilled at the art of "facilitating serendipity." Their professional network, cultivated by being involved in events (talk to developers, not at them), presents the opportunity to make heroes.
Making heroes, makes community, and funnels customers to the top of the revenue graph.
WHAT IT IS: While advocates are free from carrying sales or marketing numbers, they still need to respect that they work for, and are paid by, a specific company for a specific reason. Being afraid of sales conversations when presented the opportunity is unacceptable. If such an opportunity arises it is important that the advocate connect the customer with the right salesperson WHILE maintaining the customer’s trust, independence, and integrity.
As an example, it is not uncommon to be asked about costs by a customer at a presentation. Advocates should have a general sense as to the cost of the products they are presenting, and how they compete in the technology landscape. Advocates are free to refer to prices listed online, but should refrain from offering specific numbers or price proposals. Likewise, situations may present themselves where the advocate and corporate sales are in the same meeting with the customer. While the advocate should not violate the personal integrity, it is important to respect the goal of the sales team. Saying bad things about your product to customers in such a setting is not appropriate behavior.
Keeping up with technology presents a very real challenge for developers. Offline meetings focused around technologies (not companies), helps to stay current and explore options. Meetups and user group meetings are not formal marketing events.
The personal brand of an advocate is just as important as the corporate brand. Advocates should have a social presence all their own. This plays a key role in building authentic relationships with developers.
Written articles and content follow the long tail. Their persistence over time provides extended reach. Metrics for volume or popularity (a) ignore the long tail and (b) drive technically shallow content. IBM release cycles are not our customers release cycles. Broader adoption can take months or even years. Shallow content results in frustration and abandonment. High quality, deeply technical content is key.
Be aware of the signal-to-noise ratio your business makes. Too much marketing noise can make finding the one thing a developer wants, very difficult. Creating relationships builds signal and reduces noise. Implementation
Developer "Wow!" moments are features that can be live-coded completely in the span of a 45-minute conference session. Find the “Wow!” moments in your product(s). Developer relations should lean into product groupings that deliver "Wow!" moments.
There is a difference between measurement and metrics. To savvy developer advocates, metrics present an opportunity to game the system. In an increasingly digital world, this has become easier for a skilled developer to accomplish. Getting more tweets is a simple matter of a few hours with the Twitter API, and a little splash of bot code.
Measurement however presents data - and developers love data. They love to generate it, analyze it, and discover trends from it. To that end, it is far more effective to measure every possible detail of developer relations that is reasonably possible, than to assign metrics. Evaluating results over time presents a general understanding of performance.
It is at the discretion of each developer advocate to engage with companies to get insight around sentiment, and help build developer relationships.
It is critical to participate in conferences and groups - not just attend them to speak, and then leave. Attend sessions. Meet exhibitors.
Developers in a conference audience will research you. Personal brand ensures credibility. Content also has a "long tail" of discovery.
Sometimes you meet somebody that would turn into a champion, if only you had the time to spend with them. Do that.
It is important to remember that advocates are people, too, not just cogs in your sales machine. Advocates need time to explore new directions for personal and professional career growth.
It may be preferential to think of your developer relations organization as a cost of doing business. Think of it as the accounting department. The accounting department needs to exist in a company, but there are no “active developer” KPIs assigned to it. Without an accounting function, a company would be lost. The same is true for developer relations if you are a company that sells products to developers.
That being said, what you measure informs the strategic decision you choose to take with your products. If you measure the wrong things, you could end up wasting time on the wrong initiatives. For developer advocacy the number one priority is to gain developers trust and respect, internally and externally, and help developers solve problems and become successful using your company’s technology. You cannot measure trust or respect, it is a non-measurable effort. You can measure NPS (Net Promoter Score) and how that improves over time for your company, but not on a specific team nor team member.
If developer advocates are focused, measured, on pouring developers into the top of the funnel they are not going to focus on making sure those new developers become engaged, productive developers with your products. The developer relations organization should be aligned with gaining external developers' trust, respect, and how to help them become successful developers with your product(s) (which ultimately impacts the bottom line). It is important that your company makes sure that developers have a great experience from sign-up to first deployment, and to set them up for long-term success.
This is why vanity metrics are so dangerous to companies. They are not just misleading to the outside world — they can start a vicious-cycle. You use a metric because it makes your company (or team) look good, and because you start tracking it, you want it to continue to increase, so you start optimizing for it. This will take you down the wrong path. This is you should carefully consider what, if any, metrics you place on the developer relations team or individual contributors, but measure and track everything we do to ensure that we know that we are doing the right things, and that, if needed, we can course correct quickly if the impact is not what we expect.