WatchTurm

Why is CAB not in control? That usually makes people uncomfortable. Let me explain: CAB is important. - It brings structure. - It introduces a review. - It reduces obvious risk. But CAB is not in control. CAB approves the change. Control verifies reality. A change can be: • documented • reviewed • discussed • approved And still… Production can drift - Tags can differ - Manual fixes can slip in - Feature flags can stay enabled. Nothing “violated” the process. Yet clarity is gone. The uncomfortable truth? Many organisations mistake governance for visibility. They believe: “If it went through CAB, we are in control.” But CAB evaluates intent. Control requires continuous insight into: • what is actually deployed • how environments differ • What changed since yesterday • who owns the current state That doesn’t happen in a meeting. This is not an argument against CAB. It’s an argument against stopping at CAB. Compliance is not the same as operational control, and at scale, the gap becomes expensive. The real question isn’t: “Was this approved?” It’s: “Can we see, in real time, what changed and where?” That’s where maturity begins. #ChangeManagement #ReleaseManagement #DevOps #ITGovernance

The “Blocked” column - control or avoidance? Many teams create a Blocked column with good intentions. • It looks structured. • It looks transparent. • It feels responsible. But do you know if in practice? It often becomes a waiting room for accountability. When something is hard, unclear, politically sensitive, or cross-team-dependent, we move it to Blocked. And suddenly… • It’s no longer urgent. • It’s no longer owned. • It’s no longer pushed. • It’s “visible”. On paper, visibility improves - In reality, momentum dies. Let’s be honest. Most blocked work isn’t blocked by infrastructure. It’s blocked by: • unclear ownership • avoided escalation • uncomfortable conversations • dependency management no one truly owns A column does not resolve friction. It labels it. The dangerous part? “Blocked” can normalize waiting. Teams start managing the board instead of resolving the constraint. Work doesn’t move because it was categorized. Work moves because someone takes responsibility. In mature delivery systems, blocked items are not parked. They are actively managed. The real question isn’t: “Do we need a blocked column?” It’s: “Who wakes up every day thinking about unblocking?” Visibility without ownership is decoration. Control requires action. #ReleaseControl #ReleaseManagement #DevOps #EngineeringCulture

Stability is not a tooling problem. It is an architectural problem. 📢 In this piece, I break down the layered model of operational responsibility - and why DevOps and Release Governance must be intentionally separated to prevent slow-moving systemic drift. #release #devops

A Pull Request title is not a label. It’s part of your change control system. In release management, major production issues rarely start with “bad code.” They usually start with a lack of control over change. And one of the most underestimated elements of that control is… the Pull Request title. Sounds trivial? Only until someone asks: “What exactly is in this release?” In a mature environment, a PR isn’t just a merge request. It’s a formal unit of change. It connects: Ticket → PR → Commit → Build → Deployment → Production If a PR is titled: “fix” “update” “changes” you’ve already lost context. And in release management, context = safety. At scale, improvisation breaks. With multiple repositories and environments, you need to quickly understand: Is this a feature or a fix? Is it safe for a hotfix branch? What business change does it represent? A clear PR title allows: automatic release notes generation faster incident investigation better change failure analysis safer scope control A vague one forces manual investigation - usually during a P1. When production breaks, time matters. A PR titled: PAY-342 Fix incorrect rounding in payment calculation is minutes to diagnose. A PR titled: quick update is archaeology under pressure. Naming conventions aren’t bureaucracy. They’re a signal of engineering maturity. A well-written PR title is a declaration: This change has a clear scope. It’s traceable. It’s accountable. And in complex environments, that difference matters. Curious how this works in your organization. Do you treat PR naming as a detail - or as governance? #ReleaseManagement #SoftwareDelivery #SystemThinking

A release problem we keep seeing - again and again... In complex systems, release issues are rarely caused by bugs. A lack of visibility causes them. Across multi-repository setups, teams often assume that a release is complete because: - all pull requests were merged - pipelines were green - a release branch exists In reality, one service is frequently not deployed. Quietly. Without an explicit failure. And without anyone noticing. Why does this happen? This usually isn’t negligence. It happens because: - information is spread across multiple tools - ownership is split between teams - deployments happen at different times - no single place reflects what is actually running Each step looks correct, but the system-level picture is missing. How do teams usually try to fix this? Most organisations try to patch the problem by: - adding manual checks - maintaining spreadsheets - asking in chat channels - introducing additional approval steps This often leads to: - slower releases - higher coordination cost - more process, not more clarity And still, the problem comes back. Why does this approach break down? Manual verification doesn’t scale with: - more repositories - more environments - faster delivery cycles The more complex the system becomes, the more fragile these workarounds are. How do we look at it? Instead of asking: “Was this supposed to be deployed?” We believe the real question is: “What is actually deployed - right now?” Visibility should be built into the process, not reconstructed after something goes wrong. #releasemanagement #devops #softwaredelivery