Success metrics as narratives

Wowza Media’s Director of Developer Relations Amara Graham describes the use of narratives before, during, and after events to get a complete picture of dev rel event success.

Video

Summary:

• Numbers aren’t effective storytellers

  • Numbers are open to interpretation and they especially have connotations.

  • Numbers lack context and situational awareness

  • Numbers are open to interpretation

  • Numbers have connotations.

  • Numbers, even in the hands of the well-intended, can become dangerous.

• Language

  • Start adding some of that language together with your numbers

  • Understand a little bit better about your developer relations activities, especially when we start talking to your different folks within your teams

• Happening* is any sort of DevRel activity - blogs, conference talks, workshops, etc.

• Before the Happening*

  • Make sure that you’re evaluating previous iterations.

  • Setting expectations and setting an event-specific goal.

  • Ask - Does this align with your target developer persona?

• During the Happening*

  • “How are you feeling about the expectations and goals?”

  • Do you need to reset anything?

  • Ask - Where is everyone?

  • Getting great technical questions

  • Setting up for job seekers

• After he Happening

  • Did you meet the expectations and goals that you set at the beginning?

  • Would you do it again?

Stop letting other people, organizations, teams, what have you, define your success.

Scribbles:

• Success looks different as you’re going across your DevRel activities.

• So, if you’re doing a conference, it’s going to be very different from a meetup. If you’re doing a conference talk, it’s going to be very different from the conversations and engagement that you have at booths.

Numbers aren’t effective storytellers

• It’s unrealistic to assume that numbers have denotations.

  • That’s your dictionary definition, even though they’re well regarded as fact.

If we don’t present it with context and we don’t present it with that situational awareness, numbers are not going to gain that themselves.

• Numbers are open to interpretation and they especially have connotations.

  • 100%, or you have nothing, 0% -- not really true.

  • In some cases, you may be working on improving a particular percentage to be within 20% or 30%.

• Numbers lack context and situational awareness

• Numbers are open to interpretation

• Numbers have connotations.

• Numbers, even in the hands of the well-intended, can become dangerous.

Language

• Start adding some of that language together with your numbers

• Understand a little bit better about your developer relations activities, especially when we start talking to your different folks within your teams

  • Get their perspective about a particular event or activity

  • See how they describe it.

  • See how it was impactful for them

  • The engagements or the connections that they made.

Before the Happening*

• *Happening

  • the happening for you could be any sort of DevRel activity.

  • Writing a blog

  • Conference talk

  • Hosting a virtual workshop.

  • All of the things that you don’t have to travel to do.

• Make sure that you’re evaluating previous iterations.

  • “Did it make sense for us to attend this function, or did it make sense for us to be involved with this activity”?

  • Go back and evaluate

    • What you did in that particular happening.

    • Does it make sense to continue doing that?

• Setting expectations and setting an event-specific goal.

• Ask- Does this align with your target developer persona?

  • or does it align with some sort of new functionality that we’re releasing?

  • or a new programming language functionality that’s coming on board.

We live in a very agile world, going back and iterating on these things is really important and it keeps your developer audience engaged.

• This is where you need to start shaping your idea of success or your idea of failure.

During the Happening*

• “How are you feeling about the expectations and goals?”

  • Internal monologue if you’re there by yourself.

  • Questions to your team on the day, you know, two or three of the particular things happening as you’re setting up or as you’re getting ready to continue going.

• Do you need to reset anything?

  • But for workshops and conferences, this works really well.

  • You’re able to level set with your crowd

• Ask - Where is everyone?

  • If they are splitting their time between your webinar and your competitor’s webinar.

• Getting great technical questions

• Setting up for job seekers

After he Happening

• Did you meet the expectations and goals that you set at the beginning?

• Would you do it again?

• This is where those numbers start to creep in.

I want the best use of time for my developer relations folks. And if we’re not getting those technical questions or we’re not seeing the right developer audience, we’re going to just move on.

So, what should you do?

• Using words and evaluating at every stage is incredibly important.

• Check-in with you or with your team, combine it into one comprehensive look so that you can evaluate the entire happening.

• If you have a large team or you’re sending a large team to an event

  • you can collect feedback and run it through sentiment analysis.

• If everybody’s responding in kind of a negative manner

  • worth digging into and understanding.

  • If it’s things like technical difficulties -- understandable.

• You want to share your goals and expectations

• Make sure that you’re gathering baselines.

Stop letting other people, organizations, teams, what have you, define your success.