I first came across PETALS at a previous company, where Si, our engineering manager, had come up with a simple way to check in on how the team was doing. We were a close-knit, remote-first team, yet even there, we had blind spots around wellbeing and personal growth. Spending five to ten minutes on PETALS at the start of a retro surfaced things we weren't seeing in our delivery metrics. A low score on one petal was usually the start of a conversation the team needed to have anyway.
PETALS is a team health check built around five feeling factors: Productivity, Enjoyment, Teamwork, Learning and Serenity. They are drawn as petals on a flower, giving us a quick view of how the week felt and a starting point for discussion.
These days I contribute to the PETALS app. As AI tools and agents change how we develop software, I want to understand what that means for the people doing the work. Recent research from Model Evaluation and Threat Research (METR) and DevOps Research and Assessment (DORA) gives us useful evidence to consider, both about productivity and about the experience of working in a team.
What delivery measures leave out
In DORA's 2025 survey, 17% of respondents belonged to the “constrained by process” profile, where stable systems coexisted with high burnout, high friction and low impact. Technical stability alone did not give a complete picture of their working experience.
The report surveyed nearly 5,000 professionals, around 90% of whom reported using AI at work. Eight of the ten outcomes DORA tracks showed an association with AI adoption, including throughput and individual effectiveness. Burnout and friction did not. These are self-reported comparisons across respondents, rather than measurements of how the same people's experiences changed over time. DORA suggests that burnout and friction are closely tied to organisational processes and culture, which individual use of AI may do little to change.
There was an encouraging finding about authentic pride: greater AI adoption was associated with greater pride, with the analysis suggesting a link through time spent on work people considered valuable. That connects with the conversation around Enjoyment: what work did people feel good about, and what made it satisfying?
What feeling productive tells us
METR's early-2025 experiment found that experienced developers took 19% longer with AI on codebases they knew well. Participants nevertheless overestimated AI's effect on their task completion time by around 40 percentage points on average.
Its later experiment suggested speedups for both returning and newly recruited developers, but both groups' confidence intervals included no effect. Selection problems also made the results difficult to interpret: some developers would not participate without AI, and others withheld tasks where they expected it to help most. Concurrent agents complicated recording time spent on individual tasks. These difficulties do not invalidate the earlier finding for the developers, tasks and tools studied, but they limit what we can conclude about how the effect has changed.
Speed and value are different questions too. In METR's 2026 survey of 349 technical workers, the median self-reported speed gain was about 3x, while the estimated gain in work value was between 1.4x and 2x. AI can make previously costly tasks worth attempting. METR calls these Cadillac Tasks when people undertake them because AI makes them cheap and the speed gain substantially exceeds the value gain. They can still be worthwhile; the time saved does not translate directly into value gained.
For me, the Productivity petal has always been about whether I felt able to make progress. That is different from estimating how long the same work would have taken without AI. The score gives us a way to discuss what helped or got in the way, alongside looking at what we delivered.
How the workload changes
DORA found an association between greater AI adoption and increased delivery instability. It found no evidence that adoption weakened instability's harmful relationships with outcomes such as burnout and product performance. A team could be delivering more while also spending more effort dealing with things going wrong.
Its 2025 report also suggests that some friction may shift from writing code to deciding what to ask for and checking results. One developer interviewed described stakeholders expecting more work in less time because of AI. DORA's 2026 return on investment report discusses the verification tax: the effort required to review AI-generated code. Through Serenity, we can ask how that workload feels and whether expectations leave enough time to check the work.
Learning deserves attention too. Matt Beane, writing in the DORA report, describes how developers learn through shared problem-solving, with senior colleagues passing on knowledge that is difficult to document. His research raises a concern that automation can reduce those opportunities when experienced people can complete the work themselves. When discussing Learning and Teamwork, I would want to know whether people still get opportunities to work through difficult problems together and feel they are developing their skills.
Making room for the conversation
A Serenity score does not measure burnout in the same way as DORA's multi-item scale. What PETALS offers is a regular opportunity to explain how work feels and discuss what the team could change. Following the team's experience over time also fits DORA's advice to compare a team with its own past performance rather than against a benchmark.
That brings me back to what I valued in those retrospectives. A low score gave us a reason to stop and understand something about our working week that we might otherwise have missed. The research gives me more reason to keep making room for that conversation as our tools change.
At your next retrospective, try a PETALS snapshot and leave time to discuss the scores. What made work easier or harder this week, and what would the team like to change?