<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title><![CDATA[TechVault PulseWave]]></title>
  <link>https://techvaultpulsewave.com/</link>
  <description><![CDATA[TechVault PulseWave is an independent technology consultancy run by Marcus Hale. Audits, advisory retainers, and written analysis for organisations making complex technology decisions.]]></description>
  <language>en</language>
  <atom:link href="https://techvaultpulsewave.com/feed.xml" rel="self" type="application/rss+xml" />
  <item>
    <title><![CDATA[On reading vendor documentation slowly]]></title>
    <link>https://techvaultpulsewave.com/</link>
    <description><![CDATA[There is a particular kind of document that arrives in a client's inbox looking like a proposal but functioning as a commitment. I have been thinking about how to read these more carefully, and what slowing down actually costs.]]></description>
    <pubDate>2026-07-03</pubDate>
  </item>
  <item>
    <title><![CDATA[A note on the strategy session format, and why I added the intake questionnaire]]></title>
    <link>https://techvaultpulsewave.com/</link>
    <description><![CDATA[I changed the format of the one-off strategy session in April. The intake questionnaire is new. Here is why I added it, and what difference it has made to the calls themselves.]]></description>
    <pubDate>2026-06-12</pubDate>
  </item>
  <item>
    <title><![CDATA[What I have been reading: three books on organisational decision-making]]></title>
    <link>https://techvaultpulsewave.com/</link>
    <description><![CDATA[A brief account of three books I have read in the past few months that have been useful to the consulting work, and one that has not been useful at all but was worth reading anyway.]]></description>
    <pubDate>2026-05-20</pubDate>
  </item>
  <item>
    <title><![CDATA[How to read a SaaS renewal proposal before you sign it]]></title>
    <link>https://techvaultpulsewave.com/notes/how-to-read-saas-renewal-proposal.html</link>
    <guid>https://techvaultpulsewave.com/notes/how-to-read-saas-renewal-proposal.html</guid>
    <description><![CDATA[Every autumn, give or take, a stack of renewal proposals arrives on my desk — PDFs, DocuSign links, the occasional printed binder from a vendor who still believes that weight confers authority. Most of them are dressed up to look like formalities, like the kind of paperwork you sign at a car dealership while someone hovers with a pen. And most of the people I work with, across sectors as different as mid-size logistics companies and regional NHS trusts, treat them exactly that way: a quick scan, a signature, done. What I've come to understand, after years of auditing these agreements after the fact — after the price increase has landed, after the seats have ballooned, after the auto-renewal has quietly fired — is that a SaaS renewal proposal is not a formality. It is, in the driest possible sense, a negotiation that one side has already prepared for and the other hasn't. This piece is about changing that.]]></description>
    <pubDate>2025-04-16</pubDate>
  </item>
  <item>
    <title><![CDATA[Why your technology audit should produce a document, not a slide deck]]></title>
    <link>https://techvaultpulsewave.com/notes/technology-audit-document-not-slide-deck.html</link>
    <guid>https://techvaultpulsewave.com/notes/technology-audit-document-not-slide-deck.html</guid>
    <description><![CDATA[I have sat in a lot of rooms where a technology audit was being "presented," and I have noticed a particular silence that settles over those rooms about twelve slides in — not the silence of concentration, but the silence of people who have quietly stopped following and are now waiting for the conclusion. The slide deck has become the default deliverable of the consulting world, and I think it is a genuinely bad default, one that flatters the presenter and obscures the work, and nowhere is that more costly than in a technology audit, where the findings are dense, the dependencies are non-obvious, and the stakes of misunderstanding tend to compound over the following eighteen months. I want to make the case, as plainly as I can, for the written report — not as a nostalgic preference, but as a structural argument about what audit findings actually require in order to be understood and acted upon. This is not a polemic against slides as a medium; it is a specific argument about the mismatch between what a technology audit produces and what a slide deck can hold.]]></description>
    <pubDate>2025-09-02</pubDate>
  </item>
  <item>
    <title><![CDATA[The incumbent advantage: how vendors shape RFP criteria in their own favour]]></title>
    <link>https://techvaultpulsewave.com/notes/incumbent-vendor-rfp-criteria-bias.html</link>
    <guid>https://techvaultpulsewave.com/notes/incumbent-vendor-rfp-criteria-bias.html</guid>
    <description><![CDATA[There is a moment in almost every enterprise procurement process I have been part of — usually somewhere between the third stakeholder workshop and the first draft of the requirements document — where I notice something quietly wrong. The language of the RFP has begun to mirror the language of the incumbent vendor's own marketing collateral. A capability described in suspiciously precise numerical terms. An integration requirement that exactly matches one proprietary API. An evaluation criterion that rewards years of installed-base experience in a way that no challenger, however capable, could honestly claim. It is rarely deliberate sabotage. It is rarely even conscious. And that, I have come to think, is precisely what makes it so durable and so hard to correct. The incumbent advantage in procurement is not a conspiracy; it is a structural feature of how large organisations gather information, and understanding it as such is the only way to do anything useful about it.]]></description>
    <pubDate>2025-03-24</pubDate>
  </item>
  <item>
    <title><![CDATA[What a monthly technology advisory retainer is actually for]]></title>
    <link>https://techvaultpulsewave.com/notes/monthly-technology-advisory-retainer-explained.html</link>
    <guid>https://techvaultpulsewave.com/notes/monthly-technology-advisory-retainer-explained.html</guid>
    <description><![CDATA[I have been on both sides of the retainer agreement more times than I can count cleanly — as the adviser being retained, and as the person inside an organisation arguing the budget line to a sceptical finance director. Each time, I have noticed the same gap: the people buying the retainer imagine one thing, and the people selling it imagine another, and neither party tends to say this out loud until several months have passed and some small resentment has quietly calcified. What I want to do here is say it out loud. Not to talk anyone into or out of the format — retainers are genuinely useful, under the right conditions — but to give you a clearer picture of what you are actually purchasing when you sign one, because the clarity tends to improve the outcome considerably. This is written from the technology advisory context specifically, though I suspect most of it applies to any professional discipline where the engagement is ambient rather than project-shaped.]]></description>
    <pubDate>2026-05-23</pubDate>
  </item>
  <item>
    <title><![CDATA[Platform migrations and the people who have to live with them]]></title>
    <link>https://techvaultpulsewave.com/notes/platform-migration-human-cost-organisations.html</link>
    <guid>https://techvaultpulsewave.com/notes/platform-migration-human-cost-organisations.html</guid>
    <description><![CDATA[There is a particular kind of exhaustion that settles over a technology team roughly a year and a half into a platform migration — not the sprint exhaustion of a deadline, but something more chronic, more ambient, the kind that accumulates in the body the way damp accumulates in old walls. I have sat in enough post-mortems, enough steering committee rooms with the wrong people in the chairs, to know that this exhaustion is almost never caused by the technology itself. The stack is rarely the villain. What tends to break things is a set of decisions made very early — sometimes before a single engineer has been consulted — that encode assumptions about how an organisation works, what it values, and who has authority, assumptions that then have to be lived with by people who were never in the room. This essay is an attempt to think carefully about that gap: the distance between the contract stage, where everything is a slide deck and a statement of intent, and the operational reality eighteen months later, where those intentions have calcified into someone else's daily problem.]]></description>
    <pubDate>2025-01-18</pubDate>
  </item>
</channel>
</rss>
