Communicating with Stakeholders

The jump from senior developer to lead is mostly a jump in communication. The code still matters, but more and more of the outcome depends on whether the right people understand what you’re doing and why. These are the habits that made the biggest difference for me.

Keep the meeting on its agenda

When someone is confused and the call is turning into a debugging session, say “let’s take this offline.” Arguing details in front of ten people derails the agenda, wastes everyone else’s time, and can leave someone feeling singled out. Follow up one-to-one, straight away.

Speak the listener’s language

Project and delivery managers don’t need the technical detail; they need milestones, effort and risk. “We’re replacing the state library” means nothing. “This removes a class of bugs that has cost us a day a sprint, and takes two weeks” does. Translating is not dumbing down. It’s doing the work of making your work legible.

Design high, delegate clearly

In a team with mixed experience and cost, the most valuable thing a lead can do is the high-level design and a clean breakdown into well-defined tasks others can pick up independently. It’s leverage: your time goes into the decisions only you can make.

Pitching a roadmap

When I had to present a platform roadmap to budget holders, a mixed technical and non-technical audience, this structure worked:

1. Recap what the platform is and who uses it.
2. Core features, shown as a map of sub-features, UI, APIs and end-to-end journeys.
3. Enhancements planned.
4. Value: less bespoke code, faster delivery of new use cases.
5. Three epics, not thirty tickets.
6. Timeline as a simple Gantt chart.
7. Questions.

Present it with confidence. Hedging reads as doubt about the plan.

The insight that changed how I pitch

A lot of a “costly” roadmap is work that’s needed anyway. It only looks expensive because it’s finally visible, instead of trickling in as ad-hoc priorities nobody budgets for. Framing the roadmap as making existing demand predictable, not as adding new cost, changes the conversation.

In practice

Design reviews are the other big stakeholder moment. My checklist for those is Design Review Readiness Checklist, and the habit of writing decisions down is Architecture Decision Records.