Strategic Planning and OKRs

Why This Matters at the Director/VP Level

Here's the shift that catches a lot of new directors off guard: you're no longer planning what your team builds. You're planning why your organization builds anything at all, and connecting that "why" directly to the company's revenue, growth, and survival.

When you were a manager, you took goals handed to you and figured out how to execute. Now you're the one setting those goals. You're sitting in rooms where the CEO says "we need to grow ARR by 40% next year," and you need to translate that into an engineering strategy that actually makes it happen. That's a fundamentally different job.

If you get this wrong, you'll have dozens or hundreds of engineers building things that don't matter. If you get it right, you become the leader who makes the entire company's strategy actually executable.

The Planning Cadence

Annual Planning

Annual planning is where you set direction. Not detailed plans — direction. Think of it like pointing a ship. You're not plotting every course correction; you're deciding which port you're sailing toward.

A good annual plan for an engineering organization answers four questions:

What are the company's top priorities for the year?
What does engineering need to build, improve, or maintain to support those priorities?
What investments do we need to make in our platform, tools, and people to stay healthy?
What are we explicitly choosing NOT to do?

That fourth question is the hardest and most important. Strategy is about saying no. If your annual plan has fifteen priorities, you don't have a plan — you have a wish list.

Here's a real cadence that works well:

October-November: Gather input. Talk to product, sales, customer success, finance. Understand what the business needs. Review what worked and didn't work this year.
November-December: Draft the plan. Circulate it. Get feedback. Argue about it. Revise it.
January: Finalize and communicate. Make sure every team understands not just what they're doing, but why.

Quarterly Planning

Quarterly planning is where you get specific. This is where strategy meets execution. Each quarter, you're asking:

Are we still pointed at the right destination?
What specifically will we accomplish in the next 90 days?
What did we learn last quarter that changes our plan?

The quarterly cycle is also your chance to course-correct. Maybe the market shifted. Maybe a competitor launched something. Maybe that big bet you made in Q1 isn't paying off. Quarterly planning gives you permission to adjust without abandoning your annual strategy.

A mistake I see constantly: treating quarterly planning as just "divide the annual plan by four." That's not planning — that's arithmetic. Each quarter should have its own coherent theme and set of outcomes that build on what you learned.

The Monthly and Weekly Check-ins

Between quarters, you need lighter-weight check-ins. Monthly, you should be reviewing progress against your quarterly OKRs with your leadership team. Weekly, you should have a pulse on whether anything is off track enough to need intervention.

Don't turn these into status report theater. The question isn't "what did you do?" It's "are we going to hit our targets, and if not, what do we need to change?"

Connecting Engineering Goals to Company Revenue

This is the part that separates strategic directors from tactical ones. Let me walk you through how to do it.

Start with the Business Model

Before you can connect engineering work to revenue, you need to deeply understand how your company makes money. This sounds obvious, but you'd be surprised how many engineering leaders can't clearly articulate their company's business model.

Ask yourself:

How does the company acquire customers?
What drives customers to pay more over time?
What causes customers to leave?
What are the unit economics?
Where is the company in its lifecycle (growth stage, mature, etc.)?

Map Engineering Work to Revenue Levers

Every piece of engineering work should connect to one of these levers:

Acquire new customers — Build features that attract new users, improve conversion, support new markets.
Retain existing customers — Fix reliability issues, improve performance, build features that increase stickiness.
Expand revenue per customer — Build premium features, support upsell paths, enable new use cases.
Reduce costs — Improve efficiency, automate manual processes, optimize infrastructure.
Reduce risk — Security, compliance, disaster recovery, technical debt that threatens stability.

When you present your plan, every major initiative should clearly map to one of these. If it doesn't, you either need to find the connection or question whether you should be doing it.

Make the Math Explicit

Don't just say "this will improve retention." Say "we're losing 3% of customers per quarter due to reliability issues. This initiative targets reducing that to 1.5%, which represents $2.4M in preserved ARR."

Executives live in the world of numbers. When you speak their language, you get credibility and resources. When you speak in vague technical terms, you get budget cuts.

The OKR Framework

What OKRs Actually Are

OKR stands for Objectives and Key Results. The concept is simple:

Objective: A qualitative description of what you want to achieve. It should be inspiring, memorable, and time-bound.
Key Results: Quantitative measures that tell you whether you achieved the objective. They should be specific, measurable, and challenging but achievable.

That's it. The framework is simple. The hard part is doing it well.

Writing Good Objectives

A good objective passes these tests:

Can you explain it to someone outside engineering in one sentence?
Does it clearly connect to a business outcome?
Is it ambitious enough to require real effort but not so crazy that people give up?
Does it have a clear time frame?

Bad objective: "Improve platform reliability." Good objective: "Make our platform so reliable that uptime becomes a competitive advantage in enterprise sales."

See the difference? The second one tells you why it matters and gives you a north star.

Writing Good Key Results

Key Results are where most teams struggle. Here are the rules:

They must be measurable. "Improve performance" is not a key result. "Reduce p99 latency from 800ms to 200ms" is.
They must be outcomes, not outputs. "Ship the new caching layer" is an output. "Reduce database load by 60%" is an outcome. The caching layer might be how you get there, but the key result is about what changes in the world.
Aim for 3-5 per objective. Fewer than 3 and you probably aren't capturing the full picture. More than 5 and you're losing focus.
Set them at about 70% confidence. If you're 100% sure you'll hit a key result, it's not ambitious enough. If you're 30% sure, it's demoralizing. The sweet spot is "we can probably do this if we're focused and a little lucky."

Example: A Complete OKR

Objective: Make our platform the fastest in the market so that performance becomes a key selling point.

Key Results:

Reduce median API response time from 340ms to under 100ms.
Achieve 99.95% uptime (up from 99.8%).
Get "performance" mentioned as a strength in 40% of post-sales survey responses (up from 12%).
Zero P1 performance incidents lasting more than 15 minutes.

Notice that KR3 connects directly to the customer experience. That's crucial — it keeps you from optimizing metrics that don't actually matter to anyone.

Cascading Goals: Company to Team

The Cascade Model

Here's how goals should flow:

Company level: 3-5 objectives that represent the CEO's and board's top priorities.
Department level (your level): 3-5 objectives that show how engineering supports the company objectives. Not every company objective needs an engineering-specific one, and that's fine.
Team level: Each team picks 2-3 objectives that contribute to the department objectives.

The key word is "contribute," not "copy." You don't want every team restating the company objective in their own words. You want each team identifying their unique contribution to the bigger goal.

How to Actually Do This

Step 1: Take the company objectives and ask, "What does engineering need to be true for this to happen?"

Step 2: For each answer, ask, "Which team or teams are best positioned to make this true?"

Step 3: Work with those team leads to craft objectives and key results that are specific to their scope but clearly connected to the bigger picture.

Step 4: Look for gaps. Is there a company objective that no engineering team is supporting? Is there a team that isn't connected to any company objective? Both of those are problems.

Step 5: Look for conflicts. Are two teams going to need the same resources? Are any objectives in tension with each other? Sort this out now, not mid-quarter.

The Alignment Check

Every team member should be able to answer: "What's the company's top priority right now, and how does my work contribute to it?" If they can't, your cascade is broken.

I like to do a simple exercise: randomly ask individual contributors to explain how their current project connects to the company strategy. If they can do it, your communication is working. If they look at you blankly, you've got work to do.

Measuring Outcomes, Not Outputs

This is the single biggest mindset shift in the OKR framework, and it's the one most engineering organizations get wrong.

Outputs vs. Outcomes

Output: We shipped the new search feature.
Outcome: Customer support tickets about "can't find what I'm looking for" dropped by 60%.
Output: We migrated to the new database.
Outcome: Our infrastructure costs dropped by 30% while supporting 2x the load.
Output: We completed 47 story points this sprint.
Outcome: New user activation rate improved from 23% to 41%.

Outputs tell you what you did. Outcomes tell you what changed because of what you did. Directors and VPs need to be obsessed with outcomes.

Why This Is Hard

Engineers are trained to ship things. "I built it" feels like success. But building something nobody uses, or something that doesn't move the needle on the metric you care about, isn't success. It's waste.

This is emotionally difficult. You're telling a team that spent three months building something that the work isn't done until the outcome is achieved. That means they might need to iterate, adjust, even throw things away and try again.

Your job is to create a culture where this is normal and expected. "We shipped it but it didn't work" should be followed by "so let's figure out why and try something different," not by moving on to the next feature on the roadmap.

Practical Tips

Define the outcome before you start the work. If you can't articulate what success looks like in terms of a measurable outcome, you're not ready to start building.
Instrument everything. You can't measure outcomes you can't see. Invest in analytics, observability, and data infrastructure.
Build in time for iteration. If a quarter has you shipping something in week 11 of 13, you have no time to measure and adjust. Ship early, measure, iterate.
Celebrate learning, not just winning. A team that tried something, measured it, learned it didn't work, and pivoted to something that did is performing exactly right.

Strategy vs. Tactics

What's the Difference?

Strategy is about choosing what to do and what not to do. It's about allocation, prioritization, and direction.
Tactics are about how you execute the strategy. They're about implementation, processes, and techniques.

As a director or VP, your primary job is strategy. You should be spending most of your thinking time on "are we doing the right things?" not "are we doing things right?" You have managers for the latter.

Common Traps

Trap 1: Getting pulled into tactical details. It feels productive. It feels like leadership. It's actually you not doing your job. When you're deep in code review discussions or sprint planning, you're neglecting the strategic work that only you can do.

Trap 2: Strategy without tactics. The opposite problem. Some directors live in the clouds and never connect their grand vision to executable plans. Your strategy is only as good as your teams' ability to turn it into quarterly and weekly work.

Trap 3: Confusing activity with strategy. "Our strategy is to adopt microservices" is not a strategy. That's a tactic. The strategy is "we need to enable independent team velocity because our biggest constraint is teams blocking each other." Microservices might be one tactic to support that strategy.

A Framework for Staying Strategic

Every week, ask yourself:

Am I spending at least 40% of my time on work that only I can do (cross-team coordination, exec alignment, org design, resource allocation)?
Did I say "no" to anything this week? If not, I'm probably not prioritizing.
Can I clearly articulate why we're doing what we're doing, not just what we're doing?

Real-World Examples

Example 1: The Startup That Planned Too Much

A Series B startup I worked with spent eight weeks on annual planning. They produced a beautiful 60-page strategy document with detailed quarterly plans for the entire year. By February, their biggest customer churned, a competitor launched a killer feature, and their lead architect quit. The plan was useless.

The lesson: Plan at a level of detail that matches your uncertainty. Startups should have a clear annual direction but only plan one quarter ahead in detail. Save the energy you'd spend on Q3-Q4 planning for actually learning and adapting.

Example 2: The Enterprise That Didn't Connect to Revenue

A large enterprise engineering org set their OKRs purely in technical terms: reduce tech debt, improve test coverage, migrate to cloud. All good things. But when budget season came, the CFO asked "what did engineering accomplish this year?" and the VP couldn't answer in business terms. Budget was cut by 15%.

The lesson: Always, always, always connect your goals to business outcomes. Tech debt reduction isn't about code quality — it's about shipping faster, which means getting to market before competitors, which means revenue.

Example 3: The Team That Measured Outcomes

A payments team had the objective "Make checkout so fast and reliable that it becomes a conversion advantage." Their key results included a business metric: checkout conversion rate. They shipped their first optimization and conversion went up 2%. Then they noticed that the conversion improvement was only on desktop, not mobile. They pivoted, focused on mobile, and got another 5% improvement. Total revenue impact: $8M annually from a four-person team over one quarter.

The lesson: When you measure outcomes, you discover things you wouldn't have found by just shipping features and moving on.

Common Mistakes

Mistake 1: Too Many OKRs

If your organization has more than 5 objectives at any level, you have too many. I've seen companies with 15 objectives and 60 key results. Nobody remembers them. Nobody uses them. They become a compliance exercise instead of a focusing tool.

Three objectives is usually the sweet spot. Five is the maximum. If you can't fit your strategy into five objectives, your strategy isn't focused enough.

Mistake 2: OKRs as a Performance Evaluation Tool

The moment you tie individual performance reviews to OKR achievement, people will sandbag their key results. They'll set targets they know they can hit. The whole point of OKRs — setting ambitious goals and learning from what happens — dies.

OKRs are a planning and alignment tool. Performance evaluation should be about how people approach their work, the quality of their decisions, and their impact over time, not whether they hit an arbitrary number.

Mistake 3: Set-and-Forget

Setting OKRs in January and not looking at them until December is pointless. OKRs need to be reviewed regularly — monthly at minimum, weekly if possible. They should be a living part of how you make decisions, not a document gathering dust.

Mistake 4: Copying Google's System Exactly

Google popularized OKRs, but Google's implementation is designed for Google's specific culture and scale. Blindly copying their system (e.g., "70% achievement is the target") without understanding why they do it that way leads to confusion. Adapt the framework to your organization's culture and maturity.

Mistake 5: Bottom-Up Without Top-Down

Some organizations let every team set their own OKRs independently and then try to "roll them up" into a company strategy. This produces chaos. Cascading should be primarily top-down (company direction flows to teams) with bottom-up input (teams inform leadership about what's possible and what they're seeing on the ground).

Mistake 6: Ignoring the "Keep the Lights On" Work

Not everything fits neatly into OKRs. Production support, on-call, dependency upgrades, hiring — these are essential activities that need to be accounted for in your planning. If you pretend 100% of engineering time goes to OKR work, you'll consistently under-deliver. A realistic split is 60-70% OKR work, 30-40% operational and maintenance work.

Business Value

Strategic planning and OKRs aren't a management exercise — they're a resource allocation mechanism. Consider what's at stake:

A 100-person engineering team at an average fully-loaded cost of $250K per person represents$ 25M annually. Strategic planning is how you decide where that $25M goes.
If 20% of your engineering effort is going to projects that don't matter (a conservative estimate for poorly-planned organizations), that's $5M per year in wasted investment.
Companies that connect engineering goals to revenue targets consistently outperform those that treat engineering as a cost center. The difference shows up in faster time-to-market, better customer retention, and more efficient use of engineering headcount.
Well-cascaded OKRs reduce duplicate work, resolve conflicts earlier, and give teams autonomy within a clear framework. This isn't just about efficiency — it's about speed. And in competitive markets, speed is survival.

The director or VP who can articulate "here's our strategy, here's how it connects to revenue, and here's how we'll measure success" is the one who gets budget, headcount, and executive trust. The one who can't is the one whose team gets "right-sized."

Your planning process is your single biggest lever for organizational impact. Invest in it accordingly.

Common Pitfalls

Setting too many OKRs. Having more than five objectives at any level dilutes focus and turns the framework into a compliance exercise that nobody references in actual decisions.
Treating OKRs as a performance evaluation tool. Tying individual compensation to OKR achievement causes sandbagging, kills ambition, and defeats the purpose of stretch goals.
Planning in isolation from the business model. Writing engineering goals in purely technical terms without connecting them to revenue levers makes it impossible to defend budget and earn executive trust.
Confusing outputs with outcomes. Measuring "features shipped" instead of "customer behavior changed" leads teams to celebrate delivery without validating impact, wasting engineering investment.
Set-and-forget planning. Creating annual or quarterly plans and never revisiting them means you are executing on stale assumptions while the market moves around you.
Bottom-up planning without top-down direction. Letting every team set independent OKRs and rolling them up produces incoherent strategy and duplicated effort across the organization.

Key Takeaways

Strategy at the Director/VP level is about deciding what to do and what not to do -- saying no is the hardest and most important part.
Connect every engineering initiative to a specific revenue lever: acquire, retain, expand, reduce cost, or reduce risk.
OKRs are a focusing tool, not a tracking tool. Three objectives is the sweet spot; five is the maximum.
Key Results must be measurable outcomes, not outputs. Aim for 70% confidence when setting targets.
Cascade goals top-down with bottom-up input. Every engineer should be able to explain how their work connects to company strategy.
Plan at a level of detail that matches your uncertainty. Detailed quarterly plans, directional annual plans.
Reserve 30-40% of engineering capacity for operational and maintenance work that does not fit into OKRs.
The planning process itself is your single biggest lever for organizational impact.