Summary

• A developer advocate is a mix of an evangelist, an engineer and a tech expert who loves creating content and also is an inclusive community builder.

• Qualities that make a great developer advocate

  • Enjoys learning

  • Embraces changes

  • Likes building

  • Empowers others

  • Are creative

  • Like to share their work

  • Embrace diversity

• A typical day of dev advocates usually/arguably revolves around two things

  • Content

  • Community

Scribbles

What/who is a developer advocate?

• They can go by many names -- the closest would be, evangelist, an engineer and a tech expert who loves creating content and also is an inclusive community builder.

• Developer advocates like the name suggest, advocate for/to developers.

• They help developers/users, use the product better and make it easier to understand the tech.

• Facilitator who empower you to engineer products with ease.

Great developer advocate

What exactly makes a developer advocate -- great?

Enjoy learning

• Learning never stops, especially in this job. There might be frequent switching of the tech stack.

• Always looking out for new tech and ways to solve problems.

Embrace change

• Dev advocates are engineers who are aware of how fast the tech advances.

• They are ready to embrace the change.

• Enthusiastic about ramping up each time a new tech is released.

Like building

• Developer advocates know what they are advocating for developers who use their products.

• They always find ways to build and improve the dev experience.

Empowering others

• Finding their success in other's is something that comes naturally for them.

• Empowering developers to create great products.

Are Creative

• Developer advocates look for creative ways to challenge the existing product to make it better.

• Try to deep-dive into how it works and learn the underlying technology so that they can answer the "why".

Like to share

• Sharing information is a great way to advocate, or let's just say it is necessary for an advocate. How else are they supposed to be connected with the users?

• Strongs communication is the key.

Embrace diversity

• Work with a large developer audience, which includes people from diverse backgrounds.

• Diversity brings various ideas due to the various backgrounds of different individuals.

Work cross-functionally

• Developer advocates need to work with various teams and need to communicate the needs of different teams.

• Working closely with the product teams as well as the community.

Typical day of dev advocate

• Now, this is something that can vary so much, especially based on the dev advocate's goals and choices. But, rest assured community and content are still the main part of their goal among a few others.

Community

Without a community, there is not product.

• Community is not just a group of users/developers/customers interested in your product but a group of like-minded individuals who believe in the product and its success.

• Building a community is all about-- a group of people with common passion, who share a sense to achieve together.

• Check the linked scribble below to know more about few well-known community builders out there and how they started building their communities.

• Being a part of the community helps in identifying who is contributing to the community, their passions.

• Helps in building trust and facilitating collaboration.

• Dev advocates need to make sure there is a constant engagement in the community and providing them with the content.

• Community engagement is continuous work.

Content

• A typical day of an advocate may go by in deciding the type of content that should be provided with the product.

• A large portion of the product's success boils down to the content that goes with it.

• Without the right content, it gets difficult to for developers to know what the product does, how does one get started with it, what can one build with it.

• What content to make? Should be among the first questions you ask.

• Who is the content for? Which users are we targeting?

• What do we want to achieve with this content? -- metrics attached with it.

• Once all the questions are answers, one can have a better understanding and a clear bias on what content their team wants to create.

• The story behind why the product is beneficial for the users, along with other similar products out there and giving an honest comparison.

What does it take?

What exactly does it take to become and developer advocate?

Always seeking to learn new and explore new things.

Summary:

• Understand the problem with your product’s current interactivity and creative initiatives that let developers be creative.

• Understand how you can help them using your product.

• Test creative initiatives and get feedback.

• If you want people to see that value, it’s really important to get it to a way that people can explore and be curious and let them play and be creative.

• Understand the outcomes and measure how it has impacted the experience of your developers.

Scribbles:

The problem

• This product does not feel intuitive.

  • It doesn’t feel intuitive and natural.

• Hard to use.

• Not the coolest thing in the world.

How can they help them?

• Make it easier to see the value, easier for us to understand, and show developers why they should be using messaging and why they should care.

• Make it easy to try out.

• Give people opportunities to play because right now, it’s pretty hard to get going, so they want to give them that chance.

Children are very discerning customers.

• They really made sure that they would appeal to them.

• So they decided to use Scratch.

  • Scratch is an open-source project developed at MIT.

  • Basically, it’s a visual programming style.

  • It lets people click and drag things together like little blocks, and that shows the syntax of the program without worrying about the syntax of the program.

• Max (speaker) decided to go away and try to make some things so that they could use messaging with Scratch. ‌

• “Where does my 9-year-old come in?”

  • They wanted the kids to be able to see the value.

  • They decided to find a real test subject.

  • His team lead has a 9-year-old son.

  • Using this and using this program, he was actually able to create a little game in Scratch.

  • But he was also able to save his score by putting it onto a messaging queue.

  • He was able to understand why he was doing that and why he was able to see his high scores again.

‌The Scratch Extension (Scratch X)

• Program runs in a browser and communicates with a Raspberry Pi.

• Basically, they’re allowing that to actually send messages and give them instructions.

• Then, they're taking the score from here and they're putting it back to the program.

• Gives a sequence of lights to be played on here, and the user then has to try and remember that sequence and play it back.

Outcomes

• This has allowed them to actually go and talk to developers -- developer conferences.

• It meant that they can actually now have a conversation with their developers, and with people who maybe want to understand why they should use messaging and what the value is.

• Developers can see that value.

  • They found that their developers really do understand what’s going on here.

• People actually get to have a play with something and they get to have some fun.

Developer Evangelism

Technical keynotes should be captivating, right? But too many are dull and pitchy. Avery Rosen shares practical tips for pulling off a keynote people will talk about.

Melinda Seckington shares how some simple design element tweaks can magnify the impact of your presentation.

Drawing on her extensive experience of conference speaking, Mel shared insights that are a must-see for anyone working in developer relations.

Melinda Seckington completes her three-part series on how to create great conference talks.

Various well-known developer event organisers discuss what they see as being the future of gathering, talking about how events will look like in 2021 and beyond!

Developer Experience

Tanay from n8n, talks about the power of great content, including its ability to shape the culture of a developer community, and how to approach creating a meaningful content strategy from scratch.

Listen to Laura Cowen as she goes around talking about how she developed a community and DevRel culture in IBM making the organisation understand the needs and expectations of the developers.

Jamie Wittenberg talks about great ways you can incorporate to make your documentation better and more accessible to new developers.

Explaining your role and function comes with the territory of working in this space, but why is that? It’s tricky to define, describe what developer relations is, and why it even exists?

Mike Stowe takes a look at the Hierarchy of Developer Needs, and how you can use it to balance your efforts and ensure your users are successful.

Lorna Mitchell covers what it takes to create a README that engages and informs developers.

Cristiano Betta shares the practicalities of how they have taken an engineering approach to their API documentation.

Can you make good release notes by collating your commit messages? Eva Parish argues not. Eva Parish explains the different purposes of commit messages and releases notes.

Google’s Sangeetha Alagappan talks about making your docs inclusive, what accessibility means in the context of documentation, and common pitfalls you might encounter.

In this talk from DevRelCon London 2019, Jo Cook talks about The Good Docs Project and Google’s Season of Docs are working to make it easier to create excellent open-source documentation.

Gary Niemen share their story of how their approach to documentation has changed at Spotify, drawing parallels with Joseph Campbell’s Hero’s Journey framework.

Community Management

Let's take a dive into learning what flywheels are and how to make them, eventually using them to build better communities.

Developer relations and community management often look like two sides of the same coin, but taking a step back it becomes clear that they are distinct yet related.

Gerard runs through the key elements in growing a successful tech community around meet-ups and events.

Twitter Spaces fireside chat as we discuss growing healthy open-source communities with Brian Douglas, Developer Advocate at GitHub.

Orbit CEO Patrick Woods and Community Lead Rosie Sherry, discuss how you manage a community at scale and the lessons learned scaling up along the way with Ben Lang, Community Lead at Notion.

How you drive business growth with Community and why you need a Go-to-Community strategy, not just Go-to-Market.

How experienced community leaders from various backgrounds started building community and what worked for them.

Managing A DevRel Team

Brandon West from Amazon AWS talks about how to manage a distributed developer relations team, especially where each person on the team tends to travel a lot.

Whenever it has come asking as to "what is the main role of DevRel team"? The answer-- "It totally depends", which definitely raises more doubt in the mind of the person asking it.

What's the ROI -- the metrics to measure them -- explaining it to an employee. With DevRel Qualified Leads you first set your own metrics that truly reflect the value of the work that you do.

Scribble from Mary Thengvall's amazing blog "The DevRel Path To Success: Awareness, Enablement, Engagement", which talks about what are the key elements of a developer relations team.

How does one move up in their organization as a DevRel? What does that "up" even look like if it even exists! Let's take notes from Chris Noring who is a Developer Advocate at Microsoft.

To devise a DevRel strategy, one must understand their company's needs and the tactics that can be used to meet them. Let's take a look at the four pillars to understand all of this in a better way.

Let's take a look into knowing the key elements required to make a "DevRel dream team".

A research-based framework for recognising and managing overwork.

David G Simmons shares the reality, including potential upsides, of making mistakes.

Miscellaneous

How do you know whether moving into developer relations or DevRel is right for you?

Christiano Betta talks about the importance of creating different tools and collecting metrics, especially for startups helping them grow more with a small team!

What is the career path in developer relations and how can you build a long-term plan for your own DevRel career?

DevRel Scribbles is a collection of notes from different DevRel Talks, Podcasts or anything that covers the best practices around DevRel. This can be exceptionally useful for someone trying to find out a specific topic, a specific thing they might have heard at a conference or just exploring different talks and do not have the time to listen to it wholly. Just read the notes and you're good to go on most parts!

As this repository grows, we will have a curated list of DevRel talks, segmented in different groups. Using the great search features of GitBook one can easily find out the best practices related to a specific field within minutes, skim through the notes and know what might be the best thing to do for a specific case!

Our aim is to keep this repository open source and free to use for anyone in the community. The support and contributions here would be the thing driving it forward. Let us know if you're willing to help!

Looking to submit a DevRel Talk/ Podcast to be covered here?

Summary:

• Ask questions based on ethics before creating a tool.

  • So, maybe collectively, again, we don’t have all the answers, we’re kind of here to pose some more questions.

• Personal communication techniques

  • Somebody wants to be that whistleblower, at least feel comfortable.

  • They know that a community has their back.

• What drives developers?

• What do we do about it?

  • Take a look at what the root cause is.

• Causation and root cause

  • What can we do about it?

• Understanding Culture

• Psychological safety?

• How would you report on a violation of ethics?

• How can DevRel’s solve the problem?

Scribbles:

What drives developers?

• It’s pride.

• “I made that. Have you seen how cool that is? I made that.”

• That’s really what drives people to build things and to keep growing.

• It’s pride being able to say you did something that was really wonderful.

If we’re not thinking thoughtfully about what we’re building, what could possibly go wrong?

• There’s a ton of fraud that’s in the industry.

• Issues happen when we’re not being thoughtful or thinking about ethics in what we’re building.

Oh, crap. I made that. I’m part of that responsibility. Or for those of us in dev rel, it’s like, Holy crap, they made that with our tools. How does that make you feel? That’s when it starts to become really personal.

What do we do about it?

• Take a look at what the root cause is.

• There’s a number of different root causes for tech not being thoughtful and ethics not being followed.

• There’s a lot of complex undertakings, a lot of projects are getting more complex.

Causation and root cause

• Developers as a whole, and even dev rel as a whole, tends to be quite immature, lacking experience.

• Survey results that came from Stack Overflow

  • One-third learned to code in the last nine years and a lot of them don’t have a lot of business experience either,

  • There’s a lack of context and a lack of just knowing how to interact, especially within a big corporate environment.

How would you report on a violation of ethics?

• Most don’t know how to report it and they don’t know how to handle it.

“Developers can actually be the last line of defence against unethical code.” Wow

Root cause

• Inexperience

• Unreasonable deadlines

• Shareholder expectations

• Incomplete information.

• Culture lacking in psychological safety

  • Feeling very uncomfortable speaking up.

What can we do about it?

• One of the biggest characteristics of being good in dev rel is empathy.

• DevRel’s belong to a group that sits in the middle of everything and talks to everybody, so we’re in a good position to be able to bring some of those issues forward.‌

Culture

• Culture is not created from top-down.

• “Here’s what our culture is. It’s written on the walls and everybody follows it.”

• Culture is really about what happens every day, day-to-day in business, and culture can change from the bottom-up.

Psychological safety?

• If you’re in a meeting with your boss and you worry about reprisal for speaking your mind or telling them, “This is not OK. “This is not ethical,” then it means you don’t have psychological safety within your team, or with your boss, or with your peers.

How can you create it in other people?

• Start doing it yourself, even if leadership isn't doing it yet.

• Moment someone says something you don’t want to hear, or even if they bring a personal attack, instead of defending or having a fight reaction, try to become curious about what it is.

  • The depth of that feedback.

  • Where do they come from with this?

  • What’s going on there?

• Key part of psychological safety is being able to listen and understand.

• Not just listen to respond.

• Understanding takes a willingness and curiosity to get in the shoes of the other person who’s trying to tell you something.

• Talk about times when they failed and times when they were wrong.

  • People often feel that they have to show that they’re right.

What can DevRel do about it?

• DevRel can act as a safe channel to leadership.

Think of it this way, if some engineers of GitHub didn’t feel safe within their departments to speak up, dev rel could have gathered all of those numbers and all of that feedback.

• It comes down to how we can empower our own teams

• How we can empower the developers that we work with.

  • With information/training/ guidelines

  • Personal communication techniques

  • A community that has their back

Summary:

• Evaluating your existing program.

• Keywords

  • Shoe - People

  • Pyramid - Principals

  • Truck - Signals

  • Map - Placemaking

  • Hallway - Journey

  • Flywheel - Publishing

• Know who you’re actually serving.

• Defining core principles.

• Signal change

• Make a place

• Journeys

• Publishing

Scribbles:

Six things to remember when evaluating your existing program.

• Keywords

  • Shoe

  • Pyramid

  • Truck

  • Map

  • Hallway

  • Flywheel

• ⬆️ They’ll make some sense by the end of the scribble

Know who you’re actually serving

• Maker is an interesting concept to discuss.

  • A maker is someone who puts their hands on the products to solve their personal and professional challenges.

• An emphasis is required to keep telling the story of who the maker is. What we’re doing, why we’re doing it, is for the people who actually put their hands on the product.

• Personal -- these folks want to advance their own skills and abilities.

• Professionals, they have goals that they want to meet in their own career.

• Maker is someone who builds.

• The goal of doing DevRel is to try to join them on that building journey.

  • Because they’re going to build with lots of different tools and technologies.

  • Your hope, your aspiration is to be able to join them in that building process.

• Enterprise developer -- security, scalability, and legacy. ‌

Defining core principles

• Why does your program exist?

• Why does it really exist?

• Not just to drive sales, you have to go deeper than that.

• Programs should exist to empower developers along their journey.

• Tools to solve the problem

  • Providing solutions that are easy to find and simple to use.

• Knowledge to grow expertise

  • Delivering insights in areas where we have something to say.

• Community to share progress

  • Uniting developers to lead their work and careers forward.

‌

Signal change

• You have to give outwards signals, especially when you’re in a turnaround or a reboot, that something has changed.

• You have to back that up with visible outward signs.

• The visible outward signs had to be backed up with real behind the scenes change.

Make a place

• Show, don’t tell

  • Demonstrate ability to deliver value; serve first.

• Every page is the homepage

  • Far more traffic enters through the rest of the website

  • Creating focused opportunities for discoverability is critical

• Navigation is brand

  • Educate visitors about your opinionated worldview with opinionated navigation.

  • Lead with fresh, a topical structure that aligns with the user journey.

• Best content first, presented in the best way

  • Videos, Blogs Learning paths

  • Every grouping of content is not the same, each group must be allowed to be different.

Journeys

• Question/Challenge

• Developer program content

• Implementation

• Solution Achieved

• What stories across the top do they tell themselves about themselves, about their work, about their world?

• What content are we going to create?

‌

Awareness journey.

• There are moments of truth along this journey, where someone is moving from left to right, and they have a moment of proof that tells them, holy cow, I think I’m on the right track.

‌

Publishing

• DevRel program at scale across many locations, the digital, online, grip is everything.

• Your job is to fix the broken gears and teeth, even if you can’t see the immediate result.

• Mobile layouts. ‌

• Small compounding changes

  • Seo optimizing titles

  • Cross-linking to other assets(votes)

  • Mobile-first

  • Tone and voice (brand rep.)

  • Functional content/ tutorials

  • Videos

  • Working gates (SSO)

  • Talk to your audience (weekly newsletter + social media)

Keywords Now!

• Shoe - People

• Pyramid - Principals

• Truck - Signals

• Map - Placemaking

• Hallway - Journey

• Flywheel - Publishing

Summary:

• How do you design effective slides?

  • How do you create slides that are compelling and help your audience understand what you’re trying to say?

  • Principles for slide design

• Principles for slide design

  • Maximise Signal, Minimise Noise

    • Maximise relevant information rather than irrelevant information.

  • Make Important Information Stand out

    • Use contrast in your slides to make things memorable.

  • Show and Tell

    • Information recall is better when combining text and images.

  • Be consistent

    • Use consistent designs for slides with the same purpose.

• Maximise Signal, Minimise Noise

  • Focus on one purpose per slide.

  • Slides are not your teleprompter.

  • Your slides are not meant as notes or references for people after your talk.

• Make important information stand out

  • Colours

  • Shapes

  • Size

• Show and tell

  • Photos

  • Icons

  • Shapes

  • Animations

• Be Consistent

  • Use consistent designs for slides with the same purpose.

Scribble:

The goal of the presentation

• There are endless motivations for giving a presentation and no two presentations will ever really be the same.

• Yet, at the heart of it, they all have one thing in common.

• No matter what your presentation is about, your number one goal as a presenter is to allow your audience to absorb your information

What are Effective slides?

‌Cognitive load

• This is the amount of mental activity required to accomplish a goal.

• So, mental activity being things like perception, memory, and problem-solving.

Effective slides?

• Slides that help reduce that cognitive load.

• Slides that help effective help your audience consume your information.

How do you create design effective slides?

How do you create slides that are compelling and help your audience understand what you’re trying to say?

Principles for slide design

• Maximise Signal, Minimise Noise

• Make Important Information Stand out

• Show and Tell

• Be consistent

Maximise signal, minimise noise

• So this principle comes from the theory of signal-to-noise ratio.

• The concept is that in every type of communication we have, there is a certain amount of relevant information, the signal, and there is a certain amount of irrelevant information, the noise.

• We want to maximise relevant information rather than irrelevant information.

How do we do that in our slide designs? How do we make sure that the information on our slides is mainly relevant rather than irrelevant?

Maximise Signal

• Focus on one purpose per slide.

  • So this is about maximising the signal.

    • The moment a slide has multiple purposes, it dilutes the relevant information.

    • So rather than having a single slide -- split them out over several slides.

• Slides are not your teleprompter.

  • You’re using your slides to get a point across to your audience and you’re using your slides as reminders to yourself.

  • If you really need something to help you remember what to say, use your presenter notes for that because that’s what they’re there for.

• Your slides are not meant as notes or references for people after your talk.

  • Your slides are meant for the audience that is there in the room with you.

  • If you need to share something with people afterwards, use a format that actually makes sense for that.

  • So a blog post or a video of a talk or anything other than the slides that are meant for your audience.

Minimise distraction

• We’re trying to minimise noise.

• Ensuring that we don’t have any irrelevant information.

• Try to use common sense and just make your slides clean and simple.

Ways of being distracting

• Too much text on one slide.

  • So the moment you have a slide like this (one with lots of texts), people stop listening to you.‌

• Too much going on them.

  • So keep your slides simple and clean so that they’re not visually distracting.

So this is exactly the same images as before, but because there’s no overlapping and because there’s no text over it it’s much easier for the audience to process.

Make important information stand out.

• Contrast the state of being strikingly different from something else in juxtaposition or close association.

• Use contrast in your slides to make things memorable.

Ways

• Colours

  • Choose a colour palette that has contrasting colours.

  • Besides using contrast within slides, you can also use the contrast between slides.

• Shapes

  • Circles, squares, triangles.

  • Fonts

    • The way of achieving contrast is through using different types of fonts within your presentation. ‌

    • Using different fonts within the same phrase or sentence. So the contrast is used to highlight specific words.

    • Using different fonts for different elements on the slide.

• Size

  • grabbing an element and making it bigger. ‌

Show and Tell

• This principle comes from the picture superiority effect -- information recall is better when combining text and images.

Ways

• Photos

  • Makes your slides more lively, more memorable.

  • Maximise signal, minimise noise -- make sure it’s relevant.

  • Completely fill-up the slide and then pair it in some way with text over it.

    • The audience will have a much more visceral reaction, which, again, makes it more memorable.

• Icons

• So the easiest resource for icons is the Noun Project. This website offers a ton of royalty-free icons of all different topics. And you’re bound to find icons in there that you can use. I even found one for Synergy once. And I’m really annoyed with myself for looking that up.

• Shapes

  • Simple pie charts.

  • Building diagrams that are much clearer than relying on text alone.

• Animations

  • Don’t misuse them.

  • Keep it as relevant as possible

Be Consistent

• “The usability of a system is improved when similar parts are expressed in similar ways.”

• Use consistent designs for slides with the same purpose.

Ways

• Identifying patterns

  • So this is all about identifying your slide patterns.

  • What are the types of slides within your presentation? ‌

  • Helps as your audience has reference points.

  • They become easier to process even though it, kind of, might happen subconsciously. ‌

“I don’t believe that there is one true way of creating slides. So this whole talk isn’t about getting you all to create the same type of slides that I do, but rather it’s helping you to get a basic understanding of design and applying it to your own style and presentations.”

Summary

Why

• Students are a fantastic audience to get your brand message out, testing out your product and everything else at a very high engagement rate.

• You need to empower students in your ways, helping them learn and understand how to become better developers.

• Student trust other students, talking to each other about the feedback.

• Students even become advocates for your brand

• Although they might not generate revenue instantly, students provide a long term outreach for your business.

• Students graduate much before you think, work in startups, internships increasing your product reach everywhere.

• Your documentation does not work until a first-year computer science student reads it and successfully integrate your product.

• Students active in the community are great for recruitment!

How

• Reaching universities directly is not fruitful. You should reach the societies through the departments.

• Explore different Facebook groups and interact with them

• Participate in their events both online and offline.

• Communicate with them

• Be fun and interact with them, sharing your knowledge in every aspect and not just talking about your product

Scribbles

Engaging Students

Focus Group

• 18-22 year old students from UK & Scotland students are focused here

• Typically study a fixed degree

• Found out that students in the UK and EU are more Tech Savvy than the US because of the major mind system but less prepared in other ways

• Found out that students in the UK struggled with Pitches and Presentations and may struggle in cultural interviews more than the US Students.

• This talk primarily focused on students who study CS and also the ones who are not related to CS in any way in their education but met evangelists and people from the industry experiencing this world of CS.

• Belong to the Students' Union and more specifically societies that are meant to empower students in a particular subdomain.

Why Engage Students?

• Students are fantastic to get your brand message out there.

• They're fantastic in testing out your product

• Very very good for the students' enrichment in education

• Recruitment is a great part of this as well - not being touched in detail in this talk.

Brand

• We're looking to make connections with developers and to enable them to build cool things, enable them to use our products in fantastic ways.

• Students generally do not have an idea about the Software development world, their degrees do not teach them about real-world things.

• They know the fundamentals of building a product but do not have the real-world tools to make them in the first place. Our role is to enable them to do that.

• Another thing about students is that they converse a lot. This enables a culture within the student community of trusting senior students.

Reinforce

• Here the example of Heroku was given that students 2.5 years ago learnt about Heroku at a hackathon and till date, their juniors are using it because of the praise they have heard from their seniors about it.

• You do not just evangelise your product but tell the best practices here. It should not sound like marketing but a talk where they're learning something new about development in general. You can include your product as an innovative way inside it.

External Advocates

• Students are extremely vocal outside of their community as well

• Student advocates, many times, are the first people to deal with company-related issues within the community

• They redirect people who are facing issues to the right person - the evangelist of the company.

• Many times they stand themselves as evangelists as well for the company.

Loyalty

• Students are incredibly loyal.

• They get excited about the events within the community and even fly over long distances just to attend them.

• They become advocates for these products ultimately.

Product

• Your documentation does not work until a first-year computer science student reads it and successfully integrate your product.

• They're extremely great to talk to about the product.

Signups

• Although students are a great market, they cannot generate profit for you instantly. Their metrics will be very low comparatively because of that.

• The example of Dell: Just by engaging in different hackathons over the course of 2 years with comparatively minimal expense, Dell's brand awareness increased by 5 times, increasing the sales by that number as well.

• Another brand saw 40% of the targetted students using the credits provided by the company. They were given to 40k students and 14k actually used it.

• Students love free stuff.

Students Graduate

• They graduate sooner than you realise, most of them are in the 2nd and 3rd year.

Students Build Startups

• Since they know how to use their platforms easily they'll prefer that.

Students Intern with companies

• A lot of times they can influence the companies decision to use a certain system they're already aware of.

Education

• Students have vast capacities to learn about technologies just by interacting with the evangelists and also the evangelist get to learn a lot of new things by interacting with the students

• There are great repercussions on what you do on their career as well in a huge way.

• You just don't need to give them technical skills, you can give them any kind of advice that is relevant to them - give them presenting advice, give them public speaking advice, etc.

Recruitment

• Students who come to technical events are high performing students, they are self-motivated, they're talented.

• The requirement of experience in hiring is something that makes a lot of problems

• Recruitment becomes very easy at hackathons. If someone's there you can see them work for 24hrs to put together a project, you can see them working in stress, you can see them at crunch time, you can see their teamwork, their pitch. They are people who have the capability to become leaders in the future!

How

• Reaching universities directly is not directly fruitful. You should reach the societies through the departments.

• If you reach out to universities directly, it might look like an advertisement to them.

• Societies are student-run special interest groups. They have some forward officers who are elected and are well trained in different aspects, having their independent stand. Societies even have bank accounts in many places.

• These societies are constantly organising events, bringing external speakers etc where people can just go a speak for free addressing students.

• If this goes through the society students are more excited. Students trust other students.

• Be mindful of the key times like the University Exams or holidays which are highly inconsistent times.

• On the flip side, every summer for example students get ready for internships and this can be a nice time for certain outreach.

Connecting with Students

• Once you give a talk, expect tons of Facebook requests from students all over. Adjust your privacy features to handle that.

• Explore groups like Hackathon Hackers, Hackathon Hackers Europe, be active in those groups. There are niche groups where you can find your audience and interact with them.

• Don't worry about being old! Students will love to interact with you.

• Do fun and games with students - they're great people to have fun with and interact!

• Students are going to assume you are superheroes! Be chill and interact freely. Don't behave like a business penguin, have fun with them

Technical keynotes should be captivating, right? But too many are dull and pitchy. Avery Rosen shares practical tips for pulling off a keynote people will talk about.

Summary

A rocking technical keynote?

• Big annual developer conference

• Bunch of announcements

• Lots of software demos

Applying the 5-step agile process to make sure you rock 🤘🏼🎸 your keynote.

Following a 5-step agile process

• Ideation

  • Setting up work that has to happen before sorting the tasks.

  • Making sure you have parts that are interconnected with each other throughout.

• Composition

  • Build working demos

  • Sketch slide wireframes

• Side-craft

  • The process of making sure that things go from those wireframes to really nice looking stuff.

• Rehearsal

• Production

  • Place where you need to start finalizing and dropping the things that aren't adding up.

Scribbles

• Engineering communications is applied thought, leadership, in presentations, in media and in application design, an adjacent of DevRel.

A Rocking 🤘🏼Technical Keynote

• Big annual developer conference

• Bunch of announcements

• Lots of software demos

What does it do?

• Sets the tone and gives purpose to the whole event

• Collects the exposure, product roll-outs and features along with competitive analysis.

• Helps in understanding the technical aspect.

How to rock the keynote?

• Breaking down the keynote into a five-part agile process

• Applying those ⬆️ to keynotiest presentation

• If you aren't preparing for a presentation, you might wanna change that.

• Get a "village" of people ready. (A lot)

• 100 - 150 hours worth of time

• People resources to invest in...

  • Comms engineer

  • Speaking coach

  • Engineers building software demos, more the merrier.

  • Product managers

Ideation

• Setting up work that has to happen before sorting the tasks.

• Making sure you have parts that are interconnected with each other throughout.

• Hashing out all the possibilities.

• Something that eventually leads to good storytelling.

• Identify the audience you are presenting to.

• Set a specific outline for the team.

Software Demos

• Goals:

  ** Testify to the truth of the claims you make in the talk track

  ** Show a use case an audience member can connect with their own experience

  ** Show how the software solves the use-case

• Anti-goals:

  * You are NOT demonstrating how to use* your software or product

  ** Audience members do not need to learn enough detail to perform tasks

• Software demo specifications (example below)

Composition

• Say real words

• Build working demos

• Sketch slide wireframes

• Practice strong transitions

• Insert session callouts

Build working demos

• Weekly demos

  • This helps us make sure that everything is set up early -- the one in charge should be checking with the assigned engineers weekly

• Midpoint demo

  • Sets up review panel where everyone working on the demo, make sure they are progressing from software development pov.

  • Make sure everyone's hitting the messages/ comments that were outlined in the goals.

Sketch slide wireframes

• The presenter can track and evolve even before the graphics are done.

• Defer work on slides that might change

Session Callouts

• These are links to previous talks or sessions that you mentioned in the current keynote. Induces interaction and makes sure everything is interconnected.

Slide-craft

• The process of making sure that things go from those wireframes to really nice looking stuff.

• Beauty the slides

• Create interactive elements.

• Graphics are always better than bulleted words.

Rehearsal

• The main difference between amateurs and professionals.

• What more to say...? You are going on stage after so much hard work...what's stopping you from a little rehearsal.

• 🤘🏼rock bands rehearse whenever they get time.

Production

• Place where you need to start finalising and dropping the things that aren't adding up.

• Making sure engineers aren't using their real id's as it will be a live demo.

• Making sure the person in charge has all access to the keys

• Spare laptops, using bookmark where everyone behind the scene in sync.

But I will tell you how I wrap it up, which is that if you do all this right, then you’ve got yourself an amazing keynote and you can talk to the people in your audience later and find that they’re ready to tell your story for you.

Summary

• Structure of a usual story

  • Beginning

  • Middle

  • End

• Needed Story Structure

  • Context

  • Action

  • Result

7 Steps

• Context

  • The Hook

  • The Goal

• Action

  • The Protagonist

  • The Journey

  • The Conflict

• Result

  • The Recap

  • The Kick

Scribble

• Stories are the way humans convey concepts and ideas, memories, events, and emotions to one another.

• Learning how to do so in a way that is memorable, relatable, and impactful is really, really, really valuable.

• Once you know what you want to talk about.

  • !{insert link of talk design scribble}

• How do you design the story in such a way that it has the best impact it could have?

  • !{insert link of design scribble}

• How do you structure your talks so that the audience gets the most out of it?

‌

Usual Story structure

• Structure of a usual story

  • Beginning

  • Middle

  • End

• Start of the talk will be in that what-is phase. By the end of the talk -- what-could-be phase.

• Understand what that goal is before knowing what story to tell.‌

Needed Story Structure

• Context

  • Introducing the main character, setting the scene, giving the background.

  • Giving the right background, setting the scene, giving enough information to start.

• Action

  • About what happens to the main character.

  • Exciting middle bit, where you don’t want the audience to get bored and you give lots of information

• Result

  • How the story ends.

  • What you’re trying to achieve with the audience.

7 Steps

• Context

  • The Hook

  • The Goal

• Action

  • The Protagonist

  • The Journey

  • The Conflict

• Result

  • The Recap

  • The Kick

The Hook (Context)

• Grabbing their attention

  • Memorable

  • Impactful

  • Visceral

  • Emotional

• Something that immediately has the audience wanting to know more.

• Types of Intros

  • Statement

    • Make a statement about something that might be a little bit controversial or surprising to some people.

  • Anecdote or story

    • Something a little bit emotional just to grab the audience in.

  • Metaphor

  • Quote

  • Question

• Make it relevant.

The Goal (Context)

• Convince them to listen to you.

• What is the current state?

• What’s the background?

• What’s the starting point of the audience?

• Why is it important to them? What’s in it for them if they listen to you?

The Protagonist (Action)

• Understanding your protagonist is all about making sure that you’re telling the story with the right hero in mind

  • Since the action, the middle part, has the bulk of the story, that is where it’s really important that you define your hero.

• Allow the audience to be the hero in their own story.

• The audience doesn't really care about you and you being cool. They care about how they can be cool themselves.

• Flipping it around and tuning the story to the audience, so how can you get the audience to do that cool thing that you did?

The Journey (Action)

• Middle of a story, there are multiple moments, multiple events, where the main character runs into an obstacle to progress to the end goal.

• Throughout the middle section, there will be these ebbs and flows of rising tension. So just think about random action movies.

• How many of these action sequences will you have?

• How many sections does your story have?

  • What this also means is that you need to figure out what info belongs together and put those into the same section, so don’t jump around.

• Depth versus breadth.

  • Will you cover a few points in deep detail?

  • Or will you cover lots of points but each only in shallow detail?

“You can almost always tell the same story in different ways. So there’s no right or wrong way of doing this, but be aware of how structure changes the impact of a story.”

The Conflict (Action)

• Understanding what is stopping people from getting from A to B.

• Going back to the idea of going from the what-is phase to the what-could-be phase,

  • Understanding why they aren't there yet.

• It’s your job to acknowledge that conflict and make it part of the narrative.

• You need to figure out how to make it relevant to the audience and make it easier for them to relate to and understand

• If you make it relevant, it also makes it more impactful and more memorable.

‌The Recap (Result)

• Remind people what they’ve learnt.

• For shorter presentations, this might be a single line, but for long presentations,

• you want to remind people all the things that you’ve covered.

• This is also a moment to celebrate what people know now.

‌The Kick (Result)

• Finally, the kick, so end with a bang.

• The audience will remember the final minutes the most so in a way, it pretty much echoes the beginning.

• Make it memorable, impactful, visceral, emotional, so do something that will stick with the audience.

Summary:

• 5 Phases of Design thinking

  • Empathise

  • Define

  • Ideate

  • Prototype

  • Test

• Empathise

  • Understand who our users are and what our user needs are.

• Define

  • Observations that we’ve made so far and defining core issues

• Ideate

  • Generating as many ideas as possible.

• Prototype

  • Creating a scaled-down version of the end products.

• Test

  • Getting deliberate feedback about your product and then making sure that you ask the right questions

Scribble:

• Designing an effective talk, it’s the same process as designing an effective product.

• Company launches a product after doing the research of figuring out whether it’s a product that people want, yet, it’s something that happens all the time in our talks.

• Apply design thinking when creating a new talk?

  • Design thinking is a way of thinking deliberately about what you’re creating and constantly reacting and reflecting on that.‌

5 Phases of Design thinking

• Empathise

• Define

• Ideate

• Prototype

• Test

Empathise

• When building a product, we first try to understand who our users are and what our user needs are.

• It’s all about doing the research beforehand

• Researching our users, who will be listening to it, who is the target audience?

Audience

• Know about the events, the organizers and most importantly, the attendees.

• What the background is, what prior knowledge they already might have.

• Figure out what other speakers there are and also what they are talking about because that also influences people’s prior knowledge.

Format

• Understand what the logistical constraints are.

  • How long is your time slot?

  • What time will you be speaking at?

  • What type of stage are you speaking on?

  • Whether you’ll have access to Wi-Fi or audio?

Topic

• Write down what you already know about the content of your talk.

  • What’s the title, the abstract, the key takeaways?

Define

• Analyze all the observations that we’ve made so far and define what our core issues are.

• So what are the problems that we’re trying to address with this new product?

  • it will always be about convincing the audience of whatever message you’re trying to get across but the angle of that message can be quite different.

  • It might be about teaching a new skill, it might be to convince people to use a specific product,

  • it might be to inspire or motivate or frighten people to do or change something.

Think, Feel and Do

• Filling up columns of as many ideas as possible with the following questions.

• Think

  • What do you want your audience thinking about?

  • What mindset do you want to change?

  • What will the audience learn’

• Feel

  • How do you want the audience to feel?

  • Inspired, motivated, scared?

• Do

  • What actions do you want the audience to take?

  • What should they do after the talk?

Ideate

• About generating as many ideas as possible and then limiting and choosing.

• Diverge

  • Try to generate as many ideas as possible while keeping the goals and the audience outcomes in the back of your mind.

  • Write down all the possible ideas that will help achieve those goals and those outcomes.

• Converge

  • Distilling all that information into something more usable.

  • Three techniques - prioritize, filter and cluster.

  • Prioritize

    • Putting the ideas that you have in order of importance, highlighting which ideas are the most important ones.

    • Makes it easier to see which ones you might need to drop if you need to.

  • Filtering

    • Dropping off the talk, so which ones just don’t fit in, or things that aren’t as important as the rest, or that you know that you won’t get around to.

  • Clustering

    • Which ideas go naturally together?

    • Can help you identify maybe the three topics that you can cover in a 20-minute talk and maybe you can know from…you can find out from it which topics you might need to ask for a 50-minute talk.

Prototyping

• Creating a scaled-down version of the end products, which you can then put in front of users and test with.

• It’s about creating the bare minimum that will get you useful and valuable feedback without really wasting too much time.

• Prototype your talk structure.‌

  • Before even creating any slides-- Create an outline first.

• Beginning, middle, and end.

  • Beginning

    • Start of the talk will be in that “what is” phase.

    • The Hook

      • Grad their attention.

    • The Goal

      • Convince them why they should listen.

  • Middle

    • Everything in b/w “what is” and “what could be”.

    • The Main Ideas & Journey

      • Focus on what will bring the audience close to your goal.

  • End

    • “What could be” phase.

    • The Summary

      • Recap the main ideas

    • The Kick

      • Give them something to remember

Testing

• The testing phase is all about getting deliberate feedback about your product and then making sure that you ask the right questions to get that feedback.

• Prepare your feedback givers.

• Prepare actual feedback questions.

  • What areas do you want feedback on?

  • Is it about the timing of your talk, specific sections that you don’t feel are quite right?

“Good presentations, good blog posts, good documentation, they’re all about understanding your audience and building the right message for them.”

Summary:

• Content is one of the essential pieces of the puzzle when it comes to creating a great developer experience.

• Focus on creating an inclusive environment for the community.

• Like companies and products, developer communities are unique as well.

  • There might be an overlap between different communities, there usually isn’t a one-size-fits-all.

• Questions answered ..

  • How important is content to creating a great developer experience?

  • How does content help in shaping the community culture?

  • What are those first couple of things that companies should do to go about building a great community?

  • Words of wisdom for other teams starting this DX function or DevRel?

We’ve got to accept the fact that it’s a living thing, it needs attention and will never be finished. - Tanay’s view on documentation.

Scribbles:

How important is content to creating a great developer experience?

Content is one of the essential pieces of the puzzle when it comes to creating a great developer experience.

• From a developer relations perspective, it’s the base of a lot of activities that they do.

  • Content can -

    • Help in building awareness about a product.

    • Help people get onboarded and inspire them to build something that makes an impact in their lives.

    • Helps nurture the community.

Stories that are shared by the community are often the most powerful ones to inspire other community members as well.

How does content help in shaping the community culture?

• Focus on creating an inclusive environment for the community.

• Every question should be treated with the same degree of respect.

• Encourage people to ask questions, no matter how elementary they think that their question might be.

After all, if people are having issues and they’re asking basic questions, that could mean either their product’s usability can be improved or that they can provide better content or documentation for education.

• The tone of writing reflects their approach to community management.

  • “Simply,” “easily,” “just” - don’t make it past their editorial review.

  • If not done correctly -- a great way to lose people.

  • Community adapts to things like this.

What are those first couple of things that companies should do to go about building a great community?

• Like companies and products, developer communities are unique as well.

  • There might be an overlap between different communities, there usually isn’t a one-size-fits-all.

• Companies make the mistake of going all-in to build a community.

  • Ask them why they’re doing that.

• Communities can not be built with such a transactional agenda or without knowing why you’re doing that.

• Building an audience is not the same as building a community.

Should content creation be done daily when starting from zero?

• Daily content gets a bit too much if it’s just one person working on content.

• Roles like developer experience or developer relations, you’ve got to do a lot of learning.

  • Especially as part of early-stage companies, product matures really quickly, new things get added, you’ve got to learn them.

• You’ve also got to read a lot of content to get some good inspiration for things to do.

I think like daily content, if it’s just one person handling, is unfortunately a quick way to burn out.

Tactical tips for teams when it comes to creating really great docs.

• Treat the documentation like a product.

We’ve got to accept the fact that it’s a living thing, it needs attention and will never be finished.

• Do usability testing.

  • Can really bring out shortcomings in your docs that as an expert one might have never thought of.

• They learned about this practice of doing usability testing from the folks at Twilio.

Words of wisdom for other teams starting this DX function or DevRel?

• There is no one correct way of doing this.

• Do what works best for the community.

• Don’t be afraid to try out something radically different because it takes time to get insights into what is working and isn’t.

• Don’t underestimate the value of such collaborations because partnerships can give rise to content that’s very interesting and helpful for both communities.

  • Content will help you reach out to folks who might not have heard of your product before.

  • Great organic way to grow developer communities.

Strategies implemented by the n8n community

• n8n’s community initially were made from fans who tried out the product, found out that it created value for them.

• They wanted to create a place where people can discuss automation, ask questions about n8n and get value out of it.

• For them, the number of followers is really just a vanity metric.

• They don’t really do traditional marketing on their social media channels but try to provide high-quality content and share things that might be helpful for their community.

n8n’s Community Focuses

• At n8n, they have three loosely defined focuses for the content they create.

  • Onboarding

    • This helps solve the blank canvas problem.

    • Helps in solving the “what do I do next?”

  • Education

    • Talks about what powerful things you can do with certain tools or platforms, but it also covers more conceptual topics.

  • Community interviews

    • Stories that are shared by the community about how they use n8n.

Which of those three areas is or was the most challenging to start with?

• They started off with onboarding

• n8n has a blank canvas when you open it.

  • Editor UI where you can add notes

  • Create your workflow

• How can I actually connect these different apps or integrations to create something meaningful? - Tanay

• It was challenging because they have a very diverse community.

How does the n8n team act on the community feedback?

• Feedback is really important from the perspective of what they are doing in the developer relations team.

• They really keep an eye on this kind of feedback because it depends on that, and that correlates to basically what their content strategy would look like.

• It doesn’t do anyone much good if they create content that nobody wants.

• They synergise between different functions in the company to find out what is most valuable for their community.

• Common threads around certain topics, which makes it clear what topics they need content on.

  • If they already have content on it, it gives them insights into what needs to be better.

• They chat with their users.

• Take part in user onboarding to give them a deeper understanding of what is the most valuable type of thing for their community.

n8n’s Tracking

• If somebody wants a certain integration to be a part of n8n, they can open a feature request and other community members can vote on it.

  • Helps in understanding which kind of features or certain notes would be most useful for the community.

• They also try to take more qualitative feedback when talking to the users.

What was it like to start all by yourself?

• They had great documentation on the core part of the product.

  • A great base to build on top of.

• Taking notes on the go about the product.

• Ping team members to get an explanation on something.

• Cross-posting on Dev.to and Hackernoon.

• They realized that they were taking SEO hits by not having the blog on their domain

  • They are in the process of doing a migration away from Medium.

Dev.to, Hackernoon - for syndication, if you had to just pick one, what performs the best?

• For n8n it was Hackernoon.

  • One can easily run into challenges with Hackernoon.

  • It needs to be really developer-focused content that performs well, their content is educational rather than marketing-focused.

• Dev.to works really well for some companies but it really depends on how much of an audience you already have.

Summary:

• Design thinking - Programme Design Thinking

• Vision

• Understanding

  • Knowing why you are doing something.

  • Understand what problem you are solving

  • What context in which the problem exists.

• Define

  • Who is the target audience?

• Ideate

  • Finding the best idea.

• Test

  • Testing the idea.

• Leverage

  • How can we maximise benefits?

• This process helps in becoming a better organizer, and helps to be a better leader then eventually leads to the creation of something meaningful.

Scribbles:

‌

Design Thinking Framework

• Brings you through to integrate the needs of the users, understand the possibilities of technology, and the requirements of business need to come to a solution that can meet all of that.

• How can we use this, how can we copy this, and apply it to the programs?

• Mistakes many people make is to jump straight from ideation straight to execution.

• Without a very mindful approach to understanding why we are doing this and what problem we are solving, it is very easy to be pulled in a different direction like I was.

Vision

• Questions to ask …

  • Why are you doing this?

  • What are your goals?

  • What are the desired outcomes?

• Vision helps with understanding if we’re solving the right problem.

• DevRels can solve a lot of all the problems - not all problems are the right problems to solve.

• Having a strong vision sets the foundation, helps set the right direction

• Understand what sort of metrics will be important for you.

Understand

• Questions to ask…

  • What is the problem?

  • How are people solving the problem now?

  • Why are the current solutions inadequate?

• Not everyone learns how to code to become a software engineer. Some of them just want to learn because it’s fun.

  • Some of them want to learn to enhance their current role.

Define

• It's between the more abstract research and vision with the very tangible execution strategy.

• Define is understanding who our audience is, what are their hopes and dreams and fears, and how can we reach out to them.

• Helps in focusing on who exactly I’m helping.

User Persona

• User Persona is related to your vision and also what problem you’re solving.

‌

IDEATE

• Questions to ask

  • What are all the possible ideas?

  • Which is the “best” idea?

  • What idea gives you the shortest feedback loop?

• Find out what is the best idea to pursue given the constraints and the resources you have.

• Learning is to prioritize ideas before a short feedback loop.

  • A feedback loop is a time taken to plan, execute and learn from that experience.

• So ideas for a short feedback loop helps you learn more faster.

• Talk to different people to help me refine the idea.

Test

• Questions to ask..

  • What is the best way to test this?

  • What are the risks involved?

  • What did you learn?

Testing Methods

• Feedback from users

• Run a small event

• Creating prototype

Leverage

• Leverage is simply to squeeze any ounce of, in fact, other things that you are already doing.

• What are some other goals that you can achieve?

• What are some of the momentum that you can create from the things that you are already doing?

Summary:

• Why don’t we just scrape a list of all the commits that went into the last release, and boom, instant release notes?”

• Having well written and consistent commit messages are important and having great release notes is also important, the two are not interchangeable.

• Commit messages are terse technical descriptions of what you’ve changed in a unit of work and why, for an audience of developers.

  • Commit messages are a chance to capture the context around what you’ve done in a way that will make things easier for your future self and your coworkers.

  • It only takes a few extra seconds of brainpower to write a commit message that’s useful

• Release notes are a list of the important user-facing changes in a release, generally written at a less technical level of detail and focusing more on behaviour.

  • Release notes are an excellent opportunity to tell your users about the awesome thing you’ve built and why they should use it.

Scribbles:

Commit messages

• Commit messages to record brief technical details of what you’ve changed in a unit of work.

• Be brief but still complete enough that someone can get a sense of what happened.

• Why are you making this change?

• It’s less important to focus on the details of how you accomplish something‌.

Audience

• You can assume that your reader is pretty technical but they don’t have all the context.

• This is why it’s important to include the reasoning.

On my team, we like to say that good documentation is like a love letter to your future self.

Release notes

• A high-level and less technical summary of what’s changed about a product or a feature or an API in a release.

• Your release notes should be written at a less technical level than your commit messages.

• Focus on the resulting behaviour and not how you did it.

• Release notes should be framed from the perspective of the end-user.

‌Audience

• Your users and there’s a wide range, depending on what your product is.

• Your users might be super non-technical or they might be developers just like you.

• Think about what information they need to know.

  • Did you make some kind of improvement?

  • Did you change how something existing works?

  • Will they need to refactor code to remove an API you deprecated?

  • What will look or feel different to them when they’re using the product?

‌

Comparison

Commit Messages

• There’s a ticket number, it starts with a verb in the imperative.

• It briefly mentions all the pertinent details,

  • The library name

  • The version number

  • Efficiently states “why”, which is -- support for gifs.

Release note

• You have a bit more room for information in a release note.

• Starts by talking about what the change enables the user to do.

• Links out to further reading, where they can get help if needed.

• And it ends with inspiration for what the user can do to get started using this new thing. ‌

How do you get started writing great release notes?

• Don't recycle wholesale.

• You can look back through your Git history to remind yourself of what you’ve done,

  • Pick out the changes that are most interesting or impactful to a user.

• And feel free to leave things out because there are plenty of things in your Git history that a user doesn’t care about.

• Take each one and imagine it from your user’s perspective.

  • How will this affect them?

  • What differences will they notice in the product?

  • Are there any breaking changes or actions that they have to take?

• Adjust the level of technical detail as appropriate, based on what you know about your users.

“Good release notes get users excited about the hard work that you’ve put in to building your product. So use both commit messages and release notes appropriately and don’t waste these opportunities.”

Summary

• Understanding the basic needs of developers

• Understanding AIDA model

• Digging deeper into company and developer needs.

• Putting it together

  • Audit

    • Any hierarchy needs to be audited.

  • Plan

    • Understanding where in the funnel you need to focus

    • Are the funnels actually working and driving developers

    • How is the audit affecting the strategy

  • Measure

    • Applying metrics at each stage to measure success, blockers, tactics.

  • Focus

    • On needs of developers

    • Building a self-sustaining community

    • Helping developers become advocates and empower them

• Guiding developers through the hierarchy or funnel without friction

• Focusing on their psychological and self-fulfilment needs

Scribbles

The focus of this talk

Try to figure out

• Where & how do we focus our efforts and energy

• How much money to build a strong program.

A few questions that bother everyone

• How do you actually build a developer relations program?

  • Should you be focused on the community?

  • Should you be focused on events?

  • Should you be focused on evangelism or education,

  • Should you be focused on open source?

• What is it that makes a good developer relations program?

• Where do you invest for maximum impact?

• How do you grow and expand your program in a scalable manner?

• How do you grow it without having to hire 40 developer evangelists on a daily basis?

• How do you grow it without having to hire 10 community managers to try to manage your forums or your community?

• How do you go a step further and take your developers and convert them into advocates?

​‌

Takeaway‌

• Understand where you’re at today, and what steps you need to take to get to where you want to be tomorrow.

• 2 different frameworks for answering the above questions and how to measure them

• This is the same tool Mike has used going from stealth startups to public companies

The question to ask before starting

If you were asked to start a global meetup program, what would you need to do in order to accomplish that?”‌‌

The answer will differ for different people‌‌

• For an established company like SalesForce,

  • A global meetup program is already there.

• For a program like MuleSoft, where the community is built first,

  • Able to launch a meetup program with 40 meetups in about 12 months.

• For a brand new startup

  • A global program is uncertain, starting with one meetup will be the key to find out if it is something they need.

Purpose of Developer Relations.

Developer Relations is a symbiotic program designed to help both the developers and the company. At the same time, DevRel needs to be an advocate for the developers.‌‌

• They need to make sure they’re putting the developer’s success first,

• Helping the developers in everything that they do

  • Not just trying to sell them technology, but help them grow their careers

  • Bringing new technology to the developers,

• Helping developers utilize, adopt the technology

• Helping them evangelize the company’s tech.

  • Ultimately, you want them to be so happy with the technology that they’re talking about it to others - see the value in the technology that you see in the technology.

Two Parts

• Your company has to be successful

• Your developers have to be successful

What does your company need to be successful?

• Use the standard AIDA (Awareness, Interest, Desire, Action) model marketing funnel

  • DevRel is really responsible for the developer journey from raising awareness to all the way to adoption advocacy.

• Awareness

  • Without awareness, developers can’t find the technology

  • They can’t learn about the technology or use it and certainly can’t advocate for it

• Consideration (Interest), ie: “Okay, I’m interested. I’m thinking about using this.”

  • Giving them the tools to understand, like developer documentation, sandbox environment, etc.

• Adoption (Desire)

  • Assist them through the adoption process of becoming a customer.

  • That may be,

    • Free APIs: Using the freemium model.

    • Paid APIs: Adopting the paid or premium model.

• Advocacy (Action)

  • Taking the developer who’s using the technology

  • Change them from being someone who loves technology, to someone who’s willing to tell others about the technology.

What do people need to be successful?

• Devs are people, they have basic needs

• Basic needs fulfilled

  • survival

• Psychological fulfilled

  • purpose

• Ability to become self-fulfilled

  • happiness

What do developers need to be successful?

• Basic Needs

  • Basic Enablement

    • Documentation and onboarding -- without this, you are losing developers on the very first step of the process.

  • Community

    • Slacks, forums, social media to connect similar people sharing same the same process and so that they don't feel lost or alone.

• Education

  • Making sure developers grow -- you don't want them to be stuck with your product, you should make them grow.

• Self-fulfilment

  • Expanded Enablement

    • Online workshops and webinars, where they can watch and practice the product and various test cases.

  • In-person events

    • One of the main 🔑 elements in the whole process is to build a community of developers and who don't feel they are alone and want to grow.

If your program is not meeting the basic needs, it dosen't matter how great your other programs are.

Basic Enablement

• Messaging

  • Is your website clear in conveying the message?

  • Your messaging should be clear enough and to-point for developers to understand what exactly your product does and brings to the table

• Navigation

  • The website should be easy to navigate to areas that are always needed by the developers.

• Account creation

  • Should be a low-step process.

  • Lesser the steps the better

• Access to credentials

• Access to documentation

  • Important step to achieve developer retention.

  • If a developer is interested in the product, they want to dive right in, there might be existing tutorials from 3rd part sources, but documentation from the organization to make the onboarding of devs easier is a must.

• Usability and searchability

• Getting started guides

• Tutorials and examples

• Error reporting

If a developer cannot create an account and build their first basic app with 5 minutes, your platform is too difficult to use.

Community

• A way for developers to obtain support, network with each other and be recognized by the organization.

Types

• Internal

  • Forum

  • Team messaging

  • MVP program/ambassadors

• External

  • StackOverflow

  • Social Channels

  • GitHub

Education

• Making sure developers become experts in their field

  • Blogs

  • Videos

  • Podcasts

  • Open-source

  • Training programs

Expanded Enablement

• Taking education up a notch.

  • Webinars

  • White-papers

  • Case studies

  • Online workshops

  • Virtual events

  • Certification

In-person activities

• Great way for creating connections with your developers, recognizing potential DevRel qualified leads and rewarding them. (Not sure about DevRel qualified leads? Here's a link that should help you out)

  • Meetups

  • Summits

  • Hackathons

  • Conferences

Summary

Create Inclusive documentation

• It is the right thing to do for developers but also for the business

• The documentation is someone's first experience with your product

• Your documentation is the best marketing material you might have!

3 ways to lose a dev due to documentation

• New devs aren't familiar with code conventions

• Developer environments are hard

• New devs lack context

How to fix this?

• Test your docs on different operating systems and have someone with low development experience try it

• Create a legend & glossary for your documentation

• Add context to your tutorials

Scribbles

Edge cases for great product documentation:

• Users should be able to simulate the development environment

• Users should not be entering their personal information, email addresses or use any credit cards for accessing the documentation

• Users should be able to save their work and return to it.

• Assume that users might not have written a single line of code before

• Users should be able to access everything with even tablets or cell phones

Three ways you might lose new developers due to your documentation

New developers are not familiar with code conventions

• Problem:

  • $ sudo apt update - Newbies might not understand what a simple $ here might represent

    • Similarly,

      • Using >>> for interactive shell

      • Using [ ] around values where you want people to substitute their API credentials

    • You cannot avoid conventions generally because they increase inclusivity generally

• Solution

  • Include a legend in your documentation that defines any conventions used.

• Problem:

  • New developers aren't familiar with developer workflows, such as when to use the command line vs a text editor.

    • Eg: Newbies might get confused what part of documentation represents shellcode and what represents javascript code.

• Solution

  • Use visual differentiation to indicate different parts of the developer workflow

    • Use syntax formatting, number lines, etc,

    • Different parts to indicate output vs input files, code vs shell etc.

• Problem:

  • Even with the best explanations, some of the things might get lost.

• Solution

  • Use screencast or gifs to make developers aware of the process.

Developer Environments are hard

• Don't assume the operating system one might be using for accessing your code.

  • Eg.: A lot of documentation assume people using UNIX/ Linux systems and Windows users might get discluded.

• Solution 1

  • Link to someone else's explanation of how to use different operating systems.

  • Write your own detailed solution for these specific cases: More involved and yields greater benefits by keeping developer on your platform

• Solution 2

  • Explain command and environmental differences, using a different platform, shells and respective commands for that

• Solution 3

  • Set up examples on Codepen, Glitch or repl.it, where they can run and test your documented example code.

• Solution 4

  • If a browser-based development environment does not work for your product, use a VPS/ VM solution for that.

New devs lack context

• New Developers don't know what your product does

  • Solution: Add a few sentences at the beginning of the quickstart and tutorials. Include key activities.

• Your docs are expansive and hard for a new dev to navigate

  • Solution: Provide use cases for your product and use them to guide developers through your documentation

• Your docs are hard to find or your product requires signing up to test

  • Solution: Create a sandbox

What you can do to fix this tomorrow?

• Have a friend with less development experience try one of your tutorials and document every confusing point

• Test your docs on different operating systems

• Create a legend for your documentation

• Add a glossary to your documentation

• Add context to your tutorials

Summary:

Docs as Code

• Store your documentation in GitHub or SVN, or whatever you want to use, but these days a lot of it is in Git.

• Build the documentation automatically.

• Review the documentation as you write it.

• Publish the documentation without much user intervention.

• Test anything that can be tested.

  • Making sure that your documentation quality is gonna remain good going forward.

  • That kind of thing.

• Modularize to prevent duplication,

  • So that we can reuse our documentation.

• Reuse -- All of that will allow us to maximize value.

• Using a pipeline to tie it all together.

Scribbles:

• README allows you to make a backup, you export it.

• Turns out when you do import and export and import kind of thing, you’d expect it to be symmetrical. If I create export and I just import it over here again and should be getting the same system at the end. Not how it worked at ReadMe.

Problems

What were the problems faced during the process of translation?

• Hard to translate

• No audit trail l

• No review process

• No modularity

• Hard to refactor

• Hard to ensure quality

Docs as Code concept

• Store your documentation in GitHub or SVN, or whatever you want to use, but these days a lot of it is in Git.

• Build the documentation automatically.

• Review the documentation as you write it.

• Publish the documentation without much user intervention. ‌

Docs as Engineering

• Necessarily not covering architecture -- but software engineering.

• Software engineering, we’ve got a lot of principles that we’re all familiar with.

Software engineering principles

• Modularity: Writing modular code, and that we should

• KISS: Keep things simple, and that we

• DRY: Shouldn’t repeat ourselves, and that we should

• Anticipate change

• Do one thing well: The Unix principle of doing things well.

• To test early

Testing and linting

• Testing early,

• Testing often,

• Testing the parts

• Testing the whole.

  • Validate internal links

• Test at the source.

  • For documentation, that means that if you test early, you want to There’s a couple of things you can do there.

• Test the unit.

  • Spell-checking.