The Developer’s Journey
To write software is to explore. The life of the developer is an endless series of quests to discover the technologies they can use to build new things in new ways, to unlock new opportunities for their business, to solve interesting problems, and to grow themselves.
Like all stories, these technology adoption quests follow a predictable structure. There are five stages every developer must go through, in whole or in part, to master a new tool or technique. Everything about the contributions of a Developer Relations organization to the business (DevRel in common parlance) in empowering developers in this quest - how it supports the go-to-market strategy, how it's measured, where it’s located in the business, the impact AI is having - is dependent on this journey. I’m going to walk through each of those stages from a developer's point of view. Whether you're a developer or not, you're invited to come along!
Discovery
The first stage is the starting point for every new quest: it’s the place of discovery. Every technology you use now—React, OpenSpec, Kafka, SuperSet, Pydantic—is one with which you once had some kind of initial encounter. Traditionally, that encounter has looked like one or more of the following:
- A conversation with a friend or colleague
- Social media/tech news aggregators
- Serendipitous discovery at a conference
- Input from an influencer
However it happens, the discovery stage is a short one. You see a new thing, and decide whether to care about it—whether it’s worth investing a little time to learn more. If you’re busy, you may move on. But if something about the context grabs your attention, you’ll keep going.
Understanding
What you’ll try to do next is understand the new technology. To do that, you’ll need to build a mental model of it, attempting to understand the basic kind of thing it seems to be, the problem it solves, and what sets it apart from the other solutions in its category. That category could be a programming language, a database, a machine learning library, an application framework, or a new agentic development workflow. Suppose it’s a new database. Is it diskless? Transactional or analytic? What key tradeoffs does it make? Perhaps it’s a new language. How is it an improvement over its nearest neighbor? Is it designed for applications or systems programming? Is it optimized for agentic development? Well-crafted content should be able to give you the answers you need to help you discern not just what this new thing is, but the impact it might have on your work. Is it something cool worth playing around with, or is it something truly significant that could solve an urgent problem you’re having right now?
Play
And if it’s an urgent problem, or the technology just seems interesting, the more likely you are to want to sit down and play with it. Once you have a solid mental model in place, it’s time to see the thing in action in a contained environment where you can watch it work and safely put it through its paces.
You don’t know enough to put the thing to practical use yet—you can’t build a React app, write a Claude Skill, or produce messages to a Kafka topic when you’re brand new to each of those things—but you want to kick the tires. You need a quickstart.
The most basic form is a GitHub repo with a self-contained hello world, including a README that guides you through each step of some simple process that yields a successful result in five or ten minutes. If the product is cloud-native, this can be an in-product tutorial or some sample data to show new users how to get started with the free tier. Whatever “hello world” means in the context of the technology, it’s all in this can, with a button to press and a light to watch to see when it comes on. That’s what you want to see.
Building
If playing around with the product for ten minutes or so showed that it seemed to work, then it’s time to get to work solving a real problem. You might start small, perhaps hacking for an afternoon, building a proof of concept. From there, you might launch a meaningful project with the new tool, one that’s tied to real business outcomes that are visible up their management chain. You might well spend months working on an ambitious build-out. Or it could be years—a whole season of your career.
The support you need during this stage grows as your capabilities do. You’re way past the “getting started” stage—the building stage is about putting the technology to work in earnest. You might benefit from tutorials and talks that cover advanced techniques or new features, but ultimately, you’re exploring edge cases and possibly finding bugs as you truly use the product in real life.
You and the fellow developers you meet along the way can spend weeks, months, or even years in this stage, happily building valuable things.
Advocacy
Ideally, you’ll be so excited about what you’re building, and getting such great results, that you’ll want to share your success with the world. Not everyone does this, mind you. Some are happy just to keep building things, but some of us get so excited about a new technology that we make it our mission to get everybody else on board too. We give talks at conferences and meetups. We write blog posts. We hold internal lunch-and-learn sessions to give colleagues on other teams a chance to get up to speed. It’s not enough that we alone are winning—we want their colleagues to win too, and win with this particular technology. That’s why this stage is named for what the most invested members of a developer community do: we Advocate.
A robust community of advocates is essential for any business with a substantial developer-facing surface area. Advocates bring a level of credibility that even the best DevRel program can’t duplicate, since they do what they do strictly for the love of the game, detached from any commercial interest. It’s easy to give short shrift to this stage, but Advocates must remain the ultimate goal of a mature DevRel program. Ideally the program has provided its community with the tools they need to navigate their quest to discover, understand, play, and build with your technology, not just successfully, but with enthusiasm—the kind of enthusiasm that makes them an advocacy engine for the technology, and with it for the business itself.
The journey of a thousand miles...
The Developer’s Journey is the strategic "north star" of every successful DevRel program. It’s the framework for thinking about content, events, programs, staffing, and metrics that quantify DevRel's success. In my next post, I’ll talk about what successful execution using that framework traditionally looks like, and the disruptive influence AI is having on it. Spoiler alert - it's not what you'd expect.