<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Change Management on Cliff Hults</title><link>https://www.haguest.com/tags/change-management/</link><description>Recent content in Change Management on Cliff Hults</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 Cliff Hults</copyright><lastBuildDate>Fri, 01 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.haguest.com/tags/change-management/index.xml" rel="self" type="application/rss+xml"/><item><title>The Paved Path: Making the Secure Choice the Easy Choice at Scale</title><link>https://www.haguest.com/posts/2026-05-01-the-paved-path/</link><pubDate>Fri, 01 May 2026 00:00:00 +0000</pubDate><guid>https://www.haguest.com/posts/2026-05-01-the-paved-path/</guid><description>&lt;p>&lt;em>This is the final part of a series. Start with &lt;a href="https://www.haguest.com/posts/2026-02-06-give-the-backlog-teeth/" >Part 1 — giving the backlog teeth&lt;/a>, then &lt;a href="https://www.haguest.com/posts/2026-02-13-the-waiver-trap/" >Part 2 — the waiver trap&lt;/a>.&lt;/em>&lt;/p>
&lt;p>The waiver experiment was a failure in the best possible way; it was diagnostic. It told me exactly where the real bottleneck was: &lt;strong>fixing a vulnerability was hard to &lt;em>do&lt;/em>, not hard to &lt;em>decide&lt;/em>.&lt;/strong> Teams weren&amp;rsquo;t ignoring the work because they were lazy or uncaring. The work to fix a dependency vulnerability was slow, manual, and painful. Every fix was a research project.&lt;/p>
&lt;p>So I stopped trying to apply more pressure and started asking the question that changed everything:&lt;/p>
&lt;blockquote>&lt;p>&lt;em>What if fixing a vulnerability was the easiest possible thing to do?&lt;/em>&lt;/p>&lt;/blockquote></description></item></channel></rss>