Brian Munz built and scaled the developer relations team at Qlik, a data analytics and visualization company. In his time at Qlik, Brian inaugurated and scaled the DevRel team with more full-time hires, organized Qlik's approach to developer events and content, and built out the 40,000-strong developer community Qlik Branch. After leaving Qlik last week, I caught up with Brian to get his thoughts on the benefits of community, the perils of managing a DevRel team across departments and his advice for anyone spinning up a DevRel team today.

Table of Contents

• How did you build a community for 40,000 developers?
• Where does DevRel fit inside a company?
• How do you balance authenticity with business value?
• How has open source affected developer relations?
• How do you hire for DevRel?
• What should a new team do to prove value?
• Who is doing developer relations effectively?

Q: Your team built and curated a 40,000-strong developer community around open source projects. How did you manage that?

When I first joined Qlik ten years ago they had just opened their first "web developer" piece of the product. This part was brand new and not widely used, but myself and a few other Qlik employees saw that it could be very powerful and started building solutions for it. It became very easy to add complex functionality to Qlik with a background as a JavaScript or web developer, and we would get requests from inside and outside the company for the code behind these solutions. Eventually we were getting so many requests, we decided to aggregate all these projects in one spot and further open source these extensions.

The user base and community grew organically based on the value these open source extensions provided. Occasionally, corporate customers would find our developer portal and get frustrated because they’d think these open source extensions were actually a supported part of the product, and we would have to gently tell them “this isn’t for you, this is for developers.” This is one reason it's important to differentiate between developers and “power users” of your product. At Qlik, these power users were actually also called “developers."

As the community continued to grow in number of users and number of open source projects, I founded a DevRel team to accommodate this new, different community that was turning out to be pretty useful to developers.

One of the missions of our DevRel team has been to grow and foster the Qlik Branch community. I remember being up all night until 6a.m. hand-coding a landing page so that developers could get early access the morning of the announcement of the program. We got 600 people to sign up for early access that morning. Now, it’s up to 40,000 developers and 750+ extensions open sourced on the platform. With that kind of growth comes challenges: how do you make sure the cream rises to the top? How do you ensure that developers are still finding the community useful? Those are tough questions that still need to be answered, honestly.

The Branch community sped up innovation in the ecosystem for extensions, and created a rising tide that lifted all boats. Consultants made a bunch of money by uploading open source extensions and then upselling support, or gaining leads from the community visibility.

Q: Where does DevRel fit inside a company? I've seen it placed under Marketing, Product, or even reporting to the CTO.

DevRel has been in five different verticals inside Qlik in the last seven years. This may sound chaotic or inefficient, but there are few reasons where moving DevRel to different teams can make a lot of sense. I mentioned previously that our team was small and scrappy, which made our jobs a lot of fun -- however, it also caused some friction when it came time to define KPIs and objectives after changing teams.

When moving teams, in some cases we were in certain parts of the organization when we needed to be there. For a while we were aligned with the Partner organization, which makes sense because at the time our partners were getting their heads around the value of the open source extensions we were curating. Later, we moved under Product, which was helpful as we were gathering feedback from developers and bringing it back into the product. There’s no one answer as to where DevRel fits, and I encourage you to think that DevRel could be most effective in different departments at different times.

However, DevRel teams can run into trouble if you’re reporting in a category where your goals are mis-aligned. For example if our team were to report into a less technical sales organization, our goals of serving the community could conflict with the goals of the organization. You also want to make sure you have the ability to grow a community with the right kind of leads instead of just aiming for a number. Growing a community haphazardly can make the community too “fluffy” and the community VIPs can get lost in the mess.

Q: How do you stay authentic to your community while providing value to the business?

Our approach was to use honesty and transparency to foster a vibrant community where developers provided value to each other, and by proxy, to the Qlik ecosystem.

Our Qlik Branch team was always scrappy, moving fast and asking for forgiveness instead of permission. There was some word-of-mouth that salespeople would worry that our team would "ruin" sales calls because we were always honest with developers -- we placed community and developers over marketing and hype. If we saw that a potential customer had bad information -- for example, paying for ten servers when they only needed one -- we would politely inform the customer that there was a more effective way to accomplish their goal. Philosophically, developer relations needs to serve the community that they build.

That honesty can pay itself back because it engenders loyalty to the program. When you’re honest with somebody who is used to being spoken to politically, it is refreshing. Our development partners would sometimes read press releases and product announcements, and then come to us and ask “what’s really going on?” “Is this feature ready for us to code something with it?” If it wasn’t ready, we would always tell them, because if they tried to build on a feature or API that failed while they were building it, it would be immediately clear that we were not being straightforward, and their time was wasted as a result. A number of these people are now close friends. You may not be able to quantify honesty and loyalty in terms of KPIs, but you see the community sticking around, and you generate invaluable buy-in from developers because you’ve made and valued those relationships.

One of our DevRel hires was actually somebody who was too outspoken for a role elsewhere in the company -- but inside our team, we saw that transparency as an asset, not a liability.

One reason for this is that developers deeply value honesty. Everybody says developers don’t want to be marketed to, which is somewhat true depending on how you define marketing, but what developers really want is an honest proposition that gets to the core of how your product can help them and what they’ll need to do to be successful. If you're able to provide that honesty, in the future when a developer needs your software, they’ll use it. This makes it sound like it’s easy to market to developers, but it’s not: I’ve worked with really skilled developer marketers who are experts at their craft. But you do have to tread a line where if you get too cutesy or dishonest you can shoot yourself in the foot. The value you create here plays out in the future where developers will know they’ll get the answer they need by consulting you, even if the answer isn't "use my product."

Q: Developers can be huge boosters of open source inside a company. How has an open source philosophy affected your DevRel work?

Today, Qlik open sources a lot of the libraries that power their APIs, which is a big change from when I joined. I’m not going to take any credit for that change, but my point is to illustrate that it can be a slow process to convince people that open source is a good thing. Seven years ago, I would have to put material into my presentations about what open source means and why open source is a good thing. Some old school companies didn’t see the value.

In fact our first incarnation of Qlik Branch was built on a proprietary tool: some management at the time was uncomfortable with open source, to the extent that they wanted us to use a paid product that had support; we later found out that the support was not effective at all. I preferred to use an open source tool, and when you look at the two communities the open source one was incredibly active. Eventually, we decided to rebuild Qlik Branch ourselves on our own engine and open-source the code. So, we were running Qlik Branch on Qlik’s products. We wanted the community to know that we believed in the product so much that we incorporated it into Qlik Branch, and the community could even clone and modify the Qlik Branch source code for their own use.

Q: Let's talk about someone starting a developer relations team today. Who should your first hires be? How would you approach building out the team?

I would break this down into skills, diversity, flexibility and empathy.

First, a note about roles and classification: In larger companies it can be difficult for human resources to understand differentiation between a DevRel engineer versus a regular developer. Occasionally you'll need to list a DevRel hire as an engineering hire for bureaucratic reasons. Make sure that the role is senior enough to match the responsibilities of a position in developer relations -- there can be a tendency to mis-classify developer relations engineers as junior developers. In fact, I consider DevRel engineers a different type of role because you have to be able to speak, communicate and teach effectively, on top of engineering responsibilities. DevRel requires extra skills and it can be tough getting corporate hierarchies to understand that.

Skills
Hiring a devrel team today, I would start by defining what you’re looking to get from DevRel. Based on those goals, what are you going to focus on? I’ve found that some DevRel hires have been good at hanging out with customers and helping them architect a solution, while others were better at going and speaking at a high level to a large audience. So not only do you have to define what you’re trying to get out of DevRel, but also: what skills that you need do your candidates have? It’s very rare that people will have all the skills you're looking for (although these people do exist!) Perhaps you'll find someone who is just incredible at cranking out videos and webinars, and they can focus on that and not be distracted with traveling to conferences. Don’t think of it as having each member do the same thing; he or she needs to be managed to focus on their skills.

Diversity
Focus on the diversity of your team. Years ago, there was less attention on diversity at a corporate level, but these days you really shouldn't build a non-diverse DevRel team. The parts of the developer community that I love tend to be more vocally inclusive and vocally compassionate, and open to diversity and accepting people who are different. By portraying yourself that way and architecting a team that way, it makes your team more open to developers out there who are approaching you.

Flexibility
When looking to build out a team and hire, another thing would be to hire people who are flexible. You can put DevRel hires into an inflexible system, but really you need to take opportunities as they come. People need to be free to follow the paths that present themselves; maybe you’ll meet somebody at a conference and be able to build out a great collaboration.

Empathy
Also, it has to be people you get along with. I’m not breaking new ground by saying this, but I’ve come across some genius developers who I know I will never get along with; having that person on a team and their toxic presence will outweigh the benefit of what they’d be able to produce.

Q: What advice would you give to a person or company starting a DevRel team who is concerned about the value proposition?

Ask yourself what’s the reason you want your company to develop a DevRel specialty. Some companies have been told that they need DevRel but they don’t necessarily understand it. There are many misconceptions about DevRel, especially due to the focus on community and fun integrations. DevRel can be goofy: a drone that controls a toaster!

There will be people in the company who won’t understand the value of that, and will want to use those resources to sell more products. In some companies DevRel's customer interaction comes at the conclusion of the sales cycle, helping customers who have already purchased the product; in other companies it’s at the other end, handing off leads to the sales team. You have to make sure expectations are set properly: if everyone believes that getting eyes on the product will get the product sold, and you put your KPIs around that, good for you; if it’s thought leadership, then that’s great too, but make sure you have consensus.

An effective DevRel team can be this rough-around-the-edges, adaptable system: it’s always able to be fully engaged with the community and serve your KPIs. Developers are always developers at heart, and you won’t lose the enterprise developer if you decide to do a weird wacky project. Even if the developer’s boss doesn’t understand a blog post that comes across as "wacky" or "fun," the developer will understand the abstraction, and the developer can translate those expectations to the enterprise.

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

Donald Farmer said we had empathy with the developer community, and the people I admire are along those lines. I appreciate people in the community who are nice, have empathy, and don’t take crap from anyone but also represent in that way which is pretty important and should be valued more for sure, being able to see people as they are. Every developer has to be new at some point, even new to the community. Have empathy for them and they’ll be loyal to your community, and you’ve been able to help lift someone up into a new level in their career. It’s a long process and it’s difficult to track metrics on a member by member basis, but you can see the value in the value of the community. The benefit of creating these relationships, whether the bigwigs understand it or not, is to create loyal users of your product and making hundreds of empathetic, positive relationships in your life.

Here are some people I'd like to specifically call out. Most of these people aren’t “deep cuts” to the DevRel community, but they’re the ones inspiring me most nonetheless:

• Sarah Drasner
• Cassidy Williams
• Scott Hanselman
• Tomomi Imura
• Of course all the DevRel people I’ve worked with at Qlik Nick Webster Alexander Thor Ana Nennig Rey Riel Wuzhong Zhu Tracy Russel-Beck and this weirdo named Dave Nugent

Thank you Brian Munz for giving this interview.