The method
FREE GRID™
Framework for Repeatable Execution & Efficiency. Four pillars: Governance, Rhythm, Integration, Durability.
“I didn’t create FREE GRID™ in a classroom. I built it in the spaces where the cost of unclear systems is measured in mission failure, not missed deadlines.”
In the Navy, I watched divisions of capable people produce inconsistent results because nobody had defined who owned what, when reviews happened, or how any of it would survive a personnel rotation. In university governance I saw the same pattern with different vocabulary: authority clear on paper, unclear in the room. At the Pentagon I was handed complex, multi-stakeholder work with no playbook and real consequences downstream.
Each time the failure had the same shape, and it was never a shortage of effort or intelligence. It was that the system for turning intent into action had never been built, or had been built once and left to erode.
FREE GRID is that system, written down. It addresses four specific failure modes: unclear ownership, inconsistent rhythms, siloed coordination, and institutional knowledge that leaves when people do.
What follows is the whole method — the definitions, the questions to ask about your own organization, what each failure looks like from the inside, and the first repair for each. It is written so you can use it without us.
If you would rather be told which pillar is your constraint than work it out, that is what the Diagnostic does.
Governance
Decision rights, ownership, accountability, and escalation.
Governance is not your org chart. It is the answer to a narrower question: for any given decision, who decides, who must be consulted, and what happens when they disagree.
Ask yourself three questions
- Name the last significant decision your team made. Can you say who made it, without checking?
- When a decision is made in a review meeting, is a named person and a date recorded before the meeting ends?
- When two leaders want opposite things, is there a written rule for who breaks the tie — or does it depend on who escalates hardest?
What it looks like when this is weak
Decisions get made twice. The first time in the meeting, the second time three weeks later when someone who was not in the room reopens it. Work restarts. Nobody is obstructing anything; the authority to close the question was simply never assigned.
The first repair
Write down who decides for the five decisions your team makes most often.
- List the five decisions that recur most — the ones you have argued about more than once.
- For each, name one person who decides. One. Not a committee, not a role, a person.
- For each, name who must be consulted first, and who only needs to be told afterwards.
- Put it on one page and send it to everyone it names. Expect two of them to object — that objection is the work, and it is cheaper now than mid-quarter.
You will know it took when: A decision you would have relitigated stays closed, and you can point at the line that closed it.
Rhythm
Meetings, reviews, information flow, decisions, and learning cadence.
Rhythm is the cadence at which your organization notices things. Not how often you meet — how quickly a problem that appears on Monday reaches someone who can act on it.
Ask yourself three questions
- What is the longest a serious problem could go unnoticed before it surfaces in a standing meeting?
- Does your weekly review end with decisions, or with updates?
- When something went wrong last quarter, was there a scheduled moment where the team examined it — or did everyone just move on?
What it looks like when this is weak
The status meeting is well attended, well prepared, and decides nothing. People report what they did. Nobody leaves with a changed priority. The meeting has become a ritual for demonstrating effort rather than a mechanism for redirecting it — and everyone privately knows it, which is why the real decisions happen in the hallway afterwards.
The first repair
Give your weekly review a decision agenda instead of a status agenda.
- Before the meeting, ask each owner for one thing they need decided — not a summary of their week.
- Put those decisions on the agenda by name. If there are none, cancel the meeting; you have just learned something.
- End every item by recording the decision, the owner and the date, out loud, before moving on.
- Keep the log where the team can read it. The log is the point; the meeting is only how it gets written.
You will know it took when: The meeting gets shorter and the hallway conversations afterwards stop.
Integration
Dependencies, handoffs, shared outcomes, and cross-functional synchronization.
Integration is what happens at the seams. FREE GRID’s argument is that execution fails less often inside a team than in the handoff between two teams who each did their part correctly.
Ask yourself three questions
- Can you name every team your current priority depends on, and does each of them know they are on that list?
- When work moves from one team to another, is there a defined moment where it is handed over — or does it just appear in someone’s queue?
- Which dependency, if it slipped by two weeks, would you find out about last?
What it looks like when this is weak
Two teams discover the same dependency in week nine of a twelve-week effort. Both are certain they raised it. Both are probably right — they raised it in different rooms, to different people, neither of whom owned the seam between them.
The first repair
Map the dependencies for one priority, and give every seam an owner.
- Take your most important current effort. List every team whose work it needs.
- For each, write the specific thing you need and the date you need it.
- Send that list to each of those teams and ask one question: can you do this, by then?
- The answers you get back are your real plan. The disagreements are the dependencies you were about to discover in week nine.
You will know it took when: A dependency slips and you hear about it in week two rather than week nine.
Durability
Continuity, capability transfer, adaptation, institutional memory, and the ability to survive leadership or environmental change.
Durability is whether the organization survives losing people. Every operating system works while the person who built it is still there; the question is what happens the week after they leave.
Ask yourself three questions
- If the person who understands your most important process left on Friday, what breaks on Monday?
- Can you find the reasoning behind a significant decision made a year ago — not the decision, the reasoning?
- For each critical responsibility, is there a second person who has actually done it, rather than someone nominated to cover it?
What it looks like when this is weak
Someone asks why the process works this way and the honest answer is that nobody currently employed knows. So the team either preserves a constraint that stopped applying two years ago, or removes it and rediscovers, expensively, why it was there.
The first repair
Start a decision log, and write down the reasoning — not just the decision.
- One page, one entry per significant decision. Date, decision, what else was considered, why this one, who approved it.
- Add the next decision you make. Do not backfill a year of history; you will stop.
- When a decision is superseded, add the new entry and point it at the old one. Never edit the old one — a log you rewrite is a log nobody trusts.
- Review it once a quarter. Most entries will be uninteresting. The two that are not will pay for the whole practice.
You will know it took when: Someone new answers a "why do we do it this way" question without asking anyone.
How the four interact
You do not get to pick your best one.
The weakest pillar sets the ceiling for the whole system.
| Pillar | Illustrative height |
|---|---|
| Governance | 34 of 100 |
| Rhythm | 78 of 100 |
| Integration | 62 of 100 |
| Durability | 71 of 100 |
| System ceiling | 34 of 100, set by the lowest pillar |
- A decision that nobody owns cannot be executed on a good cadence — it will simply be made again next week.
- A perfect cadence cannot rescue a handoff nobody owns; the meeting will surface the same problem repeatedly and resolve it nowhere.
- Handoffs that work today stop working the moment the person who understood them leaves.
- And durability is meaningless without decisions worth preserving.
So the four are not a menu. Improving your strongest pillar is the most comfortable work available and it changes nothing. The return is in the weakest one, which is usually the one nobody wants to open.
This is also why the Diagnostic weights the minimum rather than averaging the four. An organization scoring 80, 80, 80 and 30 is not a 68. It is a 30 with three strengths it cannot spend.
If you would rather not do it alone
What an engagement actually involves.
Everything above is yours to use. This is what it looks like when Gerode runs it with you.
It starts with the Diagnostic — 2 weeks, $5,000–$10,000. Four to six interviews, a four-pillar score, a findings memo, a risk map and a 30-day action sequence.
The output is a named binding constraint, not a list of everything that could be better. You can act on it yourself, and plenty of organizations should.
Where the constraint is structural rather than a matter of attention, the Sprint builds the operating system around it over four to six weeks: decision rights written down and agreed, a review cadence with consequences attached, dependencies owned, and a 90-day plan somebody has approved.
What is explicitly not included
- Implementation labour — Gerode designs the operating system; your team runs it.
- Legal, tax, accounting, or insurance advice.
- Classified analysis, or any work requiring access to controlled information.
- Software development.
- Unlimited revision rounds.
Stating this up front is doctrine, not modesty. An engagement that has not agreed its edges has not been scoped.