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 one of the initiatives in DevRel Page, we thought it might be helpful to have different DevRel Talks documented in one place, sharing the notes, which have been extremely useful for us learning best practices to the core.

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!

For eg.: Someone is making a student community plan and looking for some best practices around it, they'll go and enter the things they're looking for in the search and a talk by Joe Nash that covered it all mostly appears! Combining multiple talks, their notes and just reading the summary will save so much time for folks here.

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?

Reach out to @yashovardhan directly or submit an issue! Questions/ Comments/ Feedbacks are always appreciated!

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?

Summary:

• Stay out of the way during hack week.

  • Hackers are eager to dive into products!

• Learn as much as possible from the developer experience of hack teams that were building on our API and SDK products during Hack Week, of which there were many.

• ‌Studying DX from employed developers can be tough.

• Avoid collecting feedback on your entire platform.

• Be super aware of which resources your internal developers use when they build their hacks.

• Take some time at the end of your internal hackathon to interview developers.

Scribbles:

• One was to stay out of the way during hack week.

• Learn as much as possible from the developer experience of hack teams that were building on our API and SDK products during Hack Week, of which there were many.

‌Studying DX from employed developers can be tough.

• They are very different from external developers who use your SDK or API and

• They often bring background knowledge about a product that an external developer would not have access to.

Tips to make it easier to get useful DX insights from a hack event.

• Avoid collecting feedback on your entire platform.

  • Pick really specific topics that I wanted to study and do a deep dive on those.

  • Focusing on a small area can make it actionable for the product team.

• Be super aware of which resources your internal developers use when they build their hacks.

  • Employees at a company tend to have extra access to resources like log files, source code, and other developers who may have worked on the developer tools that they’re going to use.

  • When hack teams’ internal hack teams stray away from using your public documentation, that decision can be really insightful and could indicate a gap or problem with what’s publicly available on your website for developers.

• Take some time at the end of your internal hackathon to interview developers.

  • One-on-one about their experience with your chosen process or product area.

    • It helps to bring pre-planned questions and to be really specific in these interviews.

  • As part of the interview, it’s also really important to take time to understand their day job, the team that they worked with on their hack,

  • The project goals of the hack

    • This context really helps place the feedback, makes it actionable and gives you context that can help turn that into something you could bring back to your product team.

Summary:

• Organizations realizing the importance of go-to-community rather than go-to-market for driving business growth.

• Understanding the existing metrics from go-to-market.

• Explaining how metrics for go-to-community has more impact on the community than go-to-market.

• Sharing your story is a must when trying to grow.

• Treat communities are ongoing research and development function.

• Leverage community members and advocates to do the marketing for you!

• Marketing does help you grow, but only up to a certain point, every organization depends on the community to drive growth from there.

Scribbles:

• Making opportunities where no one loses knowledge — everyone gains knowledge.

• Language itself can create a sense of hostility in some ways — and something that we should really take seriously.

• Expanding the term 'developer' opens up more opportunities for all.

• In order to get Go-To-Community integrated into the culture, you need to explain the metrics of community in terms of the known and functioning Go-To-Market strategy.

• Tracking sentiment among developers — how did developers feel about the product and how did this influence the company strategy as a whole?

• Community + DevRel =. how you listen to your people!

• Market side vs Community side: Old way of thinking -- Better Culture: Synthesis of Market and Community.

• Sharing stories is one of the most important things we can do as community builders.

• The community team is in ways an R+D function

"I dont think there is developer market, there is a developer community, and we need a community team to reach that"

• DevRel, Community, Marketing = all diff teams...or is DevRel & community manager = same team.

• Let the community do the marketing for you.

Potential of having a great community

• Product growth

• R&D

• Marketing!

If adoption is a future success — how can you tap into the future of your org. through Go To Community.

• Marketing will help you grow, but there will be a ceiling to that growth. If you want to grow beyond that, you will need community. The scale possible with the community can never be possible with marketing.

• Marketing is not community building

"Stories we share are tools for driving change" - Sam Ramji

Summary:

• Structuring the project with promotion paths

• Hierarchy of advancement in open source projects

• Holding yourself accountable for the communities and making sure you start initiatives to stay interested.

• Setting clear paths for learning and advancement.

• Establishing your intentions, boundaries, and interests — and communicating that (or being open to hearing this is so important!

Scribbles:

Characteristics of a good open-source community...

• structure

• knowing who to talk to

• documentation

• steps how to contribute

• the architecture

• structuring the project with promotion paths

Ladder Model for Open Source

• hierarchy of advancement in open source projects

• allows for buying and learning

• setting clear paths for learning and advancement

Share your work with the community, do not hide behind your code and work.

• Have your readme at the bare minimum. Make it easier for the newbies!

• Holding yourself accountable for the communities and making sure you start initiatives to stay interested.

• Make sure your community shares the same goal as you.

• Not accepting contributions in open-source == respectfully drawing a line about how much and what kind of engagement you want from the community,

• Documentation (blog posts, guides, etc) and paying attention to the little details including down to social cards is super helpful especially in telling stories and intention.

Tackling imposter syndrome...?

Here's how Brian approaches impostor syndrome and making open source accessible -

• Intentionally you're going to have a solution written in the issue, provide an easy win.

• Providing mentorship and help.

• Giving credit where you can.

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.

Summary

• Notion really focused on the top of the funnel i.e. user acquisition.

• From there, the Ambassador program proved useful in building community.

• Educating the community.

• Identifying power users, and making the power users feel valued.

Scribbles

• Investing early in communities helps in the long run.

• The biggest pieces initially starting up the community were templates and the ambassador program.

• Two things they focused on: Top of funnel sign-ups, helping users understand how to use notion better.

• Lessons learned from empowering ambassadors -- work to make sure they're feeling as supported as possible and helping them tap into what they manage most

• Fostering better relationships with core users - making people who already value your product feel valued.

• Word of mouth is still a very reliable and trustworthy tool that can be leveraged by building genuine community leads.

• Notion employee's favourite Notion tool? -- keyboard shortcuts, callouts, toggles,

• Notion's unique artwork has helped achieve a unique branding of its own. It has also become a huge marketplace for templates, logos, characters, and all sorts of artwork inspired by existing Notion's theme.

Leveraging ambassador programs for marketing

Why invest heavily in marketing when you have ambassadors? 🙃

• No like for real, there are always people out there who genuinely believe in the product and do not look for any monetary value.

• For folks likes these, being part of the community, contributing toward's the growth of the product is more satisfying than the monetary value to compensate for their time invested in the process.

Tips for better community lead

• Systemize things faster.

• Build systems and processes.

• Document everything whenever possible.

Summary:

• Ways to measure your developer programs in terms of acquisition, engagement and satisfaction, but far away from marketing.

  • More focused on a community perspective.

• Dev rel is about building relationships.

  • Department you came from but always have in mind the real mission and why you were hired as a dev rel and not as a marketing specialist.

  • ‘Cause dev rel is about building relationships, and it’s about community.

• It’s really really nice that you track things related to marketing but don’t only do that.

• Be near your developers and go to the same places with them.

  • Try to get the whole picture.

• Understanding metrics take a lot of time.

• Needs to get the domain knowledge

• DevRels need to interpret numbers to get insight for your community.

Scribbles:

Dev roles are really diverse.

• A dev rel can be hired by a soft foundation.

• They can be hired by a company.

• They can be hired because they want to manage open source projects.

• Or just proprietary software.

• Makes it really, really difficult to bring up a standard way of metrics.

• Dev rel roles can report to many different departments and those departments have different ways, and different KPIs to measure success.

Dev rel roles are connected

• They’re hired by a foundation.

• They're hired for a company.

• They report to marketing

• They report to engineering.

• Mission of a dev rel is always to build relationships with developers.

• Developers can be seen in many different profiles or personas.

• At the end, everything is related to community issues and ways to measure community.

Measuring acquisition

• We can measure the developer growth by software product/project.

• Real examples from the CHAOSS community.

• Try to analyze the developer retention rate or the developer bounce rate.

• Example - Software GrimoireLab, Open source

  • Activity -> community -> Attraction and retention.

  • Measure Git, ’cause we are fond of our community, it’s really engaged, it does a lot of Git code, for instance, and that’s a lot of Git commits.

  • You can see the attracted developers and the last committed developers over a period of time.

Measuring engagement

• Take a look at the data sources about all the different challenges the developer community faces.

• All the different data sources are aggregated, all the different channels where our community is.

• We can define if my community is a contributors community, is a user community, is a maintainer community, or any other type of community you would like to profile.

• Depends on a lot of domain knowledge.

• Define a personas pattern.

Developer engagement by software product or project

• See the most active community and the most engaged community project among the other ones.

• Identify which projects had at some point some activity and then were left like the one on the prospect.

• What happened then?

• What did we do wrong?

• Or what can we do better in order to improve that engagement with the project itself?

Measuring developer satisfaction

• Uber OPSO use case

• OPSO - open source program office.

  • Where open source and all the related activities related with open source are centralized and growing inside a company.

• Uber wanted to know how efficient they were in answering, enclosing, and merging pull requests.

• They wanted to measure GitHub in this case.

• They wanted to know how fast they were when measuring Uber developers versus non-Uber developers.

• Turns out that they tend to merge non-Uber developers took them more time when, rather than when, they wanted to merit a Uber developer pull request.

“Let’s start with a round of introductions. Sean, why don’t you go first?”, says the organizer of the meeting.

“Sure thing.

Hey there, my name is Zeus and I work in developer relations.”

Summary:

• At the heart, DevRel is a people business

• Building real relationships with internal and external engineers

• 3C's of DevRel

  • Community

  • Coding

  • Content

Scribbles:

• Developer relations -- a variety of tasks and responsibilities that can vary from company to company.

Responsibilities of DevRel

• Now, like mentioned above ⬆️ can be a variety of tasks that can vary according to which category DevRel is focused on in an organization.

• But below ⬇️ are a few tasks that are almost done by every DevRel.

As you can see, developer relations is highly cross-functional, dynamic, and includes a wide breadth of skills and responsibilities. According to Bear Douglas, Director of Developer Relations at Slack, developer relations is “an interdisciplinary role that sits in a border space between product, engineering, and marketing”.

• Besides product management, DevRel is the only role that might be a part of various kinds of meetings.

3 C's of Developer Relations

Community

• Building personal connections with developers

• Growing awareness of the platform

Coding

• Creation of resources to be used by developers

• Great way to build trust

• Forms the foundation for demonstrations of your platform

Content

• Creating reference materials like documentation, guides, blogs and videos

• Helps in extending the reach and educating the community

Difficult to define DevRel. Why?

• Large breadth of tasks and responsibilities comes within developer relations.

• Responsibilities change within every company.

• DevRel might be in different parts within the organization

  • Engineering

  • Product

  • Marketing

• DevRel is still a relatively new function for companies to have.

• Applicable to companies with developer-facing products.

• Somewhat niche, makes it harder to define to people outside of the tech industry.

So, what is developer relations?

The art of developer relations is to actually build authetic relationships within your community without selling or marketing to them.

• The purpose of developer relations is to build relationships with and enable our technical communities.

Why does it exist?

• One of the ways to put it would be that it "always exists".

• Having a product where users are developers, you are already into developer relations then, even if you have a dedicated team or not.

• So, even if your organization doesn't have a DevRel, there must be someone writing technical documentation, code samples, connecting with developers to solve an issue.

• While developing a product, one of the first steps as a developer is to create documentation, samples, uses cases to get started.

• If you want to learn more about community flywheels you can check the scribble below

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

Promotions don't just happen by hard work, it's a mental shfit, it's a promotional comapaign, it's a ton of work. But for the right company for the right mission, it will be worth it.

Scribble

• If you already have a career in DevRel, you must've already done all/most of the following-

  • Created written content

  • Created video content

  • Spoken at meetups and conferences

  • Working with the product team to advocate for user's feedback

• Okay, so that's all done, what comes next? How does one move up in their organization and what does this "up" look like?

What's Next?

Management

• Managing various functions or teams.

• Genuine interest in people and wanting to see them grow is important if you choose this path.

Individual Contributor

• This is a great option if you want to continue what you are already doing.

• It's all about the impact and choosing your time wisely.

• Time being a finite resource, make sure you make it count.

How to make the time count?

• List of did I questions --

  • Improve the product?

    • DevRel was hired to grow the product in some way or another.

  • Change the way we work?

    • Finding a way your team and you perform tasks more efficiently.

    • Suggesting ways to do the job, better.

  • Are people aware of the work?

    • Making sure that people are aware of the work that you do.

    • Internal communities shouldn't be left out. Let the people you are working with know what you are up to.

    • Helps in increasing trust once people start seeing you as someone who brings about changes and comes with valuable input.

  • Measuring Impacts?

    • The aim should be to constantly measure the impacts of almost everything. But can all activities be measured in terms of impact? Arguably, yes and no, but that at least gives you a little push to measure activities you do.

    • If you can't put in terms of numbers, become a storyteller. Stories are way easier to explain than numbers.

How to get there?

• One definitely needs to keep growing their skills. If you are a great content creator and struggle to strategize or talk to management -- learn how to.

  • Write a strategy doc

    • Missions, Visions and the impacts of the work that you are doing.

  • Put yourself in a manager's position

    • Whatever position you are aiming for-- put yourself in their shoes and think about how they would their jobs and how they formulate their strategies for such a massive crowd under them.

    • Looks at their way of communicating -- their style of email writing.

    • Basically, watch 👀 and learn.

  • Be brave

    • Opportunities come knocking? Take it!

    • Fire, passion, courage, Rambo it!

    • Things will be outside your comfort zone -- adopt a growth mindset.

  • Laugh in the face of hardship

    • Times might get tough, high-level management, politics

  • Get a mentor

    • There's always someone who has taken the same path before as you. Even though their journey might not be your journey, listen, there's something to be learnt about human behaviour.

  • Tell people you want up

    • Tell people you work with/around you that you want to "up".

    • Align yourself to the mission.

    • Committing publicly pushes you harder.

  • Having/Making the manager believe in you

    • The blog mentioned about "having" a manager that believes in you, will make you deliver above your ability. It's true, but if you don't "have" one, "make" them believe in you by working hard.

It's sometimes very hard to navigate being a manager or mange things at a high-level cause it's all about politics. Sometimes you need to circle the problem and listen and just live to fight another day.

Summary:

• Make sure you are finding a suitable flight that fits in your schedule.

• For more organised packing -- use packing cubes.

• Sleep is important.

  • Use time shifter apps to track time and schedule in a more efficient way.

• Planes

  • Have a neck pillow.

  • Have a scarf.

  • Earplugs

  • Do whatever it takes in order to sleep. You know how you sleep best.

• Hydration

  • Make sure you keep hydrated.

  • Planes are very dehydrating.

  • Carry an extra bottle of water.

Scribbles:

Airline Troubles:

• What happens when you have a cancelled and delayed flight?

  • Within the EU, if you land here if you get delayed here, you end up getting the compensation of some kind.

  • In the U.S

    • Regulations aren’t as good.

Packing:

• Using packing cubes.

  • Can take them out of my bag and set them out.

  • Easy way to keep track of what’s dirty, what’s clean. and you can even get some that are more specific for dress wear.

Sleep

• Makes us feel functional.

• We’re in events a lot where we may be expected to drink.

• There may be a lot of coffee.

• Sleep deprivation is literally torture.

  • It is not allowed under the Geneva Convention.

• Doctor if for some reason you need additional assistance.

• Time shifter apps

  • When you should get some sun.

  • When you should wear sunglasses.

  • When you should avoid sunlight.

  • When you should avoid caffeine.

• Planes.

  • Have a neck pillow.

  • Have a scarf.

  • Earplugs

  • Do whatever it takes in order to sleep. You know how you sleep best.

Hydration

• Most planes have humidity levels of around 20%.

• Staying hydrated on planes.

  • Bring a water bottle and refill it.

Burnout is a recurring point of discussion amongst dev rel practitioners. What can we do to recognise and avoid burnout before it’s too late? Anjuan Simmons shares practical advice in this talk from DevRelCon London 2019.

Summary:

• The emotional cost in the form of burnout in the software industry is unaccounted for.

• Burnout leads to three major consequences

  • Exhaustion

  • Cynicism and detachment

  • Sense of ineffectiveness and lack of accomplishment

• Taking a break from social media helps. If you can't do it permanently, restrict it to whatever's important.

• Health -- burnout takes a physical toll on the body.

  • Staying hydrated.

  • Getting enough sleep.

  • Physical activity to keep your body moving.

Scribbles:

• The emotional cost in the software industry is unaccounted for.

• A lot of people forget about this emotional cost which is caused by burnout.

Causes of burnout in Tech

• There's always new technologies and new tools and new frameworks that need to be learnt.

• To always keep shipping -- always shipping code, values to customers and proving worth to the business.

• Increased workload.

Definition

• Psychological syndrome leads to three major consequences

  • Exhaustion

  • Cynicism and detachment

  • Sense of ineffectiveness and lack of accomplishment

Symptoms of Burnout

• The ongoing feelings that today's resources aren't enough to meet tomorrow's demands.

Three Dimensions

• Emotional Exhaustion

• Depersonalisation

• Reduced personal accomplishment

Numbers

• Research by Gallup shows -- out of 7.5K employees, 23% reported feeling burned out at least sometimes.

• Another 20% reported feeling burnout very often or always.

• 40% felt burned out sometimes.

• Around 2/3rd of full-time workers experience burnout on the job, i.e 66%

Highly engaged workforce tend to end deal with burnout and are the first ones around you who might be planning to exit.

Effects

• Feelings tired and having stress, elevated blood pressure and increased heart rate.

• Progression of mood from being sad, to being terrified to having outbursts of anger.

• Bedridden or end up in emergency rooms cause they are "too tired" and "exhauster" from burnout.

Common solutions to burnout

Corporate solutions

• Hiring coaches to tackle burnout in employees

Individual solution

• Escapism

  • Nice vacation -- make sure you don't make vacation into work -- trying to click best pictures everywhere.

We try to do so much work to show we are not working.

Burndown chart

• 50 in the image is 50 units of work, units can be anything based on your work.

• The ideal line would be a straight line where every day an equal amount of work is done and by day 10 we get it down to zero.

• If you are working under the line, then you are burning out.

Burnout Resistant teams

How to create teams that are burnout resistant?

• Relationships

  • Developing connections

  • Engagement between coworkers

  • Get-togethers

• Having a gift card that requires two people to use them.

• Getting out and meeting in person and working together.

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

• Understanding the key roles of DevRel team

• What each and every key role does

• One of them is the facilitator

• Community managers and organizers are often involved in outreach and community events alongside evangelists, both online and offline.

• Evangelists are involved in the community events, however, they need to be very familiar with the product being the first point of contact for new developers and businesses.

• They (evangelists) also are responsible for getting back to the community with answers from the product teams.

• Developer educators, or facilitators end up working mostly online and behind the scenes for the event, offline interactions and technical workshops are their forte'.

• Seeing how to structure the DevRel teams as well as knowing how each role fits into core pillars of developer relations is important.

• Building a team around those ⬆️ helps in setting the right metrics for each team.

Scribbles

Key roles of DevRel team

• The Evangelist

• The Facilitator/ Educator

• The Organiser

• Those ⬆️ key elements will make sure you have the right mix to pull off great DevRel adventures.

• If you are starting out as the sole DevRel, then you might need to fill that very spot yourself.

• Once you are expanding, you will have to find out great people to fill in your weak spots.

Evangelist

• Person who will stand on the stage and preach to the thousands of developers.

• Attends various conferences and meetups to share info about the product

• Collecting feedbacks

• Showing off the killer presentation with a pinch of memes

Educator/Facilitator

• Provides the support/acts as a backbone for developers

  • Documentation

  • Quick start guides

• Running technical training events

• Speaking at workshops

• Helps in making complex topics digestible

Organizer

• Community folks who bring developers together

• Fuel to the community

• Helps in maintaining peace and prosperity in the community

• Making sure any issues raised are sorted out ASAP

• Having the right mix of people always helps brings a balance to the team

• Leads to kinds of activities that the developer relations often participates in

  • Outreach

  • Community

  • Product

  • Education and Support

The real key to building a great team is finding people who understand one another. It might go too far to say that this is the golden ratio of building the ultimate dev rel team but it’s a place to start.

Summary

• DevRel and community management share many similarities.

• When it comes to all three categories -- DX, DevRel and CM, the lines are blurred. There are roles and actions that can be performed by either or both. But it still makes sense of us to think of them as distinct practises.

• DevRel of community management -- neither arrived fully formed.

• DevRel and community management even though from the same root, have taken a different direction.

• Difference between the two -- their end goals.

• Community and community management is everywhere!

• Genuine communities can be built even where there is no coding involved.

• DevRel can too happen without any attempt at building or managing communities.

Scribbles

• Developer Relations - DevRel

• Developer Experience - DX

• Community Management CM

• How does one define the various roles/task under developer relations/experience and community management? -- Bands on a spectrum, the high school, em spectrum something like that.

• Bands on the spectrum help us to understand their characteristics.

• When it comes to all three categories -- DX, DevRel and CM, the lines are blurred. There are roles and actions that can be performed by either or both. But it still makes sense of us to think of them as distinct practises.

• The diagram clearly helps in breaking any hierarchy, if at all. It helps in giving a clear-er approach from an implementation choice for an organization.

DevRel family tree

• Wait! Wasn't it mentioned ⬆️ that there is no hierarchy? But now there is! Which can help us understand the interplay between developer relations and community management.

• DevRel of community management -- neither arrived fully formed.

  • DevRel

    • Open source projects built awareness and attracted contributors with a mix of developer programs.

  • DX (Developer Experience)

    • Evolution of tech writing, User experience and more.

  • Community

    • Open source, PR, various forms of marketing and customer service.

Connection with Open Source

• DevRel and community management even though from the same root, have taken a different direction.

• In the late 1990s and early 2000s, it was rare for companies to involve themselves in open source.

• Sun, Red Hat and Canonical are a few examples of open-source communities which borrowed methods from academia, special interest groups, and clubs, these were communities that developed their own ways to manage their development of software, attracting users and contributors.

• Matthew (Author of the blog) thinks that it was Ubuntu's broader community focus was the point where community management and developer relations began to take separate paths.

• Much of what everyone does in DevRel and community was pioneered by open-source communities.

DevRel and community do different things

• Difference between the two -- their end goals.

• DevRel

  • Building sustainable awareness, adoption, and community around developer-targeted products.

  • Community management is one of the techniques DevRel relies on.

• CM

  • Creating and maintaining a process that enables people to comes together for a common goal.

Community without DevRel

• Community and community management is everywhere!

• Part of community management is called customer service, usually delivered through social media and forum software.

• Genuine communities can be built even where there is no coding involved.

DevRel without community

• DevRel can too happen without any attempt at building or managing communities.

Example

Take the example of the banks releasing open banking APIs. They have developer portals, many are starting to go out and talk at events, some publish content. Few, if any, are building genuine communities around their offerings. Perhaps within time some will have thriving communities but many will meet their goals without doing so.

Community management ≠ DevRel

• Like it was mentioned earlier there is no hierarchy as such and both CM and DevRel can be essential in particular cases for growing a community of developers.

• But they are not the same thing.

Summary:

• One of the main things to always remember is that each event -- online, hybrid, or physical, it's those little decisions made by the core team that can eventually make the event successful and now it depends on how you set the metrics for success.

• In an online world - if someone is online and present —they're likely willing to be approached.

• Reaching out to speakers is hard for in-person events.

• Try to think more about reach than attendance as a metric.

• Having a global staff helps to reach global audiences.

Scribbles

🚩 Takeaways

• It's really difficult to know who to approach IRL (in real life), online events make this easier, especially for introverts.

• People were left with less time during COVID, not more time.

• In an online world - if someones is online and present —they're likely willing to be approached.

• People from niche interests can come together, overcoming geographical limitations.

• Letting people who wanted to attend but couldn't due to cost issues.

• Long-tail of talks being available on Youtube long after the event.

• Online events are driving up the quality of the talks, giving speakers more confidence, helping them overcome stage fright, etc.

• Online brings more diversity on how to deliver talks, it is more accessible, and being able to educate/teach/talk in so many different formats

• Noticed a trend of online communities (Slacks, Discords) staying more active after events, Kevin's communities have noticed the opposite, ie, less or no activity after events.

There is more organic engagement in the community in between events. People stay connected because they remain on the platform, instead of physically going to a different space and disconnecting from the community. -- @Jonathan Gottfried from MLH

• Now that events have transcended geographical limitations, it would be really useful to think across timezones, languages, etc to expand the potential audience to the whole world.

• Think about accessibility in demographics where people might have limitations for example connectivity speed.

• Having a global staff helps to reach global audiences.

What are some positive outcomes in taking events online, What would you retain?

• Recording stuff for later reference.

• People have been making more meaningful connections because everyone seems more 'equal'.

• People are more receptive to being approached.

• People took respite in online events due to the disruption in their lives due to COVID.

• COVID forced us to pivot, put resources to best use.

What do you see as the future of Hybrid Events?

• Hybrid events are hard, just like hybrid workplaces!

  • Going to have to get really really creative.

• Events are social experiences, talks are important but not the main thing.

• Harder to bridge the gap between in-person and online.

• Depends on the nature of the event. Easy for hackathons, harder for conferences.

• Serendipity online vs in-person may not have a lot of overlap.

• We need to know what part of an in-person event will get value from having an online component, taking the whole event online may not make perfect sense or be feasible.

• Challenges of covering in-person events via video and taking them online fully.

• Reaching out to speakers is hard for in-person events.

• Issues finding accessible and inclusive venues - some people can't go to bars for example.

• Inclusive timings are still a challenge. Everyone's being cautious about hybrid events!

How can we get more people to attend events?

• Try to think more about reach than attendance as a metric.

• Reusing assets from events afterwards.

• Online events might have greater reach post-event, youtube videos for example. - Low attendance could be because of Zoom fatigue.

• Rethink online event as not just a Zoom call, but maybe say as a Youtube playlist.

• People look for social aspects in events, if that can be replicated online, then it might be helpful.

• An event needs to offer high-quality social contact.

• Content is a hook, not the full reason to attend.

• Often there's not a real good engagement strategy for IRL events.

We need to rethink the success metric. In the past an event's success used to be measured by "how many people attended" there is a real opportunity here and now to go beyond that. You can have low attendance numbers and still be considered a success because you can now measure other things now, like engagement. - @Kevin

Summary

• Define your community

• Challenge the status quo to reach where you want

• Fund the work properly

• Build the internal sub-community within the organization as well

• Understand the development and marketing relationship

• Defend the target audience, understanding their needs and advocating them

Scribbles

• Were more focused on Developer Experience but developers expected community support.

• Wanted Java EE Developers to love their product (Liberty) so much that they tell their friends to use it too

  • Created articles, resources, GitHub codes, YouTube videos, etc.

  • Created shared expertise within the community

  • Openness within the community - meeting developers at conferences, talking to people generally, sharing experiences

Where did it start?

• Whiteboard session at Devoxx 2008 (Belgium) - comparing Java application servers - everyone complained about difficulties starting/ fixing errors and consulting fees.

  • Wanted to create resources for Liberty to get around this problem.

• Realised that they need to create a more developer-focused website for their community.

  • Frequent updates, adding new articles regularly created engagement, people were coming to the website and interacting

Motivating the Internal Developers

Wanted to get regular content from internal developers

• But this became difficult for them with a day job

• One developer made in charge of maintaining fresh content, working a day a week dedicated to this.

• As it grew, one person was hired full time for regulating this.

• Made a strict weekly publishing schedule to maintain a regularity (Made a pipeline)

• Executive director motivated developers to contribute to content around Liberty - it worked!

Wanted to involve developers to be involved with Social Media, StackOverflow or go to conferences

• Mentoring them to use the handles

• Letting them know the use of hashtags

• Creating guidelines around attending conferences

• This cannot be forced - social media is genuine and if forced to post/ tweet, it reflects

Recognising complementary roles of marketing & development

• Developer Advocates were hugely protected by the marketing team

• Marketing is good at awareness and hooking people to the product

• Marketing helps the product to shine but developers need details as well

• Added a trial for developers to try out the product

  • If registration was added to trial download, 60% of the developers turned away, if not the marketing couldn't collect leads.

  • Cold calls attracted negative reactions from developers.

Timelines

• Building a developer community is organic and long term.

• Marketing needs to work on short term campaign

Metrics

• Quantitative Measures: Numbers of downloads, visits to the website

• Qualitative Measures: Quotes from people, their thoughts on the product

Understanding the users and advocating for them

• Most difficult thing: Keep the focus on who is the end-user & who is the target.

• UX Terms: Primary users, secondary users, tertiary users

• Developers are the main users

Don't publish everything!

• It is difficult to say no, but things should be relevant to the target audience

• Having a clear definition of what is needed, helps in this regard.

Is it working?

• Yes - Metrics are going up!

• More people are talking about the product - getting feedback

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.

• The example of Capital One given at 12:00 is a fantastic example of implementing this.

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

Summary:

“I encourage everyone who hasn’t to see the value and actually connecting with your developers one-on-one so you can learn from their stories and feel their pain.”

• It doesn’t really matter if it’s on the phone or through video or in-person,

  • as long as you’re kind of connecting one-on-one and asking them open-ended questions.

• Don’t Assume your developers

  • Want what you do

  • Are all the same

  • Know your product

• Put on your researcher Hat

• Make your finding in researchable format

• Include your stakeholders --

  • don’t get overprotective by the process.

• Frame your findings to support your customers and business.

Scribbles:

• It’s important to tailor your DevRel initiatives to your company’s business model and your team structure.

• Set up objectives for your team.

Biggest challenges in DevRel

• Determining which of the numerous activities is the most leveraged,

• How should the docs be improved

• Move to the OpenAPI spec

• Writing code examples

• Creating SDKs

• Speaking at conferences

• Fostering a dev community

• Answering technical questions

• integrating with partners

Quote Our initial thought was, you know, we’re developers so we know what developers want. We’ll just choose the things that seemed useful to us. Wrong.

🚩 Takeaways:

Don’t assume you know what developers want.

• Generalize developers of your platform

  • 1st Party Developers - Engineers that build integrations on our API.

  • 2nd Party Developers - Work on/for customers.

  • 3rd Party Developers - Build apps for many asana customers to use.

• It can be difficult to actually track down the developers and get that first handful of meetings.

• Really hard to understand the behaviour of your users until you have one-on-one conversations and meet with them and listen in person.

Don’t assume your developers know your product.

• Not everyone loves your product as much as you do.

• Reevaluate our developer experience.

  • Writing an object hierarchy doc to explain the elements of your product.

Don’t assume all of your developers are the same.

• Create distinct personas and expand each a bit more.

• Creating different developer tracks for each group.

• Packaging all of these developer interviews into case studies and presenting them to numerous teams across your organisation.

Importance of internal platform evangelism.

• Cultivating a thriving developer ecosystem is difficult if you can’t get your internal teams excited about the product.

Ask the hard questions to a broader set of developers.

• Choose your research methods and goals before you start talking to users.

• Ask open-ended questions.

  • Give people the space to speak their minds.

  • Get out of your own way, let your developers tell you what they experience.

• Come in with an open mind.

  • If you come in with an opinion, you risk only hearing the evidence that supports that hypothesis.

Ways of gathering Developer Stories

• Interviewing developers.

• Developer survey.

• Developer community

• Feedback form

• Documentation

• Meeting and researching with 1st party, 2nd part and 3rd party developers.

Structure and organise your findings in a more actionable format

• Organize the feedback into themes

  • Each section was a different theme

  • Custom fields to track user stories by dev personas.

Include your stakeholders.

It’s also about customers and the business .. not just developers.

• Start reframing some of the developers needs to encompass some of the broader customer and business needs.

• Represent developers at company planning.

Summary:

• Differences between being a product-based software engineer

• Pros and cons of this move

• Signals in your own life are strong indicators that you might be successful in DevRel

• What the DevRel mindset is

Scribbles

• The main focus of the blog is to focus on the engineering side of developer relations.

Difference between being a software engineer on a product and a software engineer in developer relations

Software Engineering vs DevRel - The difference

Time spent coding

• Product-based software engineer the majority of your time is spent working on

  • features

  • fixing bugs

  • writing tests

  • eliminating technical debt

  • writing design documents

• Engineer in developer relations, there’s simply a lot less time to do all of this

  • developer relations teams are the connective tissue between 3rd party developers and the internal product and engineering teams

  • time spent on creating, building, and connecting with communities.

  • collecting feedback and working with your internal stakeholders to make sure the product is evolving to better serve the developer community

Size of coding projects

• not always be the case, but generally speaking, the size of the coding projects in DevRel is smaller.

• building a proof of concept, a demo, a code snippet, or perhaps a client library

• your code itself is to be used by other developers within their own projects

• building a community, overhauling documentation, amplifying knowledge about a product through videos and speaking engagements -- less coding.

Part of everything

• part engineer, part product manager, part marketer, and part business development.

• encounter a lot of different stacks

• have to be flexible and learning new stacks on the go.

Focused on people

• DevRel at its’ core is about people

• software engineering is often more about the code you produce

• a mix of a great engineer who connects with other engineers and has the respect of the internal teams at the same time caring about people (developers) and making them successful.

Evaluation of contributions

• software engineer’s impact is likely focused largely on technical contributions

• For DevRel

  • community growth/support

  • growth of product awareness

  • product influence

  • communication regarding product launches

  • delivery of technical content

Pros

• Requires being good at a different set of skills.

• You have a chance to see the world.

• You’ll be closer to the people who use the product.

Cons

• There are less DevRel jobs than software engineering jobs.

• Most people understand the value a software engineer brings to a company, it’s not as clear in developer relations.

• There's a lot of explaining to do.

Signs to switch to DevRel

• Actively participated in or organized programming events, contests, hackathons, or workshops.

• Spoke at technical conferences or meetups.

• Have a mixed background of engineering and product or project management.

• Academic background or teaching experience of technical subjects.

At the end of the day, it's all about the mindset, #DevRel being about people, the mindset has to be one of empathy. Their success is our success.

Summary:

“Your developer advocacy might not look like anyone else’s, and that’s okay. Ours was messaging.” -- Olja

• Their developer advocacy structure

  • Messaging

  • Enterprise design thinking

  • Developer essentials badge

  • Sample in five languages using 3 APIs

Enterprise Design Thinking

• Loop

• Restless Reinvention

• Diverse Empowered Teams

• Observe

• Reflect

• Make

• Hills

• Playbacks

• Sponsor Users

Scribbles:

How to support developers for a 26 year old software.

• We don’t look after just devs.

• The way their product works, they have multiple users, they have application developers and administrators.

Developer Knowledge cycle

• If developers came out of university or they were starting in the ’90s,

  • They were used to having to learn and spend a lot of time finding out about technology, and they had time and they were measured on how well the stuff that they created worked.

• The developers that are coming out of universities are used to trying things out for a little while, and then things working.

  • They don’t want to spend three months learning about something and then building something.

  • They want to find it, try it, and it then works straight away. And they were having a few problems with this.

• For existing developers who like their product, they would support them with new functions.

• New developers, who needed a bit of help, needed to accelerate their progress.

Developer Challenge

• Being measured on Time to working code, and so they felt quite sympathetic to their problems.

• Your developer advocacy might not look like anyone else’s.

  • Messaging

  • Enterprise design thinking

  • Developer essentials badge

  • Sample in five languages using 3 APIs

MQ …?

• What is MQ and how does it work?

• Mainly, they have a server component that is installed and configured, and then they have applications that interact with the server.

• And basically what this is for is moving data in messages between systems and applications; in a very low-level explanation.

• Two types of users -- admins and developers.

  • The admins are looking after the server-side of things, and application developers are developing applications.

  • How they’re interacting, and how things have developed over the years that aren't quite working anymore.

• In terms of what it does for business, it connects the pieces and makes everything work together.

Enterprise Design Thinking

• Loop

  • Drive business by helping users achieve their goals.

• Restless Reinvention

  • They observe, reflect, make.

  • They try to work with diverse teams because at that point -- get the best information and different points of view.

• Diverse Empowered Teams

  • Move faster by empowering diverse teams to act.

• Observe

  • Immerse yourself in the real world.

• Reflect

  • Come together and look within.

• Make

  • Give concrete form to abstract ideas.

• Hills

  • Aligns teams in meaningful user outcomes to achieve.

• Playbacks

  • Stay aligned by regularly exchanging feedback.

• Sponsor Users

  • Invite Users into the work to stay true to real-world needs.

Empathy

• It is the first stage of design thinking.

• Putting yourself in the shoes of your user.

• Imagine how things work for them, and understand what their problems are.

• They work with empathy maps. they try and figure out what their users say, think, do and feel.

• Helps them understand when they start building solutions for their users, how best to go about it. ‌

Hills

• These are statements that they set to themselves after we’ve been through design thinking processes

  • Have shared understanding between different stakeholders so that everyone knows what it is that we’re working on, what we’re working towards, and what the mission is.

• And so from the very starting point, when they were trying to figure out what they wanted to improve

• They wanted a developer to be able to understand a little bit about MQ and start a sandbox environment and start a sample application.

How did they go about it?

• They created a platform that wasn’t anything very complicated.

• What did they help them to understand?

  • Just the very basics about what their message is, what MQ is.

  • How they can stand up and setup, without understanding everything that admins have to understand.

  • They gave it to them in Docker, with some default configuration in there so that they didn’t have to learn everything.

• They were getting good feedback through the websites and through some events.

• Admins -- they came in for a user-group meeting,

  • Try and tell them about everything new that’s happening.

  • Asked them some questions, what they thought problems were when developers deliver codes.

  • They tried to get them to empathize with developers.

  • Why would they deliver such bad codes, that they wouldn’t work? And they didn’t think they were going to engage with the process but they went all out.

Developer Essential Badges

• They created a badge.

• They didn’t start from scratch. They had some materials from the LearnMQ platform that I started with before.

• They started really simply, which sounded quite weird. they started with questions, they went around their team and asked everyone what they thought the questions would be for developers to learn.

• They created a challenge for developers to actually go and look at some codes. they did it in such a way that they would have some backup and troubleshooting.

• They put those samples in GitHub in three ways, so that if they didn’t really want to get their hands dirty and code it from scratch, they could fix some bugs.

Quote - “People are taking this up, and they are now talking to students, taking it to universities, and possibly doing customer workshops.”

Sample in 5 langs & 3 APIs

• MQ Verbs tell you how to interact with the server. And they often say it’s a very elegant API.

• Only has 26 verbs, and then you can do everything with those.

  • Behind each of those, there is a library of material that you have to go through, in order to understand what you need to do.

  • Admins, they understand all of this, they know how it works. But for developers, they see this, and they tend to move on to something else.

  • But they came up with all their samples and all the patterns, in different languages. And they’re consistent.

How did they do this?

• They picked some of the basic patterns, and obviously, they started with Java.

  • They wrote a lot of their initial material for JMS.

• They also touched their MQI, which is the native API. And they have thin wrapper libraries for Go and Node.

How does it work in practice?

• They would start with Java, they thought we’d finished, test it, and put out Java.

• They went and worked on Go and Node.

• Their teams were surrounded by experts, and developers who developed MQ

  • They wanted to go through the pain that their developers go through, and not ask too many questions.

• They tried to look for pointers and tried to solve their problem on their own

• They wouldn’t actually ask for more help until they would spend two or three days not being able to do it.

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:

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