Check out the free virtual workshops on how to take your SaaS app to the next level in the enterprise-ready identity journey!

Pro Tips for Developer Relations

Pro Tips for Developer Relations

I’ve been a professional developer advocate for a little over two years. I started out at Stormpath, and six months later, I leapt at the opportunity to do the same thing at Okta. I say "professional" because even though I’ve been a technical speaker since 2004, I never got paid for it.

During my first year (2017) at Okta, I traveled and spoke a lot. A lot being more than I’d ever traveled and spoken previously. By my count, I spoke 37 times, at 20 conferences, in 10 different countries. Near the end of that year, I experienced a bit of burnout. From that experience, and from talking to friends, I realized that I was trying too hard. I was creating too many new presentations for conferences. A couple of team members experienced travel fatigue as well, so we decided to refocus in early 2018.

Now we focus on producing content for and our YouTube channel first and foremost, and we try to speak at an event once per month. If that event happens to be local, great! We have no hard and fast rules on where evangelists should speak, but we try to hit major US cities, and target meetups (because they’re more intimate).

Recently, I tweeted a "DevRel Pro Tip" about how we produce content here at Okta.

The reason I like this system so much is that it makes you want a good developer experience. You want integration in the sample app to be fast. You want the tutorial to be simple. You want the demo to be awesome. Good software makes all of that possible.

I’m not sure if it was the content of that tweet or the excellent image created by David Neal, but it’s my most popular tweet. Ever!

Because of the positive feedback from that tweet, I figured it’d be fun to talk to friends that do developer relations to get their pro tips for making life easier. Of course, these tips don’t just apply to developer advocates. They apply to pretty much anyone that blogs and speaks (for fun or profit).

Aaron Parecki, Developer Advocate at Okta

Aaron Parecki

Live demos - practice practice practice! Nobody wants to see you muddling through a live demo on stage, forgetting commands or making mistakes.

Never rely on the venue’s internet for your demo! If you can, run a local copy of everything on your laptop so that you can do the entire live demo offline! If that’s not possible, then at least bring your own wifi hotspot so that you aren’t relying on the venue’s wifi.

Bruno Borges, Developer Advocate at Microsoft

Bruno Borges

One thing I like to do from time to time is what I call a Mashup Presentation. It requires zero content creation but requires demo creation. When I do something like this, it involves simply curating existing content from other presentations (from within the company or 3rd-party authors that allowed you to reuse their material), and then work on a demo that uses most if not all pieces described in the material. It is a good way to compact and connect interesting topics and present to developers, so they don’t need to figure out the intrinsic connections between the ideas. Plus, consumes less time.

A second tip is to contact the regional sales field when traveling, to find opportunities to meet with customers/prospects. May sound salesy, but it actually shows itself as a great source of real-world ideas to be covered in the future. Plus, it brings the advocate down to Earth. :)

Finally, I like to reuse as much material as possible, whether from myself or from others. What matters is presenting something that will be never-heard-of to the audience, doesn’t matter if it is something that was created in 2001. To me, advocacy is more about bringing information than "creating information."

Chloe Condon, Developer Advocate at Microsoft

Chloe Condon

I’ve always described my role as an "extroverted engineer" (which is a little hilarious, as I myself am an ambivert). Being a Developer Advocate means having a lot of balls in the air at once- from creating content, working with "influencers", organizing meetups, speaking at conferences, communicating to engineering teams, working on demos, remembering to eat and breathe…​ it definitely requires an agile brain to keep all the plates spinning at once.

Lately I’ve noticed that one of the coolest parts of job is that I get paid to meet/collaborate/work with some very cool people. I’ve always despised the concept of "networking", so I’ve just been thinking of it as "friend making" as of late. Though my default-mode is to escape to my hotel room post-conference and hide under a blanket, I’ve found that some of the most valuable connections (or "friendships") I’ve made have been in person at post-conference happy hours, after meetups, etc.

When it comes to creating content (especially at start-ups), it’s easy enough to create a cool demo/video and post it to your company’s internal blog. However, sometimes this can feel like an echo chamber. How often are you visiting other tech start-up tools' blogs? What is the audience reading it? Will it get any eyes beyond internal folks, potential interview candidates, and folks who read it from a tweet you posted? Working with other "friends" will not only get the content onto other blogs/resources/etc., but it also shows your tools playing well together, and gives fresh perspective and insight from someone outside of your organization. Teamwork makes the dream work! And friendship makes the…​ spend…​ lit? Ok, I need to workshop the pun, but you get the idea.

David Blevins, CEO Tomitribe

David Blevins

My number one, career-long tip would be to prepare and maintain an extra 20 minutes of material for any talk.

You walk into every talk knowing you can never possibly run short, which brings you confidence. Your mind will be focused on how to solve the problem of delivering as much as you can in such a short time, which shifts your mind off of yourself and onto the audience. You’ll be forced to ask them questions, so you know where and what to skip. Your talks will become interactive and more engaging. Every talk will be a little different which helps you fight speaker-boredom. In fact, as you discard parts and add another 20 minutes, your talk will naturally evolve to a completely different talk.

By nature, every talk you give will contain some seasoned material and experimental material. This is the magical balance that makes a rockstar speaker. Asking questions and engaging is scary for attendees. You need to both be incredibly knowledgeable, but also willing to take a risk and be vulnerable with them.

I have a couple of speaker-hacks I always use, but over time have needed less. First, I eat before every talk, preferably something heavy. You can’t get "butterflies in your stomach" if there’s no room. The second is I bring a bottle of water to every talk. If you start to lose your breath while talking, just stop and take a drink. You can catch your breath, slow yourself down and no one’s the wiser.

Heather Downing, Developer Advocate at Okta

Heather Downing

One of the best tips I ever got, is to structure your presentation with the WHY - or the end result - first. Think about the way television shows have changed their approaches over the years. They used to begin with the credits for the program and then start after that. Nowadays it is much more compelling to drop a viewer right into the action of a story - BEFORE the title sequence. You have less than two minutes to capture an audience’s interest in a way that will sustain them through an hour long presentation (or longer for a workshop). Tell them up front why you would use the code you are doing, but also communicate the end result once you do.

Another tip that leveled me up as a technical speaker: recording my screen while coding the solution before the talk. Just go through the typing you will do, and even break it up into small recordings labeled by order and description of what they are. If possible, upload them to a cloud folder for you do download on a separate machine if yours bites the dust. This has saved my skin more times during internet failure and IDEs freezing then I’d care to mention. Besides, this way, you can step out from behind the podium and gesture or point out what you are doing here and why. Most developers can read faster than you can type. Bonus content to use with creating YouTube videos or Twitch streams.

Effective speakers use social media tools to broadcast what you are talking about. Twitter is heavily the favorite here, so find out the day before what the conference handle is and any current year hashtags to use with your posts. Don’t forget to post a link to your sample code repository and/or slides on SlideShare for reference immediately after your session ends. That keeps the conversation going!

James Governor, Redmonk co-founder

James Governor

Say no to people ‐ a lot. No is your friend. Your good, decent, faithful friend. It is always there for you. By nature, DevRel folks tend to be eager to please, and love to be helpful. Being rigorous about what opportunities you take on, and those you pass up, is super important, for effectiveness and all round self-care. Say no to conference organizers, so no to your employers, say no to that extra trip that will mean you’re on the road three weeks out of four. Say yes to family, say yes to friends, say yes to quiet evenings. Always be saying no.

Related - you’re so money you don’t even know how money you are. Is impostor syndrome getting you down? You’re an EXPERT. Everyone wants to hire dev rel talent. Your company doesn’t appreciate the value of your work? Everyone wants to hire dev rel talent. Someone is being an asshole on the internet about dev rel? Everyone wants to hire dev rel talent. You are great; you keep the wheels cranking for so many platforms, people and community. Be kind to yourself. Because you’re worth it. And did I remember to say everyone wants to hire dev rel talent?

Editors note: Check out James' Sympathy for the DevRel blog post for more. I also enjoyed his talk with the same title on YouTube.

James Ward, Developer Advocate at Google

James Ward

Live code in presentations is more engaging than code on slides. But it takes tons of practice to do well. I often rehearse my live coding segments dozens of times. So much that I could do them in my sleep, or while nervous on stage, and talking to the audience.

Practice your talk in the demo environment you’ll use on stage. I was once thrown off in a demo because I switched to a machine that didn’t have git tab completion. Make sure that things like screen resolution are also the same.

Before you begin presenting code, walk to the back of the room and make sure the code is legible, i.e., font large enough with adequate contrast.

If an audience size is small for the allotted space, incentivize the attendees to bunch together in the front (perhaps with swag). This creates more positive energy that will help the audience and you to be more engaged.

Leave your bubble. To get a different perspective, seek out opportunities to interact with diverse groups. Go with the salespeople to a briefing in Utah. Lead a workshop in India. Present to college students.

Josh Long, Spring Advocate at Pivotal

Josh Long

"Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte."
"I have made this longer than usual because I didn’t have the time to make it shorter." -Blaise Pascal

Prefer breadth to depth. As a rule, I do a lot of "first steps in…​" type content because the way you grow an audience is by teaching them something they didn’t know. I’m not getting too far into the weeds of a given topic in my articles, presentations, etc. It’s all shallow-end-of-the-pool type stuff. When I first started I realized that while I might want to write about, say, the cross section of rules engines and enterprise application integration, this wasn’t a topic that has hugely broad appeal. In 2010, a better topic might’ve been "Getting Started with REST." Or something.

Target your audiences. If you are going to do depth-first content - something that takes for granted the audience’s familiarity with the topic - then make sure to target the content to the right people. I’d put that content on my company’s website properties, for example. Or at my company’s tentpole conference SpringOne Platform. Or, make it content that people can self-select into. It would be a wasted opportunity with a possible divergent audience if I were to give those sorts of talks at a JavaOne or a Devoxx or a GOTO or a QCon.

A developer advocate isn’t necessarily a road warrior. Developer advocacy is not just about presenting at conferences and while killing it at a conference talk in some other country is a satisfying way to spend a day, it’s by no means necessarily the most effective way to reach people. If you’re going to be at a conference then make sure your talk is recorded and that it will be put online. Otherwise, you’re just doing the talk for the people in the room. Hopefully you got a few hundred people, but was that worth the cash expenditure? The time? I try to do big shows with a global reach. Otherwise, blogging, podcasting, screencasting, webinars, and even just Tweet storms can all reach larger audiences. Technical content news portals and aggregators like InfoQ, TheServerSide, Reddit and DZone can even help you get that content to larger audiences, too. Some of the best developer advocates I know are almost never at conferences. The one exception to this user groups. Often, user groups are the only way to reach people who might not be in a large market and might not otherwise be inclined to travel for tech. A good deal of companies are perfectly nice places to work but don’t send their people to San Francisco or some other major technology market for training every year. That’s the rule, not the exception. A User Group might be the best place to reach these people. Not to mention the intimacy makes these venues an ideal place to test content before you take it to the big shows.

Relax. If you’re nervous then how can you expect your audience to be enthusiastic about your tech? Stage fright is a part of our basic fight-or-flight instinct. Our lizard brain kicks in when we’re surrounded by large groups of people we don’t know. It’s innate in each of us to be nervous on stage at first. This will subside with practice and the sooner the better. Practice, practice, practice. It’s cliche but you really will improve even if you just give the talk a half dozen times to yourself in front of a mirror or a recording laptop camera. Set a timer and everything. The best orators practice. If you’re still nervous, and just generally, it’s always a good idea to have a drink on stage. Water. Tea. Coffee. Something to clear a throat, fill in the idle time, stop a coughing fit, or generally keep your body circulating.

Different strokes for different folks. Do a little of everything. If we agree that the best way to reach people isn’t always by being a road warrior, and if we agree that you should stay in the shallow end of the pool and do lots of introductory stuff, then a happy consequence is that you’re home and able to focus. Use that idle energy on different mediums. Blogs, articles for magazines or online tech portals, podcasts, Twitter threads, screencasts, webinars, and books are all tools of the developer advocate, in addition to conference talks. Try to do a lot of each every year. I blog, podcast, write books, do screencasts, and yes, I spent more than a month and a half in airplanes traveling more than half a million miles last year to hundreds of meetings around the world. The more I do the more I want to do because I learn in the process. A master teaches.

Prefer breadth to depth, part II. Ironically, I want to add some depth to my point about preferring breadth over depth. Nothing worse than an itchy throat or an unyielding cough on stage. If you’re doing introductory articles, then there’s no reason not to have introductions to lots of different things. Do talks of the form $YOUR_TECH with $OTHER_TECH. This has two benefits. It extends your reach to members of the communities of other technologies and it gives you a built-in opportunity to reach out and work with other people in those communities. You’re going to do the same talks over and over, so it’s nice to keep it interesting and, every now and then, do a tag team talk. I try to do a half dozen big, new, talks with people in other communities every year. I’ve made friends and learned new things in the process. The more out of your comfort zone, the better! These talks inspire creativity.

Relax, part II. Don’t take yourself so seriously! I love having intense, serious soliloquies in my performances because they set the stage for the inevitable comic relief of whatever absurdity I’ve got planned. It helps disarm people. If somebody wanted to learn about your tech they could read a blog post or a book. But they chose to come watch you explain something. Don’t waste people’s time with a blog post you’ve extracted out into bullet points. If you’re on stage, you’re performing. Take advantage of the medium. Tell stories, jokes, do visual humor, etc. If you want them to remember something, give them something memorable. Visual and spoken humor is a great way to do that. At least, so I’m told…​

Never forget your privilege. Remind yourself every day that you’re a very lucky person. You get to be the visible face of a technology on which a good deal many people besides yourself work while also earning a healthy paycheck, traveling the world and becoming tech-famous. Meanwhile, there are real teachers, who take responsibility for outcomes and put in 8-15 hours a day for months at a time, educating the youth in our society, who would kill to have our bad days. These men and women are heroes and in a fair society they’d be much better rewarded for their efforts. It is always OK to donate time and money to teachers and students

Use your platform responsibly. Don’t be an ass.

Lee Brandt, Developer Advocate at Okta

Lee Brandt

I recommend giving new talks at user groups first. This helps the user group leaders (who ALWAYS need speakers). It also helps you gauge interest in the topic and get questions/feedback to improve your talk.

For ideation, I recommend asking your network. I often do this with a tweet: "What do you wish you knew more about?"

For travel, buy a second set of everything you MUST have on a trip (shampoo, conditioner, belt, razor, etc.) and keep it in your suitcase ready to go. That way, you never forget these things. I used to forget a belt all the time and would end up having to buy one on the road. First thing I do in a hotel room is pull the "laundry" bag from the closet to use for my dirty socks and underwear. That way it stays in my suitcase and not laying on the floor, etc.

Markus Eisele, DevRel Lead Lightbend, Inc.

Markus Eisele

Social Media and Developer Relations:

Social media is great. Being in contact with people from all over the world and being able to help your community from everywhere is nothing short but amazing. Yet, there are a few things to keep in mind while using these tools to their full extent without failing.

  • Be yourself - Act as a person before you try to promote a product.

  • Listen more than you talk. - "You have […​] two ears, but only one mouth. This is so because you are supposed to […​] listen more than you talk"

  • Remember that this is also marketing. - Honor the three E’s of Content Marketing: Educate, Engage and Entertain

  • Respect the receiver. - "Every message has four sides." Schulz von Thun

  • Have a focus. - Stay focused, go after your dreams and keep moving toward your goals

  • Deliver relevant content. - Rather make a show that 100 people need to see than a show that 1000 people want to see

  • Don’t spam

  • Know your metrics

  • A picture is worth a thousand words

  • Respect cultural differences

Unfortunately, there is no general advice on the content you should tweet about as this will probably also heavily depend on your own interest and your field of work. But one thing should be kept in mind. There are things you don’t talk about at a dinner table. And this simple rule should absolutely apply to all your public interactions.

If you want to learn more, I can only suggest looking at this complete presentation on the topic.

Mike Hartington, Developer Advocate for Ionic

Mike Hartington

Prepare to fail. Demos will fail, it’s bound to happen. Always have a backup plan like a video.

Before making a presentation (slides), write down some ideas as bullet points. I write most of my talks as just a giant list in markdown before ever making slides. It helps to get all the ideas out before slides are even thought of.

Giving a talk can be nerve-wracking if you don’t have a process. Best piece of advice I’ve ever got is to take some time beforehand and get into "character". Walk around a bit, do some push-ups, listening to some hype music.

Randall Degges, Head of Developer Advocacy at Okta

Randall Degges

One of the pro-tips that has served me well over the years: be authentic. Don’t be afraid to swear, or just generally be yourself when giving presentations, writing, etc. Write like you speak, speak like you’re talking to friends, and just be yourself. =)

Secondly, think about whatever it is you can do to have the biggest impact on developers in a positive way, then do that thing. That might be engineering work, marketing work, meetings, but do whatever needs to be done.

Ray Tsang, Developer Advocate at Google Cloud Platform

Ray Tsang

Rehearse! English is my second language. I rehearse out loud a lot for my presentations to get used to what I say and how I say it. During my rehearsals, I record myself to identify words that I can pronounce more clearly, catch any "uh" or "um" that can cause a distraction, watch for tone, pace, volume, and pauses. When I mess up, I restart from the beginning.

Don’t memorize the speech word for word. I let the slides drive and remind me of the story I want to tell. Each slide is a hint to the detail of the story I want to tell. The slides are ordered to complete the story arch. A few words on the minimal slide remind me of my own experiences and thus remind me of the story I want to tell.

Live coding should also tell a story. Some parts of the code are boilerplate. That doesn’t help the story - automate it, template it, or have a shortcut for it. Some other code is important to discuss and/or illustrate key points.

Clearly identify the goal of the presentation/content. This helps me guide the amount of detail I need for my presentations/code labs. If there are boilerplates that are irrelevant to the goal, try to simplify it.

Be honest and authentic. As developer and user of different technology. If something doesn’t work well, it doesn’t work well. How can we improve it? What are we doing to improve it?

Prepare to recover from a demo fail. If I’m confident that I can fix it, I’ll talk about the issue, the strategy to diagnose, and discuss how to fix it. If it’s unrecoverable, move on to the next topic.

Always make slides, demo, and source accessible online so that others can try it.

Trisha Gee, Developer Advocate at JetBrains

Trisha Gee


Screencasts should be short, like 2-5 minutes. Even screencasts over 3 minutes can lose the watcher’s attention. To that end, a screencast should focus on a single tip/feature/use case. If your screencast is longer than this, it probably needs to be broken down.

The hard thing about screencasts is not the recording or editing (although editing it to have good rhythm/flow and be punchy is hard); the hardest thing is figuring out what to showcase and presenting a use case or code sample that’s simple enough to be understood but real-life enough to help developers to understand how it applies to their work.

Reusing content:

Screencasts can be split up into even smaller sections for promoting things on Twitter. Think less than 30 seconds of movie/gif on Twitter to either highlight a cool feature or as a teaser to a longer piece of content (blog or screencast).

The more time you invested in prepping something (e.g., a talk or live demo), the more you should aim to reuse that content. E.g., for my live demos, I usually give them at half a dozen conferences (at least) during the year, fine-tuning them as I go. When I’m happy, I’ll record it as a free webinar either via JetBrains or the Virtual Java User Group (or both!) so that everyone can see the "final" version. I also use the code from these demos and the experiences of learning to put together the demo for further content, like blog posts, screencasts, Twitter tips, and articles for online magazines or guest blog posts.

Live demos:

Don’t do them! No, really! OK in all seriousness, if you really really want to do a live demo on stage then do some or all of the above:

  • Keep them short and simple, so they’re less likely to break, and you’re more likely to be able to complete them without something going wrong

  • If you’re doing a longer demo, split it into short steps and ideally have a way to jump straight to step 3 (for example) if steps 1 and 2 didn’t work (see backup plan below)

  • Try, if at all possible, not to need the internet. It’s always really flaky at conferences.

  • Script absolutely every step you’re going to take. If something goes wrong or you forget where you’re at, you should be able to view your script (preferably on a separate device like a phone or tablet) and find out exactly what you need to do next. This includes writing out all commands and/or code that you might need to type in the demo

  • Practice, practice, practice. For a talk, I would practice it maybe 2-3 times before I first give it. For a live demo, at least twice that. Your fingers should remember what to do, not your brain.

  • Have a backup plan (or two or three!). E.g., copying and pasting the code from your script; using a git repo with the steps already committed as separate commits; having macros or live-templates to automatically play some steps; having a video of the demo should things go horribly wrong.

Live demos are really hard, and they take a BIG time investment. E.g., I can probably prep a standard talk in 2-5 days, depending upon the content. A live demo will take 2-3 weeks minimum, and that’s working almost full time on it.

More Pro Tips!

There’s a lot of wisdom in these pro tips. Practice, practice, practice - especially when doing live demos! Prepare to fail, and have a backup plan for when your demo doesn’t work. Be authentic and let your personality shine through in your presentations and online persona. Like Trisha mentions, live demos are a real-time investment so prepare accordingly and practice. I like to write up a demo script (like this one), so I don’t forget the necessary steps to making things work.

Use social media wisely (try to stay away from politics and religion, just like you would at the dinner table) and listen more than you talk. Tell a story with your presentations and live coding. If you do live coding and demos, make sure the source code is available (and well documented!) so others can try it.

To see some examples of how we do developer advocacy at Okta, check out these posts and videos:

If you have more pro tips for speaking or living the #DevRel lifestyle, I’d love to hear them! Please add them in the comments, or hit me up on Twitter (@mraible).

Update: Pro Tips for Developer Relations, Part 2 is now available!

For more awesome content, follow @oktadev and subscribe to our YouTube channel.

Matt Raible is a well-known figure in the Java community and has been building web applications for most of his adult life. For over 20 years, he has helped developers learn and adopt open source frameworks and use them effectively. He's a web developer, Java Champion, and Developer Advocate at Okta. Matt has been a speaker at many conferences worldwide, including Devnexus, Devoxx Belgium, Devoxx France, Jfokus, and JavaOne. He is the author of The Angular Mini-Book, The JHipster Mini-Book, Spring Live, and contributed to Pro JSP. He is a frequent contributor to open source and a member of the JHipster development team. You can find him online @mraible and

Okta Developer Blog Comment Policy

We welcome relevant and respectful comments. Off-topic comments may be removed.