Technical Roadmap English: How Engineering Managers Communicate Strategy

Introduction

One of the most visible responsibilities of an engineering manager is communicating strategy — to leadership, to product teams, and to the engineers doing the work. The vocabulary you use in roadmap discussions signals whether you can operate at the right altitude: not too deep in implementation details, not too vague to be useful. This post breaks down eight core terms that engineering managers rely on when discussing roadmaps, priorities, and product direction.

Strategic Roadmap Vocabulary

North star — The single overarching metric or goal that guides all product and engineering decisions. It represents what long-term success looks like for the product or team, and it is used to evaluate whether individual initiatives are moving in the right direction.

“Our north star is time-to-first-value for new users — every roadmap item we prioritize this quarter must demonstrably reduce that number.”

Milestone — A significant checkpoint or deliverable within a project or roadmap that marks meaningful progress. Milestones are not tasks; they are outcomes that confirm a phase of work is complete.

“The first milestone is a working authentication flow in staging — once that is signed off, we can begin load testing and move toward the beta milestone.”

Initiative — A large, strategic body of work that groups together multiple related projects or epics. Initiatives are typically aligned to business goals and span multiple teams or quarters.

“The platform reliability initiative covers three separate engineering workstreams: on-call tooling, SLO instrumentation, and dependency upgrades across our core services.”

Dependency — A relationship where one piece of work cannot start or complete until another is finished, often across team boundaries. Managing dependencies is one of the most critical — and politically sensitive — parts of roadmap planning.

“We have a hard dependency on the data platform team delivering their new ingestion API before we can begin the analytics dashboard work in Q3.”

Defer scope — To consciously decide to move work out of the current cycle and into a future one. Deferring scope is a deliberate prioritization decision, not a failure, and communicating it clearly prevents misaligned expectations.

“After reviewing capacity and the dependency on the identity service, we decided to defer scope on multi-factor authentication to Q4 — the core login flow will ship on schedule.”

Phase — A discrete stage in a project or roadmap, often used to break large initiatives into manageable deliverables. Phases allow teams to ship incrementally rather than waiting for a complete solution.

“Phase one delivers read-only access to the new reporting module; write capabilities and export features are scoped for phase two in the following sprint cycle.”

Horizon planning — A roadmap structure that divides future work into three time horizons: near-term committed work, medium-term planned work, and long-term exploratory bets. It helps teams balance execution with strategic investment.

“We use horizon planning to ensure the team is not 100 percent focused on delivery — horizon three gives us space to prototype ideas that might become core product features in 18 months.”

OKR alignment — The process of ensuring that engineering work maps directly to Objectives and Key Results defined at the company, department, or team level. Alignment means there is a traceable connection between what engineers build and what the business is trying to achieve.

“Before we finalize the Q3 roadmap, I need each team lead to confirm OKR alignment — every initiative on the board should tie to at least one key result we are accountable for.”

Using These Terms Effectively

Engineering managers who communicate roadmaps well share one habit: they make the reasoning visible. It is not enough to say “we are deferring scope on feature X.” You need to explain what dependency forced that decision, what milestone it unblocks, and how the change affects OKR alignment. That narrative turns a list of tasks into a coherent strategy.

When presenting to senior leadership, lead with the north star and milestones. When working with product managers, speak in initiatives and phases. When coordinating with other engineering teams, focus on dependencies and how you plan to resolve them. Matching your vocabulary to your audience is as important as knowing the words themselves.

A Note on Horizon Planning in Practice

Many teams say they do horizon planning but in practice only plan horizon one in detail. The value of the framework is in naming the distinction explicitly. When you say “this is a horizon two bet,” you are communicating that the work is not yet fully specified, that it may change shape, and that it requires different kinds of decision-making than committed delivery work. That nuance prevents engineering teams from treating exploratory prototypes with the same rigor as production features — which wastes time — or from treating production features with the same looseness as prototypes — which causes quality problems.

Mastering this vocabulary gives you the language to operate at the strategic level while staying credible with engineers who want specifics. That combination is what distinguishes strong engineering managers from those who are merely technically skilled.

Bridging the Gap: Specificity & Clarity for Non-Native Speakers

The core of effective communication regarding technical roadmaps isn’t just about stating what needs to be done; it’s about conveying why, how, and when with a level of precision that minimizes ambiguity. For non-native English speakers, this can feel particularly challenging. The nuances of phrasing – the subtle differences between “should,” “could,” and “must” – can dramatically alter interpretation. Let’s consider a common scenario: receiving feedback on a pull request. A manager might leave a comment like, “This needs further refinement before merging.” While seemingly straightforward, this lacks specific direction. It doesn’t tell you what specifically needs refinement – is it the logic, the testing coverage, or the documentation? The impact of that comment hinges entirely on your understanding of “refinement” within the context of the project and team standards.

Similarly, during a sprint planning meeting discussing an OKR (Objectives and Key Results), you might hear someone say, “Let’s prioritize features impacting user engagement.” This is good strategic language, but it needs to be translated into actionable tasks. A non-native speaker could struggle with the implied metrics – what constitutes “impact”? How will that impact be measured? To avoid misinterpretations, engineering managers often strive for more concrete phrasing. Instead of saying “improve performance,” they might say, “Reduce page load times by 20% on mobile devices during peak hours.” The addition of specific targets and contexts drastically reduces ambiguity. This isn’t about sounding overly technical; it’s about establishing a shared understanding. It also reinforces the importance of asking clarifying questions – “Can you elaborate on what ‘impact’ means in this context?” or “What metrics are we using to determine success?”

The key is recognizing that professional English often relies heavily on implied meaning and contextual assumptions. Building this awareness takes time and practice, and actively seeking clarification when needed is always the right approach. Don’t hesitate to ask for examples of how a particular phrase is typically used within your team’s workflow. Most experienced engineers appreciate the effort to improve communication and will be happy to provide guidance. Focus on understanding the underlying intent behind the words, not just the words themselves.

Here’s an example of how you might use git to address a comment related to code review:

# Example: Applying suggested changes from a code review
git checkout --force <branch_name> # Force update to incorporate feedback (use with caution!)
git add .
git commit -m "Refined logic based on reviewer feedback"
git push origin <branch_name>

This simple command demonstrates the practical application of understanding feedback – a change is made, committed, and pushed. It’s a tangible step towards demonstrating that you’ve understood and addressed the concerns raised.