Building a Developer Motion

After spending years leading developer relations, marketing, and experience teams, I’ve noticed something interesting: while many companies successfully create short-term developer interest, few manage to build a sustainable developer motion — that self-reinforcing momentum where developers naturally adopt, champion, and help improve your platform.

A developer motion is a coordinated strategy across engineering, product, and marketing that drives natural developer adoption and advocacy. It’s not building a product, marketing, or community in isolation, but a comprehensive approach that aligns your developer experience with how developers actually work and make decisions.

In this series, I’ll share some of my learnings and insights from years of hands-on experience building developer programs at companies like Auth0, Okta, and Writer, while also consulting for and advising other companies, developer advocates, and marketing leaders. While every company’s situation is unique, understanding these fundamental principles can help you build a more effective developer motion.

Note: This series will not cover building teams or organizations. While that process is equally important, the orgnizational structure is dependent on the overall developer motion strategy and how it fits into the business. I plan to cover this process elsewhere.

The three pillars of a developer motion

Through my experience building developer programs at different scales, I’ve found that a successful developer motion rests on three core pillars, in this specific order:

1. Developer Segmentation & Personas: Before you can build anything effective, you need to identify which developers are most likely to succeed with your platform. While working at Auth0, I learned that trying to serve “all developers” inevitably leads to scattered efforts and diluted impact. You need to deeply understand specific segments’ motivations, challenges, and decision-making processes.

2. Developer Journey & Experience: Once you know who you’re serving, you can map and optimize how those specific developers discover, evaluate, and adopt your platform. This journey mapping becomes much more focused and actionable when you’re designing it for well-defined personas rather than a generic “developer.” You could separate developer journey and experience into two separate pillars (and indeed, they will often be separate workstreams), but they are so intrinsically connected that I advise against it.

3. Developer Marketing & Relations: Only after understanding your target personas and their ideal journey can you build effective outreach programs. This isn’t simply traditional marketing, but a careful balance of education, community building, and product feedback loops designed for specific developer segments.

While it’s ideal to build each pillar sequentially, the reality is that you’ll need to iterate on each pillar at the same time. The business won’t really accept that you can’t start marketing to developers before you’ve spent months researching your personas and their journey through the product.

I learned this when I started at Writer. Coming from a very mature program at Auth0 and Okta, I had this vision of building a developer motion from scratch in perfect sequence. In a fast-paced startup in the lightning fast and highly competitive AI space, I’ve had to speed run the process and iterate on each pillar at the same time, doing tiny experiments to test and learn.

Why a developer motion matters

If you’re running a software company today, developer buy-in is likely critical to your success in one of several ways:

• Developers might be your direct customers
• Your product might include libraries or tools that developers need to implement
• Developers might be key influencers who recommend your solution to technical leadership

Understanding these dynamics is crucial because they shape your entire strategy.

Common pitfalls to avoid

Developers are quite different than other consumers, and their decision-making process is often driven by technical and professional identity. This is why engineering, product, and marketing must work together to build a developer motion. This is no easy task, which is why so few companies get it right. I’ve seen many teams struggle with similar challenges when building a developer motion:

• Jumping straight to developer marketing before understanding their target personas and ensuring a solid developer experience
• Avoiding journey mapping altogether
• Treating developer marketing as fundamentally the same as traditional marketing
• Rushing to scale before establishing fundamentals
• Over-engineering solutions instead of starting simple
• Lack of clear success metrics and timeboxing
• Trying to do everything at once without clear prioritization

One of the most important lessons I learned while scaling Auth0 and Okta’s developer relations function was that building a developer motion is fundamentally about human relationships. Developers have a deeply personal connection to their work - not just because of passion, but because of professional identity, craftsmanship, and trust.

Many companies miss this fundamental truth. They focus exclusively on technical features or marketing campaigns without considering the human element of how developers make decisions and form relationships with tools and platforms.

Getting started

Before launching any developer initiatives, ask yourself these essential questions:

1. Who are the specific developers succeeding now with your platform or product and most likely to succeed in the future?
2. Is your developer motion primarily marketing-driven or product-driven? While it’s usually both to some extent, understanding the primary driver helps with prioritization. The answer to this question depends on company stage, vertical, and product maturity.
3. Are you supporting an enterprise sales motion, a product-led growth motion, or both? More simply: will developers be giving you their credit cards? This will determine whether your developer motion is top-down, bottom-up, or both.
4. How will you measure success? Whether it’s active developers, sign-ups, product feedback, developer reach, or revenue, clear metrics are crucial. You will likely need a few key executive-level metrics for the business alongside several health metrics for the developer motion.

Patience is a must

Building a successful developer motion takes time. It requires patience to understand your target developers, map their journey, and create programs that truly serve their needs. But when done right, it creates a sustainable advantage that’s hard for competitors to replicate.

In the next post, I’ll dive deep into developer segmentation and persona creation, sharing practical frameworks I’ve used to identify and understand key developer segments.