← Back to Onboarding Hub
Slack @ Tenzai
What Slack Is For
Slack is the primary operational communication layer at Tenzai.
✓ Use Slack For
- Fast iteration, decisions, and alignment
- Engineering coordination during scans and POCs
- Customer POC channels (shared with customers)
- Sales ↔ Engineering feedback loops
- Early surfacing of blockers and uncertainty
✗ Do NOT Use Slack For
- Sharing sensitive customer artifacts or credentials (use platform or secure vaults)
- Long-term documentation (belongs in Notion)
- Making decisions without a written summary
Slack Channel Structure
Channels are organized by function and execution context, not hierarchy. Most meaningful work happens in a small number of high-signal channels.
Think of Slack as a thinking surface — discussions evolve in public and converge over time.
Core Internal Channels
#engineering
What it's used for: PR coordination, reviews, merge decisions, architectural discussions, CI failures, postmortems.
This is where engineering decisions are debated and ratified.
- Always include context (PR links, screenshots, concrete proposals)
- Expect iteration and disagreement
- Summarize outcomes when threads get long
#product
What it's used for: Product behavior debates, tradeoffs between correctness/clarity/speed, early-stage discussions before code is finalized.
This is a deliberation channel — disagreement is normal.
Common endings: "Let's try it and revisit" · "Ship behind a flag" · "We'll see it in action"
#dev_* channels
Examples: #dev_platform, #dev_agent, #dev_ui, #dev_exploiter, #dev_morty, etc.
Usage pattern: Component-level deep dives, discussions too detailed for #engineering, early exploration.
Treat these as your home channels if you work in the area, but surface conclusions back to #engineering.
Customer & POC Channels
Customer channels follow a naming convention:
Channel Naming
#internal_<customer> — Internal discussion about the customer (they're NOT in the channel)#external_<customer> — Shared with the customer (they ARE in the channel)
Used For
- Live POC coordination
- Authentication, networking, and scope clarifications
- Feedback on findings quality
- Rapid unblocking of security and compliance concerns
Rules of Thumb
- Be concise, technical, and precise
- Assume messages may be forwarded internally by the customer
- Never overshare speculation or roadmap promises
- Always summarize conclusions
If you join a POC channel:
- Read channel history first
- Identify the customer's core concern
- Answer precisely, not defensively
How Work Flows Across Channels
1. Explore
#product or focused channel
→
2. Decide & Execute
#engineering
→
3. Communicate
Customer / POC channel
Slack reflects work in motion, not polished specs.
Communication Norms
✓ Do
- Share partial progress early
- Ask questions in public channels when possible
- Summarize decisions after long threads
- Use bullets and structure
✗ Avoid
- Long unstructured message dumps
- Silent work during POCs
- Private DMs for broadly relevant topics
- Context-less links
What New Joiners Often Miss
- Engineering priorities are often customer-driven
- Slack context is frequently fresher than Notion
- POCs directly influence roadmap decisions
- Clarity beats cleverness in customer-facing work
How to Be Effective Quickly
- Lurk in
#engineering and #product during your first weeks
- Read recent POC notes in Notion
- Ask why a feature exists, not just how
- Summarize and confirm shared understanding
Getting Help