TGL Communication Pathway Map

CEO one-pager

Full reference

Rollout plan

For the CEO: This map covers both internal and external communication. Route by type, not urgency. Each pathway has a defined home, a source of truth, and a clear escalation path.

Routing table

I have an idea

People pathway

Escalation ladder

Rules of engagement

Internal communication

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
Escalations	#management-team	Decision log	See escalation ladder	2→3	—
Process / policy	Draft → review	Wiki (final)	Affects multiple teams	2	—
Strategic initiatives	monday.com	monday.com	Resource or priority conflict	3→4	—
Meeting outcomes	Fathom	Fathom + decision log	Actions unclaimed >48h	2	Logging
People situations Issues, departures, terminations	CEO + HR (private)	HR records	See people pathway tab	4	—
New hire onboarding	HR-led process	Wiki + HR records	CEO support needed	2	Standardize
Board / investor updates	CEO-authored	Google Drive	Significant company event	4	No cadence

External communication

Type	Primary channel	Source of truth	Escalate when	Level	Gap
Routine client comms Authorized members only	Email / client channel	HubSpot	Risk, scope change, or dispute	2	No sign-off rule
Client escalation Bad news, disputes, risk	Internal align first	HubSpot + decision log	Any risk to relationship or contract	3	No protocol
Public client mentions Case studies, press, social	Draft → internal → client approval	Google Drive	Client hasn't approved	3	No process
Board / investor comms	CEO-authored	Google Drive	Significant company event	4	No cadence
Vendor / contractor	Email / contract	Google Drive	Scope or payment dispute	2	—
Client portal Project visibility & deliverables	TGL Client Portal	Client Portal	Client can't access or content is wrong	2	—

Internal = stays inside TGL External = leaves TGL highlighted = source of truth = known gap

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. Internal

What kind of idea is it?

New product or service idea

Before you share it: Write it down first — what it is, who it's for, what problem it solves.

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.
Step 5: Announce to the broader team only after ownership and first steps are clear.

Draft in DriveRock in mondayLeadership meeting#announcements after

New policy or process change

Before you announce it: Draft it, review with affected teams, then publish.

Step 1: Draft in a Google Doc — what changes, who it affects, when, and why.
Step 2: Share with leads of affected teams for input — set a 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.

Draft in DrivePublish to WikiLog decision#announcements

Shift in priorities or direction

The risk here is silent pivoting — you change direction in your head and three teams are now working toward different goals.

Step 1: Bring to leadership first — #management-team or next leadership meeting.
Step 2: Update monday.com to reflect the new priority. Archive what's changing.
Step 3: Log the decision — priority shifts must be on record.
Step 4: Communicate to the full team via #announcements.

#management-team firstUpdate mondayLog decision#announcements

Quick directive or immediate change

Even fast decisions need a record. If it affects how people work, it needs to be written down.

Step 1: Post 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.

Right channel firstLog 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. Rule: if you're not ready to name an owner and a first step, the idea isn't ready to share yet.

This pathway covers all sensitive people situations — performance issues, interpersonal conflict, voluntary departures, and involuntary terminations. The communication cascade is the same in every case. Internal only — never external

Two tracks — same communication cascade

Track A — Senior staff

CEO-led

Step 1: CEO identifies or is made aware of the situation.
Step 2: CEO engages HR immediately — HR advises on legal and policy, owns documentation.
Step 3: CEO and HR align privately — decision, timeline, and communication plan confirmed before anything is shared.
Step 4 onward: Communication cascade below.

Track B — All other staff

HR-led

Step 1: HR identifies or is made aware of the situation.
Step 2: HR leads the process — CEO is kept informed and collaborates on decisions with company-wide impact.
Step 3: HR and CEO align privately — decision, timeline, and communication plan confirmed before anything is shared.
Step 4 onward: Communication cascade below.

Communication cascade — both tracks

CEO + HR align privately

Decision made, timeline set, communication plan confirmed. Nothing leaves this circle until all three are locked.

HR records

CEO brings outcome to leadership sync

Post in #management-team or raise in next leadership meeting. Leaders are informed — not consulted. Share the outcome and communication plan, not the details.

#management-team

Leaders address it at the next live team meeting

No Slack announcements. No async messages. Live only — every time. Leaders deliver a consistent message so the team hears the same thing regardless of which lead they report to.

Live meeting only

CEO addresses it briefly at the next all-hands

Acknowledge the change, provide appropriate context, close the loop company-wide. Brief — the goal is to signal that leadership communicates openly, not to relitigate the situation.

All-hands

Hard rules:
→ Never announce a departure or termination in Slack — live only, every time, no exceptions
→ Communicate the outcome, not the story — keep details private
→ Don't let it sit — silence creates more anxiety than a brief honest acknowledgment
→ Consistency matters — every leader delivers the same core message
→ HR documentation is the source of truth — not Slack threads, not meeting notes

Handle it at owner level

Routine coordination, individual blockers — anything one person can resolve

Task stuck <24hClarification neededRoutine handoffs

Team lead / manager

Blocker >24–48h, unclear ownership, cross-person friction, client judgment call

Blocker stalledTwo people can't alignDeadline at risk

Leadership → #management-team

Cross-functional conflict, resource decision, process gap, multi-team or client risk

Two teams can't alignResource neededClient at risk

CEO — last resort

Company-level tradeoff, strategic direction, core policy exception, board-level event

Company directionLeadership conflictBoard / legal

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.

Internal rules

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.

4If it will be referenced again, it belongs in the wiki or a durable doc.

5Meetings are for deciding and solving — not reading updates aloud.

6Escalate by pathway, not urgency feeling. Follow the ladder.

7The person closest to the work communicates first — unless it's a company-level message.

External rules

8Only authorized team members communicate directly with clients. If in doubt, check first.

9Any external communication carrying risk requires internal sign-off first. No exceptions.

10Never publicly reference a client without their explicit written approval.

12Board and investor communication is CEO-owned. No one else communicates with the board without explicit CEO direction.

Known gaps — close these in order

No sign-off rule for risky external client comms

No board / investor communication cadence

No public client mention approval process

New hire onboarding communication not standardized

Decision log not yet built

Add: external sign-off rule to client SOPs

Add: board/investor update cadence

Add: client approval checklist for public mentions

Channel structure

Source of truth

Decision log

Escalation matrix

External pathways

New hire onboarding

Internal Slack channels only — external comms do not live in Slack

Company-wide

#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: leadership sync + escalation surface (Level 3). All Level 3+ decisions logged here. Decision log pinned at top.

Repurpose

#team-ps

Professional services coordination. Renamed from #professional-services. Coordination only — records in Airtable.

Rename

#team-delivery

Cross-client project coordination. Full picture of active delivery work. Airtable is source of truth.

Add

#team-ops

Ops coordination. Process questions, system updates, internal logistics. Wiki is source of truth.

Add

Client channels — internal coordination only, not record-keeping, not external comms

#client-[name]

Internal team coordination around a client account. Client records in HubSpot. Project records in Airtable. External client communication does not happen in Slack.

Fix purpose

Project channels — created as needed, archived on completion

#proj-[name]

Cross-functional projects needing their own 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. External client communication never happens in Slack.

Internal tools

Tool

Owns

Does NOT own

Slack

Quick coordination · announcements · escalation signals · culture

Final decisions · task tracking · client records · external communications

Airtable

Project execution records · status and blockers · handoff notes · decision log (future)

Strategic priorities · SOPs · working drafts · client relationship records

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

Fathom

Meeting summaries · transcripts · decision recall · follow-up reference

The decision log · task ownership · policy documentation

HR records

Employee issues · performance documentation · departure and termination records

General announcements · project records · strategic priorities

External-facing tools

Tool

Owns

Does NOT own

HubSpot

Client contact records · relationship history · deal pipeline · external comms history

Project execution · delivery status · internal process docs

TGL Client Portal

Client-facing project visibility · shared deliverables · status updates accessible to clients · formal client-facing communications

Internal project records (→ Airtable) · relationship history (→ HubSpot) · working drafts (→ Drive)

Google Drive

Working drafts · PRDs · proposals · client/project-specific docs · board/investor materials

Final published process (→ wiki) · client relationship records (→ HubSpot)

Document scope rule: Client or project-specific docs → client's Google Drive folder. Technical specs that apply across all work → wiki. Board and investor materials → dedicated Drive folder, CEO-owned. If in doubt: does this apply to one client/project, or to TGL generally?

Internal · every decision log entry needs these fields

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 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.

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.

Internal escalation — click any level to expand

Handle it yourself

Direct owner · peer-to-peer

Escalate at this level when

You have authority and information to resolve it alone

It affects only your own work or one other person

Resolvable peer-to-peer within 24 hours

Move to Level 2 when

Stalled more than 24–48h with no resolution

Ownership unclear or requires someone else's authority

Bring in your manager

Team lead · functional manager

Escalate at this level when

Blocker stalled more than 24–48h

Two people can't agree on ownership or approach

Work 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.

Bring to leadership

#management-team

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

A client escalation exceeds what a manager can handle

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.

CEO decision required

Last resort only

Escalate at this level when

Genuine company-level tradeoff — 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

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.

External communication pathways — click each to expand

Routine client communication

Authorized team members only

Who can communicate directly with clients

Only designated, authorized team members. If you're unsure whether you're authorized to send something, check with your lead before it goes out. All client communication is logged in HubSpot.

Channel — match the client's preference

Email, Slack Connect, or phone/video depending on the client. The channel varies — the rule doesn't: everything gets logged in HubSpot regardless of channel used.

Sign-off required for

Bad news, scope changes, pricing discussions, or anything with legal or contractual implications — get lead sign-off before sending

Routine status updates, scheduling, and delivery coordination — no sign-off required

Client escalation

Bad news, disputes, relationship risk

The rule

Internal alignment before anything goes externally. No one sends a message to a client about a disputed or sensitive situation without lead sign-off. No exceptions.

Pathway

Flag internally first

Post in the client channel or #team-delivery with what's at risk and what you're planning to say. Tag your lead.

Get lead sign-off on the message

Lead reviews and approves the external message before it goes out. For high-stakes situations, bring to #management-team.

Log the outcome in HubSpot and the decision log

Any client escalation that results in a decision — scope change, concession, policy exception — gets logged.

TGL Client Portal

Project visibility · shared deliverables · client-facing status

What the portal is for

The TGL Client Portal is the primary surface for sharing project progress, deliverables, and status updates directly with clients. It is the client-facing layer on top of TGL's internal execution — not a replacement for direct communication, but a structured home for formal project visibility.

What lives in the portal

Project status and milestones visible to the client

Shared deliverables and approved client-facing documents

Formal project updates and progress summaries

What does NOT live in the portal

Internal project records and execution notes — those stay in Airtable

Relationship history and communication logs — those stay in HubSpot

Working drafts not yet approved for client visibility — those stay in Google Drive

Rules

Only approved, client-ready content goes into the portal. Before publishing a deliverable or update to the portal, confirm it has been reviewed internally. The portal is a client-facing tool — treat anything in it as if the client is reading it right now, because they are.

Board and investor communication

CEO-owned · cadence to be defined

Who communicates with the board and investors

The CEO owns all board and investor communication. No one else communicates with board members or investors about company matters without explicit CEO direction.

Recommended cadence — to be decided

Monthly investor update — written, CEO-authored, sent via email. Covers: progress against priorities, key metrics, what's working, what's not, what's needed.

Quarterly board meeting — structured agenda, materials prepared in advance, decisions and action items documented.

Ad hoc updates for significant events — major client win or loss, significant hire or departure, strategic pivot. Don't wait for the next scheduled update.

Source of truth

Dedicated Google Drive folder — CEO-owned. Board materials, investor updates, and meeting notes all live here. Nothing board-related lives in Slack or in general company folders.

Gap to close: TGL currently has no defined communication cadence with its board and investors. A consistent monthly update, even brief, is better than irregular comprehensive ones. Recommend deciding on a rhythm and committing to it.

Public client mentions

Case studies, press, social proof

The rule

Never publicly reference a client — by name, logo, or identifiable detail — without their explicit written approval. This includes case studies, LinkedIn posts, press releases, website testimonials, and conference presentations.

Approval pathway

Internal draft and alignment

Draft the content internally. Get sign-off from the account lead and CEO before it goes to the client.

Client review and written approval

Send the draft to the client contact with a clear approval request. Get written sign-off (email is fine) before publishing anything.

Publish and log

Publish after approval is received. Log the approval and published link in the client's HubSpot record.

Internal · HR-led with CEO support

Owner: HR, with CEO support. HR leads the onboarding communication process end to end. The CEO's role is to provide context, culture, and welcome — not to manage the logistics.

Communication pathway — new hire joins TGL

Offer accepted — internal announcement

HR notifies relevant leads privately before the team announcement. CEO or HR posts a brief welcome in #announcements: name, role, start date, and who they report to. Keep it warm and simple — nothing more.

#announcementsHubSpot / HR records

Pre-start — logistics and access

HR sends the new hire a pre-start checklist: tools to expect, what to bring, first day schedule. IT and ops provision access to all required systems before day one. No one should arrive on their first day waiting for a laptop or Slack invite.

Onboarding checklist (Drive)Wiki — role guide

Day one — orientation and introductions

HR walks the new hire through the communication pathway map, tools, and how TGL works. CEO does a brief welcome — in person, video, or async Loom. New hire is introduced in the relevant team channel by their lead.

Live or async welcomeTeam channel intro

First 30 days — check-ins and feedback

HR schedules a 2-week and 30-day check-in. Lead checks in informally in week one. Any gaps in access, documentation, or context get flagged back to HR and ops to close.

HR check-insUpdate wiki if gaps found

What to standardize before the next hire: The pre-start checklist, the day one orientation flow, and the wiki onboarding guide. These three things currently vary by hire — standardizing them means every new person gets the same quality of start regardless of who's doing the onboarding.