We chose Agile because we forgot how to talk to each other

Many Marketing teams would benefit from killing off old power structures. Agile Marketing can help.

A few years ago the Mozilla Marketing department probably looked a lot like teams at comparably sized tech outfits. And it probably suffered from many of the same dysfunctions. Rigid functional silos with entrenched hierarchies battled each other for dollars and the CMO’s affection. Efficacy was all but impossible to prove and so time and resource arguments hinged on emotion and intuition rather that data-backed hypotheses.

As a service bureau for a 1000+ person organization that delivers critical software to hundreds of millions users around the world, the number of incoming requests for our time was staggering. Moreover, there was no obvious means to prioritize all these requests. With everyone in their own silos and not regularly talking to each other, who was responsible for making the call on what a given resource worked on today? Securing resources from multiple department heads was challenging given everyone’s busy schedules and competing priorities.

Power was often amassed and guarded by not sharing information with other marketing functions, and you can imagine how that might impact the quality of an end product. So here was what we might call Metaprinciple #1 for our Agile system: Design the organization to improve the frequency and quality of communication inside the marketing organization. If you also have this challenge, Agile might be a good fit for you too.

Prior to our evolution, the only solution for getting groups to work together on high priority work was to more or less get the entire 100+ person Marketing team to focus on one or two big “launch” events per year. We called these “Waves” or “Moments in Time.” These were old-school Marketing events — relatively big budgets, date-driven. They were exciting too; they gave the whole organization something to rally behind and they gave us all purpose. There were almost always cool billboards that our friends and families would see. They even produced some good results!

But we were effectively spending twelve months on two big bets. And the cycles were grueling. We’d spend six to eight weeks sprinting towards a launch date and then three or four months exhaling. It burned people out. And our productivity sank.

Enter the Durable Team

A big motivation for us to go Agile was breaking the existing power structures that inhibited communication and required frequent, expensive resource trading discussions between department heads. Plus we felt the drag of near-constant context switching as individual resources were shifted from project to project in a way that inhibited them from gaining deep understanding of a particular user or business issue. We imagined an environment where small teams would be formed around our most important priorities and then be given the freedom and autonomy to address them without having to manage through unnecessary resourcing debates or politics. And then we set out to build it.

We started from a few core principles:

• Teams that can work together, uninterrupted, for long stretches of time will exhibit increasingly strong performance
• Small teams are more efficient and better at communication
• Generalist skill sets will be more useful on small teams
• We’ll also need some specialization of talent

We called these groups Durable Teams because we believed so much in that first bullet. And a year later we have evidence that we’re right, but also a cautionary tale or two. The teams whose membership have been more stable display sophisticated levels of empathy and understanding, mature and frequent communications and better productivity than those whose rosters have shifted frequently. We wanted teams to have at least six months and ideally a full year working together so they could develop this kind of chemistry.

This has been much harder than we imagined because as we learned more about what worked in our Agile system we felt we had to make changes to teams to reflect that. Changing the makeup of a team is always a hard choice because it’s a little bit like setting the reset button on any banked chemistry. Teams have to integrate a new voice, share their norms and hope it all works out. This is time. This is energy. And for us sometimes it was worth that cost. With any luck the lessons here will help you avoid some of the things we did that forced us to make as many team changes as we did.

The next principle was team size. We’re big believers in the power of small groups — they can make quick decisions, learn how to work together quicker, and have to spend less of their time getting people on the same page and managing through the messy human stuff that arises when you put adults together and ask them to figure stuff out. Of course there are tradeoffs.

Some of that messy human stuff is creativity, inspiration and genius. And when you limit the number of voices on a team you do lose the opportunity for some amazing things to happen to. Mozilla is an organization that believes to its core in open source ideals that say more voices on a problem can lead to a better solution and we know that’s sometimes true. Still we felt like teams of 5–7 offered the best balance of diversity of thought and real agility.

And this is where things get particularly sticky for many marketing teams who decide to try Agile. How do you choose which 5–7 people to put on a team? Which skill sets do the teams need? How do you support the Durable Team with external resources? Why does this model seem so much easier in product development organizations? We’ll dig into all this and more in upcoming posts.

Images courtesy of Rick Pinchera Illustration and Design