Descope is a developer-friendly customer and agentic identity platform trusted by over 1,000 organizations. This year, they returned to GitNation events as sponsors of TechLead Conf London, following earlier sponsorships of React Summit and JSNation. We sat down with Abhi, Senior Director of Marketing at Descope, to talk about developer engagement, why "leads" are the wrong metric for developer events, and why the entire identity space is starting from scratch when it comes to AI agents.

Abhi, thanks for sitting down with us. For developers who know Descope as an auth and identity platform but not the team behind it - can you introduce yourself and what you do there?

I run marketing at Descope, and this is the first company I've worked at where the company name is a verb! Our goal is to help developers "descope" authentication and identity management from their daily work - whether that's for their web apps, mobile apps, partner portals, MCP servers, or AI agents.

Descope has grown fast in the CIAM and identity space. Give us the short version: what is Descope, and who is it really built for?

Descope is a developer-friendly customer and agentic identity platform. We provide developers with a host of abstraction layers - visual workflows, SDKs, APIs, MCP server - that help them easily create and modify identity journeys for their customer apps and AI agents.

One of our early marketing taglines at Descope was "drag and drop auth for any app," and the "any app" part of that holds true to this day. Descope is for any developer: hobbyists looking to add auth to their side projects, startup devs looking to save time while going to market, devs at fast-growing companies looking to add SSO and SCIM for enterprise customers, and devs at large enterprises that want an identity layer that can scale across regions and millions of users.

You've been engaging developer audiences for a while now - events, content, community, open source. How would you describe Descope's overall approach to developer engagement today?

Our approach to developer engagement has been based on consistent principles since the beginning: meet developers where they are, educate them rather than market to them, and have them use the product as quickly as possible.

Meet developers where they are: We've invested in unobtrusive ads on developer documentation sites, community meetups and hackathons, developer tutorials and sample apps, sponsoring open source projects in the authentication and identity space, and of course developer events with organizations like GitNation.

Educate before marketing: We write a variety of developer content that's meant to teach authentication concepts and show them how to plug Descope into any type of application. Our learning center has close to 100 educational articles on everything from SAML and MCP to JWT claims and workload identity.

Have them use the product: Descope has a free forever tier that any developer can use, and all the tutorials we write require just the free tier to follow along with.

Descope operates in a space - authentication - where developers are often skeptical of anything that feels like a black box or lock-in. How do you engage developers without triggering that skepticism?

While we say we market to "developers," we know that not all developers are the same. They have a range of (strongly held) opinions and preferences, so our goal at Descope is to adapt to their preferences rather than force them to adapt to ours.

In the product, we do this by providing abstraction layers that range from no code to lots of code. Developers can use our visual workflows, SDKs, APIs, or MCP server to spin up auth for their projects, letting them use the "version" of Descope that best fits their working style. All our SDKs are open source and we have migration scripts and AI agent skills that make both migrating to and from Descope seamless.

Auth is also something teams often build in-house before they consider a vendor. How do you meet developers where they are in that journey?

If a company's developers have built auth in-house and are happy with how it's working, we're certainly not here to change their minds. What we've often found, however, is that auth is a never-ending journey. A company starts with simple username-password and social logins, then adds SSO for enterprise customers, then adds passkeys for extra security, then adds tenant-based controls as it moves upmarket... and so on. If and when developers realize that their time is better spent working on the core product rather than doing and redoing authentication, we are here to help.

Descope is also built to be augmentation-friendly for this very reason. If developers want to keep most of their in-house auth stack but solve a narrow problem with Descope (e.g. MFA, SSO, M2M auth), they can do that. We even let developers keep their existing backend token formats while modernizing their frontend auth flows with a feature called External Tokens.

What channels actually work for reaching developers today? Where do in-person events fit relative to docs, content, community, and open source?

In our experience, it's never any one channel that works. As I mentioned in a previous answer, there are several types of developers, and they all have their own digital spaces to hang out, research methodologies, and preconceived notions on what an auth provider should do. Our aim is to be consistently present in good faith across all channels that developers are present in and let time do its thing.

What's a mistake you made early on with event sponsorships - something you'd tell another dev-tool company to avoid?

A mistake we made early was focusing too much on "leads" from developer events. There are certainly events where short-term leads and follow-up are valuable, but developer events tend to have a brand awareness impact more than a lead generation one. We now aim to show up well to events, let developers know what we do and why we're different... and that's it. We can't control when a developer will need an auth provider, but whenever they do, we hope they remember Descope as an option.

How do you decide which events are worth showing up to? What's the filter?

It's a part-science, part-art process that keeps changing to be honest. We consider everything from the ICP that's attending the event, the region (and whether we have sales presence in that region), the cost, the other sponsors, and other one-off things. Since Descope is a good fit for both practitioners and decision-makers, it's easy for an event to seem relevant - the tougher decision is to decide which events *aren't* relevant!

How do you measure whether a sponsorship was worth it? Badge scans, pipeline, awareness, something else?

If an event has a lead gen component, then badge scans are considered for sure. But we try not to scan badges for the sake of scanning them, since we know that number can be artificially high and not be a true reflection of how the event went. More than anything, we ask the booth staff to reflect on the quality of conversations they had at the booth, whether they thought they spoke with relevant people, and if they would sponsor this event again if given the chance.

What does "showing up well" mean to Descope at a conference? What should attendees expect from your team?

"Showing up well" means being confident in the details of our product and how it can help, as well as being curious about the problems our audience is facing. Our booth staff does custom preparation for each event, including what capabilities to call out.

You sponsored TechLead Conf London with us this year. Who at Descope are you trying to reach specifically, and what's the message you want them to walk away with?

We're trying to reach technology leaders and engineering managers who are responsible for authentication and identity management for their products. We want them to walk away with patterns we have learned from serving 1,000+ organizations on how to adopt an identity stack that balances user experience, agent experience, and security.

You sponsored React Summit and JSNation with us a few years back - what's stayed with you from that era, and what's different about how you approach events now?

What has stayed with us from 2023 is that developers do not like to be explicitly marketed to. They want to know how things work and ideally want to speak with their peer developers while doing so. What has really changed from 2023 is how AI is dominating conversations now. In a sense, everyone is starting from scratch when it comes to agent identity - the entire space is very new, so there are no true experts and everyone is willing to learn more, which makes events like this one a perfect avenue for education.

If another dev-tool company were on the fence about sponsoring a developer event, what would you tell them?

I would say that there are two paths ahead of you: either do not sponsor any developer events, or sponsor them consistently for months. You are unlikely to find success by just sponsoring 1-2 of them. It takes time to build trust with developers, but events are one of the places they go for learning and upskilling, so consistently showing up there is sure to have a benefit. But let time do its thing! There are no shortcuts to this.

For the past 11 years, GitNation has been at the forefront of organizing developer conferences in Europe and US. Interested in sponsoring our events? Contact us: [email protected]