Kill the triad — long live the TEAM
As with software development, the key to building a great team is continuous improvement. Our Co-CEO & Founder of Atlassian, Scott Farquhar, always says, “Great things don’t come from individuals, they come from teams.” Therefore, behind the scenes at Atlassian, we are constantly working on how our teams work better together.
And, like our products, we dogfood our Team Playbook to help guide us as we make these improvements, which can sometimes lead to some prickly discussions.
“Doing project retros isn’t enough. To build a great team, you have to dive into how people engage with one another and reveal areas that need more focus. You have to build a safe place to listen to feedback and come away with actions where everyone feels heard.” — Jens Schumacher, the Head of Software Teams at Atlassian.
With this in mind, Jens recently plucked his product leads from their homes in Sydney, San Francisco, and Austin, and shipped them to a destination that was far away from their daily distractions. The team of 20 included product managers, product marketing managers, and team leads, and the tasks ranged from discussing our three-year strategy, to messaging, to writing the rules for how we effectively work across geos.
Three’s company
During the week-long workshop, we ran two plays from the team playbook, Rules of Engagement and Roles and Responsibilities, followed by a retrospective on the year. During this activity, a theme arose that seemed to affect all of the other sticking points we identified: the triad needed improvement.
The triad comes from the Agile Manifesto principle that “business people and developers must work together daily throughout the project.” During waterfall software development, a single directive was set and then a project manager worked with developers to make sure that the work flowed downstream. In agile, continuous feedback from customers changes the kind of work that gets done. The triad was born as a response to this; where the PM (product manager), who has a constant pulse on the customer, works directly with the design and development leads, who are in charge of making the product. Our product development strategy is set by the traditional triad of product management, design, and development:
The triad exists to keep the circle of decision makers small, and an uneven number to break a tie. However, this requires each owner to be fully informed from all the various inputs they are meant to include.
Product managers would then work with product marketing managers to develop the go-to-market strategy for whatever the “Make” triad had prioritized in their roadmap. Product managers and product marketing managers are the main touchpoint between the “Make” triad and the “Sell” triad. So the relationship between the two is crucial, hence the offsite.
After this handoff, marketing would then build collateral for whatever the “Make” triad had identified.
But we realized that the conversation between PM and PMM was happening too late.
As you might have experienced as a marketer or product manager, once features are ready to be packaged, we often missed the chance to combine them into a single, compelling story. They might be solving for disparate customer requests, but collectively unable to address a market need. And both product and marketing teams struggled with how to fit them together to address a pain point that customers were hoping to solve.
The makeup of the triad, with marketing downstream, made sense at one point in time. Marketing hasn’t always been part of the customer feedback loop; once upon at time it was all about making collateral, putting out ads, and relying on gut and good taste to make decisions. But the role of marketing has evolved into a data-driven, customer experience machine. Today, the product experience begins at the Google Search Results Page, not just the signup form.
In fact, 93% of all online experiences start with a search engine (Forrester). And marketing owns the entire customer experience leading up to the “try now” button. The makeup of development teams has also evolved to be more cross-functional, smaller, and more nimble. The buyer journey looks more like a matrix of interactions, than a series of events — some interactions are tracked through marketing technologies, while others are captured in product analytics.
By informing marketing, analytics, and other inputs, after prioritization’s were already made, we were excluding a large part of the whole story.
The triad gets a makeover
Before we discuss the improvements we made to our triad, I think it’s important to talk more about the evolving roles of marketing, ops, and dev in a DevOps and agile marketing world.
Modern marketing doesn’t just build collateral anymore. Like product development, marketing gains continuous insights into how users are interacting with specific messages and content, and makes continuous improvements to the buyer journey. Sound familiar? The development of marketing materials, web experiences, content, on-boarding, email, and lead nurturing, are all about user experience design. Saying the right thing to the right person at the right time. UX in products is based on these same data points. Yet we aren’t sharing across the two.
Similarly, the Support & Ops teams are experiencing an inability to keep up with the features the “Make” triad is shipping, resulting in a massive pile up of features being blocked by infrastructure. DevOps as a cultural shift has developed in response to this trend in an attempt to break down the walls between the “Make” triad and the “Ops” triad. So why not on the other side?
Our triad model created a situation where in the “Make” triad worked closely, in the same geographical location, and relied on ancillary meetings to inform the “Sell” triad. But as a team, we knew we weren’t thinking end-to-end with this setup. There was a collaboration failure, something that couldn’t just be solved through tooling. So as in DevOps, we had to re-invest in the culture of collaboration across all the teams. And how do you that? Empathy.
Empathy for the win
During the Roles & Responsibilities play, I was paired with our product lead. I wrote what I thought she did, and vice versa. We had hung out all week getting to know each other, but when it got down to what we did, we both scratched our heads. The entire point of this exercise was to highlight this lack of empathy across the team. I realized that she was leading product for the entire team, not just one feature set, and she realized that I was leading content strategy, not just SEO. From it, we made a promise to continue to invest in our relationship and work together on our a shared strategy; to share insights from my pre-sign-up view across to her post-sign-up view.
This is the goal: Know what each member of the team outside of your triad does, and bring them in early for a collaboration, rather than a presentation.
Triad 2.0
We need to break down silos, open the lines for better communication across the team, while still keeping the core decision making group small. This will require that we think about the triad in terms of delivering value to our customers, not by job titles.
In re-evaluating our triad, we go back to the design thinking principles of Desirability, Feasibility and Viability. These three components should help us understand how our roles come in and out to make decisions. The idea is that it’s fluid.
Desirability — Do people want this?
Feasibility — Can we do this?
Viability — Should we do this?
Within each of those components, inputs from various parts of the business are not only crucial, but required. Desirability, for example, could be led by a Product Marketer who brings data from search and ads and content, in addition to customer input. Feasibility could also include marketing in that a new feature would be impossible to deliver to customers due to its complexity. It could also include Ops & Support. Viability could include Product Analytics, who could say that people aren’t using a certain feature anyway, and it’s not worth the investment. With more people included in the core triad, the responsibility lies with the team as a whole to make sure that value is delivered. And that’s where innovation lies.
Seagulling and other takeaways
One of Atlassian’s core values is “Open company, no bullshit”. Because of this, all our work and documentation is captured in Confluence and open for all to read. But with great power, comes great responsibility. Confluence makes it super easy to share your work across geos, teams, and levels. It also gives people permission to comment on everything. We call this “seagulling.”
Seagulling (verb): Where someone comes into your work, shits all over it, and then flies away.
When empathy within a team starts to erode, “seagulling” is a symptom. People feel compelled to comment on work they weren’t involved in but feel strongly about, often without context, cause a little ruckus, and then fly away. Habits like this chip away at the fundamentals of a strong, cohesive team. It creates an environment where it’s uncomfortable to be wrong, to try something new, or to simply misinterpret a data point.
As a team, we’ve outlawed this, dubbing “Seek first to understand” as a team value. In order for us to improve, we had to go back to the basics and reassess the rules in which we work together.
For example:
- Bring in product marketing during the development of Project Posters
- Have a monthly roadmap review that discusses progress towards our OKRs, not status updates
- Improve decision making with a DACI
- Change the “Make” triad lunches to include product marketing to continue to foster empathy
- Keep your requirements documents open; ask for marketing feedback
- Work towards a full-funnel view of the customer, from a Search Results Page to MAU
- And last, no seagulling
The reinvestment in team collaboration can happen at any time. But in order to make progress, you have to be willing to change what’s not working and try something new, without the fear of a bird pooping on your head.
Liked this post? Give it some love, and follow Smells Like Team Spirit — dedicated to making teamwork a better place, one story at a time.
