Maker Party Engagement: Week 2

Two weeks in!

Let’s check in on our four engagement strategies.

First, some overall stats:

  • Events: 862 (up nearly 60% from the 541 we had last week, and more than a third of the way towards our goal of 2400)
  • Hosts: 347 (up >50% from 217 last week)
  • Expected attendees: 46,885 (up >75% from 25,930 last week)
  • Cities: 216 (goal is 450)

Note: I’ll start doing trend lines on these numbers soon, so we can see the overall shape.

Are there other things we should be tracking? For example, we have a goal of 70,000 Makes created through new user accounts, but I’m not sure if we have a way to easily get those numbers.

  • Webmaker accounts: 91,998 (I’m assuming “Users” on this dash is the number of account holders)
  • Contributors: If I understand the contributors dashboard correctly, we’re at 4,615, with 241 new this week.
  • Traffic: here’s the last three weeks. You can see we’re maintaining about the same levels as last week.

——————————————————————–

Engagement Strategy #1: PARTNER OUTREACH

  • # of confirmed event partners: 205 (5 new this week)
  • # of confirmed promotional partners: 63 (2 new this week)

We saw press releases/blog posts from these partners:

We also started engaging Net Neutrality partners by inviting them to join our global teach-ins.

——————————————————————–

Engagement Strategy #2: ACTIVE MOZILLIANS

  • Science Lab Global Sprint happened this week—I don’t yet know the total # of people who participated
  • Lots of event uploads this week from the Hive networks.

——————————————————————–

Engagement Strategy #3: OWNED MEDIA

  • Snippet: The snippet has generated nearly 350M impressions, >710K clicks, and >40,000 email sign-ups to date. We’ve nearly finalized some additional animal-themed icons to help prevent snippet fatigue, and have started drafting a two-email drip series for people who’ve provided their emails via the snippet (see the relevant bug).
  • Mozilla.org: In the first few days since the new Maker Party banner went live we saw a significant drop in Webmaker account conversions (as compared to the previous Webmaker focused banner). One likely cause is that, in addition to changing the banner itself, we also changed the target destination from Webmaker to Maker Party. We’ve rolled back the banner and target destination to the previous version, and are discussing iteration ideas here.

Analysis: We’ve learned quite a bit about which snippets perform best. The real test will be how many email sign-ups we can convert to Webmaker account holders.

——————————————————————–

Engagement Strategy #4: EARNED MEDIA

Planting seeds:

  • Mark had an interview with Press Trust of India, India’s premier news agency that has the largest press outreach in Asia.
  • Brett had an interview with The Next Web

TV/Video:

English:

What are the results of earned media efforts?

Here’s traffic coming from searches for “webmaker” and “maker party.” No boost here yet.

—–

SOCIAL (not one of our key strategies):

#MakerParty trendline: You can see the spike we saw last week has tapered off.


See #MakerParty tweets here: https://twitter.com/search?q=%23makerparty&src=typd

Some highlights:

Screen Shot 2014-07-21 at 3.11.53 PM Screen Shot 2014-07-21 at 3.12.27 PM Screen Shot 2014-07-21 at 3.12.58 PM Screen Shot 2014-07-21 at 3.13.49 PM Screen Shot 2014-07-21 at 3.14.19 PM Screen Shot 2014-07-21 at 3.15.59 PM Screen Shot 2014-07-23 at 3.35.32 PMScreen Shot 2014-07-24 at 4.06.45 PM

 

Maker Party Engagement: Week 1

Maker Party is here!

Last week Geoffrey sent out the Maker Party Marketing Plan and outlined the four strategies we’re using to engage the community in our annual campaign to teach the web.

Let’s see how we’re doing in each of those four areas.

First, some overall stats:

  • Events: 541 as of this writing (with more to be uploaded soon)
  • Hosts: 217 as of this writing
  • Expected attendees: 25,930 as of this writing
  • Contributors: See Adam’s post
  • Traffic: see the image below, which shows traffic to Webmaker.org during the last month. The big spike at the end of June/early July corresponds to the launch of the snippet. You can see another smaller spike at the launch of Maker Party itself.

Screen Shot 2014-07-20 at 9.29.00 AM

——————————————————————–

Engagement Strategy #1: PARTNER OUTREACH

  • # of confirmed event partners: 200 as of this writing
  • # of confirmed promotional partners: 61 as of this writing

We can see from analytics on the RIDs that Web 2.0 Labs/Learning Revolution and National 4H are the leading partners in terms of generating traffic to Webmaker.org. Links attributed to them generated 140 and 68 sessions, respectively.

Additionally, we saw blog posts from these partners:

——————————————————————–

Engagement Strategy #2: ACTIVE MOZILLIANS

  • Appmaker trainings happened at Cantinas in MozSpaces around the world last Thursday. Waiting to hear a tally of how many Mozillians were engaged through those events.
  • You’ve probably seen the event reports on the Webmaker listserve from Reps and Mentors around the world who are throwing Maker Parties.
  • Hives are in full effect! Lots of event uploads this week from the Hive networks.

Note re: metrics—though there’s evidence of a lot of movement within this strategy, I’m not quite sure how to effectively measure it. Would love to brainstorm with others.

——————————————————————–

Engagement Strategy #3: OWNED MEDIA

  • Snippet: The snippet has generated nearly 300M impressions, ~610K clicks, and ~33,500 email sign-ups to date. We now have a solid set of baseline data for the initial click-through rate, and will shift our focus to learning as much as we can about what happens after the initial click. We are working on creating several variants of the most successful icon/copy combination to avoid snippet fatigue. Captured email addresses will be a part of an engagement email campaign moving forward.
  • Mozilla.org: The Maker Party banner went live on July 16 in EN, FR, DE, and es-ES. So far there’s been no correlative spike in traffic, but it’s too early to draw any conclusions about its effectiveness.

——————————————————————–

Engagement Strategy #4: EARNED MEDIA

Our partners at Turner4D have set up several interviews for Mark and Chris as well as Mozillians in Uganda and Kenya.

Radio

Print

English:

Indonesian:

German:

Spanish:

Importantly, Maker Party was included in a Dear Colleague Letter to 435 members of the U.S. Congress this week.

What are the results of earned media efforts?

None of the press we’ve received so far can be directly correlated with a bump in traffic. Because press, when combined with social media and word of mouth, can increase general brand awareness of Mozilla and Maker Parties, one of the data points we are tracking is traffic coming from searches for brand terms like “webmaker” and “maker party.” The graph below shows a spike in that kind of searching the day before the launch, followed by a return to more average levels.

Screen Shot 2014-07-20 at 10.13.35 AM
SOCIAL:

We do not consider social media to be a key part of our strategy to draw in contributors, but it is a valuable supplement to our other efforts, as it allows us to amplify and respond to the community voice.

You can see a big spike in mentions on this #MakerParty trendline: trendline

See #MakerParty tweets here: https://twitter.com/search?q=%23makerparty&src=typd

Some highlights:

tweet1 tweet2 tweet3 tweet4 tweet5 tweet6 tweet7That’s all for this week. Stay tuned. The analysis will get deeper as we collect more data.

Heartbeat: Engagement Style?

On a recent Webmaker call, I learned about the proposal to have the Webmaker teams start operating on a regular schedule, which has been dubbed “heartbeat.” Each heartbeat lasts two weeks, and includes planning, retrospection, heads down working, a mid-point check in, and demos.

I dig this. I was a Scrum Master in my former life, and the heartbeat idea echoes Scrum, which I know to be a super effective tool for creating rhythm on a team.

In addition to the benefits/goals cited in the presentation, I would add that rhythm is also good for:

  • syncing between teams
  • increasing accountability and trust within a team
  • ensuring continuous improvement
  • increasing velocity/productivity
  • improving morale

Here are some thoughts on how we might implement a heartbeat within the context of the Engagement team:

  • Identify the right heartbeat duration. Does two weeks make sense for the highly responsive and externally-focused work we do?
  • Incorporate planning into our team meeting. This might just mean making sure the answers to the question “what will get done this week?” are in bugzilla and/or on the workbench. I’ve found that planning works best when teams are operating from a shared, continually updated backlog of items. If you have this, “planning” can be very low effort: it’s simply pulling a set of items from the top of the backlog and labeling them with the upcoming heartbeat.
  • Add demos to our routine. This could be part of the weekly team meeting, or perhaps could be done in an ad-hoc way. Creating the expectation that each part of the team will demo something during each heartbeat would lend even more intentionality to the planning.
  • Incorporate retrospecting behaviors. This might mean a 10-minute debrief at the end of every heartbeat, either for the whole team, or perhaps divided into the different functional areas. It might mean building a virtual suggestion box for people to share ideas about how to improve our process, or cultivating a weekly “One thing I will do differently this week is…” habit. There are lots of ways to build a culture of action-oriented retrospection!

Curious to know what others think about adopting the heartbeat model for the Engagement team.

Thoughts on the role of the Engagement Team within the Foundation

Adopting a Service Mindset {Anagram: Tom’s decade revising a pint}

At my last job I played a project manager-like role for the in-house web development team of a nonprofit organization. The web development team was really more of a software company in that they were creating feature-rich, highly interactive products for a variety of end user clients; those products just happened to be on the web. Our work was served by other teams: the customer support team, the marketing team, the operations team, and more.

It has been interesting to move from the world of product development to a functional area where much of what we do is provide support and services to program teams.

The support and services that the Engagement Team provides run the gamut from fundraising and partnership strategy, to grants pipeline management, to external communications and campaign strategy, to production services (read: the graphic design, web development, and copywriting services of Studio MoFo).

I realize that the Engagement Team might not be seen (by its own members or by others) in this way—as a team that supports other teams. After all, we lead our own initiatives and we tell a meta-story of the Foundation that is more than the sum-total of the individual programs. But it has been a helpful framing device for me as I learn the terrain here, and I don’t think it would be a bad thing to be seen this way. I think it would be a very, very good thing.

I’m learning about some of the challenges that are unique to providing support for program teams.

  1. In some cases, the main challenge might be simple visibility—making sure that people know your services are available to them. I’m of the belief that no amount of well-crafted wiki pages or etherpads will provide that visibility unless those things are placed in front of people at the moment they need them. Who remembers to look at wiki pages and etherpads that aren’t already a part of their regular workflow? (Okay, probably some people do, but not everyone, and besides, it’s a maintenance nightmare and it becomes less effective over time as staff members come and go.)
  2. Another challenge is helping people understand how your services can fulfill one of their perceived needs. There are two parts to that thought—first, they have to believe they have a need, and second, they have to believe your service will fill it. For some services, this is a no-brainer. “I can help you fund your project”—the need is clear, as is the connection to the service. Done and done. With other services (for example, external communications), the need may not be top of mind for program staff who are heads down and in the weeds of their program work.
  3. Another challenge is scaling. How do we support all of the great work that’s going on? I’ve heard members of the engagement team talk about their desire to provide training to other staff and community members. This kind of expertise sharing would increase capacity across the board. Total win.

Servant Leadership {Anagram: Parental dervishes}

Here are some principles I’d like to adhere to as we figure out how to best support the work of our fellow MoFos, while at the same time leading the way in the areas where we have expert-level knowledge:

  • Meet people where they are. In some cases, we can expect people to come to us with support requests, but in general, we should be meeting people where they are. We should attend their meetings and check in on their project plans in order to identify the areas where we can apply the knowledge and experience for which we were hired.
  • Become experts at surfacing obstacles to people’s work. I could write an entire blog series about the challenge of surfacing obstacles. (Note to self: write an entire blog series about the challenge of surfacing obstacles). We are only helpful if we are solving real problems for people, so we have to know what the real problems are.
  • Tell our own story. We know the value of what we do; we need to figure out how to share that with others. And really, we should be showing, not sharing.

Curious to know what others think.

Clockmastering 101

Creating the Clock {Anagram: Ken Clog, Architect}

In order to be a good clockmaster, I need to know what’s on the clock. I need to know what promises we’ve made, what deadlines we have, and what milestones we need to hit.

That information is currently spread out in dozens of different places—in spreadsheets, docs, etherpads, bugzilla tickets, and miscellaneous project management software. There are grant timelines, social media schedules, campaign calendars, individual project timelines, email production calendars, marketing plans, and so on.

This is going to be fun!

Baby Steps {Anagram: Abs by Pets}

Right now I’m just focusing on one aspect of our work—the various places where we store communications-related calendars.

We’re currently keeping several different calendars updated:

  • The Engagement Calendar on StudioMoFo.org is a nice visualization, is public-facing, and lets visitors to the site know what’s currently on the Studio MoFo docket. I’d suggest we maintain it if it’s providing value to people. Does anyone have any evidence either way?
  • I’ve found that the no-longer-aptly-named “April-May-June” etherpad is quite useful in that it provides a little more context about the different projects. It also has a slightly lower barrier to entry because the StudioMoFo calendar is dynamically generated from a separate spreadsheet. But as much as I like it, I’m going to suggest we scrap it. The name itself suggests that we never intended to keep it around for long. I think we can safely retire it now. Any objections?
  • The “Engagement Calendar,” the first in a multi-sheet spreadsheet, might already be obsolete. I’m intuiting that it served as a great tool when the team was mapping out the arc of the year, probably sometime in January. It seems to be losing its value, though.
  • Perhaps more controversially, I’d also suggest we lose the Email Production Calendar tab of that same spreadsheet. It’s not that I don’t think it’s important to coordinate and plan our email strategy. In fact, it’s because I think it’s so critical that we coordinate email that I don’t want to depend on people remembering to update a spreadsheet. I’m wondering if the value from this spreadsheet could be gained another way. The Monday morning editorial meetings should prevent any collisions on a weekly basis. We might be able to get at the longer term planning at the monthly communications working meeting that Erica proposed. Thoughts on this?
  • Perhaps against my better judgement, I’m also replicating this information in one new place—the not-yet-ready-for-primetime Engagement Team Workbench. I’d like to eventually have the workbench serve as canon for the entire team’s deliverables. Because a wiki has a higher barrier to entry than an etherpad, it somehow feels more authoritative. I want people to trust that what’s on the calendar is accurate and current. I’d like to borrow from the Webmaker team’s playbook and update the workbench on a sprintly basis (however we define that) with our expected deliverables.
  • A sub-set of projects are also included in at least two different MoCo spreadsheets. I’ll take responsibility for maintaining those, since those seem more difficult to consolidate.
  • All of this information also lives in bugzilla, which is, of course, a non-negotiable. I would like to have a conversation about what type of work gets logged in tickets, and at what level. I’ll save that for another day.
  • There are also separate tools for managing Studio MoFo production deliverables and social media calendars, but since those systems are relatively independent, I’m not going to suggest any changes. (Though I’d love to find a way to eventually reduce the costs associated with keeping the same work updated in bugs and Asana and spreadsheets.)

I’ll be pushing these ideas at upcoming meetings, but I’d welcome any comments on this blog, too.

On being new

The New Kid {Anagram: Think Weed}

This is the first time I’ve started a new job in ten years.

It’s quite a change to go from having a decade’s worth of history/knowledge/context with an organization to being completely immersed in newness. It’s good practice in adopting a beginner’s mindset.

While listening in on a call with our Gear Store vendors the other day I had this thought: “Wow, I have absolutely no opinion on what gear to sell.” Not that I was being asked for an opinion; it was just strange to notice that I didn’t have one. At my old job, I would have had tons of opinions rooted in my understanding of our brand manual and my deep knowledge of our audience. But here, I was completely devoid of insights. It was equal parts refreshing and disorienting.


What am I doing? {Anagram: A dogma within}

I’ve done some thinking about what I want to accomplish in the immediate future. What follows is the totally hackable set of goals I’ve narrowed in on.

Phase One Goals:

  • build a workbench, using the wiki + Bugzilla, that:
    • supports people’s workflows (read: enhances people’s existing workflows, not “adds a new, annoying layer to people’s workflows”)
    • provides some performance metrics
    • helps us identify mis-alignment by providing a birds-eye view of where we are vs. where we should be.

     

  • get teamwide consensus on processes to support the above
  • benchmark some metrics:
    • something related to “velocity” (some objective measure of the rate at which work is getting done)
    • something related to quality (which, in our case, is probably just the nice and objective metric about whether we’re meeting our stated goals)
    • something related to team members’ happiness (specifically in regard to processes/team communication, not, like, their romantic lives)

I imagine the workbench will go through quite a few iterations before it can do all of the above, so Phase 1 might be a big hurdle.

Phase Two Goals:

Once over the Phase 1 hurdle, I’d like to focus on continuous improvement. That means…wait for it…retrospectives! “Retrospectives” are one of the several things I’d like to adapt from the world of Agile software development (my homeland, if you will) and apply to the engagement team’s work. Retrospectives are the best!

On a software team running “Scrum,” a retrospective would be a regular, dedicated ritual at the end of every “sprint.” The retrospective allows team members to reflect on how they’re doing, and agree upon changes to their process.

I won’t necessarily push for regular retrospective meetings (ain’t nobody got time for that!), but when the time comes, I probably will try to come up with some clever ways to inject retrospective behaviors into our team’s workflow.

Week One

First Impressions {Anagram: SOS: Fries Misprints!}

Heading into my (short) second week at MoFo, the following thoughts are swimming around my brain:

  • Everyone here is smart and kind, which I consider to be the two most important traits in colleagues. Win! Thanks to everyone for being so welcoming.
  • This feels like the type of environment where you have to/get to “jump in.” This makes me happy because I learn by doing, but I’ll have to ask for forgiveness in advance if my contributions sometimes lack full context. I’ll try to find the right balance between listening and contributing.
  • Given the facilitative nature of my role, I expect my main unit of contribution will be on the process side of things, rather than product, content, and the other outcomes of our work. In some ways I think it’s more difficult to jump in on process, because there may be a lot of context and history that I can’t read about on wikis and blogs. Again, apologies in advance for all of the things I’m sure I’m going to mis-read during my spin-up phase.

Lay of the Land {Anagram: Lady Halftone}

I’ve asked a few people what they think are the areas in which I might be helpful. I’ve heard several answers including: establishing a team-wide rhythm, improving communication habits and meeting practices, setting up systems, and increasing communication between the various parts of the Engagement team’s work.

I’m looking forward to asking the same question of everyone on the team. I’m going to need a metric to know how well I’m doing, and so far the main metric I’ve identified is “team member happiness regarding systems and processes.” (Suggestions for other metrics welcomed!)

Dropping Philosophy {Anagram: Holding Pro-Hippy Spy}

I’m a big believer in letting systems emerge, rather than designing them, at least when it comes to groups of people (and the web). Emergent systems start from the question, “What is happening now?” and use a repeated pattern of evaluation and incremental changes to work towards better systems.

Kanban is a tool used in the manufacturing and software worlds to manage workflow and prevent bottlenecks. I like to think of Kanban as a method for discovering the process you already have in place. Even if you haven’t sat down and defined a process, if work is getting done, there is some process in place—maybe a really messy one. Kanban helps teams expose that process, and then begin to identify any problematic parts and make changes.

Honestly, I don’t know if Kanban would be an effective tool for the communications- and development-flavored work of the Engagement Team. I bring it up here only because I do think it may be valuable to implement some kind of discover/experiment/evaluate rhythms into the team’s workflow. To clarify: I’m talking about the meta process part of the work (the How), not the outcomes part (the What), though of course discover/experiment/evaluate might also be applicable to, say, building a new web property or writing a grant.