Let's start with you. Who are you, what do you do, and what does your company build?

I'm Dwayne McDaniel, Principal Developer Advocate at GitGuardian. I help people figure stuff out. I see that as my entire mission. I am very happy to help people learn better practices around secret security. 

GitGuardian, the company I work for, builds a platform that helps people define and deal with their credential layer. We see ourselves as a credential layer security platform that helps teams discover, remediate, and prevent hard-coded secrets from sprawling.

What does DevRel actually mean to you? Is it marketing, engineering, product, or something else entirely?

DevRel to me means helping people figure stuff out. That takes many forms and involves many activities. 

I used to be a sales rep who was good at explaining things but who didn't care for some of the other aspects of that role. I had a very good VP of Sales explain that you can do just the parts I enjoyed: help train people, help write articles, videos, and docs that will help people better use the platform.

I soon discovered the world of developer relations, which connects marketing, engineering, product, and sales. I see myself as sitting in between all of those. I am more focused on awareness and activation than I am on code samples. I'm also my company's representative in the broader community, giving talks at conferences and bringing market learnings back internally to all my departments.

DevRel works in both directions: you speak for the company to developers, and for developers inside the company. How do you balance the two, and when have you pushed back on your own team for developers' sake?

I don't see it as exactly an equal split, but I do try to find a balance. I never want to come across as salesy when I'm talking to the community. I'm more likely to promote larger-picture ideas that align with our product but don't require our platform to embrace that area of security.

I also don't want to be a conduit just back to sales, funneling leads, but instead funneling in the ideas that people bring up and the larger trends I see coming down the road. A good example would be watching AI development in real time, as people moved from trying to build their own LLMs to now building harnesses, and what that means from a credentialing perspective. I've had many great conversations with our executive team as well about these bigger-picture perspectives.

Fortunately, I don't get a lot of pushback from developers themselves on how to use our product or even about our mission. It's more about awareness that they don't know how large the problem is or how fast the attack surface is expanding. But again, developers' job is not to stay up on security news, and that's what I focus on helping bridge the gap on.

Tell us about your community. Who's in it, how big is it now, and what helped it grow?

I am part of the larger security community that makes up organizations like BSides, DEF CON's AppSec Village, and, in Chicago, BurbSec. We are really on the front lines of defending organizations of all sizes and shapes and moving the conversation away from reactive-only alert response to proactive resilience measures.

No one company has a monopoly on this community because it's such a widespread topic that it really encompasses every vertical and every industry. There's a real sense in security that we're all in this together, and that has helped it grow and stay sustainable since it started, years before I joined.

What's a launch or campaign you ran that you're proud of? What happened, and what did you learn?

One of my favorite major releases and campaigns has been around endpoint protection, which is a mixture of "shift-left," helping developers do their jobs better with better guardrails that don't get in the way, while at the same time empowering security teams to get visibility that has never been possible before into what credentials the developer's laptop holds.

I feel this is such a necessary message, and it is being very well received. Instead of focusing on what developers shouldn't do or what security teams need to invest in, we talk about meeting the developer in their workflow without adding more toil or yet another new tool to use, while at the same time standardizing a security approach that really does address the heart of how so many attacks are successful.

Seeing the reactions online to people thanking us for making these tools available and for helping them understand the problem set in the first place is very rewarding.

In a product-led world, the product is the marketing. How do docs, onboarding, free tiers and sample apps fit into your DevRel work, and what's one change that measurably improved developer adoption?

I doubt we would be a company if we didn't have a free tier and a straightforward enough mission that every developer on Earth understands. It is simple: they need a tool like ours to help keep them safe from making human errors and publishing things they shouldn't publish into their repositories.

At the same time, it's a balancing act because our paying customers are very, very large enterprises, and the real value of what we do starts showing up with Developer teams over a certain very large enterprise size. Part of the reason we're successful is that we have focused so much attention on the individual developer experience, really working on prevention and guardrails and shifting left in a way that has led to hundreds of thousands of individual developers using our products for free. With the trust we earn they take that product knowledge into their organizations to help improve their overall security posture. The fundamentals of "never hardcode a secret" is a useful belief for all developers, whether they use our tools directly or not in their day-to-day organizational work.

For us, one thing that has worked very well in the last year has been adding AI guardrails, extending tools that developers already know and trust to a new surface that has a lot of moving parts. We are meeting them where they are and not asking them to do anything new or fancy, just using tools that automatically keep them safe in the least obtrusive way possible. This innovation has been a game changer in our adoption from developers across some of our largest customers.

What's your favorite piece of content your team has shipped, and why did it work?

My personal favorite piece was an anchor blog post that defined what we meant by the concept of identity in the context of non-human identity governance. This was my favorite because it forced me down a philosophical path to even try to understand what the concept of identity meant at all, and when it finally did ship, it became the number one most-read article I've ever written.

But more than that, it was an anchor piece I could refer back to across my speaking roles, my other blog posts, and my videos to this core concept that identity is extremely hard to prove unless you have things that don't change over time, and for machines, we can track a lot of what we think of as identity into the access mechanisms they actually use.

I think it worked because it wasn't a challenging new definition or a new Gartner quadrant to align yourself with, but really a fun philosophical argument for understanding what you're even trying to define your own tool stack with. Every time I've worked it into a conversation casually at an event or in a professional setting, it always ends with the same general positive reaction, and it's something I have really spent the last two years of my life resonating on.

How do you measure whether DevRel is working? What do you track, and what do you ignore?

This is one of the hardest things about this role. 

Sales always wants to measure things in dollars closed, and marketing always wants to measure things in reach by number of clicks and number of views. The reality is that, from a pure revenue perspective, I sit at the very top of the funnel and am tied to a lot of opportunities, but how directly I am attributed to the closed number is much harder to calculate.

So awareness, measured by the number of talks I've given, the audience size, as well as traditional content metrics, is what my manager mostly cares about. She sees the value in having someone on the team who understands what's going on in the community at any given moment and who is always keeping up with the forefront of technology, which is only possible from all the conversations I have in person and all the sessions I get to go to at conferences continually.

How you actually measure the impact of how I've shaped product or directly contributed to the pipeline is tricky, though that part of the role drives me to just keep trying things. 

I learned a long time ago that for DevRel, you can't be reactive; you need to be proactive in all things. Even reacting to a situation needs to align with a larger goal and larger projects you already have in motion. Otherwise, you're going to get overwhelmed and pulled in a thousand directions.

The advice I give for anybody new to being DevRel is to go look up Phil Leggetter's Pirate Metrics. I do it at least once a quarter, trying to align my situation with the general trends and columns he laid out in that methodology. However, I don't report those specific numbers up the chain.

"Talk is cheap. Show me the code." Linus Torvalds wrote this on the Linux kernel mailing list in 2000. How does that idea shape the way you reach developers?

This is very true for anyone shipping a development kit or something a developer will use day in, day out, like a platform. I don't exist exactly in that capacity. My company is a security tooling company that focuses on devtools that automatically fire to keep the developer safe, not a new SDK to learn or an API to hit.

While we definitely do have an API, it's a very, very small percentage of our users, only at very large organizations, who ever directly leverage it. So building API examples and scripting logic that transmutes data you can get from the platform isn't really a use case we have a call for here.

However, showing our product in action requires a deeper-level knowledge of how DevOps works, how developers actually perform their job day to day, and having at my fingertips code repos that reflect reality and aren't just sample apps that don't do anything or that run well locally but don't account for pipelines and CI/CD build systems. So I would ultimately say authenticity via code is super valuable, but not necessarily definitive of the role.

There's a well-known saying that "developers are allergic to marketing." Do you agree? How do you reach developers without it feeling like marketing?

Developers just want to get their hands on things and see for themselves. This is a very good thing because it means if you have anything to download or to test, it will be downloaded and tested. I know for myself I ignore marketing websites as much as possible and jump straight to documentation.

However, marketing in the larger sense means that you'll never get to that documentation if you don't know the thing exists in the first place. I think being allergic to marketing means being allergic to marketing that looks good to sales and executives but is detached from the developer's day-to-day experience.

Good marketing, in the form of videos that are also entertaining or social media posts that align with what the developer is thinking at that particular moment, is how you get a developer to go into the documentation and see what this thing really does. But that says more about traditional marketing failure than it does about developers being weird to market to.

Kathy Sierra argues in Badass: Making Users Awesome that the goal is to make users awesome, not to make the product look awesome. How does that idea show up in your work?

This is at the very center of how we approach our shift-left and prevention strategies. We know very well that developers do not want to be called out for making mistakes, so we stress that local activity with our tooling stays local when they use things like our VS Code extension or our pre-commit hooks.

These things let developers deliver better code overall that's going to require less rework and ultimately make them look better and more productive to their companies. The goal should never be to show off that they used GitGuardian, but to have everyone on the team asking how they are the ones who never seem to ship a plain-text credential or accidentally include a .env file in a commit. The idea that we can get everyone working more safely is about as badass a concept as I can think of.

How did you first come across HackerNoon, and is there a story you've read or written here that stuck with you?

HackerNoon has been holding down that corner of development content that is pure to the heart of the developer for a long time. I've been reading HackerNoon for so long I honestly don't remember where it first came on my radar. Likely back when I first became a DevRel, I was already reading it because there's a purity to the conversation that is lacking on a lot of other platforms, and the fact that it's focused on development overall versus platforms that take all comers for any kind of article makes me feel like I'm in a true community and not just on a content website.

Whose DevRel work do you admire most, whether people, companies or programs, and what do they do that others should copy?

I learned the basics of this profession from Cal Evans from the PHP world. I learned the metric side of it from Phil Leggetter, but the DevRels who have inspired me the absolute most have been the ones who just keep showing up to conferences and making awesome projects time and time again.

One of the names that jumps to mind in the security space is the field CTO over at Ox Security, Chris Linsey. His raw passion and enthusiasm for what he is working on, combined with his very interesting past experiences, make him a unique voice that is always engaging and always asking the most interesting question in the room. You really feel like you're on a discovery journey with him whenever you see him talk or engage in his content. That's what I hope to aspire to.

Are you a Dev Rel Leader? Get Interviewed.