Building Bridges with Other Departments in Developer Relations

There are not many people in developer relations who can keynote a conference, write a book, vocally advocate for equality and mentor others in the space. Today I'm speaking with Estelle Weyl, who has done each of the above multiple times throughout her career. I first met Estelle Weyl when I was running meetups and conferences in San Francisco, at which she has been kind enough to speak. Estelle is a big picture thinker who sees the promise of developer relations as a field, but can also get into the nitty-gritty of the pros and cons a particular specification or piece of documentation. I sat down with her to discuss DevRel from the 10,000 foot level down.

Table of Contents

• If a startup wants to get into DevRel, what should they do?
• What can tech events do to foster community engagement?
• What's the best way to speak at conferences?
• Who should consider a career in DevRel?
• How important is awareness to standards?
• How have developer conferences changed recently?
• Who is doing developer relations effectively?

Q: You’ve written a number of technical books, maintained developer documentation for Mozilla, keynoted at dozens of conferences, even ran your own conference. Which of these should a startup getting into DevRel focus on?

That really depends on the goal of the startup and the goals for the devRel team. You need to create and monitor KPIs that make sense for the company and the actual role and the capacity you have in that role.

Know what the expectations are for your position up front, and make sure you set those expectations in a way that you feel comfortable accomplishing those goals. If you are a one-person DevRel team and you say you’re going to make 30,000 contacts in that year, all you’re going to do is staff booths at conferences and give out swag. That’s fine if that’s what you’re into, but if you alternately said you were going to reach 2,000 decision-making engineers and each of those will each be introduced to your product, then that could be a more lucrative long-term strategy.

This can be a difficult conversation to have with the higher-ups in your organization, but you have to be able to put that into lingo that they understand and maybe work towards an agreement where 50% of your time is spent doing long-term strategy such as what we discussed, and the rest of the time is spent on metrics that they are more comfortable with, for example, sponsored content. It’s important to meet the goals of the company without sacrificing the role itself. Your reputation is your biggest asset in the developer community and you need to advocate for what you believe in. In order to not compromise on certain things, you need to train your executives, sales and marketing team about the value of DevRel and the difference between the educational mission of our profession and, for example, a sales engineer.

Generally, you want to get your tools and services out into the community and educate developers on how they work so that when their team needs that tool, your solution will be top of mind.

Q: What can tech events do to encourage community engagement?

What makes #PerfMatters so much fun is the party and social interactions are not about tech -- once you get to know someone, you can talk to them about tech, but our events are focused on building connections by building legos together, Jenga, and connect-4. We also have spin art, an amazing balloon artist, balloon popping, and face painting, which is to gets attendees to focus on stuff other than tech, and hopefully feel comfortable sharing. We also have a rainbow hat that you have to hand to a person that you have never met before. If you’re only talking about the tech at hand, everyone will be peacocking and talking about their successes and not about their failures. Getting to know people in a relaxed atmosphere enables people to be more open and real.

Q: How should a developer advocate approach getting into conferences as a speaker?

If speaking at conferences is something you want to do, the first step is to get accepted. You have to ask to get a yes. Even when there are 600 applications for 12 spots, you can get one of those 12 spots! You need to train your advocates on how to write an interesting proposal and promote the speaker so that the audience knows it’s a topic that interests the audience, and not a topic that’s interesting to the developer advocate’s company. In devRel, or even in general, tyou want to get that free spot and educate, as opposed to getting a sponsored slot and selling.

Q: What separates a good DevRel candidate from a great one? Who should pursue a career in developer relations?

Ideally, you'll get a job getting paid to do what you already do in your free time. If you don’t enjoy speaking and aren’t already speaking at conferences, then you may not want to commit to something you won't necessarily enjoy. If you’re already doing it, then it’s great to take that job because you get paid to speak. So if you’re contributing to open source documentation, be that MDN or documenting SASS, it is fantastic to get paid for that.

There are different types of DevRel roles; some are speaking, some are documentation, some are community organizing. Other jobs include mostly staffing booths at conferences and yet other roles involve organizing the whole conference. What are you individually passionate about? You want to find the job that you’re already doing, and you also most likely want to do it for a project in a technology you’re interested in, and with people you want to work with.

Some people believe that work and hobbies should be separate. I have always looked for jobs where I do my hobby as a profession. My hobbies include building professional ladders, promoting performance and accessibility, explaining specifications. It’s been fantastic to get paid for these roles I enjoy doing.

I love to manage people because I love to help people grow. It’s so fulfilling to get other DevRel people into the field and do workshops on how to speak and build out a DevRel team and mesh them together with Engineering and Marketing. One way I like to encourage team building is via improv, which can help with seat-of-the-pants thinking and brainstorming.

I once had my laptop hard-crash in the middle of a presentation. I was doing a talk on mobile debugging tools and I had too many debugging tools for my device to handle. That’s most speakers’ biggest fear. I kept on going, presenting without slides while rebooting. Once I realized that I could rescue myself from that, I realized almost nothing worse could happen to me onstage. Admittedly, I retired that talk.

Q: How can community awareness help or hinder the adoption of a product or standard?

It depends what product you have. If you have an Enterprise product, you may not have to make as many individual sales because each deal may be huge, but for such a sale to happen, the connection needs to be deep. Wherea, if your product has a low price point, you want to get more people energized and using it as soon as possible. In the latter case it’s more about how many people you reach, rather than the depth of each interaction. Your approach to promoting your product has to do with the objective of your team and the scope of your product.

As a different example, if you’re promoting a framework and you want more teams to use it, realize that your target audience will not switch to and from your product on a weekly basis. Of course, you want potential users to make the decision to use your product, but you also want to facilitate discussion around your product and the decision process to ensure people making such decisions consider your tool. Your product then has to sell itself.

As an example, a certain mobile development platform which isn’t really around anymore had a small but impressive DevRel team. They had a great device and platform that was popular with business people, not developers. Had they invested in getting developers interested -- in distributing test devices, provided training on porting to their operating system, and gotten developers inspired to create apps for their service, there may have been a viable store. But, they didn’t. Their users moved to the devices with better application availability. To me it seemed like they hired a great devRel team, but then failed to adequately support their initiatives.

DevRel should also be about developer support. As part of that process, you need to have good documentation and a method to gather developer feedback. Ideally that feedback is provided to a dedicated team that responds to developer feedback -- even the developers who aren’t your customers. If you limit support to only paid clients, you'll miss out on a ton of use cases. A developer who isn't paying you is only a developer who isn't paying you yet.

And every bit helps. If your goal is selling to enterprises, perhaps a free product seems like it won’t move the needle on adoption. But if you look at services like Twilio, getting started can be free, and you can bump up from microdollars to upwards of a million dollars. Getting the experimenting developer to try your service helps sell your service when that developer is on an enterprise team.

Q: How have developer conferences changed in the 10+ years that you have been speaking?

When I started speaking at conferences, DevRel wasn't an identified role. The speakers at these conferences were mostly authors or developers. I started speaking in 2008, after going to my first conference in 2007. I chose the first conference I attended because the only woman I knew of in our industry was speaking at that conference -- she was the only woman on the roster. Once I got to the venue, I could count the number of women in the audience on my fingers (I didn't even need to use my toes.) I knew we had to do better in terms of numbers and representation, and I thought, "If someone has to do this, it has to be me." I met Stephanie Sullivan at SxSW and her talk was AWESOME. She told me about reaching out to conferences and offering to speak, so that’s what I started doing.

My long-term goal has always been to build ladders for future speakers and developers to climb up. Hopefully, they will additionally build upon that ladder for other people to climb. My goal, in a way, was to be a role model. Today, many of the conferences you go to, the speaker line-up is way more reflective of our industry than those earlier conferences I attended. It’s not quite up to the level of society in general. We still have a long way to go with under-representation of women of color, Latinxs and African Americans. I'd like to see 50% women. I would like to see it reflective of the general population.

Having organized conferences, I know from experience that if you get proposals from women and people of color and you do a blind review, you’re going to have an better representation of women and people of color, and they’ll on average put more effort into those proposals than someone who has been told “yes” their whole life. In 2019, at PerfMatters we had 24% submissions from women and people of color, but over 50% women and people of color on our speaker roster -- and that was from a blind review process. We achieved this by reaching out to those typically under-represented communities and encouraging them to apply. This year we had 43% of proposals submitted by people self-identifying as minoritized. Our line up, amazingly, is a pretty good representation of the general population.

Minoritized people may come from a culture of being told, over and over, that they’re not qualified. Their culture and experiences may determine whether they'll believe you have their best interests at heart, and as an organizer, you may need to convince them that what they have to say is interesting and relevant, and make sure they know they won’t be rejected out of hand based on their gender or their background. You can’t get a yes if you don’t ask.

Q: Is there anybody out there in the DevRel or conference world who is doing something great that you want to shout out to?

There are so many new and upcoming speakers that I’ve just recently heard about by doing our CFP. I haven’t had a chance to hear them all speak. I hope to. I guess I want to give a shout out to all the developers who are not just teaching us tech. Learning and teaching code is relatively easy. Code is actually the easiest part of being a developer. Communication, developing teams, ensuring accessibility, performance, security, privacy and a good user experience is harder to learn, teach, and do well. So, a shout out to all those who have given me the gift of sharing their truths, especially women of color who put themselves in personal and professional risk by doing so. And, also, a shout out to all the allies who support them, especially those that do so outside of any limelight. A shout out to Kelsey Hightower, Marco Rogers, Sharon Steed, Sarah Allen, Kim Crayton, Sonia Gupta, Anil Dash, Scott Hanselman, Aisha Blake, Pariss Athena, and the slew of other fabulous people who don’t necessarily have “developer advocate” as their professional title, but who are definitely advocating for developers everywhere. I may not personally know you, but I appreciate you and thank you for all you do.

Thank you Estelle for sitting down and sharing your perspective and experiences.

Next Steps:

• Follow Estelle on Twitter
• Attend the next PerfMatters conference
• Check out Estelle's talks and workshops