Pro Tips for Developer Relations

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.

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."

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.

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.

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!

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.

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.

"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.

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.

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.

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.

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.

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.

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.

Screencasts:

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:

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.

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.