<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>governance on Paul Lewis</title><link>https://www.pjlewis.com/tags/governance/</link><description>Recent content in governance on Paul Lewis</description><generator>Hugo -- gohugo.io</generator><language>en-gb</language><copyright>&lt;a href="https://creativecommons.org/licenses/by-nc/4.0/" target="_blank" rel="noopener">CC BY-NC 4.0&lt;/a></copyright><lastBuildDate>Thu, 14 May 2026 15:00:00 +0000</lastBuildDate><atom:link href="https://www.pjlewis.com/tags/governance/index.xml" rel="self" type="application/rss+xml"/><item><title>Why Technology Retirements Are a Governance Problem, Not a Technical One</title><link>https://www.pjlewis.com/posts/why-technology-retirements-are-a-governance-problem/</link><pubDate>Thu, 14 May 2026 15:00:00 +0000</pubDate><guid>https://www.pjlewis.com/posts/why-technology-retirements-are-a-governance-problem/</guid><description>&lt;p>Most organisations treat technology retirements as change events. A vendor announces that a service, API version, or platform SKU is reaching end-of-life. Someone raises a ticket. An engineer does some work. The retirement date passes without incident, and everyone moves on.&lt;/p>
&lt;p>That version of events does happen. But it is not the version I see most often.&lt;/p></description></item></channel></rss>