Hey!

Welcome back to another week of musings.

I'm back in my regular time zone (and sleep hours) and was able to go watch the SG Giants at the ballpark (sadly, they lost!).

Here's hoping you had a great and uneventful weekend!

Was this forwarded to you? You can subscribe here!

Things I enjoyed in the past week

• Rawayana - Reyimiller | A COLORS SHOW I've been enjoying Rawayana lately, this COLORS show was a nice change of pace for their usual song arrangement! Otherwise, I recommend their NPR Tiny Desk.
• TBM 413: In That Space Is Our Power, another great post by John Cutler, on how both sides of a change are struggling to adjust, either from the ask or from the proposal.

I recently heard about another org rolling out a new "release maturity framework." It has five levels, and level 5 — the top — maps closely to what DORA calls the elite classification: multiple deploys per day, a low change failure rate, and a fast time to restore service.

Reaching DORA elite is a worthy goal. By elite, I mean the usual high-performance metrics: releasing to production constantly, multiple times per day, high confidence in the automation and the release process, and a short time to recover when something goes wrong.

But this particular framework was being rolled out as a mandate — a top-down decree with timelines and quarterly checkpoints attached.

Just mandating something, that's where I think these initiatives tend to go wrong.

You can't order a team into this state by declaring new standards, buying a new platform, or setting a quarterly goal that says "deploy 5x more often." You might get compliance for a while. You might even get a small bump in the metric. But that doesn't mean the team has become capable of operating that way.

Tooling is only part of the picture. You need reliable automation. You need fast tests. You need observability that helps during incidents. You need safe rollback paths, or even better, ways to reduce the blast radius of a change before rollback becomes necessary. You need to invest in the boring plumbing that enables frequent releases.

But tooling only helps when people trust it.

I've seen teams with decent pipelines still avoid releasing because they don't believe the automation is enough. Or because they've been burned before. Or because of just risk-aversion.

In those cases, the problem is that the team doesn't yet believe the system is safe enough to lean on.

Culture decides whether the tooling gets used

This is the part I keep coming back to.

Charity Majors talks about this in The Sociotechnical Path to High-Performing Teams, that the gap between elite and average isn't about engineering skill — it's about the socio-technical feedback loops inside each organization. The problem isn't purely technical.

If people are still asking, "Why would I want to release three, four, or five times per day?" then the conversation isn't really about CI/CD. It's about beliefs and trust.

If the teams don't trust the tooling and the other teams, the transformation will stall. It doesn't matter how much money is spent on tooling. People will go around the system. They'll batch changes together. They'll delay deploys. They'll keep extra manual checks. They'll wait for the "right moment." In the end, the official process says one thing, but the lived culture says another.

Culture eats strategy.

What actually has to change

If a team wants to move toward this kind of operating model, I think the work starts much earlier than most rollout plans admit.

You have to help people understand the benefits of smaller and more frequent releases. Not in theory, but in their daily work. Fewer moving parts per deploy. Easier debugging. Faster feedback from production. Less time spent coordinating giant launches. Less fear around rollback because the change set is smaller.

You also have to build the missing blocks! Better tests. Better on-call practices. Better release hygiene. Better incident learning. Clear ownership. Leaders who don't punish teams for every surprise while simultaneously asking them to move faster.

The boring and invisible work, but it's the only kind that seems to stick.

Elite is earned, not mandated

I don't think you can command a team into becoming elite.

You can create the conditions for it. You can remove friction. You can fund the right tooling. You can coach people through the benefits. You can help teams build trust in their systems and in each other.

But if there's deep resistance to the idea itself, or if the culture treats every release as dangerous, then no rollout will succeed for long. People won't bring their full effort into that world because they don't believe in it.

And if they don't believe in it, the system will eventually collapse back to its old shape.

In the worst-case scenario, teams might be burned out, and you won't hear any feedback at all, but also no progress!

Your turn!

Have you seen a team successfully move toward multiple releases per day? What made it work — tooling, leadership, culture, or some combination of all three? Let me know by replying to this email!

Happy coding!