Cross Department Translation

Cross-Department Translation

When to Use

• Reframe a message, spec, metric, or decision for a different internal audience
• Produce dual-audience briefs (e.g., engineering detail + executive summary on one page)
• Decode department jargon and unstated assumptions before handoff
• Convert meeting notes into action items by owner with RACI clarity
• Translate technical specs, incidents, or architecture for business stakeholders
• Translate business constraints, policy, or financial limits for engineering implementation
• Draft escalation summaries that each function can act on without re-interpretation
• Align vocabulary across product, finance, legal, compliance, sales, ops, and actuarial threads

When NOT to Use

• Company-wide messaging strategy, launches, crisis wording, or brand voice → communication-lead
• Issue trees, business cases, operating models, or steerCo analysis without audience reframing → business-consultant
• Multi-team milestones, RAID ownership, dependency maps, launch program governance → technical-program-manager
• Contract, DPA, or legal redlines and negotiation positions → commercial-counsel
• Control mapping, audit evidence pipelines, or attestation engineering → compliance-engineer
• Actuarial engagement SOW, reserve opinions, or regulatory actuarial deliverables → actuarial-consulting
• Natural-language product localization (locale strings, RTL, cultural adaptation) → route to localization/l10n skills if present
• Deep technical modeling execution (pricing triangles, IBNR) → actuary

Related skills

Core Workflows

1. Identify source and target audiences

1. Source — who wrote this; what they assume the reader knows 2. Target — who must understand, decide, or execute 3. Decision or ask — one sentence: what changes if they get it right 4. Sensitivity — legal, regulatory, financial materiality, security, personnel

Load references/audience_profiles_and_register.md for register, depth, and vocabulary norms.

2. Jargon and assumption pass

Before rewriting:

1. Highlight terms that are department-local or overloaded (e.g., "platform," "risk," "material") 2. List implicit assumptions (data exists, approval granted, timeline fixed) 3. Flag ambiguous metrics (gross vs net, ARR vs revenue, calendar vs fiscal) 4. Build a mini-glossary only for terms that appear in the artifact

See `references/jargon_decoding_and_glossary.md`.

3. Requirements and decision briefs

Use pyramid structure for executives; appendices for specialists.

See `references/requirements_and_decision_briefs.md`.

4. Meeting notes and handoffs

1. Capture decisions (what was decided, not discussed) 2. Extract actions with one owner, due date, and definition of done 3. Separate FYI from needs response 4. Add RACI when multiple teams share work 5. Include open questions with who resolves them

See `references/meeting_notes_and_handoffs.md`.

5. Escalation and executive summaries

Escalations need: situation, impact, options, recommendation, asks by role, and what not to do yet.

Keep exec sections to one screen; link detail for operators.

See `references/executive_and_escalation_summaries.md`.

Output standards

• Lead with decision or ask for executive readers; lead with context and constraints for implementers
• Define acronyms once; prefer plain language over metaphor
• Separate facts, assumptions, and recommendations
• Preserve numeric precision; never round material figures without stating basis
• Tag sections when dual-audience: ## Executive, ## Engineering, ## Finance, etc.
• Flag [LEGAL REVIEW], [COMPLIANCE], [FINANCE SIGN-OFF] when content touches those domains

When to load references

Audience profiles and register

Table of contents

1. Register dimensions 2. Audience profiles 3. Depth and format defaults 4. Sensitivity handling

Register dimensions

Tune each output on four axes:

Audience profiles

Depth and format defaults

Sensitivity handling

When two audiences conflict (e.g., speed vs compliance), state the trade-off explicitly rather than smoothing over it.

Cross-department translation scope

Table of contents

1. Definition 2. In scope 3. Out of scope 4. Quality bar 5. Common failure modes

Definition

Cross-department translation is reframing the same underlying facts so each internal function receives the right depth, vocabulary, and actionable asks—without changing substance, hiding risk, or oversimplifying material constraints.

It is not machine translation between human languages unless the user explicitly requests locale/i18n work.

In scope

Out of scope

Quality bar

Good translation:

• Preserves numbers, dates, owners, and commitments
• Makes assumptions explicit (data, approvals, dependencies)
• States one primary ask per audience section
• Separates must-have from nice-to-have
• Surfaces risks and trade-offs each audience cares about

Poor translation:

• Dumbs down technical risk for executives (hides severity)
• Adds commitments the source did not authorize
• Uses buzzwords instead of defined terms
• Mixes recommendation into facts without labeling

Common failure modes

Executive and escalation summaries

Table of contents

1. Executive summary rules 2. Escalation summary template 3. Audience-specific asks 4. Status cadence 5. Coordination with comms and TPM

Executive summary rules

Executives need decisions and consequences, not activity logs.

Target length: 150–250 words for email; one slide for deck inserts.

Escalation summary template

# Escalation: [short title]

**Severity:** [P0–P3 or company scale]
**Status:** [Investigating / Mitigating / Monitoring / Resolved]
**Incident commander / DRI:** [name/role]
**Last updated:** [timestamp UTC]

## Situation (facts only)
What is happening; scope (customers, regions, systems); start time.

## Impact
- Customer: [experience, count if known]
- Financial: [revenue, credits, penalties if known]
- Regulatory / contractual: [if applicable]

## Current actions
Bulleted; owner per line.

## Options (if decision needed)
| Option | Pros | Cons | Owner |
|---|---|---|---|
| A | | | |
| B | | | |

## Recommendation
One clear path if appropriate.

## Asks by audience
- **Executive:** [decision / resource / comms approval]
- **Engineering:** [priority / staffing]
- **Finance:** [accrual / forecast / credit]
- **Legal / compliance:** [notice / filing / control]
- **Sales / support:** [talk track / customer comms timing]

## What not to do yet
Actions that would worsen state or violate policy.

## Links
Status page, war room, ticket, runbook.

Separate message packs for customers from this internal summary—route external wording to communication-lead.

Audience-specific asks

Each ask must be actionable in one meeting or declined with reason.

Status cadence

Each update: delta since last (not full rehash).

Coordination with comms and TPM

This skill owns internal cross-functional clarity; partner skills own program machinery and external narrative.

Jargon decoding and glossary

Table of contents

1. Jargon pass workflow 2. Overloaded terms 3. Assumption surfacing 4. Glossary format 5. Metric alignment

Jargon pass workflow

1. Extract candidate terms (acronyms, product codenames, role-specific nouns) 2. Classify each term:

• Universal (define once)
• Overloaded (disambiguate by audience)
• Local slang (replace or footnote)

3. Rewrite sentences so a target reader needs no insider context 4. Footnote only terms that must stay specialized

Overloaded terms

These words mean different things by department—always disambiguate in dual-audience docs:

Assumption surfacing

Convert implicit assumptions into labeled statements:

Use Facts / Assumptions / Open questions headers when ambiguity is high.

Glossary format

Keep glossaries minimal—only terms used in the artifact:

| Term | Definition (for this doc) | Owner |
|---|---|---|
| ARR | Annual recurring revenue per signed contract; excludes usage overage | Finance |
| P99 latency | 99th percentile request duration over 5m windows | Engineering |

For dual-audience docs, add a plain-language column for executive readers.

Metric alignment

When translating metrics across teams:

1. State numerator and denominator 2. Specify time window and population (all customers vs segment) 3. Note lag (real-time vs month-close) 4. Map engineering SLIs to business KPIs in one table:

Never equate metrics without documenting the mapping assumption.

Meeting notes and handoffs

Table of contents

1. Meeting notes structure 2. Action item rules 3. RACI handoffs 4. Handoff checklist 5. Anti-patterns

Meeting notes structure

# [Meeting title] — YYYY-MM-DD

**Attendees:** [roles or names]
**Purpose:** [one line]

## Decisions
- D1: [decision] — **Owner:** [name/role]

## Actions
| ID | Action | Owner | Due | Status |
|---|---|---|---|---|
| A1 | [verb + deliverable] | [one person] | [date] | Open |

## FYI
- [facts without required response]

## Open questions
| Question | Owner to resolve | By |
|---|---|---|
| Q1 | | |

## Parking lot
- [deferred topics]

Decisions are outcomes, not topics discussed. If no decision, write "No decision — escalated to [forum]."

Action item rules

Each action must be:

• Verb-led — "Draft," "Approve," "Ship," "Validate"
• Single owner — one accountable person (RACI A)
• Deliverable-specific — artifact or measurable state change
• Dated — due date or event trigger ("before launch")

Convert vague notes:

RACI handoffs

Use when multiple teams touch the same workstream:

R = responsible (does the work) A = accountable (one person; approves completion) C = consulted (input required before proceed) I = informed (kept in loop)

Handoff email/doc must include:

1. Context — why this handoff now 2. Artifacts — links to specs, tickets, data 3. State — what's done vs remaining 4. Risks — known blockers 5. First action for receiver — unambiguous next step

Handoff checklist

Receiving team should be able to answer without a meeting:

• [ ] What is the goal and definition of done?
• [ ] What constraints are non-negotiable?
• [ ] What decisions are already made vs open?
• [ ] Who is accountable for each workstream?
• [ ] What systems/access are required?
• [ ] What dates are committed externally?
• [ ] Where is the source of truth doc?

Anti-patterns

For program-level tracking across many teams, pair output with technical-program-manager after translation is complete.

Requirements and decision briefs

Table of contents

1. Brief types 2. Dual-audience layout 3. Technical → business template 4. Business → engineering template 5. Decision record

Brief types

Dual-audience layout

Use labeled sections on one page when leaders and implementers share a single artifact:

## Executive (≤200 words)
- Decision needed by [date]
- Recommendation
- Impact if delayed

## [Target function] detail
- Context, constraints, dependencies
- Acceptance criteria / evidence
- Appendix: links, diagrams, data

Rules:

• Executive section contains no unexplained acronyms
• Detail section may reference RFCs, tickets, control IDs
• Single source of truth for numbers (no conflicting figures across sections)

Technical → business template

# [Initiative] — business summary

## Outcome
What changes for customers or the business (1–2 sentences).

## Why now
Burning platform or opportunity; link to OKR/metric.

## Scope
In / out / phase 2.

## Cost and timeline
Effort band (S/M/L), major dependencies, key dates.

## Risks
Top 3 with mitigations (availability, security, compliance, revenue).

## Decision / ask
What you need from this audience (approve, fund, prioritize, accept risk).

## Technical appendix (optional)
Architecture sketch, SLIs, link to RFC.

Translate implementation choices into business consequences (revenue, cost, risk, time-to-market).

Business → engineering template

# [Initiative] — engineering brief

## Problem statement
User or business problem in testable terms.

## Success criteria
Measurable outcomes; definition of done.

## Constraints (must / must not)
Policy, budget, date, regions, data residency, accessibility, etc.

## Non-goals
Explicit exclusions to prevent scope creep.

## Dependencies
Teams, vendors, data, approvals required before build.

## Open questions
Owner per question; deadline for resolution.

## Context links
PRD, designs, legal/compliance refs, finance case ID.

Avoid solution prescription unless the business decision already selected an approach.

Decision record

For cross-functional decisions, capture:

Pair with business-consultant when the brief is primarily analytical; stay in this skill when the core task is audience-appropriate framing.