<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title><![CDATA[MindVault Lab Flow]]></title>
  <link>https://mindvaultlabflow.com/</link>
  <description><![CDATA[MindVault Lab Flow is a Toronto-based consultancy helping founders and leadership teams make clearer decisions. One consultant, scoped engagements, plain-language deliverables.]]></description>
  <language>en</language>
  <atom:link href="https://mindvaultlabflow.com/feed.xml" rel="self" type="application/rss+xml" />
  <item>
    <title><![CDATA[How to run a decision review when your team keeps changing its mind]]></title>
    <link>https://mindvaultlabflow.com/notes/decision-review-team-changing-mind.html</link>
    <guid isPermaLink="true">https://mindvaultlabflow.com/notes/decision-review-team-changing-mind.html</guid>
    <description><![CDATA[Every leadership team has at least one of these on record: a decision that was made, unmade, remade, and then quietly shelved until someone raised it again at the wrong moment in a quarterly review. The frustration is real, but the instinct to blame indecisiveness or weak facilitation usually misses the point. What keeps a decision cycling is almost never a lack of process — it is a disagreement that has not yet been named clearly enough to be resolved. This guide walks through how to structure a decision review session specifically for that situation: where the team has already reversed course at least once, where trust in the room may be strained, and where the goal is not another vote but a genuine close.]]></description>
    <pubDate>Sat, 09 May 2026 12:15:22 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[What to send a consultant before the first call (and what to leave out)]]></title>
    <link>https://mindvaultlabflow.com/notes/what-to-send-consultant-first-call.html</link>
    <guid isPermaLink="true">https://mindvaultlabflow.com/notes/what-to-send-consultant-first-call.html</guid>
    <description><![CDATA[A few weeks ago I was fifteen minutes into what should have been a scoping call when I realized we were still untangling which version of the org chart was current. The client had sent six documents the night before, each one confidently titled "FINAL," and none of them agreeing on who owned the budget. We spent the first third of our hour on archaeology. That kind of call is recoverable — most first conversations are — but it sets a particular tone, and that tone tends to cost more than people expect, in time, in goodwill, and eventually in fees. What follows is a frank account of what actually helps before a first consulting engagement begins, drawn from years of those calls, the good ones and the ones that started in the weeds. The goal is not to hand you a checklist, but to give you a clear enough mental model that you can make good judgment calls on your own, whatever your situation looks like.]]></description>
    <pubDate>Thu, 02 Apr 2026 08:11:52 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[How to structure a post-mortem that your team will actually learn from]]></title>
    <link>https://mindvaultlabflow.com/notes/post-mortem-structure-team-learning.html</link>
    <guid isPermaLink="true">https://mindvaultlabflow.com/notes/post-mortem-structure-team-learning.html</guid>
    <description><![CDATA[Most post-mortems begin the same way: someone books a meeting room for ninety minutes, pastes a shared document into a Slack channel, and everyone arrives with a privately rehearsed version of events that places them somewhere adjacent to blameless. By the end of the session, the document contains thirty bullet points, half of which say some variation of "improve communication," and three action items assigned to people who are already overloaded. Six weeks later, the document sits in a folder no one opens, and the team makes the same mistakes on the next project. This is not a failure of intention — everyone in that room genuinely wanted to do better. It is a failure of structure. A post-mortem is a precision instrument, and when you pick it up without knowing how it works, it tends to cut in the wrong direction. This guide is concerned with how to run one that produces findings your team will actually carry forward, written for the consultant or team lead who has sat through enough unproductive retrospectives to know that something needs to change.]]></description>
    <pubDate>Wed, 02 Jul 2025 12:53:07 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[How the Quarterly Strategy Reset works: a session-by-session breakdown]]></title>
    <link>https://mindvaultlabflow.com/notes/quarterly-strategy-reset-breakdown.html</link>
    <guid isPermaLink="true">https://mindvaultlabflow.com/notes/quarterly-strategy-reset-breakdown.html</guid>
    <description><![CDATA[A few months ago I sat with a founder who had three strategy decks open on her laptop simultaneously — one from a planning day in February, one from a board meeting in April, and one she'd built herself at eleven o'clock on a Sunday night. None of them agreed with each other. That moment, more than anything I could cite from a framework or a textbook, is why a quarterly reset needs structure. Without it, strategy becomes a collection of good intentions that accumulate rather than compound. This article walks through exactly how the Quarterly Strategy Reset is organized — session by session, decision by decision — so you can come in knowing what to expect and leave with something you can genuinely use.]]></description>
    <pubDate>Sun, 27 Apr 2025 14:38:26 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[Async consulting: how most of the work happens between calls]]></title>
    <link>https://mindvaultlabflow.com/notes/async-consulting-between-calls.html</link>
    <guid isPermaLink="true">https://mindvaultlabflow.com/notes/async-consulting-between-calls.html</guid>
    <description><![CDATA[Most consulting relationships are measured in call hours, but the real work happens in the silences between them. At MindVault Lab Flow, we have spent years refining how we use asynchronous formats — shared documents, structured updates, timed feedback windows — to make the time our clients spend with us count far more than any video call alone could. This is not a philosophy of avoidance; it is a structural argument about where thinking actually occurs, and how to design around that honestly. If you have ever finished a call feeling energised and then watched that energy quietly dissolve before the next session, the approach described here is built for that exact problem.]]></description>
    <pubDate>Tue, 15 Apr 2025 21:51:32 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[When to bring in an external consultant and when to solve it internally]]></title>
    <link>https://mindvaultlabflow.com/notes/when-to-hire-external-consultant.html</link>
    <guid isPermaLink="true">https://mindvaultlabflow.com/notes/when-to-hire-external-consultant.html</guid>
    <description><![CDATA[There is a question most leadership teams avoid asking out loud, even though it surfaces in almost every strategic conversation: are we reaching for outside help because we truly need a different perspective, or because we are uncomfortable owning this problem ourselves? It is an uncomfortable distinction, and the consulting industry has little incentive to help you make it clearly. This article is an attempt to do that honestly — to give you a framework grounded in the actual nature of organizational problems, not in the convenience of a vendor relationship. The decision matters more than most people admit, because choosing wrongly in either direction is expensive: an unnecessary engagement drains budget and creates dependency, while refusing external help on a problem that genuinely requires it can cost you months of circular progress. What follows is a set of diagnostic questions and structural principles drawn from the kind of work that tends to go right, and the kind that tends to go quietly, expensively wrong.]]></description>
    <pubDate>Mon, 17 Feb 2025 19:08:48 GMT</pubDate>
  </item>
  <item>
    <title><![CDATA[The difference between a strategy and a plan: why it matters for small leadership teams]]></title>
    <link>https://mindvaultlabflow.com/notes/strategy-vs-plan-leadership-teams.html</link>
    <guid isPermaLink="true">https://mindvaultlabflow.com/notes/strategy-vs-plan-leadership-teams.html</guid>
    <description><![CDATA[Do you actually have a strategy, or do you have a very detailed plan? It is worth sitting with that question for a moment before answering, because most leadership teams — even experienced ones — discover, when pressed, that what they called a strategy was really a schedule dressed in ambitious language. The distinction matters not as a semantic exercise but as a practical one: when the two are conflated, teams defer the hardest decisions indefinitely, dress operational tasks as strategic priorities, and arrive at quarterly reviews wondering why the numbers moved but the position did not. This article works through the difference with enough specificity to be useful the morning after you read it.]]></description>
    <pubDate>Tue, 14 Jan 2025 10:05:25 GMT</pubDate>
  </item>
</channel>
</rss>
