Kim Maida on the DevRel Flywheel, AI, and Measuring What Matters
Kim Maida spent years reducing DevRel's value to a dollar figure per engagement so leadership would take it seriously. She now thinks that framework did the discipline a disservice — and describes the five-stage flywheel she uses instead.
Kim Maida is a longtime figure in the DevRel and identity space, previously at companies including Auth0 and Okta, now at Keycard, an early-stage platform for agentic credential issuing. We talk about the developer flywheel framework she's been refining since 2022, why she moved away from trying to price DevRel's impact in dollars, and how Keycard issues short-lived, task-scoped credentials so an AI agent never holds more access than it needs at any given moment.
We also get into how AI has changed her own thinking on DevRel and engineering after going from a self-described strong skeptic to relying on it daily — and why she thinks human expertise, not less of it, is what actually determines whether you get a working product or slop.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What is Keycard building?
We're a platform for agentic credential issuing — a security token service, to use the boring term. We issue ephemeral credentials that are scoped to a specific task for AI agents. When an agent is told it needs to connect to a set of services with certain scopes, and it goes to actually execute a task, it gets a short-lived credential that only has the scopes for that task and a lifetime short enough that if it ever leaked, it would already be expired before anyone could use it. The policy gets evaluated before the agent acts, so it knows what it's allowed to do before it does it — which addresses something the industry is struggling with right now: handing agents the keys to the castle and hoping for the best.
Why is this a different problem from traditional identity and access management?
Human identity is a really well-established field — companies like Auth0 and Okta have built their names being experts in it, and I've worked at both. But this is a new frontier: you want autonomous agents to be able to access a huge range of things, without holding standing access to any of it when they're not actively doing something. Traditional IAM moves slowly — OAuth 2 has been out for more than a decade and OAuth 2.1 still isn't finalized — so it was unexpected for me to end up on the cutting edge of something again, with immediate problems that nobody has solved yet.
You wrote an early framework for measuring DevRel value in dollars. Why did you move away from it?
At the time, it was about translating DevRel's impact into a number leadership could understand — if a signup was worth $80, then a champion's video that drove a certain number of signups might be worth $200 or $500. It worked for communicating a dollar value to leadership about DevRel's contribution to pipeline. But distilling all of DevRel's value into dollars tied to specific engagements felt increasingly narrow, especially once you get into developer experience or documentation quality or helping existing customers — that model just doesn't have equivalencies for those things. It does a disservice to DevRel as a mission, because DevRel is so broad that you're only capturing a tiny slice of it that way.
What do you use instead now?
A flywheel: people moving through a cycle from not knowing who you are, all the way to becoming a champion who tells other people to use your product. It's five stages. First is inspire — showing people why something would be valuable or interesting, rather than just generating awareness, because being aware of something doesn't mean you'll ever use it. Then educate, where people explore at an informational level — reading docs, checking other people's experience, maybe now asking an LLM if the product fits their use case. Then activate, when they actually start using it. Then engage, where they're committed enough to have a real conversation with you about their experience. And eventually, if they like you enough, champion — which doesn't necessarily mean joining a formal champions program, just that they're telling other people to use it and you're giving them the resources to do that well.
Which of those stages matters most to get right?
The first two — inspire and educate — are where you get the most drop-off, and developers are unforgiving. If the education experience is bad, if the docs are terrible, people won't even reach activation; they'll just move on, and you often lose them forever. Once people are actually using something, they tend to be a bit more forgiving because they're already invested in getting it to work. That doesn't mean the later stages don't matter, but the early ones are where you lose the most people permanently.
Has leadership's understanding of DevRel's value actually changed?
Yes — when I first started in DevRel, it was constantly 'how much money are you making us, what's the impact on ARR.' We always struggled to measure that, partly because everyone was looking at it through too narrow a lens to capture what DevRel actually is. The last couple of companies I've worked at cared a lot less about that kind of metrics value and a lot more about relationship value, partnerships, and early-access participation. There's still going to be some tie-in to value you can point to, but there's more room now to represent that as things like active participants in a beta program rather than everything being arbitrarily assigned a dollar figure.
How are you thinking about measuring DevRel at an early-stage company like Keycard?
Right now we're just trying to get into the inspire cycle — producing content that gets people interested in the first place — because we're early enough that everybody starts at the very beginning of the flywheel. There's no existing champions program or population of power users yet; it's still just the company doing these things. That's actually kind of nice, because I don't have people stuck at different stages that I'm trying to retain or move forward — I get to build the process at the same time as the audience.
What's your advice for people in tech worried about AI replacing their jobs?
I came from a place of strong skepticism, and what I'd say now is that using AI doesn't make you dumber or erode your expertise — it actually requires you to be more precise, because you're directing something that sort of thinks for itself but sort of doesn't. I think of it like a very young child with a very high IQ: it knows a lot, but doesn't always know how to apply it, or when it's making something up. When I was building an app with Keycard using AI agents, there were repeated moments where I had to say, 'no, you've got this identity concept wrong, you're reading the wrong document' — and without that expertise, I would have just let it keep going. The people whose jobs have longevity will be the ones who learn to orchestrate agents effectively, because the more slop you feed into that process, the more slop you get out, and it takes a person to say, 'this is the actual human need we're solving for.'