Zero to go
The start of a developer evangelism story
Here’s the deal.
You’ve got one job: make. developers. happy.
That’s it! That’s all. That’s allll you have to do. One. Thing.
<queue cricket chirps and quiet murmur of “fuuuuuuckkkk”>
I joined my current company a few months ago as their first developer evangelist. I joined because I thought their product was cool. I knew I’d learn a ton. My gut said go for it. And probably most importantly I liked the people.
So I started.
Shit. What do I do now?? Where to start?? Better start somewhere. And fast.
I pulled a trick out of my design thinking hat and started by brain dumping literally everything. I just started writing down everything I thought would be cool or fun to work on. Everything from super rad things like “have an online happy hour with users,” or “get swag socks.” To some real investments and thought leadership like “work with sales to develop a white paper about the state of X and why we think Y” and “work with our engineering team to build a forkable repo that will allow our users to do Z.”
Then as you do, I started to notice patterns. There were really only about 3 buckets that everything fit into. And those buckets were:
Now why these three?
Great question. In no particular order:
Community + Evangelism
First: getting to know your users really well. The purpose of this bucket is to engage with your developers in our native habitat (i.e.- the interwebs). It’s fun to socialize basically, but this is also to also know what’s on the minds of your developers so you can take that back to the product team and help prioritize the roadmap. Most importantly this is the foundation to build empathy and relationships with your users. That’s just good stuff in whatever role you might have.
This bucket has things like:
- Reaching out to people on various platforms- Stack Overflow, Twitter, forums, or doing some light stalking and saying hello to our Github star users
- Working with a community member to develop something
- Setting up time to video chat or talk about a community members experience with the product
- Reach out to thought leaders in the tech space just to learn about trends they see in their work
Assets + Artifacts
Next up: making stuff. The purpose of this bucket is to ship all the things. After all, what’s a developer evangelist if they don’t actually *make* stuff? Now, “stuff” can mean different things. It doesn’t have to be level 80 Java and CLI 24/7 . You can have some fun with it. Things like:
- Technical walk-throughs
- Demos ranging from beginner to incredibly advanced
- Proof of concept tutorials- “here’s what you *could* do with this”
- A video to explain something. Could be pricing. Could be setting up a new database. Just another medium to engage your users.
- Blog posts. On your site. On a partners site. On this site.
Conferences + Events
Finally: get out of the building. This is probably where most people go mentally when they think about dev evangelists. It’s the people that just fly in circles around the world or ping pong across the US. Getting out there and actually being able to point to something with a user or going to a hackathon is important. This makes the first two buckets all the more meaningful. In this bucket I have things like:
- Develop a 30 minute presentation on X topic for Y conference
- Host our own event or meetup for devs interested in Z
- Organize an online bug bounty hackathon
- Find conferences and apply to them
With these three buckets I was pretty easily able to organize all my thoughts. YAY I win right!?
Not exactly. I had all these other things that would come up when I would start to think about an idea. Just random stuff. I realized: I need another bucket.
We’ll call this the “personal research as well as assumption & bias crushing bucket” (it’s a technical term).
This is the catchall for things I don’t quite trust or ideas that I don’t think are quite there yet. Basically stuff I need to research independently. The absolute last thing myself or anyone (developer evangelists especially) want to do is talk about something without some ole’ evidence and experience to draw from. These are things like:
- Get to know X technology more
- Create a feed of interesting people and blogs to follow in the space
- Research how great open-source communities are made
- Consider how we market using Y term and if there’s a better way to explain it
- Work with design to contribute to user personas. Share these personas.
The essence of this bucket is to always be learning. We all know tech is moving ridiculously fast and changing all the time. Having a catchall for things that I know I need to learn is going to be a part of the first three buckets.
Finally, my crowning achievement is that I put everything on a Trello board. I look at this board every day. Here’s the board:
Once I got a Trello board going things got really interesting. I know have hundreds of ideas to pull from. I don’t forget small but important ideas anymore. It’s focused. Buckets became boards. Cards became deadlines. People got involved. User feedback was cited. Evidence started to pile up.
In my next post on Developer Evangelism- same bat time- same bat channel: OKR’s and prioritizing the backlog
If you like this be sure to signup for my newsletter for more of the goods.