<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title><![CDATA[Salamander 360]]></title>
  <link>https://salamander360.com/</link>
  <description><![CDATA[Salamander 360 is a one-person consultancy run by Marcus Hale. Fixed-scope strategy and diagnostic work for organisations with problems that are hard to name.]]></description>
  <language>en</language>
  <atom:link href="https://salamander360.com/feed.xml" rel="self" type="application/rss+xml" />
  <item>
    <title><![CDATA[On the problem that has no owner]]></title>
    <link>https://salamander360.com/</link>
    <description><![CDATA[Most of the problems I get called in for share one feature: nobody inside the organisation is clearly responsible for solving them. That's not an accident. It's usually a structural fact. Here's how I think about it.]]></description>
    <pubDate>2026-07-14</pubDate>
  </item>
  <item>
    <title><![CDATA[Why I stopped using the word 'alignment']]></title>
    <link>https://salamander360.com/</link>
    <description><![CDATA[It's in every strategy document. It means almost nothing. Here's what I use instead, and why the substitution matters more than it sounds.]]></description>
    <pubDate>2026-06-30</pubDate>
  </item>
  <item>
    <title><![CDATA[What I learned from a bad engagement in 2022]]></title>
    <link>https://salamander360.com/</link>
    <description><![CDATA[I took on a project I shouldn't have. The client was right that they had a problem. They weren't ready to look at it. I should have seen that earlier. Here's what I missed.]]></description>
    <pubDate>2026-05-19</pubDate>
  </item>
  <item>
    <title><![CDATA[A note on the advisory retainer]]></title>
    <link>https://salamander360.com/</link>
    <description><![CDATA[I've had a few questions about how the monthly advisory arrangement works in practice. Here's a plain account of what it involves and who it tends to suit.]]></description>
    <pubDate>2026-04-08</pubDate>
  </item>
  <item>
    <title><![CDATA[How to write a problem statement your whole organisation can agree on]]></title>
    <link>https://salamander360.com/notes/writing-a-problem-statement-organisation.html</link>
    <guid>https://salamander360.com/notes/writing-a-problem-statement-organisation.html</guid>
    <description><![CDATA[I've sat in a lot of rooms where someone has written a problem statement on a whiteboard and everyone nods, and then six months later the project has quietly drifted into solving something completely different. That's not a planning failure, usually. It's a language failure. The problem statement was written in a way that let everyone agree without actually agreeing. It felt like alignment but it was just shared ambiguity. I've been doing diagnostic work across public agencies, mid-size private companies, and a few nonprofits for long enough now to notice that the organisations who get this right tend to use a surprisingly specific kind of sentence structure — and the ones who get it wrong tend to make the same three or four mistakes. This piece is my attempt to write down what I know, with the caveat that I'm still refining this and would not claim it's a complete theory.]]></description>
    <pubDate>2025-11-04</pubDate>
  </item>
  <item>
    <title><![CDATA[When should you bring in an outside consultant, and when shouldn't you?]]></title>
    <link>https://salamander360.com/notes/when-to-hire-outside-consultant.html</link>
    <guid>https://salamander360.com/notes/when-to-hire-outside-consultant.html</guid>
    <description><![CDATA[I've been on both sides of this. I've been the consultant brought in to solve something that turned out to be unsolvable by anyone outside the organisation — and I've watched clients make real, lasting progress because they had someone external holding the thread. Neither outcome was predictable from the outside. What I've come to think, after years of doing this work, is that the question "should we bring in a consultant?" is almost never the right starting question. The better questions are more uncomfortable, more specific, and much easier to avoid asking. So this is my attempt to be honest about the conditions that make external consultancy genuinely useful — and the ones that quietly guarantee it won't be. I'm still working some of this out, so take it as a working note rather than a verdict.]]></description>
    <pubDate>2025-12-22</pubDate>
  </item>
  <item>
    <title><![CDATA[What makes a strategy document actually get used]]></title>
    <link>https://salamander360.com/notes/strategy-document-that-gets-used.html</link>
    <guid>https://salamander360.com/notes/strategy-document-that-gets-used.html</guid>
    <description><![CDATA[I've read somewhere around two hundred strategy documents over the past decade. Sector strategies, corporate strategies, national digital strategies, team-level roadmaps dressed up as strategies. And I'll be honest: most of them have one thing in common, which is that they were written to survive a sign-off meeting, not to be opened again afterward. That's not a moral failing — it's a structural problem, one that shows up in very predictable ways once you know what to look for. I'm still working this out, but I think the difference between a document that shapes decisions and one that sits in a drawer comes down to a surprisingly small number of choices — about structure, about language, and about what the document is actually trying to do for the people who have to use it. This is my attempt to lay those out as clearly as I can.]]></description>
    <pubDate>2025-11-18</pubDate>
  </item>
  <item>
    <title><![CDATA[The diagnostic interview: how to ask questions that get honest answers]]></title>
    <link>https://salamander360.com/notes/diagnostic-interview-honest-answers.html</link>
    <guid>https://salamander360.com/notes/diagnostic-interview-honest-answers.html</guid>
    <description><![CDATA[I've been running diagnostic engagements for a while now, and the part that still surprises me is how rarely the stated problem turns out to be the actual problem. Someone books a call about "alignment issues" and by the end of the first week it's clearly about one person who's been allowed to behave badly for years. Someone else says "our strategy isn't landing" and what they mean is "we have three conflicting strategies and nobody has been willing to say so out loud." The gap between the presenting complaint and the real thing is almost always there. The diagnostic interview is the main tool I use to cross it. I want to write this up honestly, including the parts that feel a bit uncomfortable, because I think there's a craft to this that doesn't get written about much — and I'm still refining it.]]></description>
    <pubDate>2025-01-05</pubDate>
  </item>
  <item>
    <title><![CDATA[Decision rights: the thing most organisations never write down]]></title>
    <link>https://salamander360.com/notes/decision-rights-organisations.html</link>
    <guid>https://salamander360.com/notes/decision-rights-organisations.html</guid>
    <description><![CDATA[I've sat in a lot of meetings that felt like reruns. Same faces, same tension, same unresolved question about who actually gets to decide something. After a while I started noticing the pattern wasn't about the people or even the topic — it was structural. The organisation had never written down who owns which decisions, so every decision became a fresh negotiation. This post is my attempt to lay out what decision rights actually are, why leaving them implicit is so costly (in ways that are easy to dismiss until they aren't), and a simple framework I use with clients to make them explicit without launching a six-month governance programme. I'm still refining parts of this, so treat it as a working note rather than a finished doctrine.]]></description>
    <pubDate>2025-09-22</pubDate>
  </item>
</channel>
</rss>
