Goal Decomposition, Resource Planning & AI Simulator

In Part 1, we covered the OP1/OP2 framework. In Part 2, we wrote SMART goals and team tenets. In Part 3, we traced every goal from the keyboard to the P&L.

Those posts answer the question: what should we work on and why does it matter? This post answers the harder question: what does it actually take?

SMART goals tell you where you're going. They don't tell you how many engineers you need, what skills they require, what it'll cost, or how long it'll realistically take. That's the gap this article fills — with a goal decomposition framework, a worked example, and an AI-powered simulator you can use right now. (Once goals are resourced, Part 5 covers how to track, review, and course-correct them.)

The Goal Decomposition Table

Every strategic goal from your OP1 should decompose into team-level SMART goals (OP2), and each of those should further break down into sub-goals with explicit resource requirements. The full picture looks like this:

This table is your bridge between strategy and resourcing. The OP Focus column traces each goal back to the planning cycle it originated from — was this a strategic bet from OP1 2025 that's now being executed in OP2 2026, or a new operational target that emerged directly in this year's OP2? Some goals span multiple cycles: Marketplace v2 appeared as a strategic bet in OP1 2025, was reaffirmed in OP1 2026, and is now being resourced in OP2 2026. That lineage matters — it shows which goals have sustained strategic conviction behind them versus which are new bets.

The rest of the table flows left to right: strategy to resourcing. The right side is what your finance and HR partners need. The middle is where the work gets real.

How to Fill Each Column

The table looks straightforward. Filling it accurately is where most teams struggle. Here's how to estimate each column without making it up.

Skills Required

Map to your organisation's role taxonomy. Don't write "engineer" when you mean "senior backend engineer with distributed systems experience." The more specific you are, the better your resource plan will hold up against reality.

Headcount & Capacity

These are two different numbers and confusing them is one of the most common planning errors.

• Headcount (HC) is the number of people assigned to the work. "3 engineers" means three humans.
• Capacity % is how much of each person's time this work gets. 80% means they spend roughly 4 days a week on this goal, with the remaining 20% going to on-call, tech debt, meetings, or other commitments.

The product of these two numbers gives you FTE (full-time equivalent). 3 people at 80% = 2.4 FTE. This is the number your finance team and resource planners actually need.

What You Say	What It Actually Means	FTE
"I need 3 engineers"	3 people, assumed 100% capacity	3.0
"I need 3 engineers at 80%"	3 people, each dedicating 4/5 of their time	2.4
"I need 1.5 FTE"	Could be 2 people at 75%, or 3 at 50%	1.5

Always state both numbers. "I need 3 engineers" is ambiguous. "I need 3 engineers at 80% capacity for 8 weeks" is a plan.

Cost to Serve

This isn't just salary. Fully loaded cost includes:

• Salary — gross annual compensation
• Benefits & employer costs — social contributions, health insurance, pension. In the EU, this typically adds 25–40% on top of gross salary.
• Tooling & licences — IDE licences, SaaS tools, cloud development environments
• Infrastructure — cloud compute, staging environments, CI/CD costs attributable to this work

A reasonable rule of thumb for European tech companies: fully loaded monthly cost per engineer ≈ €8–12K depending on seniority and location. Multiply by FTE and duration to get Cost to Serve.

Cost to Serve = (FTE × Fully Loaded Monthly Rate × Duration in Months) + Direct Tooling/Infra Costs

P&L Traversal

Every goal should trace back to a line on the P&L. The path goes:

1. Team goal → what metric does this directly move? (e.g. deployment time, churn rate, support ticket volume)
2. Department metric → what operational outcome does that contribute to? (e.g. faster activation, higher retention, lower support cost)
3. Business unit metric → what financial metric does that operational outcome affect? (e.g. ARR growth, gross margin improvement)
4. P&L line → which financial statement line item does this ultimately land on?

The four most common P&L lines your goals will map to:

P&L Line	What It Covers	Goal Examples
Revenue	Income from customers — subscriptions, services, transactions	Grow ARR, increase conversion, launch new product
COGS	Cost of Revenue — hosting, support, delivery costs directly tied to serving customers	Automate support, reduce infra per-customer cost
OpEx	Operating Expenses — R&D, S&M, G&A that aren't directly tied to revenue delivery	Consolidate tooling, improve developer productivity
CapEx	Capital Expenditure — long-lived assets, major platform investments	Build new platform, major infrastructure migration

If you can't map your goal to one of these, either the goal is too abstract or the connection hasn't been made explicit. Go back to Part 2's alignment chain and work the path from the bottom up.

The Goal Alignment Checklist

Once your goals are individually sound (see the refinement checklist in Part 2), the next failure mode is misalignment between goals. A team review of each other's goals catches problems that no individual can spot alone.

Alignment Problem	What It Looks Like	How to Fix
Too many measures for one objective	10+ unique measures all aligning to the same strategic goal. Creating reports for all of them costs more than the data is worth and dilutes employee focus.	Select 1–2 measures to use across the team. Ask: which measure best captures what we're trying to achieve? Which is practical to track?
Gaps in measurement	A manager has goals aligning to four of their director's objectives, but the team below only has goals aligning to two of them. Two objectives have no one working on them.	Decide if the gaps are intentional. If not, create goals to fill them or assign existing team members to cover the missing objectives.
Cross-department dependency without agreement	A goal requires an HR employee survey and significant IT resources to implement, but neither HR nor IT has budgeted for this work.	Any goal requiring significant cooperation across departments must appear on all parties' priority lists. Discuss, agree on resources, and escalate if they can't be found.
Misaligned timelines or quality criteria	Dept A plans to finish a new system in Q2. Dept B (which depends on it) has set goals assuming it's operational in Q1. If A meets its deadline, B still misses theirs.	Align both goals so both teams can succeed. Surface dependencies explicitly in your decomposition table and validate them across teams.
Redundant or overlapping work	A production team builds its own design capability "just in case" the design department is late — duplicating resources that could be deployed elsewhere.	Eliminate overlapping work. If the redundancy exists because of trust issues, fix the trust problem — don't resource around it.

AI Goal Simulator

Theory is useful, but practice is better. Use the simulator below to decompose any goal into sub-goals, resource estimates, and P&L mapping. Describe your goal, set your constraints, and the AI will generate a structured resource plan.

---

Final Thought

Goal planning without resource planning is just aspiration. The decomposition table forces you to confront what every goal actually costs — in people, in time, in money — and connect that cost to a financial outcome the business cares about.

If you can look at your team's goals and trace every one from the sub-goal level, through HC and cost, all the way up to a P&L line — you have a plan. If you can't, you have a wish list. The difference is what separates teams that deliver from teams that are merely busy.