Kayaks, Nachos, Pipelines, and Funnels, or: The Mofo Engagement Fall Work Week

Last week, the Mofo Engagement Team and Friends (terrible band name) met in Toronto for some some serious boating, eating, and hacking.

Prelude: With some much appreciated assistance from Erika, I got over my fear of boats and managed to canoe up and down a bit of the Humber river during our pre-work week Super Engagement Team Fun Day. We may not have been fast, but we had style (assuming your definition of style includes crashing into the riverbank). Later, I tricked several of my co-workers into ordering giant platters of nachos at Sneaky Dee’s. It was a cheesy, oversized start to the work week.

On to the work-y part!

The agenda was ambitious. We had four concurrent tracks, each with their own projected outcomes:

  • The set-up for the End of Year fundraising campaign
  • The creative brief, RACI, and roadmap for the Fall Webmaker Sales Campaign
  • The 2015 Grants Pipeline
  • And the partnership strategy, systems, and sales team for growing Webmaker

Did we achieve what we wanted to achieve?

All that, and more.

The End of Year Fundraising team was on fire. The project had been well-prepped in advance, so the team was able to use the work week as a sprint and deliver a slew of prototypes and designs. They tackled the snippet, optimized donation forms including a brand new sequential flow, localization, the fundraising.mozilla.org website redesign, overarching branding, and even an awesome community marketing idea.

The Partnerships team had several rich conversations where they identified possible partners, clarified roles, and simulated the entire sales flow using human props, sticky notes, and impressive improv skills. (I left that session with a post-it note on my laptop that read, “Why would clown mentors come back to the site?” A question for the ages.)

A centerpiece of the Fall Webmaker Campaign is the post-sales funnel which includes custom partner landing pages and a choose-your-own-adventure style event wizard to help people get started with one of three easy/fun Maker Party events. The entire funnel got spec’ed and wireframed and the Event Wizard got some design love during the work week.

(Note: The Partnerships track and the Fall Webmaker Campaign track were largely merged into a single Fall Webmaker Campaign with elements including sales, marketing, design, and product dev. The campaign is focused on reaching our 10K contributor goal, and will leverage key partners with large networks. In addition to honing our value proposition to partners, we’ll also use the opportunity to refine our marketing funnel. Later, we’ll go out and introduce a broader addressable audience to the top of the funnel. At that point, there will be a clear distinction between sales and marketing, but for the Fall campaign, we’re working in tandem.)

The 2015 Grants Pipeline team got to spend some quality time with our brand new Salesforce installation. They make web-to-lead forms, trigger events, and dashboards seem downright glamorous!

Phew.

Does this seem like a lot of stuff? That’s because it is a lot of stuff! But never fear, it’s all summarized on the Engagement Team Workbench. (You can also see a complete list of what we delivered during the work week here.)

I was amazed at how much was accomplished during the work week. My co-workers are some of the raddest, most capable and action-oriented people I’ve had the privilege of knowing. Lucky me to be a part of it!

Maker Party Engagement Week 5

Week 5!

tl;dr highlights of the week:

  • Though we saw significant jumps in Wm accounts and events, our Contributor numbers did not increase accordingly
  • We’re identifying many opportunities from the partner calls
  • Hack the Snippet is coming soon, along with the next iteration of the snippet funnel
  • The TweetChat created a temporary increase in Twitter engagement, but took attention away from press

Overall stats:

  • Contributors: 5552 (2% increase from last week’s 5441)
  • Webmaker accounts: 124K (17% increase from last week’s 106.3K)
  • Events: 1799 (crazy 50% jump from last week’s 1199)
  • Hosts: 493 (10% increase from last week’s 450)
  • Expected attendees: 76,200  (23% increase from 61,910)
  • Cities: 362 (40% increase from 260 – what caused this jump?)
  • Traffic: here’s the last three weeks. We continue to see the major boost from the snippet.
 

traffic

  • And the Webmaker user account conversion rate increased a bit further:
 

conversion

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

Engagement Strategy #1: PARTNER OUTREACH

We are learning a lot from the partner calls. Here are some of the most salient takeaways (borrowing from Amira and Melissa’s notes during Friday’s call):

Partner trends
  • Partners see value in badging their event mentors, speakers and volunteers as a form of appreciation. But there is a potential for those who receive the badges to have no idea who is badging them or what it means (lack of connection to MP). Opportunity: We need to better explain to people why they’ve received a badge and why they might want to create a Webmaker account.
  • Partners are doing things but we just haven’t captured them.  Opportunity: We need to offer real value to users in order to increase the amount of sharing/broadcasting/badging that happens through the site. 
  • Some people need way more training — Opportunity: this is where the event wizard might play a role; there also might be an opportunity to run TTT within certain orgs and spaces.
  • We need to clarify our value statement for partners. It may not be in  adding numbers to their events or traction to their programs/site, or getting press for non-Hive partners. Instead it may be in providing resources and curriculum. We can better segment partners into affinity groups (e.g. afterschool programs) and provide content, trainings, resources, CTAs specifically for them.  We can also localize those offerings to reduce hand-holding.
  • People don’t understand how broad our definition of Maker Party is: everyday events, small events, stands/booths/tables within other events — have to push them to realize that and include all of these on the events platform (note from HK: I would argue we have to offer them a reason to)
  • Opportunity: There’s the summer wave and back to school waves. We need to have strategies and actions towards both.
  • Challenges:
    • Age and time continue to be a blocker for new Wm accounts.
    • Mass emails to order swag, upload events, share information just didn’t work. They need 1-to-1.
    • We lost interest by a lot of people along the way. There’s a good 20-30% we will not be able to bring back in.
    • Parties sound like fun kid-like things (making toys etc.)
    • Getting the Maker Party logo/brand included in event promotion in a meaningful way is not happening, and the meaning behind the brand seems to cause confusion in some cases.

PROMOTIONAL PARTNERS: We continue to see only a tiny amount of referrals from promotional partner urls with RIDs.

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

Engagement Strategy #2: ACTIVE MOZILLIANS

Haven’t heard anything this week, but Amira and I are meeting with the FSA Community Manager on Monday of this week.

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

Engagement Strategy #3: OWNED MEDIA

Snippet Funnel:

The snippet funnel continues to perform well in terms of driving traffic. We’re aiming to beat a baseline 1.8% conversion rate.

We were a bit blocked by technical issues this week and weren’t able to release the new tailored account signup pages, but we continue to work on that.

The “hack the snippet” test was delayed, but will be live soon. We have a comms strategy around it (for after it’s been tested).

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

Engagement Strategy #4: EARNED MEDIA

Press this week:

Aside from a cross-post of last week’s Washington Post Magazine story (http://www.tampabay.com/news/business/workinglife/want-a-tech-job-what-to-study-in-a-fast-moving-field/2193050), we didn’t see press this week. We were focused on our Net Neutrality tweetchat instead.

SOCIAL (not one of our key strategies):

As expected, the Tweetchat temporarily increased our Twitter engagement for a two-day period—we saw double the usual amount of favorites, retweets, and replies. You can view the Storify here: https://storify.com/mozilla/net-neutrality-tweet-chat-from-mozilla-s-teaminter

The #MakerParty trendline for this week is back up to where it had been two weeks ago: 

trend

 

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

1/3 of a year

Four Months (just remembered this blog is for (H)an(n)a(h)grams, so: Fonts Humor)

I’ve been here for four months. I think the famous Mozilla firehose is finally starting to slow down. A main difference between me now and me three months ago is that now, on most days, I actually know how to do the things on my ToDo list. SuperBonus: I can usually follow what’s happening in meetings now!

Significantly, I’m starting to add things to my ToDo list that are more than just the bare minimum of program maintenance. I’m starting to understand where I might be able to innovate and add value.

About a month after I started, I inherited the job of maintaining @Mozilla social channels, and about a month after that, I inherited the job of managing the relationship with our Maker Party PR company. Together these things took up a good chunk of my time over the past two months, largely because they’re outside my area of expertise (I helped launch a social media program at my last job, but that was back when Twitter was brand spankin’ new, and things have changed tremendously since then).

While I think both of these tasks ended up providing me with a great platform for learning about the organization (I have to know what’s going on so I can tweet about it!), I am looking forward to focusing more intently on the aspects of the program manager job I feel I’ve been neglecting.

I Feel Good (I Do Elf Ego)

Some of the things I feel good about from the past few months:

  • I think the Maker Party engagement updates and analyses (some of which I’ve posted on this blog) have been helpful in sparking some good conversation at our daily “Peace Room” meetings. Also, charts make me seem smart.
  • Our Salesforce for Partners implementation is a tiny bit behind schedule, but I feel good about where we are in the process. I was glad to be able to take this partially off of others’ plates and share the burden, because no one should have to face Salesforce alone.
  • Working with Dave, Erika, Mavis, and Sabrina on the Advocacy site has been a pleasure, and I think the end product is going to be great.
  • Yesterday’s Tweetchat was pretty fun.

Can Do Better (rent taco bed)

Some things I want to work on in the months ahead:

  • I want to operationalize what it means to be a Clockmaster, and refine the suite of tools we use to manage our work. Now that we have Sprinter, I feel a lot better about Bugzilla (which, I admit, I headdesked about for the first couple months I was here). But I don’t think it fully meets our needs, so we’ll need to supplement with other tools and processes.
  • I want to help reduce the pain in our grant reporting process. Gettin’ paid shouldn’t hurt so bad.
  • I want to crack the nut of social media. I was inspired by a recent conversation with Michaela Smiley, and I believe we can do a much better job of engaging and serving our community, while also better expressing the Mozilla brand and growing the Webmaker community. Hashtag win.
  • I want to make sure Maker Party 2015 is even more full of awesome by capturing and acting upon our learnings from this year. In general, I’d like to help create a culture of reflection and continuous improvement. Not to get too existential, but isn’t this what life is about? </insight into hannah’s worldview>
  • I want to improve our systems for distributing knowledge across the organization. I’ve seen really good examples of this (Andrea’s email-fu workshop, the Fundraising workshops that happened a few months ago, Geoffrey’s trendlines workshop from this morning, and probably many more). I don’t think Encyclopedia BestPractica is working as a tool for knowledge sharing, so I’d like to come up with something that meets people where they are (rather than making them come find it).
  • I want to keep improving our cross-team collaboration. Even in my short time here, I’ve already seen great strides in this, but there’s more to do. This project brief template is one of my first direct efforts toward that, in addition to just building relationships with many of my super rad co-workers.

Finally, I just want send a big ol’ shout out to said co-workers for making my first third of a year so enjoyable.

Onward!

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.