Communicating with Stakeholders

The Communication Challenge

Technical leaders operate at the intersection of engineering and business. You must communicate in two directions: translating business requirements into technical plans for your team, and translating technical reality into business terms for stakeholders. This bidirectional translation is one of the most valuable skills a Tech Lead can develop, and it is consistently cited as the top differentiator between good and great engineering leaders.

The failure mode is speaking in technical jargon to business stakeholders or oversimplifying technical constraints to the point of dishonesty. The goal is to communicate with the right level of detail for each audience, providing enough context for informed decision-making without overwhelming people with implementation details they do not need.

Know Your Audience

Translating Technical Concepts

The art of translation is finding analogies and frames that make technical concepts accessible without being condescending.

## Translation Examples

### BAD: "We need to refactor the monolith into microservices
because the coupling is causing deployment bottlenecks and
the shared database is a single point of failure."

### GOOD: "Right now, all our features are packaged together
like a single big box. When one team changes their feature,
every other team has to wait. We want to separate features
into independent units so teams can ship independently.
This will cut our release cycle from 2 weeks to 2 days."

---

### BAD: "The p99 latency of the search endpoint is 3.2
seconds due to a full table scan on the products table.
We need to add a composite index and implement caching."

### GOOD: "Search is slow for about 1 in 100 users because
the database has to scan every product to find results.
We can fix this with a targeted optimization that should
take 2 days and will make search feel instant for everyone."

Managing Expectations

Estimations and Timelines

One of the most frequent sources of stakeholder friction is timeline expectations. Be honest, add buffers, and communicate uncertainty clearly:

• Give ranges, not points: "This will take 3-5 weeks" is more honest than "4 weeks"
• Explain what affects the range: "It is 3 weeks if we can reuse the existing payment API, 5 weeks if we need to build a new one"
• Update proactively: When timelines change, communicate immediately with the reason and the new estimate
• Distinguish effort from calendar time: "This is 10 days of work, but with context-switching and reviews, it will take 3 calendar weeks"

Saying No (and Offering Alternatives)

Tech Leads frequently need to push back on unrealistic requests. The key is to say no to the specific ask while saying yes to the underlying need:

• "We cannot build the full feature in 2 weeks, but we can ship a version with the core functionality that covers 80% of users, and add the remaining features in a follow-up."
• "Adding real-time sync would require 6 weeks of infrastructure work. As an alternative, we can add a manual refresh button in 3 days that solves the immediate user pain."
• "We can ship this by the deadline if we skip automated testing, but the risk of production bugs increases significantly. I recommend a 1-week delay to ship with confidence."

Written Communication

As a Tech Lead, much of your communication is written: emails, Slack messages, documents, and status updates. Good written communication saves everyone time.

• Structure first: Use headers, bullet points, and bold text so readers can scan quickly
• One message, one topic: Do not bury important requests in long multi-topic messages
• Include the ask: If you need a decision or action, state it explicitly at the top
• Link, do not attach: Reference documents by link so people always see the latest version