Writing for Non-Technical Stakeholders
As you grow in your career, you will spend more time talking to Product Managers, Sales, and Executives. These people don't care about your choice of state management library or your database indexing strategy. They care about Risk, Revenue, and Reach.
This lesson teaches you how to speak their language.
The BLUF Method (Bottom Line Up Front)
Executives are busy. They scan emails and Slack messages. If your point is in the fourth paragraph, they will miss it.
Bad (The "Story" approach): "We spent the last week looking at the latency issues in the checkout flow. We found that the third-party API we use for tax calculation is slow. We tried caching it, but that didn't work. So we decided to switch to a new provider. This should make the page load faster."
Good (The BLUF approach): "BLUF: We are switching tax providers to fix checkout delays. This will reduce page load time by 2 seconds and should increase conversion by ~5%. Context: Our current provider (TaxCo) is averaging 3s response times. We've vetted 'EasyTax' and it averages 200ms..."
Outcomes vs. Outputs
Stop reporting what you did (outputs) and start reporting what it achieved (outcomes).
| Technical Output | Business Outcome | | ------------------------------------- | ------------------------------------------------------ | | "We migrated to AWS Lambda." | "We reduced server costs by 30%." | | "We fixed 20 bugs in the mobile app." | "We improved the App Store rating from 3.2 to 4.1." | | "We implemented OAuth2." | "We made the login process more secure and compliant." |
The Jargon Filter
Jargon is a shortcut for engineers, but a wall for everyone else. Use the "Grandma Test": if you can't explain it simply, you don't understand it.
- Instead of: "We are implementing a circuit breaker pattern for our microservices."
- Try: "We are adding a safety switch so that if one part of our system fails, it doesn't crash the whole website."
Summary for Stakeholders
When writing for non-technical people, follow this structure:
- What is the problem? (In business terms)
- What is the solution? (In simple terms)
- What is the impact? (Money, time, or risk)
- What do you need from them? (Approval, budget, or just awareness)
Mastering this will make you the engineer that leadership trusts to lead big projects.