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.