manager-dot-dev/business-literacy
skills/business-literacy/SKILL.md
Explains business financial terms and frameworks for engineering managers — produces term definitions (ARR, COGS, CAC, LTV, gross margin, burn rate, EBITDA, AARRR), translation formulas for making engineering work visible in business language, and a three-layer framework for building business credibility. Use when the user says "business terms," "EBITDA," "burn rate," "CAC," "LTV," "gross margin," "ARR," "how do I speak to business people," "I don't understand finance," "make the case for engineering work," "connect engineering to business outcomes," "talk to the P&L owner," or "business impact." Do NOT use when the user wants to connect engineering metrics (DORA, velocity) to business metrics — use developer-productivity instead.
$ install --global
skillsauthnpx skillsauth add manager-dot-dev/manager-skills business-literacyInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 23, 2026, 2:47 PM215.9s2 files scanned
SKILL.md
- name:
- business-literacy
- description:
- Explains business financial terms and frameworks for engineering managers — produces term definitions (ARR, COGS, CAC, LTV, gross margin, burn rate, EBITDA, AARRR), translation formulas for making engineering work visible in business language, and a three-layer framework for building business credibility. Use when the user says "business terms," "EBITDA," "burn rate," "CAC," "LTV," "gross margin," "ARR," "how do I speak to business people," "I don't understand finance," "make the case for engineering work," "connect engineering to business outcomes," "talk to the P&L owner," or "business impact." Do NOT use when the user wants to connect engineering metrics (DORA, velocity) to business metrics — use developer-productivity instead.
- version:
- 2.1.2
Business Literacy
Before Starting
Check for EM context first. If .agents/em-context.md exists, read it.
If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.
If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.
If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.
Response Style
Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.
Default to:
- State the likely diagnosis or recommendation first
- Ask at most 2-3 targeted questions only if the missing context changes the advice
- Give the next concrete action and, when useful, exact wording the manager can use
- Mention the relevant framework briefly, but do not explain every part of it
- Offer a deeper version only after the direct answer
How to Use This Skill
- Need to decode a business term you heard in a meeting → The Terms That Come Up Most
- Want to make the case for engineering work in business language → Using These in Practice
- Want to build credibility with business leaders or the P&L owner → The 3 Layers of Business Impact
Default Response Shape
When translating business concepts for an EM, make the answer operational:
- Plain-English definition: explain the term without finance theater.
- Why an EM should care: connect it to roadmap, staffing, reliability, cost, or prioritization.
- Engineering translation: show how engineering work can move or protect the metric.
- Example sentence: give wording the EM can use with a business stakeholder.
- Caveat: note where the metric can mislead or be gamed.
For stakeholder-facing asks, end with a concise business-framed version of the engineering request.
Why This Matters
Engineers can succeed without understanding business language. Engineering managers cannot. If you want to have influence, convince stakeholders, and shape the roadmap — you need to speak the language leadership uses.
Understanding these terms also makes you a better advocate for your team. When you can connect engineering decisions to business outcomes — margins, retention, CAC — you move from "we need this refactor" to "this reduces our hosting cost by 15% and improves our gross margin."
The Terms That Come Up Most
Money In
ARR (Annual Recurring Revenue) — total yearly revenue from subscriptions. The core metric for SaaS companies. When leadership says "we're at $5M ARR," this is it.
MoM (Month-over-Month) — growth rate from one month to the next. A 10% MoM growth rate is exceptional.
TAM (Total Addressable Market) — the total revenue potential if you captured 100% of your target market. Used to justify investment size.
Costs
COGS (Cost of Goods Sold) — costs directly tied to delivering the product (hosting, infra, third-party APIs). For SaaS, engineering teams directly influence COGS.
Gross Margin — (Revenue - COGS) / Revenue. For SaaS, 70–80% is healthy. Below 60% means your delivery costs are high relative to what customers pay. This is where engineering decisions show up in financials. Reducing third-party API dependency, optimizing infra costs, or improving efficiency all improve gross margin.
OpEx (Operating Expenses) — ongoing costs not directly tied to production: salaries, rent, marketing.
CapEx (Capital Expenditure) — large investments with long-term value. Building a new data center is CapEx; monthly AWS bill is OpEx.
Burn Rate — how much cash the company spends per month. High burn + low revenue = limited runway.
Net Margin — what's left after ALL costs. Most startups have negative net margin for years.
EBITDA — Earnings Before Interest, Taxes, Depreciation, Amortization. A profitability measure that strips out financing. Matters more at late-stage.
Customers
CAC (Customer Acquisition Cost) — average cost to acquire a customer. If you spend $100k on marketing and get 100 customers, CAC = $1,000.
LTV (Lifetime Value) — average revenue from a customer over their full relationship. LTV should be 3–5x CAC for a healthy business. If not, growth is expensive.
Churn — percentage of customers lost per period. The silent killer. 5% monthly churn = ~46% of customers gone per year.
Retention — the inverse of churn. Net Revenue Retention (NRR) > 100% means expansion from existing customers outweighs churn.
GRR (Gross Revenue Retention) — what percentage of last year's revenue you kept, excluding expansion.
NPS (Net Promoter Score) — "How likely are you to recommend us?" Scores 9–10 = promoters, 7–8 = passives, 0–6 = detractors.
Business Health
Default Alive — if you stop raising money, does current revenue growth make you profitable before cash runs out? If not, you're "default dead."
Moat — what makes you hard to copy. Deep tech, network effects, proprietary data, brand. Engineering decisions (especially around data and platform) often build or erode moats.
AARRR (Pirate Metrics) — Acquisition, Activation, Retention, Referral, Revenue. A framework for diagnosing where growth is leaking. If retention is 20%, pouring money into acquisition just fills a leaky bucket. Fix the leak first.
Using These in Practice
When proposing technical work, translate it:
- Not: "we need to migrate off this legacy API" → Yes: "this API costs us $40k/year and is our top cause of outages; removing it improves gross margin and reduces customer churn"
- Not: "we should invest in platform" → Yes: "right now each new feature takes 2 weeks to wire up; a platform investment gets that to 2 days, directly improving our CAC by reducing time-to-value"
When reviewing the roadmap, ask the business question: which AARRR stage are we weakest at right now? Invest there first.
The 3 Layers of Business Impact
EMs who drive real business impact typically work across three layers, in increasing order of difficulty:
Layer 1 — Product: Do you and your team understand how your features are used? Have a dashboard showing feature usage that everyone can see. Know the product's AARRR metrics. A feature that ships but nobody adopts has zero impact.
Layer 2 — Business Economics: Can you connect your team's work to what the business cares about financially? Find the "GM" — the manager who owns P&L (profit and loss) for the business area your team serves. Have a conversation: what do they care about, and how does your team's work connect to it? Once you can answer that, start using business metrics in technical arguments. "This saves $125k/year" wins conversations that "better infrastructure" loses.
Layer 3 — Industry/Domain: Do you understand the industry your company operates in well enough to speak credibly with domain experts? Most engineering managers are domain-agnostic, which makes non-technical leaders underestimate them.
Three levels of domain knowledge:
- Level 1 (Passive): Know the terminology. Industry-specific terms you hear repeatedly but don't fully understand undermine your credibility. Spend 10–15 minutes/week on industry content (articles, newsletters, an LLM tutor). Ask it to explain the domain as an instructor would.
- Level 2 (Sharing): Share what you learn. Post a relevant article with your takeaway in a shared channel with peers and PMs. People who see you engaging with the domain start treating you as a peer.
- Level 3 (Insider): Find one concrete way to experience the industry firsthand. Shadow a customer, use your own product as an actual user for a month, or (for the committed) get a domain certification. The gap between knowing the domain and experiencing it is the difference between being taken seriously and being tolerated.
Dive Deeper
If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read references/sources.md for the full list of source articles (with links) and books.
Related Skills
working-with-pm— PMs use this language constantly; understanding it makes you a real partnerroadmap-planning— Tech debt and platform work need business justification to get prioritizeddeveloper-productivity— For connecting engineering metrics (DORA, velocity) to business outcomesinfluence— Business fluency directly enables the 3rd level of positioning (being trusted)
Related Skills
manager-dot-dev/em-grid-scorer
testing
VerifiedTrustedCommunity
Score an Engineering Manager's coverage across all 12 cells of the EM Grid based on their calendar and Slack. Use this skill whenever someone wants to understand where they're spending their management energy, find blind spots, get a monthly self-reflection on their EM focus, or hear phrases like "score my EM grid", "where am I spending time as a manager", "what are my blind spots", "analyze my calendar as EM", "which EM areas am I neglecting", "how balanced is my management focus", or "check my EM grid coverage". Always pull live calendar data — never ask the user to describe their week manually.
22SKILL.mdUpdated May 9, 2026
manager-dot-dev/written-communication
development
VerifiedTrustedCommunity
Helps engineering managers write messages, announcements, and stakeholder updates that land well — produces a 3-Step Writing Framework (Prepare / Write Simply / Run a Garbage Collector), the Async Re-Explanation Trap (calling out missed messages), and the Compression/Decompression model for diagnosing why messages are misunderstood. Use when the user says "draft a message," "write an announcement," "communicate this change," "how do I word this," "message for my team," "write an update," or "how do I communicate X." Do NOT use for verbal feedback or difficult conversations (use `feedback` or `difficult-situations`).
20SKILL.mdUpdated Apr 23, 2026
manager-dot-dev/working-with-pm
development
VerifiedTrustedCommunity
Helps engineering managers build a functional PM–EM partnership and become more product-oriented — produces a 3-pattern PM–EM dynamic model (PM-Led / Engineering-Led / Fake Balanced), a true partnership definition, the "It's Important to Me" card for navigating disagreements, tips for getting engineers closer to customers and usage data (launch vs. landing, session recordings, customer conversations), and an explicit responsibilities exercise. Use when the user says "PM relationship," "PM drives me crazy," "product manager," "roadmap disagreement," "PM overrides me," "PM–EM partnership," "I want to be more product-oriented," or "how do I get engineers closer to customers." Do NOT use for general roadmap prioritization (use `roadmap-planning`) or when urgency is being manufactured by a PM (use `managing-urgency`).
20SKILL.mdUpdated Apr 23, 2026
manager-dot-dev/working-with-architects
testing
VerifiedTrustedCommunity
Helps engineering managers work effectively with Software Architects, Staff Engineers, and Principal Engineers — covers the EM's side of the relationship (responsiveness, proactive consultation, giving credit), how to advocate for architect time, pre-consultation preparation, and the two architecture team models (Centralized vs. Decentralized). Use when the user says "architect," "staff engineer," "principal engineer," "technical design review," "working with senior technical people," "getting architecture help," or "how do I get more architect time." Do NOT use for managing staff/principal engineers who report directly to you (use `managing-high-performers` or `delegation`).
20SKILL.mdUpdated Apr 23, 2026