Navigate
"The hardest part isn't the strategy. It's getting humans to follow it."
Navigate Process
Navigate drives adoption through the hardest part of any transformation - getting humans to follow a new system. It identifies allies, manages politics, trains the team, and handles the hard decisions with humanity. The goal: leave behind a system that runs without you.
Change Management
Why it matters
Every recommendation from R-E-C-O will die if the organization can't adopt it. Strategy without adoption is just a slide deck. The research was thorough, the exposure plan was sharp, the conversion system is built, the operating rhythm is designed - and none of it matters if the people who need to execute it won't, can't, or don't understand why they should.
How to do it
Level 1 - Map stakeholders by influence and attitude
Plot every person involved on two axes: influence (how much power they have over adoption) and attitude (supportive, neutral, or resistant). This creates your political map:
Level 2 - Design communication strategy per group
Different groups need different approaches. Supporters get early access and ownership roles - they become your internal advocates. Neutrals get data and quick wins that prove the system works. Resistors get transparency and time - they need to see that this isn't a threat, it's an upgrade.
Level 3 - Build adoption milestones with visible wins
People need to see that the new system works before they'll trust it. Front-load the quick wins. A visible improvement in the first two weeks buys more credibility than a 90-day strategy deck. Each milestone should be measurable, communicable, and tied to something the team already cares about.
Change Management Checklist
- Mapped all stakeholders by influence × attitude
Plot on two axes: influence (power over adoption) and attitude (supportive/neutral/resistant). This is your political map.
- Created communication plan per stakeholder group
Supporters get early access. Neutrals get data and quick wins. Resistors get transparency and time.
- Identified 3+ quick wins executable in first 2 weeks
Front-load visible improvements. A win in the first two weeks buys more credibility than a 90-day strategy deck.
- Executed quick wins and communicated results
Don't just do the win - broadcast it. The team needs to see that the new system produces results.
- Designed adoption milestones with measurable outcomes
Each milestone: measurable, communicable, tied to something the team already cares about.
- Created feedback channel for concerns/resistance
People need a way to voice concerns without fear. Unheard resistance goes underground and becomes sabotage.
- Scheduled weekly check-ins during transition
The transition period is fragile. Weekly check-ins catch problems before they become crises.
- Documented adoption progress and blockers
Track what's working and what's stuck. This documentation drives the next week's priorities.
Leading with the big scary changes. Start with quick wins that build trust. If the first thing people hear is "we're cutting agencies and restructuring," they stop listening. If the first thing they see is "we found $8K/month in wasted spend and fixed it," they lean in.
Real-world example: Instead of announcing "we're cutting 3 agencies and restructuring the team," started with "we found a tracking error costing $8K/month in misattributed spend - it's fixed." Quick win, visible savings, trust earned. Then the harder conversations happened from a position of credibility.
Ally Identification
Why it matters
Your allies already exist inside the organization. They knew the problems were real but had no data, no platform, and no authority to make change happen. They've been frustrated by the same broken processes you're now fixing. Finding them early turns a solo effort into a movement.
How to do it
Level 1 - Identify by behavior
Who asks hard questions in meetings? Who's frustrated by the status quo? Who's been quietly collecting data that nobody uses? These people aren't hard to find - they're the ones who light up when you show them that someone finally has the evidence to back up what they've been saying for years.
Level 2 - Engage early with data
Share findings before the big reveal. Give them context. They become advocates because the data validates what they've been saying. This isn't manipulation - it's giving credit where it's due and building a coalition that can push change from multiple directions simultaneously.
Level 3 - Give them roles in the new system
The person who asked "how do we know this works?" becomes the person who measures whether it works. The person who flagged wasted spend becomes the budget owner. Allies aren't just supporters - they're the future operators of the system you're building.
Ally Identification Checklist
- Identified 3+ potential allies based on behavior/questions
Who asks hard questions in meetings? Who's frustrated by the status quo? Who's been quietly collecting data nobody uses?
- Shared early findings privately with allies
Give them data before the big reveal. They become advocates because the data validates what they've been saying.
- Gathered their input on organizational dynamics
Allies know the political landscape better than any outsider. Their input shapes your approach to resistance.
- Assigned allies meaningful roles in new system
The person who flagged wasted spend becomes the budget owner. Allies aren't just supporters - they're future operators.
- Verified each ally has decision-making authority in their domain
Enthusiasm without authority creates cheerleaders, not change agents. Your allies need to be able to act on what they advocate.
- Leveraged allies to communicate changes peer-to-peer
Peer recommendations beat top-down mandates. When allies champion the change, adoption accelerates.
- Created communication channel for ally coordination
A shared space where allies can flag resistance, share wins, and coordinate messaging. The network needs a nervous system.
- Documented ally network for ongoing change support
Your ally network persists after you leave. They're the immune system that protects the new system.
Assuming seniority = ally. The most senior people often have the most to lose from change. Your strongest allies might be mid-level people who've been waiting for someone to validate what they already knew.
Real-world example: The junior marketing coordinator who'd been asking "but how do we know these LinkedIn posts work?" for two years became the analytics lead under the new system. She had the questions. RECON gave her the framework and authority to find answers.
Training & Handover
Why it matters
If the system needs you to maintain it, you haven't built a system - you've built a dependency. The goal is a team that can run everything independently. Every process, every decision framework, every reporting cycle should work without the person who designed it standing over it.
How to do it
Level 1 - Document every process where people actually work
Not in a slide deck that sits in a shared drive. SOPs go in the project management tool. Decision frameworks go in the reporting dashboard. Checklists go where the work happens. If documentation isn't embedded in the workflow, it won't get used - and documentation nobody uses doesn't exist.
Level 2 - Train through doing
Run the first reporting cycle together. Make the first decision from data together. Handle the first failed experiment together. Learning happens in the doing, not the watching. By the fourth cycle, they won't need you. But they need you for the first three - coaching, not presenting.
Level 3 - Build self-correction mechanisms
What do you do when a metric deviates? When a process breaks? When a test result is ambiguous? The team needs decision trees, not just instructions. A good handover doesn't just teach people what to do - it teaches them what to do when things go wrong.
Training & Handover Checklist
- Documented all processes in accessible locations (not slide decks)
SOPs in the project management tool. Decision frameworks in the reporting dashboard. Where the work happens, not a shared drive.
- Created decision frameworks for common scenarios
What to do when a metric deviates. When a process breaks. When a test result is ambiguous. Decision trees, not just instructions.
- Ran first reporting cycle with team (coaching, not presenting)
Do it together. You pull the data, they interpret. They propose actions, you coach. By cycle 4, they won't need you.
- Made first data-driven decision together
The team needs to experience making a real decision from real data with real consequences. That's how trust in the system builds.
- Handled first failed experiment together
Failure is part of the system. Show the team how to handle it: document, learn, adjust, move on. No blame.
- Built self-correction guides for metric deviations
A good handover teaches not just what to do - but what to do when things go wrong.
- Tested team's ability to run independently (shadow period)
Step back. Watch. Only intervene when asked. If they can run a full cycle without you, handover is working.
- Created escalation paths for edge cases
Not everything fits a decision tree. Define when and how to escalate unusual situations.
- Scheduled 30/60/90-day check-ins post-handover
Graduated independence. Check-ins get lighter over time. By day 90, it should be a 15-minute confirmation call.
- Collected feedback on what's unclear or missing
The team will find gaps you didn't anticipate. Collect this feedback and fill the gaps before they become habits.
Training via slide deck. Nobody learns from slides. Train by doing - run the first reporting cycle together, make the first decision from data together, handle the first failed experiment together. By the fourth cycle, they won't need you.
Real-world example: Instead of a 40-slide "How to Use the New Marketing Dashboard" deck, spent 4 weekly sessions where the team pulled the data, identified anomalies, proposed actions, and made decisions - with coaching. By week 5, they didn't need coaching.
Hard Decisions
Why it matters
Some transformations require removing people, ending vendor relationships, or restructuring teams. Avoiding the hard decisions doesn't make them go away - it makes the entire system fail because everyone sees that accountability has limits. The team watches how you handle the difficult parts. That tells them whether the new system is real or performative.
How to do it
Level 1 - Identify what needs to change
People whose roles no longer exist. Vendors whose services are being brought in-house. Structures that don't serve the new system. Map every required change - not just the easy ones. The ones you're avoiding are usually the ones that matter most.
Level 2 - Plan transitions with dignity
Adequate notice. Genuine help finding new roles. Public support. How you handle exits defines the culture that remains. Write better recommendations than they deserve. Make real introductions, not empty promises. The remaining team is watching - how you treat people on the way out tells them whether they're safe or scared.
Level 3 - Manage perception for the remaining team
Silence breeds fear. Communicate what changed and why at the appropriate level. Make clear the criteria are performance-based and systematic, not political or personal. Schedule 1:1s. Answer hard questions directly. The team needs to know that accountability applies to everyone - including the people making the decisions.
Hard Decisions Checklist
- Identified all roles/vendors/structures requiring change
Map every required change - not just the easy ones. The ones you're avoiding are usually the ones that matter most.
- Created transition timeline with adequate notice periods
Adequate notice - not the minimum legal requirement, adequate human notice. How you exit people defines the culture that remains.
- Prepared support for affected individuals (recommendations, introductions)
Write better recommendations than they deserve. Make real introductions, not empty promises. The remaining team is watching.
- Planned communication to remaining team
Silence breeds fear. Communicate what changed and why at the appropriate level. Be direct. Answer hard questions.
- Documented that decisions are data-driven and systematic
Make clear the criteria are performance-based, not political or personal. The data trail protects everyone.
- Scheduled 1:1s with remaining team to address concerns
People need to ask questions privately. 'Am I next?' is a real question that deserves a direct answer.
- Monitored team morale post-change
Watch for signs of fear, disengagement, or quiet quitting. Address it early. Silence doesn't mean acceptance.
- Updated processes to reflect new structure
Remove references to roles that no longer exist. Update ownership. Close the gap between documentation and reality.
Firing someone and letting the team fill in the narrative. Silence breeds fear. Communicate what changed and why (at appropriate level), and make clear the criteria are performance-based, not political.
Real-world example: After the agency audit, one agency needed to go. Instead of a cold email, held a call: acknowledged what they'd done well, explained the strategic shift, gave 60 days notice instead of 30, offered a public recommendation. The agency's founder later referred a client. Burning bridges has a cost. Not burning them has a return.
The Output: A Self-Running System
Navigate produces the end state of the entire RECON process: a self-running system where the team owns the processes, makes data-driven decisions independently, and has the framework to adapt when things change.
What Navigate Leaves Behind
- Stakeholder alignment - everyone understands what changed and why
- Internal advocates - allies embedded in the system who maintain momentum
- Trained team - people who can run reports, make decisions, and correct course independently
- Decision frameworks - self-correction mechanisms for when things break or deviate
- Clean transitions - hard decisions handled with dignity, culture intact
- Zero external dependency - the system runs without the person who built it
This is the end state: numbers rule, accountability is built in, and external dependency is eliminated. The business doesn't need a consultant to maintain what RECON built. It needs a team that understands why the system works - and that's exactly what Navigate creates.