The Opposite of Play Is Fear: How Jira's Head of Product Builds Safe, Fast-Moving Teams

Cook says she noticed warning signs on her product team as the tech industry hit a period of high ambiguity: junior people were reluctant to speak up, feedback was increasingly anonymous, and work reaching leadership was "painfully polished." By the time work is that refined, she argues, it is a bad moment for feedback, because a lot of effort may be wasted if direction has to change.

At a leadership event she heard Ben Crowe, a mindset coach who works with Olympic gold medalists and tennis star Ash Barty, explain that a flow state needs a sense of play. The surprise for Cook was his claim that the opposite of play is fear rather than work. That matched what she saw: ideas were getting more incremental because people were afraid.

She concluded the team needed to work on psychological safety or it would never reach the bigger, more innovative ideas. She brought her product managers together to brainstorm practices, and the group co-designed the ideas that she then describes in the rest of the conversation.

The first practice was splitting the PM team into smaller peer feedback groups that meet roughly every two weeks. Someone brings a rough draft, whether a strategy, an experiment or a new experience, and everyone is expected to help lift it up. Because the groups mix leadership levels, senior people model what helpful feedback looks like, and repetition turns a stressful quarterly event into a familiar habit.

Every six months the PMs also gather in person, in Sydney, starting with something fun before moving on to strategy and craft workshops taught by outside experts or by team members with relevant strengths. At the most recent gathering, senior leaders from across the company shared their own stories of failure, to normalise taking big swings and treat good learnings as worth celebrating. Cook notes that as a leader it is important to model the behavior you want to see.

She says the loss of openness started to show at around 15 product managers, once people were working on very different streams. A newer experiment is the $10 game applied to personal priorities: you and your manager divide ten dollars across your priorities to show where your time really goes. It has revealed overloaded people and mismatches between priorities and the work that moves the business.

Atlassian became remote when COVID hit, and calls its approach Team Anywhere: staff choose where they work, and flexibility is treated as something that changes people's lives rather than a perk. The company recently published a guide of lessons from about a thousand days of remote work. Cook says its research found that bringing people together intentionally boosts connection and productivity by about 30% for months, so her team meets in person around four times a year, including week-long gatherings that mix desk work, workshops and a social "festival."

Her second tip is to be deliberate, because early on everyone filled calendars with meetings to replace the lost chance to poke a head around a monitor. PMs need creative time, and Cook notes that deep work takes three to four hours, not gaps between 30-minute meetings. Her leadership team syncs calendars for two long blocks a week, one morning and one afternoon, and she keeps spare room for direct reports who need an unplanned hour on a hard strategy problem.

Because meeting time becomes precious, she insists meetings exist to solve problems while status updates are read asynchronously, using Atlassian's Atlas tool and well-documented decisions in Confluence. For teams spread across Australia, the US and Europe, short recorded audio and video messages have become close to a new document type, a big reason Atlassian bought Loom. Casual video conveys tone and can sit at the top of a document to explain it.

Cook says people often ask how to get buy-in with a date and a perfect proposal in mind, and she thinks that attitude is already wrong. Her example was changing how people start in Jira with more templates, which touched four products built on the platform. Her team took the idea and early designs to every affected product team and returned repeatedly as data and designs developed.

The same applies at the executive level: a CTO, a chief marketing officer and a head of design each see different risks, so meeting them while the idea is clear but not fully fleshed out lets you fold in their concerns. Those people then tend to advocate for you in the final meeting. Cook adds that you should focus on the problem or opportunity and stay open to ending up somewhere other than your preferred solution.

To avoid only pretending to be open, she suggests stating what you know, what is hypothesis, and how you plan to prove or disprove it. Coming in exposed, she says, builds credibility because no one expects you to predict the future. Her own example was an acquisition she badly wanted; after taking it to her boss and the head of engineering, he pulled in people from across the company with the missing knowledge, making an in-house route possible.

For the meeting itself, Cook recommends saying up front what you want from the group, whether a decision, feedback or help testing a shaky assumption. She suggests a brief narrative of the situation, what changed and the implications, and choosing the key data points for busy executives while knowing the detail underneath.

Cook describes a push to improve customer satisfaction (CSAT) that began about two years earlier when Atlassian's chief experience officer asked her to look into it. Even with a request from the top, funding was not automatic, because improving existing features is not the exciting new thing. Survey feedback showed usability was a core reason for low scores, and customer conversations, while painful to watch, were rich.

She built a business case: hard-to-use products lengthen ramp-up for new customers and slow new users inside existing customers, which hurts both acquisition and expansion. Many fixes depended on platform teams with conflicting roadmaps, so aligning them was nearly impossible. Instead each team nominated a shepherd to review designs and code changes, giving a low-cost way to help without bearing the development load.

She credits the head of design's mantra of show, don't tell: designs of the new experience and video of customers struggling brought an emotional charge that got people excited. They started small, with about 40 people, kept regular updates going, and shipped visible wins including dark mode, which required company-wide coordination. Cook says a customer recently called one change the best quality-of-life improvement in a long time.

Lenny summarises the lesson as staying small, making things visual and visceral, doing the work for other teams, showing real data and keeping it scrappy. Cook agrees that a small start does not feel like a big bet, so it becomes a way to prove direction and earn more investment.

Atlassian now has 15 products, and Cook says it did not get the first right immediately; it has had many attempts. Jira software began in 2003 as a humble bug tracker and survived shifts such as agile and cloud. Today just under half its users are developers, with the rest in support, sales, marketing, finance, design, HR and legal.

Those non-software teams were cobbling together their own Jira setups, which the company took as a strong signal that they wanted more. That led to Jira Work Management, focused on use cases outside the software team. Cook says the real advantage was a signal from customers in an area where Atlassian was already well placed to help.

Her second example, Jira Product Discovery, came from an internal program where anyone can pitch a product idea. Product manager Tammy Carson saw that PMs needed somewhere to shape roadmaps before ideas became committed work, since putting them in Jira made everyone expect delivery. Rather than run it through processes tuned for large products, Atlassian used small teams and stage gates called wonder, explore, make, impact and scale, with a little more investment at each step.

At wonder it is often one person with an idea; at explore it grows to about three people building a prototype with interested customers; at make it becomes a full team of roughly twelve. Impact means the product can sustain itself on its revenue, and scale is the full launch. Cook says Product Discovery, Atlas and, most recently, Compass have gone through this staged rollout.

Cook's advice for seeding a second product inside a large company is to start with a small idea and a small team, resisting the urge to throw four or five teams at it. She also says to give the team freedom to move fast and skip quarterly planning and business reviews while it proves product-market fit. A new product should not be held to the resilience standards of something used by millions, or it will be slowed down too much.

That freedom also pays back. Because the Product Discovery team tackled problems differently, its spreadsheet-like view of ideas is something Cook expects to pull into Jira software. Asked why Jira stays ahead of constant challengers and complaints, she points to the size of the problem it solves, with more than 125,000 customers including NASA's Mars rover team and Canva.

Customer obsession is built into rituals: a weekly company-wide email of random customer feedback, shared research, in-product feedback, social channels and a community space. Beyond that she lists hackathons where the whole company stops, a carved-off team to explore AI after ChatGPT, investment in seeding future businesses, and a willingness to move hundreds of people quickly, as with the 2020 cloud push. Atlassian also kills things quickly, as with a standalone whiteboard product that became a Confluence feature.

For Failure Corner, Cook describes a failure that was hard to spot. While improving how Atlassian products help developers, her team noticed developers forgot to update work status after switching to code, causing confusion and skewed metrics. They built automation so that, for example, creating a branch would move an issue to in progress without leaving the IDE, and it shipped and worked fine.

Her mistake was not realizing that automation could be used by many people besides developers and in every product. Years later Atlassian acquired a company that did exactly that, and she notes how expensive an acquisition is compared with building it. Now she asks of every idea whether it could be ten times bigger, apply to more users and products, or change where it might go in three to five years.

She closes with Fight Club, a 30-minute weekly meeting among her, her engineering lead and her design lead where they know they are there to have a conflict. Putting difficult conversations in a dedicated slot stops them growing and helps conflict-averse people engage. Cook says the relationship among the three is much better because they tackle issues early.

In the lightning round Cook says she sends books to her reports every year, most often Inspired by Marty Cagan to new PMs and Scaling People by Claire Hughes Johnson to managers. She is binging the TV series Foundation and enjoys its idea of clones of an emperor stretching out a single mindset across human life.

Her favorite interview question is about a candidate's biggest failure. It reveals how introspective they are, whether they are vulnerable, what they count as a big failure, and whether they show a growth mindset. She has noticed that many of her best hires had big failure stories they worked through, and the answers show whether someone forges alone or draws on a community.

Her life motto is maximizing joy: finding what matters and leaning in, or turning something annoying into something enjoyable, such as replacing lost keys with a fingerprint reader on her front door. She also keeps friendships alive by meeting friends whenever either travels to the other's continent. Her surfing tip is simply to keep going out, often with an accountability buddy, because you have to feel the sport before you can do it.