Kris Bondi is a CMO who is very focused on adoption and developer or DevOps community engagement. She has served as CMO of Neura Inc, LogDNA and Bitnami, which was acquired by VMware. Since 2016, she has been a program advisor to HeavyBit Industries, helping early stage companies refine their go-to-market strategies. Kris and I worked together when she was vp of global marketing and I was a developer advocate at Iron.io. I'm grateful that she's able to sit down with us about the often controversial relationship between DevRel and marketing.
Table of Contents
- What traits to DevRel and marketing share?
- How can DevRel and marketing enable each other?
- How do you remain authentic?
- As a marketer, what's your golden rule?
- What can't you do any other way?
- How do you measure community engagement?
- How is DevRel perceived in the boardroom?
- How do you build out a strong DevRel team?
- Who is doing developer relations effectively?
Q: Kris, you come to DevRel with the trained eye of a CMO. What traits do effective developer relations and effective technical marketing have in common?
Both developer relations and marketing programs work best when you are not obsessed with the short term sale, but rather focused on how your product works within a larger ecosystem, and why developers use your product. So for example, if my company is in the Cassandra space, my DevRel and marketing teams may focus on the Big Data communities adjacent to it. Your company doesn't stand alone, it's always part of a larger ecosystem.
As an example, when you look at a really good CNCF project, you'll notice a lot of people contributing either independently or part of different companies. Those contributors and community members have come together and decided that they're going to use this project as a way of contributing to a common cause. They're contributing to a community effort. A company that focuses solely on their own products doesn’t understand that isn’t the way the world works anymore. Even if that company is initially successful, it will never reach the same level of success as if they genuinely care about the community. (This also applies in the consumer world as well, but that’s not where I spend my time.)
If someone is looking to get into the right mindset for this, there’s a great book that is seemingly unrelated called It Takes a Tribe, by Will Dean, the creator of the Tough Mudder racing series. He talks about creating races that are purposely designed not as a competition but as something most people can’t complete without the help of others.
Q: With so much common ground, how can developer relations and marketing teams enable each other?
Developer relations is a marketing function. Developers will often say that they hate marketing; I argue they hate bad marketing. If I am selling to you and pushing, pushing, pushing-- well, that’s just sucky marketing. Your most effective marketing efforts will be built around education, because that lays the groundwork for future communication. Providing valuable information to targeted developer communities is marketing. Even when it isn’t officially part of the marketing team, DevRel is performing a marketing function and needs to be integrated with the marketing functions.
On the other side, developer relations teams often don't get enough credit for users and customers who have signed up or increased usage as a result of their DevRel efforts. For example, if a developer advocate has been on a podcast, or written an article, or run a workshop with a partner organization and that effort generates a future customer, DevRel should get credit. Unfortunately, these efforts are not always effectively tracked. Doubling down on this narrative, the users that come from DevRel efforts are often more valuable than a lead acquired from what is assumed to be traditional demand gen such as a white paper download or someone responding to an ad. The contacts coming out of the DevRel experience are more educated and more loyal because they’ve had a more authentic experience. The reality is you need both types of experiences.
Q: How do you remain authentic in developer relations and marketing?
Authenticity is about who you hire. I’ll give you an example of authenticity done poorly: A number of years ago I was at a Go conference, where my company had some speaking spots and a booth. I was at the booth with our developer community manager, Cassandra Ferrara, who has gone on to an impressive career as a DevRel leader. Cassandra is not only smart, she truly loves the developer communities that she’s a part of. Next to us was a booth of a vendor whose booth staff casually said something to imply that he did not think highly of the conference attendees: “Oh I drew the short straw, now I have to stand here and deal with developers all day.” My response was “Our company founders are developers, and developers are the reason we have a company.” He happened to be a salesperson, but no matter their role, that attitude infuriates me. If your company and staff are not supportive of the developer community, then you need to find a different industry! Engaged developer communities are the reason your company exists. If you are rolling your eyes and thinking developers are difficult, there are plenty of industries for you. Go sell insurance. In our world, it is necessary to truly love technology and respect the community.
I realize that because of my title as CMO there are limitations of what kind of authentic communications I am effective at, so I take a lead from the dev advocates where I work. Our developer advocates function as a feedback loop into the company. The reason why I have started giving people the title of developer advocate as opposed to developer relations is that these people are not only evangelizing about our products, but are also advocates for developers or DevOps inside the company. In other words, their job is to not only communicate about the company and our industry, but to give feedback to our company, our product team, and the marketing team overall about what’s happening in the community.
Your company and staff remain authentic by becoming engaged in your community. That means you need multiple people in the company engaged in the community, whether it’s attending meetups, online events, writing articles, tweeting, going to events, etc. Part of the secret to doing this well is to have people engage in whatever way feels the most comfortable to them. Not everyone is comfortable presenting or writing, but if you have a team member who wants to become involved, you can find a way that works well for them. This again speaks to the need for an integrated approach. If you have one person or a group of people who are off to the side as your DevRel team and not integrated, it’s difficult for the company to be authentic, no matter how effective that DevRel team is.
One of the favorite things about Bitnami, was that so many people in the company were engaged with the community. Bitnami didn’t have an official DelRel title, but many people in the Kubernetes community will know Adnan Abdulhussein for all his project contributions. Adnan was a software engineer at Bitnami, but he does everything I love in a DelRel pro. He participates in the community because he truly cares about it. At every company I join, I encourage employees throughout the organization to care and engage with the communities we serve. Being part of external communities seems to bring an internal community into the company, and makes the company a better place for everyone to work. It also attracts other enthusiastic talent.
Q: As a marketer, do you have a golden rule when approaching developers or DevOps?
I started my career as a journalist, so everything for me starts with a story. From that story, you identify how to engage people and why they care. The core of each story is always the same, but how you communicate it is different depending on what your audience cares about and their priorities. For example, If I’m a developer, and I have five urgent things on the list of things that I need to focus on, just because your tool will enable me to do a sixth thing, that doesn't automatically make me care. Make me care! Tell me, for example, that I can easily drop code into a YAML file and it’ll enable something needed in the build and deployment process, and will get me the end result I want. Don’t just tell me “Oh you’ll be able to do this thing in deployment” that I don’t care about. A lot of what marketing needs to do is focus on the full business and the full business includes education and adoption. In fact, if you’re in a DevOps world that should be a core piece of your efforts.
Q: In your optimal world, what are you able to accomplish with DevRel that you can’t do any other way?
I often talk about engagement and adoption and how they’re interconnected, but there is something that goes a step farther. There’s a drum I’ve been beating that is sometimes misunderstood. The ideal approach to communities is to be part of a movement, but I don’t mean a sales movement. I think it’s more important than ever for people to feel that they’re part of something bigger. Kubernetes, I would argue, is not only orchestration but a movement: it’s a different way of approaching things. We have it in our regular lives, being part of the Black Lives Matter movement, that’s bigger than yourself. Companies do themselves a disservice when they focus so much on themselves that they don’t think about how they fit into the rest of the world or what they’re really enabling. They also hurt themselves if they consider DevRel function the “other.” If they have a DevRel function as an afterthought or a separate piece as opposed to “this is who we are,” they are doing a disservice to their users, their potential users, and quite frankly to the people on the DevRel team.
Q: You've spoken emphatically about the value of community engagement, and also some common missteps. On the flipside, how should companies approach measuring the value of their community engagement?
Laura Santamaria is a great developer advocate with whom I worked who used an engagement tracking form when she was out and about. It’s pretty straightforward with questions such as: How many people attended my talk? With how many people did I speak one-to-one? How many of these people signed up for a trial? How many talks or written pieces have come from me helping someone else in the organization? For most organizations, I don’t think this level of detail is needed, but if an organization is KPI- or MBO-heavy and looking for a results-oriented approach to measurement, this is much better than tracking how many times someone presented at a meetup.
Beyond the initial engagement, DevRel, and marketing overall, should be affecting the selling process. For example, if someone is in a sales cycle and they engage with DevRel, they are likely to move fast in the selling or onboarding process. This is where attribution and advanced attribution comes in: not only tracking from where a lead comes, but also tracking the trigger point that caused them to be more active. Because DevRel may contribute to adoption, it has revenue implications, particularly for companies with a usage-based billing. It also helps reduce churn and contributes to upsell.
There’s another tactic I actually hate: when young companies try to go-to-market through hackathons. I came into a company and their initial approach was to do a lot of hackathons. While reviewing the adoption trend numbers with the operations person, I asked “On this chart, I see that in December there’s a big upswing in usage, then it falls in February and again in March. The usage in March looks like the usage in November. What happened?” The answer: it was a hackathon go-to-market approach.
If people don’t see any long term value from using your technology and are just using it for a prize at a hackathon, you’ll end up with a bunch of unsupported apps and no real growth — from that perspective it was a waste of time. Hackathons are good for education, but not as a go-to-market strategy. Once we put a true go-to-market strategy in place, you could see a steady increase. We went from 5,000 end users deployed (where the company was after those hackathons) to a million end-users within nine months. If I was just measuring initial engagement, I would be happy with hackathons. That leads to my last measurement-related point: measure based on how an action can affect something (engagement, conversion timeline, adoption), not just to collect data points.
Q: One perspective I think many DevRel professionals would be interested in is your knowledge of how developer relations is perceived at the executive level and in the boardroom. What can you tell us?
From a high level, from the business perspective, we look at DevRel as the engagement and adoption function. To have a successful DevRel program, you need other things to be happening in parallel. For example, the best developer or DevOps-focused companies have a clear business model, enabling them to know from where their revenue is actually coming. They understand how to move from users to buyers. That’s not a DevRel responsibility, but without the engagement and adoption work the buyers won’t purchase.
The companies that aren’t successful expect DevRel to be sellers (that’s never a good thing). These companies haven’t thought through their path to revenue. There was one point a few years back where “every company should have open source and then the revenue will just come.” Obviously, there needs to be actual thought into licensing and an actual business plan.
When you ask about how DevRel is seen at the board level, it ultimately comes down to the experience of the board members. Many board members, because they are investors, have become more sophisticated about what the business plan is and how the developer community fits into it. However, it takes a go-to-market person to come in and explain how DevRel fits into the company’s plans. The board’s job isn’t to dictate; the board approves.
Q: How do you build out a strong DevRel team?
It's important that your developer relations team knows what’s expected of them. My approach has always been to customize the DevRel role to that individual person. If you’re somebody who loves to write, I’ll make a chunk of your role writing-based. If you are someone who loves to do presentations but is less interested in writing, we’ll lean on you to do more presentations. That’s not something I knew originally, but that’s a way I’ve grown as a manager: I’m much more flexible around playing to somebody’s strengths rather than writing a job spec and expecting somebody to be a perfect fit.
I also think that for smaller teams, the first person in the door has to establish things, but they also get to select which part of the role they will specialize in, especially if you know that a second and third hire is coming. This specialization can help guide who you look for in future hires, and can make your team members happier overall and improve their work quality. There are some people who want to code and want to be involved in projects — if I can have somebody on my team who is spending a lot of time contributing to one or two open source projects, and have my company listed as a contributor to those projects, that is incredibly valuable. Your software engineers are probably already doing this; even if they are not listed with a DevRel title, they are doing developer relations work.
Q: Who in DevRel would you like to call out?
OpenTech Response OpenTechResponse is the group that has created the open community’s crisis response framework. Like any open source collaboration, it came out of a driving determination to fund a way for technology to help a larger need. In this case, it was how the open communities can respond to COVID-19 as well as future crises.
While OpenUK CEO Amanda Brock, DataStax VP of DevRel Patrick McFadin, and OpenTeams CTO and Co-Founder David Charbonbeau, and myself have each brought our expertise to shape OpenTechResponse, ultimately it’s the developers who are volunteering for COVID-19 response-related projects that will make the difference. To help people find projects in need of their skills, OpenTechResponse now has a dev volunteer-to-project matchmaking tool created by OpenTeams.
Top comments (0)