Simon Murray opened the session with a hand-drawn chart that he apologized for in advance. The chart wasn't pretty. It also wasn't meant to be. It was meant to explain why most improvement projects, in most organizations, don't actually produce what they were supposed to produce — and why a different time horizon than the one most organizations default to might solve more problems than a better planning template ever could.
The chart had three versions. The first showed a one-year project. The team starts with reasonable enthusiasm. Ramp-up is slow because everyone knows there's a full year ahead. Some momentum builds through the first quarter. Then come the dips — people get sick, shiny new things appear, the project competes with everyday work. Around the middle of the year something happens. A manager changes. A new corporate initiative lands. New software arrives. The original project loses standing. The team quietly recognizes that the project they defined six months ago is no longer what matters most. Then performance appraisal season approaches, and a burst of energy reappears not because the project regained importance but because the appraisal does. The chart ends with a year of nominal effort and considerably less to show for it than the initial timeline implied.
The second version showed quarterly goals — better, but not by much. The pattern of high effort followed by drift simply happened four times instead of once.
The third version showed something different. Six-week cycles separated by two-week cooldowns. The line stayed high because the cycle was short enough to sustain genuine intensity, and the cooldown was structured enough to actually reflect and plan rather than just collapse into the next thing.
Simon's argument across the session was that the time horizon of improvement work is doing more damage than most leaders recognize. Long timelines invite overplanning. They invite distraction. They invite the gradual erosion of urgency that produces the chart's familiar pattern. Shortening the horizon to six weeks — with a deliberate cooldown afterward — changes the operational physics of the work in ways that no amount of better project management training can substitute for.
The framework he walked through comes most directly from "Shape Up," the book from the Basecamp team that documents how they manage software development across a distributed team of programmers. Simon's contribution has been adapting it for businesses where improvement work has to coexist with everyday operations, and where the people doing improvement aren't full-time programmers but operators, supervisors, marketers, engineers, and anyone else with a day job to maintain.
Simon Murray is the founder of Your Maintenance Coach, based in Melbourne, Australia. He has spent over 20 years creating, leading, and coaching high-performance manufacturing teams across roles in reliability, project management, operations, and general management — from family businesses to global multinationals, from bricks to bread. He founded Your Maintenance Coach in 2012 and has worked with dozens of businesses across four continents. While his work focuses on maintenance and reliability teams, his passion is continuous improvement and finding new ways to do old things.
Simon was careful upfront about scope. Six-week cycles aren't the right structure for every kind of work. They aren't going to help you build a building or a road or any major infrastructure with a multi-year delivery horizon.
Where they work well is in businesses with a continuous flow of improvement ideas and a need for those ideas to actually become implemented improvements. The organizations Simon has worked with span everything from single-site operations with under a million dollars in revenue to fifty-plus-site enterprises with billions in revenue. Across that range, the problem he's been called in to fix is usually the same: not a lack of knowledge or tools, but a failure of sustainable implementation. People know what to do. They've been trained on the techniques. They've heard about Lean. What they can't seem to do is actually get improvements across the finish line and have them stick.
About half of Simon's time, he said, goes into researching new tools and techniques. The other half goes into change management — into the actual problem of how organizations sustain implementation over time. Six-week cycles, in his framing, are the structure that's done the most to solve that second problem in his own consulting practice and across his clients.
Simon named three specific failure modes that the six-week cycle structure addresses directly.
Chasing shiny things. When the project timeline is long, every new opportunity that appears looks like something the team can't afford to miss. The reasoning makes a kind of sense — if you have a year, what's another month spent investigating this new possibility? The result is a project team that wanders away from what they originally committed to, chases the new thing down a rabbit hole, and then can't quite remember what they were doing before the diversion started. Six weeks is short enough that when something shiny appears, the team can park it without anxiety. It's only six weeks. The shiny thing will still be there at the end. Or it won't, in which case it wasn't actually as important as it looked.
Too much detail in the planning stage. Simon acknowledged this point runs against most project management training, including his own engineering background. The conventional wisdom is that more upfront planning produces better outcomes. What Simon has observed across dozens of clients is closer to the opposite. Excessive upfront detail creates rigidity — too-specific commitments about what will be achieved and how, which leaves no room for the team to adapt as they learn. Teams that have planned themselves into a corner often discover the corner is the wrong place to be, and then they have to choose between admitting the plan was wrong or executing a plan they no longer believe in. Either choice produces poor results.
A disengaged team. This is the failure mode Simon described as most fatal to implementation. A team that didn't choose the project, doesn't see why it matters, and is participating because they were assigned to it will not produce the results a team that owns the project would produce. The work might get done in a nominal sense. The improvement might be documented. But the energy that drives genuine implementation — the willingness to push through obstacles, to make a hundred small decisions in service of the outcome, to care whether it actually works — is missing.
The six-week cycle addresses each of these failure modes through structural choices rather than through exhortation. Focus is preserved because the time horizon is short. Planning detail is bounded because there isn't time for excessive planning. Team engagement is built through the project selection process, which we'll come to.
Simon used a small analogy that landed well during the session: the birthday party.
The birthday boy or birthday girl always has an amazing day. Why? Because they chose the cake. They chose the venue. They chose the friends invited. They sent the invitations a month in advance and spent the intervening month telling everyone how excited they were. By the time the party happens, there's a real emotional investment in the day going well — built up over weeks of anticipation and ownership.
The same dynamic, Simon argued, applies to improvement projects. Teams that choose their projects are emotionally invested in making them succeed. Teams that are assigned projects are not. The difference shows up in every micro-decision the team makes across the six-week cycle. Engagement isn't a soft factor that produces marginal improvement. It's the determinant of whether the project produces results or doesn't.
Simon distilled the framework into three essential elements.
The team must choose the project. Without this, the engagement isn't there, and without engagement the structure can't compensate. The selection process Simon walked through, which we'll come to with the betting table, is the specific mechanism for making this real rather than rhetorical.
Get some quick wins early. Simon's example here was a friend named Taki, a coffee lover whose wife gave him coffee-making lessons as a Christmas present. The first lesson Taki attended started with the instructor reciting equipment names and bean-roasting theory while the students sat in rows of chairs. Taki walked out within the first half-hour and didn't go back. A few years later, his wife tried again, and this lesson was different. No chairs. An apron on the counter. The instructor put the apron on Taki, took him behind the counter where hot milk and prepared coffee were waiting, and they spent two hours attempting latte art. Was Taki any good at it? No. Did he go back for all the subsequent lessons? Yes — because he'd had a taste of what success looked like, and he could now see the gap between his current ability and where he wanted to be. The lesson generalizes: improvement projects need early wins that let the team taste what success will look like, which then sustains the effort through the less exciting middle phase.
The cooldown period. This is the element Simon thinks differentiates the framework from most other improvement methodologies, including the ones it draws from. Two weeks between cycles — not as wasted time, but as structured time for reflection, cleanup, return to day-job work, and planning the next cycle. Most project methodologies treat the gap between projects as an inefficiency to be minimized. Simon treats it as a structural necessity. Without it, teams don't actually reflect on what worked. Without it, they don't return to the day-to-day work that's been accumulating during the cycle. Without it, the next cycle starts with the residue of the last one still in the way.
Simon walked through the five-stage structure that makes the framework operational.
The pitch is the justification document for any potential project. Simon's clients use it as the entry point for any new improvement idea — submitted by anyone in the organization, reviewed by leadership, and either approved onto the project list or sent back for refinement.
The pitch contains six elements, drawn directly from the Shape Up framework:
The raw idea — what the problem actually is, phrased concretely enough that someone reading it can understand what's broken.
The appetite — how willing the organization actually is to fix this problem. This isn't a numeric metric. It's an honest assessment of whether the problem matters enough to commit resources to. Simon noted this is one element he rarely sees in other project scoping documents, and one that does significant work because it forces the conversation about whether the project should happen at all.
The solution — described in terms of outcome rather than approach. What does shipped look like? What does done look like? Not the technology or the methodology, but the visible result.
The rabbit holes — the things to be careful of. Other projects that might intersect. Other groups that need to be consulted. The places where the project could go sideways if the team isn't paying attention.
The no-gos — what's explicitly out of scope. The piece that's almost never written down in conventional project documents but that prevents enormous amounts of scope creep when it is.
A pitch that's been approved by leadership moves to the project list. The pitch itself does several jobs at once. It surfaces the appetite question early. It forces the proposer to think through the project before bringing it forward, rather than just complaining about a problem or floating an idea. It produces a small but meaningful filter on which ideas advance.
The project list is the running collection of approved-but-not-yet-active projects. It can live anywhere — Excel, KaiNexus, paper on a wall. What matters is that it's clean. These aren't ideas. These are approved projects that the business has committed to working on at some point.
During the two-week cooldown between cycles, the project list gets reviewed. Projects that have become irrelevant are removed. Projects that are still valid stay. A theme for the next cycle is identified — sometimes from a corporate priority, sometimes from a pattern in the current list (a cluster of safety projects, a cluster of product-launch work), sometimes from a recent event that has shifted what matters most.
The outcome of the cooldown review is a shortlist of projects the organization has the appetite to work on in the next six-week cycle. Not everything on the list — just what's relevant now.
The betting table is where the team picks the projects.
The mechanics are deliberately simple. Each candidate project gets written on a sticky note. The sticky notes are placed on a 2x2 grid — ease on one axis, impact on the other. Traffic-light colors mark the zones. The team works through the projects together, placing them on the grid, discussing them as they go.
The conversation is the point. The placement of any individual sticky note matters less than the discussion that surrounds it. Through the discussion, the team self-selects toward projects they care about, ranks them honestly relative to one another, and arrives at a consensus about which projects make sense for the next cycle.
Simon's framing of why this is called a betting table rather than a prioritization or project selection meeting comes from the Shape Up book. When you pick a project, you're placing a bet on it. The language is deliberate. A bet has a commitment quality that "prioritization" doesn't. You can revisit a priority. The bet, once placed, is the bet.
Simon also pulled in the Latin etymology of the word "decision" — from a root meaning "to cut off." A decision isn't about picking one thing. It's about cutting off all the other options. If the project list has fifty candidates and the team picks two for the cycle, the meaningful action isn't choosing the two. It's choosing not to do the forty-eight. That framing is what produces focus across the cycle. The team isn't carrying the weight of forty-eight other projects they might also be working on. They've cut those off. The next six weeks are about the two.
A question came in during the session about how to balance team-chosen projects with organizational needs. Simon's answer was direct: if there's serious misalignment between what the team thinks is important and what the organization needs, that's a deeper culture problem that the betting table isn't going to solve. In organizations with reasonable goal cascading and genuine engagement, the alignment is usually high. The team picks projects that the organization would also have picked, but the team picks them, which changes the energy entirely. Mark added a useful observation from his own experience: ownership often goes deeper than motivation. Motivation might get someone started. Ownership is what keeps them pushing through the inevitable obstacles to actually finish.
The project plan is where Simon's framework will scare some people and relieve others.
There are no Gantt charts. There are no individual task assignments with dates. There are no accountability columns. The project plan is a single page — Simon uses the Strategic Coach Impact Filter as his template, modified — with six sections:
The problem. Concrete, specific, clear enough that anyone reading it understands what's wrong.
The outcome. What success looks like in measurable terms.
The purpose. Why this matters. The deeper why beneath the measurable outcome.
Simon's example was instructive. A project to address low idea generation from frontline staff might have an outcome of "50 percent increase in ideas generated and implemented by frontline staff." Stop there and you have a project that becomes about hitting a number. Push to the purpose and you might get something like "we want a truly engaged motivated workforce whose ideas are acknowledged and actioned." The difference between those two framings is the difference between a project the team performs and a project the team owns. The 50 percent increase becomes a byproduct of pursuing engagement, rather than the target that the team optimizes around at the cost of everything else.
The best result. What does the most successful version of this project look like? "Amazing engagement from all, with area champions leading the idea generation process." The language is deliberately emotional. The team needs something to pull toward, not just a number to hit.
The worst result. What happens if this fails? "Staff are disengaged, turnover increases, business performance is negatively impacted." The language is again emotional. The team needs something to move away from, not just a metric they might miss.
The outcomes. This is where the project actually gets planned — but in a deliberately constrained way. The plan has space for sixteen sticky notes. Not sixteen tasks. Sixteen outcomes — chunks of work each of which represents an outcome the team will produce. Under "survey all staff" sits all the individual tasks of writing the survey, distributing it, collecting responses, and analyzing results. Those tasks live in the team's heads or in their personal task management. They don't go on the project plan. The plan operates at the level of outcomes, not tasks.
The constraint is the point. Sixteen outcomes is enough to capture the meaningful work. It's not enough to produce a detailed Gantt chart. The team has to think in terms of "what are we producing" rather than "what are we doing." This shifts the entire orientation of the work toward results rather than activity.
The tracker is a poster-sized Kanban board with three sections.
Down the left side: the projects. Each project gets a row.
At the bottom: a goal-tracking strip. Current state on the left, future state on the right, weekly check-ins in between. By the end of the cycle, where are we relative to where we said we'd be? "By October 31, we will increase the number of ideas generated per person from 10 to 15." Clear, single, visible.
In the middle: the Kanban flow itself. The columns can be customized — Simon uses building it, implementing it, checking it worked, making adjustments, monitoring impact, and done. The team moves sticky notes across the columns as the work progresses. The visual movement is the point. Watching a sticky note physically cross the board produces a different psychological effect than watching a percentage completion tick from 60 percent to 65 percent. The brain registers progress in a way that abstract metrics never quite achieve.
Simon's own tracker, visible on the wall behind him during the webinar, included eight projects organized around different elements of his consulting business. Some had nearly finished — most of their sticky notes had migrated to "done." Some hadn't started. The visual snapshot of where the cycle stood was readable at a glance, which is the point.
Simon was explicit about which parts of the framework operate continuously and which parts are bounded to the cycle.
The pitch and the project list operate continuously. Ideas come in. Pitches get written. Approved pitches go on the list. The list gets cleaned in the cooldown. None of this stops between cycles. The flow of potential improvement work is constant.
The betting table happens during the cooldown — the two weeks between cycles. The team picks the next set of projects, sets the theme, agrees on what will be worked on.
The project plan and the tracker live inside the six-week cycle. The plan is built at the start. The tracker is updated daily through the cycle. At the end of six weeks, the cycle closes. The team returns to their day-to-day work. The cooldown begins. The cycle repeats.
A question came in from Sarah about how to do any of this in environments where teams are exhausted just keeping the lights on. Healthcare IT was her specific context. The pattern generalizes — most environments where improvement work gets attempted have teams that are already running near capacity.
Simon's answer was structural and practical. Don't ask for two hours a day. Don't ask for half-days off the line. Ask for fifteen minutes.
The framing he uses with clients is "do you have fifteen minutes each day for improvement work?" The answer is almost always yes. Fifteen minutes is small enough that no one can quite refuse it. Put it in the calendar. Pick a sticky note. Work on that activity for fifteen minutes. That's it.
The compounding effect over six weeks is significant. Fifteen minutes a day across a five-person team is just over six hours of focused improvement work per week. Across six weeks, that's nearly forty hours. Not bad for an investment that no one notices as a meaningful disruption to the work day.
Simon's example was a school photography company facing an enormous seasonal surge in work. Pulling people from the production line for half-day improvement workshops was impossible. Fifteen minutes a day was sustainable. The fifteen minutes became normal. Over time it could expand — once the team had a half-hour lunch break they could occasionally extend, once a colleague covered for them on a Friday afternoon to allow a longer session. But it had to start with fifteen minutes, because fifteen minutes was the only request small enough to actually be answered yes.
The deeper point Simon made, which Mark amplified: the willingness of leadership to support even fifteen minutes a day reveals how seriously they actually take improvement work. If leadership won't support fifteen minutes, the problem isn't a lack of resources. It's a lack of will. Where there's will, there's a way to find the time. Where there isn't, no amount of methodology will compensate.
Another question came in about projects that can't be completed in six weeks. The instinct is to break them into smaller sub-projects. Simon's response was more specific than that, and the distinction matters.
Don't break a six-month project into four six-week subprojects. That just produces six-week project-management overhead without the underlying psychological structure that makes the cycle work.
Instead, ask: what can I deliver finished in six weeks? Not what's the first part of the long project. What's a complete unit of value that could stand on its own?
Simon's example was a building under construction in Melbourne — the tallest in the city at the time of the webinar. Conventionally, a building gets fully constructed before fit-out begins. This building was being fit out floor by floor as construction continued upward. A year into a multi-year project, people were already living in the building. Each completed floor was a complete unit of value, even though the project as a whole wasn't done.
That's the right model for breaking down longer work. Find the floor that can be lived in. Build it. Move to the next floor.
For software, the equivalent is the two-week sprint where something shippable has to be ready at the end. For an organizational improvement program, the equivalent is the six-week cycle where some piece of the larger transformation has to be deliverable and complete by the end, even if the broader transformation continues for years.
The framework Simon described is a sustainable execution rhythm. The disciplines that make it work — writing pitches, running betting tables, maintaining project lists, tracking progress visually, holding deliberate cooldowns — are human disciplines that no software performs on a leader's behalf. The team has to write the pitches. The team has to argue at the betting table. The team has to move the sticky notes.
What infrastructure does in this context is keep the framework operational across the scale most organizations actually run at. A single team running six-week cycles on a wall in their break room can sustain the framework with sticky notes and a tracking poster. An organization with twenty teams running six-week cycles in parallel cannot. The pitches accumulate. The project lists multiply. The themes across teams need coordination. The leadership visibility into what's happening across all the cycles becomes structurally difficult to maintain on physical artifacts that live in twenty different rooms.
The pitch-and-project-list flow Simon described is the kind of work infrastructure can carry well — capturing ideas, routing them for approval, maintaining the running list of approved-but-not-active projects, and surfacing them for selection at the start of each cooldown. The betting table itself is a human conversation, but the inputs to the conversation come from somewhere, and the somewhere needs to be findable when the team needs it.
The tracker is a visual artifact that benefits from being physical when the team is colocated, and that benefits from being digital when the team is distributed. Simon noted during the session that during Melbourne's lockdown his clients had moved to software-based versions of the tracker. The discipline of physically moving something — clicking and dragging a virtual sticky note, even — remains. The brain registers the movement. The percentage completion bar doesn't produce the same psychological effect.
For organizations running multiple teams on overlapping six-week cycles, the visibility infrastructure becomes more valuable. Leadership wants to see across teams without sitting in every team's tracker review. The flow of approved pitches needs to be visible to the leaders who approve them. The pattern of which projects are getting picked and which are sitting on the list cycle after cycle becomes its own diagnostic about what the organization actually cares about versus what it says it cares about.
None of this changes what Simon was teaching. The six-week cycle is the cycle. The cooldown is the cooldown. The team choosing the project is the team choosing the project. What infrastructure does is keep the framework operational at the scale where most organizations actually live, and keep the visibility intact across teams whose work isn't physically in the same room.
Why six weeks specifically? Because six weeks is short enough to sustain genuine intensity across the entire cycle and long enough to deliver meaningful value. Longer cycles invite drift — teams lose urgency, get distracted by shiny new opportunities, and slowly disengage as the original priority loses standing. Shorter cycles don't allow enough time to ship something complete. The six-week duration, combined with a two-week cooldown, has proven sustainable across Simon's clients and his own consulting practice.
What's the cooldown period for and why does it matter? Two weeks between cycles for reflection, cleanup, return to day-job work that accumulated during the cycle, and planning the next cycle. Most project methodologies treat the gap between projects as inefficiency to be minimized. Simon treats it as a structural necessity. Without the cooldown, teams don't actually reflect on what worked, don't return to the day-to-day work that's been accumulating, and start the next cycle with the residue of the last one in the way.
Who picks the projects — the team or leadership? The team picks, with leadership having vetted the candidate list through the pitch process. The pitch establishes that any project under consideration has been approved by leadership as worth doing. The betting table then lets the team decide which of those approved projects to work on in the next cycle. The team isn't choosing from anything they want — they're choosing from a pre-vetted list. Within that list, their choice is real.
What if there's serious misalignment between what the team wants to work on and what leadership needs? Simon's answer was direct: that's a deeper culture problem the betting table won't solve. In organizations with reasonable goal cascading and genuine engagement, team-chosen projects almost always align with leadership priorities — because the team understands the priorities. Persistent serious misalignment indicates something is broken in how strategy is being communicated or how engagement is being built, and the right intervention is to address that rather than to override team choice.
Why "betting table" instead of "prioritization"? The language comes from Shape Up. A bet has a commitment quality that "prioritization" doesn't. You can revisit a priority. The bet, once placed, is the bet. The framing produces focus across the cycle. The team isn't carrying the weight of all the other projects they might also be working on — they've cut those off, in the Latin sense of "decision" (to cut off). The next six weeks are about the projects bet on, not the projects deferred.
What goes on the project plan, and why isn't there a Gantt chart? The project plan has six sections: problem, outcome, purpose, best result, worst result, and up to sixteen outcomes (not tasks). Outcomes are chunks of work that produce visible results. Tasks — write the survey, distribute it, collect responses — live in the team's heads or personal task management. They don't go on the plan. The constraint is the point. Sixteen outcomes is enough to capture the meaningful work but not enough to produce false precision about timing. The team thinks in terms of "what are we producing" rather than "what are we doing."
Why outcomes instead of tasks? Because tasks produce activity tracking; outcomes produce results tracking. A team focused on completing tasks can be busy without producing anything that matters. A team focused on producing outcomes is forced to ask whether the outcome is actually being achieved. The shift in orientation changes what the team optimizes for across the cycle.
How do you handle projects that take longer than six weeks? Don't break a six-month project into four six-week subprojects. Instead, ask: what can I deliver finished in six weeks? Find the unit of value that could stand on its own — like a single floor of a building being fully fit out while the rest of the building is still under construction. Build that unit. Move to the next one. The discipline of asking "what can be complete in six weeks" forces the project to be structured around deliverable value rather than around an arbitrary schedule.
How do you get started when teams are exhausted from day-to-day operations? Ask for fifteen minutes a day, not two hours. Fifteen minutes is small enough that no one can refuse it. Put it in the calendar. Pick a sticky note. Work on that activity for fifteen minutes. The compounding effect over six weeks is significant — across a five-person team, fifteen minutes a day produces nearly forty hours of focused improvement work over a cycle. The willingness of leadership to support even fifteen minutes is itself a test of how seriously the organization takes improvement work. Where there's will, there's a way to find the time.
Can the cycles run as a virtual version? Yes. Simon's clients in Melbourne moved to software-based versions during lockdown and the framework still worked. The Shape Up book documents how the Basecamp team uses the framework with a distributed team of programmers. The key discipline that has to survive the move to digital is the physical movement of items — clicking and dragging a virtual sticky note registers in the brain in a way that updating a percentage completion bar doesn't. Whatever tool is used, the visual movement has to be preserved.
What's in a pitch and why are there so many specific sections? Six sections: the raw idea (the concrete problem), the appetite (how willing the organization actually is to fix it), the solution (in terms of outcome, not approach), the rabbit holes (what to be careful of), and the no-gos (what's explicitly out of scope). The appetite element does particular work — it forces the conversation about whether the project should happen at all rather than just whether it could happen. The no-gos do particular work too — they prevent enormous amounts of scope creep that would otherwise happen during the cycle.
Why is choosing what NOT to do more important than choosing what to do? Because focus comes from cutting off options, not from picking among them. The Latin root of "decision" means "to cut off." If a project list has fifty candidates and the team picks two for the cycle, the meaningful action isn't choosing the two — it's choosing not to do the forty-eight. The team carries no weight from the deferred projects across the cycle. They've been cut off. The six weeks are entirely about the two.
How do you keep momentum across a longer initiative that spans multiple cycles? Each cycle has to deliver something complete and valuable on its own. The team finishing a cycle should be able to walk away from everything else and the value delivered would still stand. The next cycle picks up from a complete unit, not from a half-finished one. This is structurally different from breaking a long project into smaller pieces — it requires designing the work itself around deliverable units of value rather than around schedule chunks.
.svg)
Copyright © 2026
Privacy Policy