TGL
Communication Pathway Map
Where signals go · where truth lives · when to escalate
v1.0 · Internal
For the CEO: Route by type, not urgency. Not everything belongs at Level 4. This page answers two questions — where does this go, and how do I get something moving?
Routing table
I have an idea
Escalation ladder
Rules of engagement
TypePrimary channelSource of truthEscalate whenLevelGap
Announcements#announcementsWiki / linked docChanges policy or ownership1
Team coordinationTeam channelNot permanentBlocker >24h2
Project executionAirtableAirtableUnclear ownership2
DecisionsMeeting / threadDecision log BuildCross-functional / unresolved3
BrainstormingThread / channelGoogle DocOutput needs a decision1
Escalations#management-teamDecision logSee escalation ladder23
Process / policyDraft → reviewWiki (final)Affects multiple teams2 Checklist
Client / accountHubSpotHubSpot + AirtableExternal comms pending align2
Meeting outcomesFathomFathom + decision logActions unclaimed >48h2 Logging
Strategic initiativesmonday.commonday.comResource or priority conflict34
This pathway is for you specifically. When you have a new idea, product direction, or policy change — use this to move it from your head into the system without creating confusion or false starts downstream.
What kind of idea is it?
New product or service idea
Before you share it with the team: Write it down first — one paragraph: what it is, who it's for, what problem it solves. This forces clarity and prevents the team from spinning on a half-formed idea.

Step 1: Draft in a Google Doc. Don't share yet.
Step 2: Gut-check with one trusted person.
Step 3: Create a Rock in monday.com with an owner, goal, and first next step.
Step 4: Introduce in a leadership meeting — not Slack. Frame as: "Here's the idea, here's who owns it, here's the first milestone."
Step 5: Announce to the broader team only after ownership and first steps are clear.
Draft in DriveRock in mondayIntro in leadership meeting#announcements after
New policy or process change
Before you announce it: A policy announced before it's fully formed creates confusion and forces you to walk things back. Draft it, review with affected teams, then publish.

Step 1: Draft in a Google Doc — what changes, who it affects, when it takes effect, and why.
Step 2: Share with leads of affected teams for input — set a clear feedback deadline.
Step 3: Finalize and publish to the wiki.
Step 4: Log the decision in the decision log.
Step 5: Announce in #announcements with a wiki link. Update Airtable or monday if it affects workflows.
Draft in DrivePublish to WikiLog decision#announcements
Shift in priorities or direction
The risk here is silent pivoting — you change direction in your head, mention it in one conversation, and three teams are now working toward different goals.

Step 1: Bring to leadership first — #management-team or next leadership meeting. Get alignment before it goes wider.
Step 2: Update monday.com to reflect the new priority. Archive or deprioritize what's changing.
Step 3: Log the decision — priority shifts must be on record.
Step 4: Communicate to the full team via #announcements: what's changing, what's staying, what people should do differently.
#management-team firstUpdate mondayLog decision#announcements
Quick directive or immediate change
Even fast decisions need a record. The temptation is to post in Slack and move on — but if it affects how people work, it will cause confusion without a written record.

Step 1: Post the directive in the right channel — #announcements for company-wide, #management-team for leadership-only.
Step 2: Log it in the decision log within 24 hours. Even one paragraph is enough.
Step 3: If it changes a process, update the wiki within the week — don't let it live only in Slack.
Post in right channelLog within 24hUpdate wiki if process change
The most common CEO communication failure at a scaling startup: sharing an idea before it has an owner, a next step, or a home in the system. The team hears it as a directive and starts moving — in different directions. The rule: if you're not ready to name an owner and a first step, the idea isn't ready to share yet.
1
Handle it at owner level
Routine coordination, individual blockers — anything one person can resolve
Task stuck <24hClarification neededRoutine handoffs
2
Team lead / manager
Blocker >24–48h, unclear ownership, cross-person friction, client judgment call
Blocker stalledTwo people can't alignDeadline at risk
3
Leadership → #management-team
Cross-functional conflict, resource decision, process gap, multi-team impact
Two teams can't alignResource neededPolicy required
4
CEO — last resort
Company-level tradeoff, strategic direction, exception to core policy, leadership split
Company direction at stakeLeadership conflictCore exception
For the CEO: If something reaches you that should have been resolved at Level 2 or 3, redirect it — don't just answer it. Every time you solve a Level 2 problem, you train the team that Level 2 doesn't exist. The ladder only works if all four levels are real.
1Slack is for speed, not permanence. If it needs to last, it doesn't live in Slack.
2If work needs to happen, it's in Airtable or monday. Slack threads are not task lists.
3Decisions that change priorities, ownership, or process must be written down. If it's not logged, it didn't happen.
4If it will be referenced again, it belongs in the wiki or a durable doc. Not a Slack thread.
5Meetings are for deciding and solving — not reading updates aloud. Async first for status.
6Escalate by pathway, not urgency feeling. Follow the ladder.
7The person closest to the work communicates first — unless it's a company-level message.

Known gaps — close these in order
Decision log not yet built — decisions being lost
No async leadership channel — everything in meetings
Process rollout not standardized
Project execution fragmented in client channels
Add: decision log (start with Google Doc)
Add: #announcements + repurpose #management-team
Add: #team-delivery for cross-client visibility
Add: process rollout checklist
Channel structure
Source of truth
Decision log
Escalation matrix
Company-wide — everyone is a member
#announcements
Official company updates only. No replies. Leadership posts only. Links to wiki or doc for detail.
Add
#general
Culture, wins, kudos, lightweight all-company chat. Not for task coordination or decisions.
Keep
#fun
Social, off-topic, team culture. Load-bearing for a remote team — protect it.
Keep
#help
Cross-functional questions with no clear home. Repeated questions = wiki gaps to fix.
Keep
#hr-announcements
HR and people-specific updates only. Separate from operational announcements.
Keep
Functional teams
#management-team
Repurposed as leadership sync + escalation surface (Level 3). Escalations, decisions, async leadership rhythm. Decision log linked here.
Repurpose
#team-ps
Professional services coordination. Rename from #professional-services. Pin purpose: coordination only — records in Airtable.
Rename
#team-delivery
Cross-client project coordination. The place to see all active delivery work at once. Airtable is source of truth.
Add
#team-ops
Ops coordination. Process questions, system updates, internal logistics. Wiki is source of truth.
Add
Client channels — coordination only, not record-keeping
#client-[name]
Account-specific coordination only. Client records live in HubSpot. Project records live in Airtable. Channel is the coordination surface, not the record.
Fix purpose
Project channels — created as needed, archived on completion
#proj-[name]
Cross-functional projects that need their own coordination surface. Archive — don't delete — when complete.
As needed
Channel hygiene rules: Use threads always. Move outputs to their durable home. Archive proj- and client- channels when work is complete. If the same question gets asked twice in #help, write it up in the wiki.
Tool
Owns
Does NOT own
Slack
Quick coordination · announcements · escalation signals · culture
Final decisions · task tracking · client records · anything you'll need in 3 months
Airtable
Project execution records · status and blockers · handoff notes · decision log
Strategic priorities · SOPs · working drafts · client relationship records
HubSpot
Client contact records · relationship history · deal pipeline · external comms history
Project execution · delivery status · internal process docs
monday.com
Strategic priorities · Rocks · initiative ownership · cross-functional milestones
Day-to-day execution · client records · process documentation
Wiki
Company-wide SOPs · role definitions · policies · technical specs · onboarding guides
Working drafts · client-specific docs · project execution detail
Google Drive
Working drafts · PRDs · proposals · client/project-specific docs in client folder · templates
Final published process (→ wiki) · client relationship records (→ HubSpot)
Fathom
Meeting summaries · transcripts · decision recall · follow-up reference
The decision log · task ownership · policy documentation
Document scope rule: Client or project-specific docs → client's Google Drive folder. Technical specs and standards that apply across all work → wiki. If in doubt, ask: does this apply to one client/project, or to TGL generally?
Required fields — every decision log entry needs these
Title required
One sentence, plain language, searchable 6 months from now
Date required
When it was made — not when it was logged
Type required
Process/policy · Priority/strategy · Ownership/roles · Client/project
Owner required
One person — not a team. Accountable for follow-through.
What was decided required
Clear enough that someone who wasn't in the room can act on it
What changes
What stops, starts, or changes — who is affected, what to do differently
Why
Context and tradeoffs — especially valuable for decisions that will seem strange later
Who needs to know
Names or teams — drives the communication step
Documented at
Link to wiki page, SOP, Airtable record, or Google Doc
Review date
For provisional decisions only — leave blank for permanent ones
When to log: If it changes how someone works · changes who owns something · would cause confusion if forgotten · or was made at Level 3 or 4. Everything else doesn't need to be logged.

Mental test: "Would a new hire need to know this decision was made?" If yes, log it.

Where to start: Google Doc this week. Migrate to Airtable within 30 days once you know what fields you actually need.
Click any level to expand its triggers and how-to.
1
Handle it yourself
Direct owner · peer-to-peer
You have the authority and information to resolve it alone
It affects only your own work or one other person
It can be resolved peer-to-peer within 24 hours
Stalled more than 24–48h with no resolution
Ownership is unclear or resolving it requires someone else's authority
2
Bring in your manager
Team lead · functional manager
Blocker stalled more than 24–48h
Two people can't agree on ownership or approach
Work is at risk of missing a deadline due to a dependency
A client situation needs a judgment call beyond your authority
Post in the relevant team channel with context — what you tried, what's blocked, what you need. Tag your lead explicitly.
3
Bring to leadership
#management-team
Two teams or functions can't align and it's blocking delivery
A resource or capacity decision affects more than one team
A process gap needs a policy decision
Decision will affect how multiple teams work going forward
Post in #management-team: what's blocked, what's been tried, what decision is needed, and your recommended path. Come with a proposed answer. All Level 3 decisions get logged.
4
CEO decision required
Last resort only
Genuine company-level tradeoff — affects mission, strategy, or core commitments
Leadership is split and the decision can't wait
Significant unplanned risk — legal, financial, reputational, or client-critical
You want validation on a decision you can make yourself
It feels urgent but hasn't cleared Levels 2 or 3
You're escalating because it's faster, not because it requires CEO authority
DM or #management-team. Include: what's at stake, what's been tried, what decision is needed, and your recommendation. All Level 4 decisions are logged — mandatory.
Stall rule: If something has been unresolved for more than 48 hours, it has already escalated — it just hasn't been named yet. Escalating early is good judgment, not failure.
Next steps to get operational: 4 phases · approval → quick wins → leads briefing → full team launch → embed & review
Approval
& feedback
Quick
wins
Leads
briefing
Team
launch
Embed
& review
1
CEO feedback and approval
This week · async · 1–2 days
Pending
Gate: Do not move to Phase 2 without CEO approval. Leadership alignment is what gives this framework authority across the team.
2
Quick wins — implement immediately
Week 1 · no briefing required · low friction
This week
Why these first: These changes require no team buy-in, take less than an hour, and create immediate visible progress. The system starts becoming real before the briefing happens.
3
Team leads briefing
Week 2 · dedicated session · 30–45 minutes
Team leads
Key goal: Make leads feel like co-owners, not recipients. Their buy-in is what makes the team launch land. If a lead pushes back on something, take it seriously — they know their team's reality better than the artifact does.
4
Full team launch
Week 3 · #announcements · company-wide
Full team
Tone matters: The launch announcement should feel like "this is how we work now" — not "here are some suggestions." Framing it as already in motion (channels live, decision log started) makes it real, not aspirational.
5
Embed and review
Week 4 onward · ongoing · quarterly cadence
Ongoing
At least 3–5 decisions logged in the decision log
Escalations showing up in #management-team, not just DMs or meetings
#help being used for cross-functional questions and answers moving to the wiki
Project status being updated in Airtable, not just discussed in client channels
Jacob receiving fewer direct messages for things that can be resolved at Level 1 or 2
The most important thing at this stage: Assign an artifact owner. A communication system that nobody maintains will drift back to old patterns within 90 days.