Gustavo's newsletter landed in my inbox this week with a phrase that's been rattling round my head since: conversational debt. His framing is simple and a bit uncomfortable. Every crucial conversation your team avoids, or handles badly, doesn't disappear. It compounds, like a loan you keep not paying off, until the bill comes due at the worst possible moment.

Gustavo splits it into three flavours:

1. Alignment debt - when people nod along in a meeting but walk out with three different understandings of what was agreed.
2. Belonging debt - when speaking up starts to feel pointless or even disloyal, so people quietly stop trying.
3. Collaboration debt - when decisions don't actually land anywhere, nobody owns the outcome, and the same problem gets rediscovered a few weeks later.

None of that is abstract to anyone who's run a team health check. It's the exact thing PETALS is trying to catch before it compounds. So I want to take two of the patterns Gustavo calls out and run them through two hypothetical teams, to see where psychological safety actually intervenes, and where it doesn't.

Two teams, same organisation, different debt

Picture a mid-size product company running two engineering teams against different OKRs, in different offices, each with its own product manager.

🗺️ Team Atlas has nine engineers, working out of the larger office. They're carrying three concurrent projects with long delivery times, the kind where a quarter can pass before anyone outside the team can see whether a bet paid off. Meetings are well attended, decisions get discussed at length, and on paper the team looks fine.

🪁 Team Kite has four engineers in the smaller office, down from six after two people left in the same quarter and weren't replaced. What used to be spread across six people is now carried by four, and the backlog hasn't shrunk to match.

Same company, same framework, two completely different flavours of conversational debt building underneath.

🗺️ Atlas: alignment and collaboration debt

At nine people, Atlas sits above the point where group dynamics start working against honest conversation. Google's Project Aristotle research found psychological safety was the single biggest factor separating its highest-performing teams from the rest, more than who was on the team. Above a certain size, that safety gets harder to sustain, because the more vocal people naturally dominate and quieter ones learn to hold back.

Gustavo's first sign shows up here almost exactly as he describes it: the people who used to push back in planning have gone quiet. Not because they agree now, but because raising a concern stopped changing anything, so they stopped raising it. That's belonging debt, and it's easy for a lead to mistake it for the team finally getting aligned.

The deeper problem for Atlas is collaboration debt. With three long-running projects and long feedback loops, decisions in planning get discussed, half-agreed, and then quietly revisited a sprint later because nobody was totally sure who owned the call. McKinsey's research on decision effectiveness found this kind of "decision decay" costs a typical Fortune 500 company around 530,000 days of management time a year. Atlas is a much smaller version of the same failure: agreement in the room, but nobody actually holding the decision once the room empties.

Gustavo's own research backs up how common this is: his Forward Talk study found 71.2% of executives admitted to disagreeing internally while agreeing publicly. Atlas doesn't need more meetings. It needs someone asking, before the meeting ends, "what are we agreeing to, and how does it change what you're doing on Monday?"

🪁 Kite: belonging and collaboration debt, from a different angle

Kite's problem doesn't look like Atlas's on the surface, but it's the same underlying failure to have a conversation that needed to happen.

After the two departures, the honest conversation was "we're carrying too much with too few people, and something has to give." Nobody said it out loud. Partly because a team of four doesn't want to be the one asking for help when leavers already made headcount a sore subject, and partly because everyone assumed things would settle down once the backlog cleared. It didn't.

This is belonging debt wearing a different mask; not people staying quiet because dissent gets punished, but because admitting you're underwater feels like admitting you can't keep up. The team's PM, sitting in a different office to the wider leadership team, doesn't see the day-to-day strain directly, only the missed dates. Without a deliberate channel for it, the actual cause never reaches the people who could fix it.

That silence has a cost that shows up in stress and burnout, not just delivery dates. CIPD's Health and Wellbeing at Work report found UK employees took 9.4 sick days on average last year, up from 7.8 in 2023, with weak wellbeing and feedback cultures named as a driver. A team that's quietly overloaded and not saying so is exactly the pattern that report is describing.

Where PETALS actually catches this

PETALS measures team health across five factors, Productivity, Enjoyment, Teamwork, Learning and Serenity, each scored regularly rather than surfaced once a year in an engagement survey. That cadence matters more than any individual question, because conversational debt is, by definition, a thing that builds quietly over weeks. A framework that only checks in occasionally will always be measuring the debt after it's already compounded.

For 🗺️ Atlas, Teamwork and Productivity are the petals that would move first. If the same people who used to challenge decisions start scoring Teamwork lower, or scores stay flat while the written comments get shorter and less specific, that's the early version of Gustavo's "your most vocal colleagues stop fighting" sign. Catching it in a snapshot means a lead can go and ask about it directly, rather than discovering it three sprints later when a decision unravels.

For 🪁 Kite, Serenity is the petal that would flag first, and probably weeks before anyone said "we're understaffed" in a meeting. A consistent dip in Serenity, especially concentrated in two or three people rather than spread evenly, is exactly the kind of signal that's easy to miss in daily standups but hard to miss in aggregated snapshot data. It gives Kite's PM something concrete to raise with leadership, instead of a vague sense that the team seems tired.

Neither example works if the psychological safety underneath it is missing. A snapshot only surfaces honest answers if people believe honesty won't cost them something. That's the same conclusion CIPD's evidence review on trust and psychological safety reaches: in psychologically safe environments, people are more willing to share views or admit mistakes without fear of punishment. The measurement tool and the safety it depends on aren't separate problems, they're the same one.

The debt doesn't clear itself

Gustavo's closing point is the one worth sitting with: teams don't choose conversational debt, they just don't notice they're taking it on. 🗺️ Atlas didn't decide to stop challenging decisions, and 🪁 Kite didn't decide to stay quiet about being short-staffed. Both drifted there one avoided conversation at a time.

What a regular health check changes isn't the conversations themselves, it's how early you notice they need to happen. Whether that's a lead learning their team has gone quiet, or a PM in another office finally seeing why delivery's slipping, the value is the same: catching the debt while it's still small enough to talk about, rather than after it's already due.

This is the kind of thing our newsletter subscribers hear about first. If you'd rather get product updates and insights like this straight in your inbox instead of waiting for the blog, subscribe below.

Dev-time is our Thursday evening ritual, whoever from the team can make it, usually three of us, sometimes fewer. This week was a proper quiet one, less "here's a feature," more "here's what I've been messing about with." Still worth sharing.

The marketing site just got a Lighthouse glow-up

Quick one first: the accessibility and performance work on this site went live right before we sat down. Colour contrast across buttons, muted text and the goldenrod accent now all meet WCAG AA (4.5:1), nav toggles have proper ARIA labels, and a batch of oversized images (including 86 "trusted by" logos) got compressed and converted to WebP.

Lighthouse CI now runs on every push too, so accessibility and SEO regressions fail the build instead of quietly slipping through. Net result: accessibility scores jumped from the low 80s to 95-96 across the key pages, and the blog listing's performance score went from 82 to 90 off the back of one hero image fix alone.

Small, unglamorous, exactly the kind of thing that's easy to keep putting off. Glad it's done.

An idea that didn't work (but was worth trying)

I'd been sat on an idea since a swim the previous Monday: what if a PETALS score wasn't just colour-coded from red to green, but the size of the shape changed too, better score, bigger flower.

I mocked it up, played with a couple of variants including an animated version, and, well, it doesn't really work. The number on the flower still needs to be readable at every size, so a low score just ends up as a tiny illegible blob. Briefly tempted to go 3D and "make it really wow, in your face," then got bored, which is probably the right instinct.

Not every idea makes the cut, but it's the kind of thing worth throwing around out loud rather than sitting on.

What everyone's been building on the side

The rest of the session turned into a bit of a show and tell for personal projects, and there's a proper theme running through them: agents quietly doing the boring bits so people can focus on the interesting bit.

• Turning personal OKR tracking into a habit-card system, then pointing Claude at a pile of notes and asking it to pull out anything that sounds like an action, straight onto a to-do list.
• A Bluetooth treadmill controller that takes plain English ("5 minutes at this speed, 10 minutes at that incline"), turns it into JSON, drives the treadmill, and logs everything back to Apple Health.
• Setting Codex loose overnight with computer use, and waking up to an email from Apple saying the app was ready on TestFlight. Unattended, start to finish.
• A watch app called Just Pace that changes colour and gives haptic feedback depending on whether you're ahead or behind pace, with audio feedback via AirPods next on the list.
• An old Nike+ idea revisited: generative "soundtrack to life" music that shifts based on what's actually around you (a lake, a busy road, open countryside) pulled from OpenStreetMap, rather than a fixed playlist.
• Nib, a voice-note app for capturing a thought mid-swim or mid-drive that gets synced and interpreted automatically, no fumbling for a phone required.
• A neat Shortcuts trick built around What's Overhead: share a Google Maps pin, it grabs the lat/long and drops a geofenced Reminder, handy for "get off here" on a train in a country where you don't speak the language.

And a proper throwback: the BBC R&D team once built something called CAKE, a cook-along video where ingredient quantities and timers lived as HTML overlays on top of the video itself, scaling automatically to however many people you were cooking for. There's a genuine itch to vibe-code a modern version of that.

None of this is PETALS roadmap, and that's rather the point, a healthy side-project habit across the team is a good sign in itself. More on the ones that stick around soon.

Atlassian's "Inside Atlassian" newsletter has been on an AI kick lately, and one line from a recent edition stuck with us: nearly half of knowledge workers say their AI knows about as much about their company as a brand new hire, at best. Feed it real context about how your team actually works and it produces up to 48% more output you can use without revision.

That framing is doing a lot of work. A new hire isn't a friend or a foe, they're just new. Keen, occasionally overconfident, and only as useful as the context you've given them. Sound familiar? It's basically how most of us are using AI right now, minus the induction.

The AI Play/Pause experiment

Atlassian ran a nice piece of research to test how deep that reliance actually goes. 123 Atlassians did an "AI Play/Pause" day: one workday using AI as much as possible, one workday with none at all.

On the AI day, priority work felt 44% easier and stress was 22% lower. On the no-AI day, 82% of people felt the urge to reach for it anyway, and 23% did without even thinking. That's not really a productivity story, it's a habit story. And afterwards, 89% of teams said they came out with a clearer shared sense of when they should and shouldn't be using it.

That last bit is the interesting part. Not "should we use AI", but "do we actually agree on when we should." Most teams have never had that conversation out loud, they've just each landed on their own answer separately.

The fragmentation tax

The other Atlassian stat worth sitting with is from their 2026 State of Teams report: 89% of executives say AI has sped up individual work, but only 6% can point to specific, organisation-wide examples of AI ROI. They call the gap the "fragmentation tax", the coordination cost of everyone getting individually faster in slightly different directions. Estimated at $161 billion a year across the Fortune 500.

We've seen a version of this ourselves. A few weeks back, on one of our Thursday dev-time sessions, we got talking about an all-hands where leadership had set out a vision for engineers to be "multi-agent" within the year, running several agents at once rather than writing code line by line. The room split roughly in two. Some people had already reframed themselves as problem solvers directing tools rather than typists, and were asking things like "how much are you going to spend on me per month, a thousand, two thousand?" Others were much closer to "I didn't get into this job to hand my code to a machine." Same team, same tools, genuinely different working models sitting side by side. That's the fragmentation tax in miniature, individual speed with no shared agreement underneath it.

Where AI actually fits in a people-first framework

Here's the thing though. PETALS was built around five feeling factors, Productivity, Enjoyment, Teamwork, Learning and Serenity, and every one of them is about people, not output. So where does AI fit into that?

Not at the top. AI isn't a sixth petal, and it's not a priority to optimise for its own sake. The moment "are we using enough AI" becomes the question a team health check is trying to answer, something's gone sideways. The actual question is always the people one, do you feel supported, are you learning, is the work sustainable, does the team trust each other. AI is, at best, one of the things that can help or hurt those answers, not a goal in itself.

Where it does earn a place is as an assistant. A very capable, occasionally overeager one that needs the same onboarding you'd give any new hire, context about how your team works, and clear agreement on when it's appropriate to lean on it and when it isn't. Treated that way, it's genuinely useful. Treated as a shortcut around the harder, human parts of teamwork, it just moves the friction somewhere less visible.

Atlassian's own "AI Pulse" newsletter made a similar point the day after their context research landed: "getting faster with AI doesn't actually make your work better." Speed isn't quality, that comes down to the person directing the work, their subject-matter expertise, judgment and taste, and their ability to spot when something doesn't add up. Which is really the whole argument for treating AI as an assistant rather than a priority, if the human doing the judging isn't in the loop, faster just means you get to a worse answer sooner.

A few real-world shapes this takes:

Friend: someone uses AI to get a rough first draft or scaffold out of their head faster, then does the actual thinking themselves. It clears the boring bit so the human bit gets more attention, not less.

Foe: someone reaches for AI as a substitute for a conversation they should be having with a teammate, asking it to write the awkward Slack message or draft feedback they haven't worked out how to say themselves. It papers over a Teamwork or Serenity problem instead of surfacing it.

Enthusiastic junior: AI produces something confident, fluent, and subtly wrong because it didn't have the context a real teammate would have picked up from six months in the room. Fast doesn't mean right, and it takes someone with actual domain expertise to spot the difference. Useful, but needs the same review you'd give any new starter, not a rubber stamp.

Why the A in PETALS isn't AI

We get asked this a fair bit, usually half-jokingly: shouldn't the A in PETALS stand for AI? It's a tempting bit of wordplay, but no, and it's a deliberate no rather than an oversight.

Every existing petal is a feeling. Productivity, Enjoyment, Teamwork, Learning, Serenity, they're all about how someone experiences their work. AI isn't a feeling, it's a tool. Bolting it on as a petal would mean measuring tool adoption alongside human wellbeing, and those aren't the same kind of thing. If you genuinely want to track AI usage, there's a whole category of DX tooling built specifically for that, and they'll do a far better job of it than a team health check ever could.

There's a sharper reason too. AI is one of the more divisive topics in a lot of teams right now, some people are all in, some are actively resentful of it, and most are somewhere uneasy in between. PETALS only works if people feel safe enough to be honest about how the job actually feels, and a dedicated AI score risks turning that into a referendum, or worse, a number that gets used to justify a decision someone's already made about who is or isn't "using AI enough." That's exactly the kind of thing that shuts honesty down rather than opening it up.

So AI stays where it belongs in this framework, a thing that can show up inside Teamwork, Serenity or any of the others depending on how it's being used, not a category with its own scoreboard.

Where this lands for PETALS

If you're running a PETALS check-in with your team, AI is worth a mention, but as a contributing factor, not a category of its own. Worth asking directly: are we agreed on when we use it and when we don't, the way Atlassian's Play/Pause teams ended up doing? Is it quietly propping up a Teamwork or Serenity score that would look worse without it? Is anyone using it to avoid a conversation rather than have one?

None of those are AI questions really, they're team health questions that happen to have AI sitting inside them right now. Which is exactly why a people-first framework doesn't need a bolt-on AI pillar to make sense of it, the same five feeling factors already cover it, you just have to remember to ask.

This is the kind of thing our newsletter subscribers hear about first. If you'd rather get product updates and insights like this straight in your inbox instead of waiting for the blog, subscribe below.

Meta thought it had cracked the AI-native team. Instead of the usual 10 to 20 person product group, it shrank things down to "pods" of three to five people, leaning hard on AI tools and agents to make up the difference.

The numbers looked great at first glance. Code changes to Meta's internal platforms and infrastructure were up 220% year-on-year. Then you look past that one metric: features that actually reached users rose a much more modest 36%, major technical and security incidents jumped 40%, and time spent firefighting those incidents rose 70%.

It's not just Meta either. DX's research across 500+ organisations found median weekly pull request throughput up 37%, while their Developer Experience Index (a measure of how frictionlessly people can actually do their work) fell from 67 to 65 over the same period. More output, worse experience. As Brian Houck from DX puts it, "we are often falling in love with our output numbers and not paying enough attention to our outcome metrics."

Peter Bell, who's writing an O'Reilly book on scaling AI adoption, reckons the sweet spot is more like five to eight people, even if only one or two are touching the same repo. Part of that is technical, several people plus agents can generate more simultaneous changes than a team can safely review. But part of it is just human: "it's nice to have a group of five to eight humans because that works for humans and it creates a sense of connection."

That number should sound familiar if you've spent any time around agile theory. The 7 ± 2 rule for team size didn't come from nowhere, it's borrowed from Miller's research on working memory, the idea that people can hold roughly seven items in mind at once before things get lossy. Applied to teams, it's really a stand-in for two things: how many relationships someone can track meaningfully, and how fast communication overhead grows. Brooks's Law is the sharp version of that second point, the number of communication paths in a team grows as n(n-1)/2, not in a straight line.

Three extra people doesn't mean three extra relationships to manage, it's 18 more. That's the maths behind why both Bell and agile theory land on roughly the same number, and it's before you even factor in AI multiplying how much each person produces.

Size doesn't just affect output, it affects who speaks

Meta's story is about a team that got too small to safely absorb what AI let it produce. But I've seen the opposite problem plenty of times too, teams that get too big to be psychologically safe.

In a larger group, the more vocal people naturally end up dominating the conversation, and quieter folks learn to hide behind them. Some people who'd normally speak up without a second thought get more hesitant just because the audience is bigger. It's not usually deliberate on anyone's part, it's just what happens to group dynamics once you pass a certain size. More people in the room doesn't mean more voices heard, often it means fewer.

None of that makes large teams bad. Plenty of work genuinely needs more than eight people. It just means size is something to actively manage rather than ignore, especially when you're running a health check like PETALS, or any other check-in that depends on people actually saying how things are going.

A few things worth doing if your team sits outside that 5-9 band:

Split the conversation, not just the work. If a health check happens in one big group, quieter voices get lost in the room dynamics before they ever answer a question. Smaller breakout groups, or individual async responses that get aggregated afterwards, give people room to say what they actually think.

Watch for silence as a signal, not an absence of one. If someone's scores are consistently low, or they're not engaging with a snapshot at all, that's not nothing. It might be exactly the thing a bigger team makes harder to say out loud. Treat it as data worth following up on, not a gap to skip past.

Don't assume confident people stay confident at scale. Someone who speaks up freely in a team of six might go quiet in a team of fifteen. That's not a character trait, it's a response to the room getting bigger. Worth checking in on directly rather than assuming their silence means nothing's changed.

Where this lands for PETALS

Teamwork and Serenity, two of the five petals, are both sensitive to team size in ways that are easy to miss. A team that's too small to safely handle its workload burns out fast, which is exactly what Meta's incident and firefighting numbers show. A team that's too large for people to feel safe speaking up quietly loses the honesty a health check depends on.

The agile 7 ± 2 guidance and Bell's five to eight both point at roughly the same band, and it's not a coincidence. That size is small enough for real communication overhead to stay manageable, and small enough for people to feel like individuals rather than a face in a crowd. Above it, and below it, you're managing a different set of risks. Worth knowing which one you're actually looking at before you decide the team just needs to talk more.

Worth keeping an eye on

It's hard to miss how hard big tech is pushing AI right now, even the personal kind. Buried under the Apple keynote headlines this week, Meta launched Muse, a personal AI agent that can shop, book travel, fill out forms and generally act on your behalf. It's a very different product to the AI pods story above, but it's the same underlying bet: that AI, applied broadly enough, makes things better.

We're not throwing stones here either. PETALS is a small team with limited capacity, and we lean on AI for a good chunk of our own work. Whether that broader push, personal assistants and all, is actually helping teams rather than just producing more stuff, is a bigger question than this post. We'll save that one for another time.

This is the kind of thing our newsletter subscribers hear about first. If you'd rather get product updates and insights like this straight in your inbox instead of waiting for the blog, subscribe below.

Dev-time is our Thursday evening ritual, whoever from the team can make it, usually three of us, sometimes fewer. We talk through what we've each been working on, what's next, and run a quick PETALS snapshot to check in on how things are actually going. This week's session ran long, so here's what came out of it.

"In a year, we expect you to be multi-agent"

We got talking about an all-hands one of us sat in on recently, where leadership set out a vision for where engineering's heading. The headline: within a year, every engineer is expected to be running multiple agents at once, not writing code line by line.

The reaction in the room was a proper mixed bag. Some people, genuinely excited, already there. Others, much closer to "hang on, I didn't get into this job to hand my code to a machine."

Talking it through, the read was that the people who've converted did it almost without trying, because they'd already stopped thinking of themselves as coders. The question that gives it away is the one people start asking about their own role: "how much are you going to spend on me per month, a thousand, two thousand?" That's someone who's already reframed themselves as a problem solver directing tools, not someone whose value is the typing.

You're a product engineer now, not a software engineer. And that shift isn't really about the coding at all. Yes, agents can 10x your output. But they don't 10x your product design, your discovery, your research. If anything, that's now the bottleneck, not how fast the code gets written.

Training AI to actually sound like you

Separate thread, same conversation: both of us have been feeding old writing into Claude so it stops sounding like generic AI output and starts sounding like us. Sertan's been using his old dissertation and coursework. I've been thinking about pulling transcripts from years of PETALS video content for the same reason, feed it in, get an LLM to learn the tone, turn that into a reference skill rather than dumping raw transcripts into every prompt.

The goal isn't to hide that AI helped write something, it's to stop spending longer editing the output than you would've spent writing it yourself. There's a real difference between "write me a random post about a random idea" and shaping, guiding, and editing something that's genuinely yours. The ideas are still ours. AI's doing the organising, not the thinking.

Worth a mention, there's a proposal doing the rounds from Google, the Open Knowledge Format, a portable, markdown-based way of building a "second brain" that works across tools rather than being locked into one. If you're already building a personal knowledge base for this kind of thing, worth a look.

A peek at where the design's heading

We also got sidetracked into design inspiration for a while, browsing Mobbin for ideas, and it kept landing on the same thing: bold, thick-outline illustration, loud colour, nothing polite about it. A proper contrast to how buttoned-up most SaaS product design still looks.

Solo, the quick one-minute PETALS check-in we've been building, is the first place that direction's actually shown up.

Thick black outlines, a highlighter-yellow highlight box, real personality instead of another clean SaaS template. And the flower needed some company. Say hello to the PETALS bee.

More of this soon.

The Sunday habit that's become a content pipeline

The other thing that came out of this session: I've started ending most sessions with Claude by asking it to draft a blog post or social post about whatever we just did. Then every Sunday, a proper review, look back over the week's sessions, pull out anything worth sharing. Once a month, the same thing at a wider angle, what's changed, what's shipped, that becomes a changelog post.

It's a small habit, but it's turned "we did some work this week" into an actual content pipeline, with barely any extra effort. I've also hooked Claude up to Buffer, so anything flagged as worth sharing gets queued up for the following week automatically rather than sitting in a doc somewhere.

What's coming next

Sertan's been reading through DORA's 2026 reports on AI's impact on team wellbeing, burnout from splitting attention across agents, skills erosion, the verification burden that comes with reviewing more AI output than you write yourself. Exactly the territory PETALS lives in. He's going to write that one up properly later this month, so keep an eye out.

You post a long update in Slack. You've put real thought into it, the context, the reasoning behind a decision, a few bullet points laying out what happens next. And it just sits there. No reply. No thumbs up. Nothing.

You start wondering if anyone actually reads these. Maybe next time you keep it shorter. Maybe you stop bothering with the detail at all.

Nobody on your team ever agreed on how a message like that gets acknowledged. Whether a reaction is enough, whether it needs a reply, or whether silence just means "seen, all good". You assumed one thing. Everyone else assumed another. That gap is where the resentment starts, quietly, over weeks.

This is exactly the pattern Gustavo Razzetti writes about in his newsletter, Demystify Culture. Conflict rarely starts with one big event. It starts with agreements nobody actually made, and the small stories people tell themselves when those unwritten expectations get broken.

The golden rule is wrong

Gustavo's point is that we default to treating people how we'd want to be treated. But everyone's expectations are different. One person treats a long Slack message as a reference doc they'll come back to. Another sees a wall of text and mentally files it under "later", which quietly becomes "never". Neither is wrong. Nobody wrote it down.

His fix is the Team Washing Instructions Canvas, a simple worksheet split into four areas:

• How we communicate, which channel carries which kind of message, and what response people can actually expect
• How we collaborate, when and where people work, and how the team handles async versus sync
• How we win together, what good work looks like, and how mistakes get handled
• How we support each other, recognition, feedback, and what's non-negotiable

Filled in properly, it turns a hundred small unspoken assumptions into something the team actually agreed on. Worth reading his full piece if you haven't already, it's where this idea comes from, including the template.

Where PETALS fits

Washing instructions are the agreement. PETALS is the pulse check on whether that agreement is actually landing.

They're not doing the same job. One is a conversation about the rules of engagement, done properly maybe once a quarter. The other is a quick, regular read on how the team is feeling, week to week, against those rules. Neither one replaces the other. A washing instructions canvas nobody revisits goes stale. A PETALS snapshot with no shared agreement behind it just tells you something's off, not why.

Use it to calibrate a new team

When a team first forms, or after a reshuffle, run the washing instructions canvas before the first PETALS snapshot. It gives everyone a shared starting point instead of each person guessing what "responsive" or "supportive" means. And it gives that first snapshot something concrete to measure against, rather than five vague feeling factors floating with no context.

Use it to reset a conversation that's gone flat

If your PETALS snapshots start feeling repetitive, same scores, same shrug, nobody's got much to add, that's usually not a sign the team's fine. It's a sign the "how we work" conversation has gone stale. Treat a flat or low-effort snapshot as your cue to pull the washing instructions canvas back out. Ask what's working, what needs clarifying, what's missing. Refresh the agreement, then pick the snapshots back up.

That Slack message nobody reacted to is a good example. If Teamwork or Serenity keeps dipping and nobody can say why, "how we communicate" is often the quadrant worth revisiting first.

A simple rhythm

Revisit the washing instructions canvas quarterly, or whenever the team changes shape. Run PETALS snapshots regularly in between. If one factor keeps coming back low, that's your signal for which quadrant needs another look.

Agreements without a pulse check go stale without anyone noticing. A pulse check without agreements tells you something's wrong but not why. Use both.

We've put together a PETALS-themed version of the washing instructions canvas, the same four quadrants, with our flower mark sitting at the centre as the reminder.

Download the printable canvas and run it with your team, then try a PETALS snapshot and see what conversation it starts.

If you use Google or Microsoft for everything else at work, you can now use them to log into PETALS too. We've integrated single sign-on (SSO) with both, so nobody on your team needs to remember or reset another password.

Less time spent on insecure passwords and password managers, more time spent on your team's snapshot.

If you'd still rather skip passwords altogether, we've got you covered there too. Toggle over to the magic link option at the bottom of the login form and we'll email you a one-click link instead.

Try logging in now and see it for yourself.

A few other things shipped alongside this: a batch of smaller user-experience improvements and bug fixes, and a brand new marketing site at usepetals.com.

We've also been experimenting with a 3rd anniversary campaign called PETALS Solo, a version you can run with just a friend or peer rather than a full team. It taps back into the original idea behind PETALS: personal weekly reflections that give you a reason to check in with each other.

Give it a try and let us know what you think.

One more thing in progress: scheduled snapshots, so your team's Friday check-in goes out automatically instead of relying on someone remembering to send it. We're opening this up to a handful of teams early, get in touch if you want first access.

This is the kind of thing our newsletter subscribers hear about first. If you'd rather get product updates and early access to new features straight in your inbox instead of waiting for the blog, subscribe below.

When I was at the LDX3 conference the other week, Dominika Rogala gave a really interesting talk about the four dimensions of burnout.

She was talking generally about burnout in leadership, but it translates to all levels. And it feels like it's becoming more prevalent now as tech accelerates again with AI and agentic workflows.

Dominika talked about the four dimensions of burnout as:

• exhaustion
• emotional distance
• loss of efficacy
• the gap between who you think you should be and who you actually are

At that point, it becomes very hard to keep saying that burnout is just a lack of resilience. This is why so many traditional well-being interventions fail. Mindfulness classes, coaching, wellness perks. They can help individuals, but they do not redesign the environment people return to every day.

I relate to a lot of the points Dominika made there. And I highly recommend you go and watch the talk now that it's been published on the LeadDev website.

But this is one of the reasons why serenity is such an important factor in the PETALS framework.

When I introduced the PETALS concept as a team exercise, I was talking from the voice of experience.

I'd been in roles which were burning me out. I'd been in management and contributor roles that were forcing me to the edge. And it's the reason why that factor is so important in this framework.

Most other frameworks don't even ask about how you're feeling from a serenity, stress, or well-being perspective. Most of them focus on the outcomes and the business metrics.

But the reason why PETALS lands so well is that we're asking people how they're feeling about things.

Burnout is just one angle when we talk about well-being and serenity. But it's an important one.

I really encourage you to go and watch Dominika's talk. It's about 20 minutes long and was quite eye-opening from a leadership perspective and from the perspective of any team member you work with.

It gives you a way to think about how burnout could be affecting your team, and where you could potentially change things for the better.

And also remember to keep those health checks happening regularly.

Use the Serenity score as a guide to have that conversation.