In partnership with
What you get from this one: the person shouting in the incident channel isn't your problem to manage, they're your best signal. Anger points at fear.
In this drop
The point: Anger in an incident is almost always fear wearing a louder coat: of fault, of blast radius, of looking incompetent.
Why it matters: Meet anger with heat or with cold professionalism, and you harden the person; the truth stays hidden, and the outage runs longer.
Try this next week: Before responding to heat, ask one silent question: What is this person afraid of right now?
The point
Severity one. Someone's typing in capitals. This should never have shipped. Who approved this. The channel tightens, people go quiet, and the debugging slows because now everyone's managing the angry person as well as the outage.
I heard someone this week say anger is almost always hiding something underneath. Fear, sadness, shame. In therapy they say it's not hysterical, it's historical. And the line that travels: the harder you push, the more hardened they become.
The engineer shouting at 2am isn't angry at the deploy. Underneath is fear. That it's their fault. The blast radius. Looking incompetent in front of the seniors now watching the channel. Anger is just the bit you can see, the easy emotion on top of the hard one. Shouting takes nothing. Saying you're scared takes strength.
Reality check
If we're honest: blameless post-mortems aren't about being nice, they're a mechanism for getting the fear out of the room so the truth can come in.
One proof
Amy Edmondson's work on psychological safety, and Google's Project Aristotle, both land in the same place: teams perform when it's safe to say the scary, true thing. Field note: after one team moved to genuinely blameless reviews (no names in the timeline, no 'who', only 'what and why'), the number of contributing factors surfaced per incident roughly doubled across a quarter. Same incidents, same people. The fear had been hiding the causes.
Where this breaks
This isn't a licence for abuse. Naming the fear under someone's anger is care; tolerating someone screaming at the team is not. Hold the behaviour line and the empathy at the same time.
Try this next week
Next time someone gets heated, before you respond, ask yourself: what is this person afraid of right now?
If it helps, ask them gently and privately, what's the worst version of this in your head? Not 'calm down'.
If you're the heated one, point the question inward. It's usually fear wearing the hi-vis.
About the book
If this Signal Drop lands with you, the same thinking runs through Metrics & Mayhem: A CTO's Guide to Observability That Actually Works. Out today in paperback and hardback. Kindle's already live.
Want to taste it first? The free first chapter is yours: FREE CHAPTER.
Or skip the chapter and go straight in: BOOK LINK.
Three links I'm watching
Amy Edmondson, 'The Fearless Organization': the definitive case for psychological safety as a performance lever.
Google re: Work, Project Aristotle: the data behind safety beating talent on team effectiveness.
Signal Drop 11, 'Your Team Mirrors You': the companion on how leaders set the emotional weather in a room.
One question for you
When someone last went off in one of your incidents, what were they actually afraid of?
Allan
PS: The episode runs about five minutes. Listen here: SPOTIFY.
Analytics on Live Data. No Pipeline. Just Postgres.
Most teams treat analytics as a separate problem. As data grows, they add a warehouse, a pipeline, a sync job. By the time data reaches their dashboard, it's already stale.
TimescaleDB takes a different approach: extend Postgres instead of splitting away from it.
Your transactions and your analytics run on the same database, on live data, with no pipeline in between.
Hypertables partition time-series data automatically as volume grows. Hypercore compression cuts storage by up to 95%. Continuous aggregates pre-compute rollups so dashboards stay fast without re-querying everything.
CERN runs it on Postgres to handle sensor data from the Large Hadron Collider.
No second database. No migration. Same Postgres you already know.