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
| Type | Primary channel | Source of truth | Escalate when | Level | Gap |
| Announcements | #announcements | Wiki / linked doc | Changes policy or ownership | 1 | — |
| Team coordination | Team channel | Not permanent | Blocker >24h | 2 | — |
| Project execution | Airtable | Airtable | Unclear ownership | 2 | — |
| Decisions | Meeting / thread | Decision log Build | Cross-functional / unresolved | 3 | |
| Brainstorming | Thread / channel | Google Doc | Output needs a decision | 1 | — |
| Escalations | #management-team | Decision log | See escalation ladder | 2→3 | — |
| Process / policy | Draft → review | Wiki (final) | Affects multiple teams | 2 | Checklist |
| Client / account | HubSpot | HubSpot + Airtable | External comms pending align | 2 | — |
| Meeting outcomes | Fathom | Fathom + decision log | Actions unclaimed >48h | 2 | Logging |
| Strategic initiatives | monday.com | monday.com | Resource or priority conflict | 3→4 | — |
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?
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
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
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
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.
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.
Escalate at this level when
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
Move to Level 2 when
Stalled more than 24–48h with no resolution
Ownership is unclear or resolving it requires someone else's authority
Escalate at this level when
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
How to escalate
Post in the relevant team channel with context — what you tried, what's blocked, what you need. Tag your lead explicitly.
Escalate at this level when
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
How to escalate
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.
Escalate at this level when
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
This is NOT a Level 4 situation
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
How to escalate
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