From the outside, working on a marketing team looks pretty straightforward. You get a few creative minds together, come up with some clever ad copy, rent a few billboards, post a few tweets, then boom! You sit back and wait for the sales to roll in.
Yeah, no.
Marketing in the age of the internet (which also remains the age of print, radio, and television, mind you) is a complex, multi-disciplinary endeavor. And the complexity is only amplified as you grow. Today, our marketing department alone is bigger than the entire company was when I joined almost nine years ago. At this scale, nothing is simple.
The challenges we’re facing as a marketing department are fundamentally the same challenges teams in Finance, Customer Support, IT/Ops, and Engineering face as they grow. With so many moving parts, you have to have some kind of structure or you’ll never get your best ideas over the finish line. The trick is not getting too formal – as we found out.
In times past, Atlassian Marketing operated largely on personal relationships and handshake agreements. Our company president at the time, a former marketing leader himself, aptly described it as “building the plane while you’re flying it.” We delivered good work, but the tang of precariousness in the air was unmistakable. While those who lead marketing campaigns were able to work effectively enough, those with high-demand skills were overcommitted and overworked. Clearly, that wasn’t sustainable.
As our headcount expanded, we got serious about how we organized our work. Maybe a bit too serious, in fact. Processes designed with the best of intentions became burdensome. Campaign leads were requesting support from designers, developers, email marketers, etc., months in advance because there was so much demand for these core skills. “We were getting in our own way,” recalls Nirali Shah, our lead program manager. “It took us six months to ship a new product tour, for example.” Clearly, that wasn’t agile.
Enter the pod
We had to make a change if we wanted to stay competitive in the fast-paced world of tech, and nobody was more aware of this than Nirali and her team. They looked back at past projects, talked to peers in and outside of Atlassian, and before long, pitched our marketing leadership team on the idea of trying a “pod” structure.
Pods are a variation of the classic cross-functional agile team. They’re nothing new, but they’re not especially common even in engineering departments – let alone in non-technical teams.
But let’s take a step back. To understand the value of agile pods and whether they could benefit your team, it helps to understand the headaches we were trying to cure.
The challenges we face as a marketing department are fundamentally the same challenges any team faces as it grows. With so many moving parts, you have to have some kind of structure.
More marketing, more problems
We are a team of 500+ energetic marketers who come up with thousands of great ideas for our portfolio of over a dozen products (not to mention our corporate brand). And like most successful organizations, we bias toward running lean. That means the competition for resources is real. Even when you’ve secured time from the people who can bring your idea to life, organizing the work is tricky. Dependencies abound and bottlenecks lurk around every corner. Priorities shift according to what’s happening out there in the marketplace.
Fortunately for us on the Atlassian marketing team, we have Nirali and her team of program managers – the unsung heroes of our department – helping to keep this ship cruising full speed ahead. That doesn’t mean it’s always smooth sailing, though.
A typical marketing organization includes email strategists, social media strategists, data scientists, designers, web developers, writers, ad buyers, and events specialists. Many larger organizations like ours also include brand strategists, localization experts, product marketers, and public relations professionals of various stripes. Staying effective at this scale and level of complexity means you have to find your “Goldilocks zone” – not too loosey-goosey, not too rigid. Anything outside that zone is a recipe for disaster.
Too-long planning cycles
Before pods, each customer-facing team, e.g., editorial, Jira product marketing, Atlassian Community, would be allotted a certain chunk of time each quarter from internal-facing, central-services teams like Design. Roughly four weeks before the beginning of the quarter, requesters would have to get their requests in (in the form of Jira tickets, natch). Requesting teams would prioritize their tickets in advance so central teams could review them, scope them, and estimate the amount of effort each one would take.
Let that sink in for a moment.
If you wanted to ship a campaign landing page in June, you had to request the work – fully conceptualized – in early March. Which means you had to have been thinking about it since some time in February. Your chances of responding to cultural phenomenons or world events in less than a few months were, uhh … slim.
Central teams would then come back and tell the requesting teams which requests they could take on in the coming quarter. It was far more transparent than before, and our designers’ and web devs’ work-life balance was better protected. But the whole system, as well-intentioned as it was, turned out to be inefficient.
Tickets, tickets, tickets
We devolved into a ticket-centric culture instead of a conversation-centric culture (oops!). Nothing happened without a ticket, which kept work organized and manageable, but nobody liked it, per se. It felt severe and inhuman – as if our inner Nurse Ratched started running the show while we weren’t looking. Eventually, requesters were raising tickets for even the most nascent ideas, just to get a toe-hold on someone’s time. Tickets were “thrown over the wall” (dev vs. ops, anyone?), often with little or no discussion to provide context.
Members of central services teams began to feel like short-order cooks instead of the elite chefs they were hired to be. They craved the opportunity to spar with the requester early on but were brought into the process at a point that felt “too late” to reshape the idea. Simply put, we weren’t delivering the best work of our lives.
How marketing pods are structured
Organized by work stream or deliverable, each pod includes three types of members: core members whose time is fully (or mostly) dedicated to the pod, part-time specialists who may be members of multiple pods, and leaders responsible for prioritizing the work and interfacing with the rest of the business.
Like many companies, Atlassian uses the Objectives and Key Results (OKRs) framework for setting company-level goals that then cascade downward into department-, team-, and individual-level goals. So aligning pods to each of our department-level objectives is a natural fit. We have a pod focused on attracting and retaining enterprise customers, a pod focused on the DevOps space, and so on.
Each pod has three core roles:
- Executive sponsor – responsible for overall planning, plus liaising with teams and executives outside of the marketing department.
- Driver – responsible for crafting campaigns and leading initiatives, as well as short-term planning and prioritization.
- Program manager – responsible for managing dependencies and balancing the load of the pod vs. the non-pod work on each specialists’ plate.
These people are (for the most part) members of only one pod.
Then, based on the pod’s specific objectives, it may also include some combination of: web developer, designer, SEO specialist, brand specialist, analyst, or email specialist. These people may be dedicated to multiple pods. For example, there are two brand specialists spread across five pods. Conversely, there might be multiple people in the same role dedicated to a single pod – our eight pods involve a total of twelve designers. (Yeah, we like art.)
In other words, there’s a lot of mixing and matching. It allows for a ton of flexibility and is actually less messy in practice than it sounds on paper. “You can dial the urgency up or down so quickly with pods,” Nirali says. “The team is already established and knows what they’re doing, so they can be all systems go on a moment’s notice.”
At the outset of the experiment, leads from the central teams, program managers, and executive sponsors got together to figure out how much capacity from each team would be dedicated to each pod. This involved some homework on the part of team leads. They had to weigh their teams’ business-as-usual workload, as well as any special projects or goals on the horizon, against what the pods would need in terms of capacity.
Everyone was operating on educated guesses and thoughtful estimates, so it was important to stay flexible and keep an open mind as all this was negotiated. And because external factors could suddenly change the scope of work, or move timelines around, there was also an agreement that we could have to temporarily adjust the amount of time allocated to pods.
Once everyone agreed how much time each pod would get from the specialists they needed, it was then up to the pod lead to determine how that time would be used. Now, most pods run two-week sprints so they’re aligned with the cadence our web development team had already established. Our design team has since started planning bi-weekly as well for even stronger alignment across the department.
So … how are pods different from other flavors of agile marketing?
The difference lies not so much in how work is planned and tracked, but in how people are organized. Although agile methodologies emphasize (even idealize) cross-functional teams, they are not strictly required. A “nuclear” team – that is, a team of people who all report to the same manager – can practice iterative planning and slice their work into one-week sprints even if everyone on the team has similar job roles. (This is exactly what our design team does, by the way). Similarly, an email marketing team can organize their work kanban-style.
By contrast, the way we’ve organized pods is highly cross-functional. The whole point is to have people from a variety of disciplines dedicated to the same project at the same time, thus all but eliminating bottlenecks and making dependencies easier to manage. A typical pod member spends some (or most) of their time on pod work and the remaining time on business-as-usual work with their nuclear team.
But, you might ask, isn’t that a distinction without a difference? Fair question. The difference is that, in this system, time for pod work is immutable and everything else has to fit in around it. Without the shared understanding we have around pods, things would be the other way around, with your nuclear team’s work taking priority and work on special projects sprinkled in at the margins. It’s a subtle-but-thrilling shift in mindset and priorities across the department.
How do you know if it’s working?
The pods have been doing their thing for a couple of months now. Hopes are high but tempered with a healthy dose of realism. Because let’s be real: we’re trying to solve a whole lot of challenges with just one (albeit major) change, and everyone is looking to get something different out of it.
For development manager Mike Heimowitz, pods promise more opportunities for focus – both for him and his team members. “I’ve assigned people from my team to each of the pods, which means they can represent our team in meetings and free me up to work on big-picture issues,” he says. Meanwhile, his team members are poised to become strategic partners for the pods they’re involved with instead of just executing on tasks.
Meanwhile, pod leader and product marketer Justine Davis is hopeful that she’ll be able to plan marketing activities around agile and DevOps with less overhead. “Before, we had to strategize for an entire quarter at a time, often without really knowing what other product marketers would be requesting from the central teams,” she recalls. “So then all the product marketing leads would meet to decide which projects were highest priority overall, and shift resources around.” With the increased control and autonomy that come with pods, much of that hassle should disappear.
You can dial the urgency up or down so quickly with pods. The team is already established and knows what they’re doing, so they can be all systems go on a moment’s notice.
The opacity that dogged Justine and her fellow product marketing managers is one of the things Nirali and the program managers hope pods will improve. “There’s a lot of reporting involved,” she admits, “but because of that, we’re already getting visibility into each pod’s metrics, successes, and dependencies.” She suspects that improving visibility will reduce blockers and increase the department’s overall throughput.
She’s not tying the experiment’s success to metrics like velocity, however. “We went back and forth on that and ultimately decided it didn’t make sense because it’s too easy to fall into the trap of churning out busy-work if you’re measuring outputs,” she says.
Instead, they are looking at qualitative measures. Do pod members feel engaged? Do they have more time for the most meaningful work? Are they achieving better outcomes with fewer headaches? If pods are able to bring about these changes for our department, Nirali hopes it can give marketers at other companies the confidence to try something similar.
And, is it working?
So far, so good. But it’s still early days.
“It took time to organize ourselves and, honestly, the shift was really hard for some people”, Nirali says. Now, with the first round of readouts from each pod underway, some positive signs are emerging. One pod that struggled especially hard at first seems to have found their rhythm and, according to Nirali, they’re jamming.
“I really have no idea what’s going to happen, which makes me anxious,” she confesses. “We’ll definitely iterate on the whole structure and process, but I’m committed to giving it a few quarters before we think about throwing in the towel and starting over with something new.”
As for the rest of us on the Atlassian marketing team, we’ll be watching and cheering from the sidelines. Keep an eye out for updates here on Work Life as our group of intrepid agilists continues their journey and shares the lessons they learn along the way.